Extending Nagios Beyond Monitoring

[Limburg, Mark (SAPOL)]

Howdy Jon,

I must say, I think you've hit the nail on the head.  It is in the core
business of Nagios to "react" when a flag is noted, and the atypical
response is to send of it's alerts.  Plenty of us tweak the scripts to
suit our own environments, and many of us have augmented our scripts to
do some smarts.

Simple example, there are often a number of "typical" things that a
sysadmin does when an alert comes through.  Is the process stuck, what
exactly is up and down, etc.  On many of our simple checks, we do
automated fixing.  If (when) a java process hangs, I run through a
standard set of actions to see if I can save it, and if I can't, then I
have to kill it.

So long as the script goes through those checks, then there's no reason
why it can't do just the same thing.

Your idea extends the same concept.  Find a state that a script can
react to, and do it.

The key question would be, in my eyes, how to build on Nagios to track
these actions .. or perhaps, is there another engine that it could hook
into?

Just thinking out loud.

M

-----Original Message-----
From: nagios-devel-bounces at lists.sourceforge.net On Behalf Of Jon Buys
Sent: Saturday, 1 March 2008 3:55 AM

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.

<snip>

-------------------------------------------------------------------------
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/