Extending Nagios Beyond Monitoring

Brock Kuhse brock at kuhsefamily.org
Mon Mar 3 02:44:18 CET 2008


Hi Jon,

> -----Original Message-----
> From: nagios-devel-bounces at lists.sourceforge.net [mailto:nagios-devel-
> bounces at lists.sourceforge.net] On Behalf Of Jon Buys
> Sent: Friday, February 29, 2008 10:25 AM
> To: nagios-devel at lists.sourceforge.net
> 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 SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/




More information about the Developers mailing list