State Stalking and notifications

[Frost, Mark {PBG}]

On more than a few occasions, I've had users ask me if it's possible to
have alerts sent if the output of a check changes.  That is, if you
consider that a check might actually have multiple failure conditions it
could be monitoring.  And example of this might be a single command you
run that reports about multiple aspects of an application.  The check
goes critical if one part of that app becomes non-functional, but if a
second piece goes off-line, the state of the check hasn't changed, so no
notification is sent.

I read about "state stalking" and thought that this might be what I was
looking for.  However, after reading a bit more closely, it appears that
what state stalking is really about is logging results of checks and not
about sending additional notifications.

I understand the philosophy of "well if one part is broken or two parts
are broken, you have to fix it anyway".  There's also the hack of having
recurring notifications sent (say every 30 minutes) which should send a
user the latest check output.  Neither of those options are particularly
nice for us.  I had thought about writing a custom check for each line
of output that this command generates, but that seems needlessly
painful.

I see that volatile checks are more about notifications, however they
will send a notification every time the service comes back non-OK (i.e.
even if the check output is exactly the same) which is not what we want.

I'm guessing the answer here is "Nagios can't do that", but I thought
I'd ask anyway.

Thanks

Mark

-------------------------------------------------------------------------
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/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null