Re: [Nagios-devel] Extending Nagios Beyond Monitoring
Posted: Sun Mar 02, 2008 5:44 pm
Hi Jon,
> -----Original Message-----
> From: [email protected] [mailto:nagios-devel-
> [email protected]] On Behalf Of Jon Buys
> Sent: Friday, February 29, 2008 10:25 AM
> To: [email protected]
> Subject: [Nagios-devel] Extending Nagios Beyond Monitoring
>
> Hello,
>
> I've had an idea, and I thought I'd run it past this list to see what
> came from it. I'm looking at a configuration and patch management
> solution, so naturally I've been looking at cfengine, bcfg2, and
> puppet. Each of these has its own positive and negative features, but
> after looking at them what struck me most was the similarity to
> Nagios.
>
> It seems to me, that at it's core, Nagios simply checks the "state" of
> something (an object?), and reports back, then depending on the state
> of the object that was checked, it runs another script, normally a
> page or email script. However, I don't think it needs to be an email
> script. I've been thinking that I could have nagios compare something
> like conf files against a central repository, and if it finds that a
> file on a remote machine is not in sync, run a script to correct the
> file.
>
> I imagine this concept could be extended to include patches: check
> the existing rpm version against the version in a central repository,
> if it is out of date run the rpm -U to update the rpm (adjust to suit
> your distro).
>
> I understand that this is outside the core concept of Nagios as a
> monitoring server, something that it does extremely well. However, in
> our situation, we already have an existing Nagios infrastructure,
> would it be more worthwhile to extend Nagios or to build an entire new
> infrastructure for yet another management tool?
>
> So, what do you think?
We have about 3-dozen Linux servers at various client sites, and are faced
with an overwhelming task of keeping all of those machines running our
standard configuration files and packages. At this point, it's been very
manual.
We've considered something similar to what you're suggesting in leveraging
Nagios to help with the task, but at this point, the idea is only in the
planning stages. We did briefly experiment with keeping NRPE configurations
up to date this way on our clients' Windows servers, and that went fairly
well, but we've stopped using NRPE on those boxes so we didn't pursue the
project further.
- Brock
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> -----Original Message-----
> From: [email protected] [mailto:nagios-devel-
> [email protected]] On Behalf Of Jon Buys
> Sent: Friday, February 29, 2008 10:25 AM
> To: [email protected]
> Subject: [Nagios-devel] Extending Nagios Beyond Monitoring
>
> Hello,
>
> I've had an idea, and I thought I'd run it past this list to see what
> came from it. I'm looking at a configuration and patch management
> solution, so naturally I've been looking at cfengine, bcfg2, and
> puppet. Each of these has its own positive and negative features, but
> after looking at them what struck me most was the similarity to
> Nagios.
>
> It seems to me, that at it's core, Nagios simply checks the "state" of
> something (an object?), and reports back, then depending on the state
> of the object that was checked, it runs another script, normally a
> page or email script. However, I don't think it needs to be an email
> script. I've been thinking that I could have nagios compare something
> like conf files against a central repository, and if it finds that a
> file on a remote machine is not in sync, run a script to correct the
> file.
>
> I imagine this concept could be extended to include patches: check
> the existing rpm version against the version in a central repository,
> if it is out of date run the rpm -U to update the rpm (adjust to suit
> your distro).
>
> I understand that this is outside the core concept of Nagios as a
> monitoring server, something that it does extremely well. However, in
> our situation, we already have an existing Nagios infrastructure,
> would it be more worthwhile to extend Nagios or to build an entire new
> infrastructure for yet another management tool?
>
> So, what do you think?
We have about 3-dozen Linux servers at various client sites, and are faced
with an overwhelming task of keeping all of those machines running our
standard configuration files and packages. At this point, it's been very
manual.
We've considered something similar to what you're suggesting in leveraging
Nagios to help with the task, but at this point, the idea is only in the
planning stages. We did briefly experiment with keeping NRPE configurations
up to date this way on our clients' Windows servers, and that went fairly
well, but we've stopped using NRPE on those boxes so we didn't pursue the
project further.
- Brock
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]