Nagios acknowledgement enhancement request

Thomas Guyot-Sionnest dermoth at aei.ca
Thu Nov 13 19:04:47 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Ivanov wrote:
>> Date: Wed, 12 Nov 2008 18:22:23 -0500
>> From: Thomas Guyot-Sionnest <dermoth at aei.ca>
>> Subject: Re: [Nagios-devel] Nagios acknowledgement enhancement request
>> To: Nagios Developers List <nagios-devel at lists.sourceforge.net>
>>
>> On 12/11/08 04:45 PM, Jim Winkle wrote:
>>> Hi,
>>>
>>> I have a suggestion for a future enhancement of Nagios.
>>>
>>> In short, I'd like there to be a way to have Nagios send
>> notifications
>>> until we acknowledge a problem -- for certain unique
>> plugins -- without
>>> ignoring future problems. Background and more details follow.
>>>
>>> We're using the check_logfiles plugin to monitor syslogs (e.g.
>>> /var/adm/messages on Solaris). check_logfiles returns
>> CRITICAL when it
>>> detects a problem, but then normally clears itself (returns
>> OK) the next
>>> time it runs.  Nagios notifies us only once under this
>> scenerio, and since
>>> it's possible that pagers might miss just one page (paging
>> services aren't
>>> 100% reliable), we'd rather get notified until we
>> explicitly acknowledge
>>> the problem.
>>>
>>> The check_logfiles plugin does have the capability to
>> continue to report the
>>> error (using its "sticky" option). This is good since then
>> we're notified
>>> longer, but if we then use the Nagios "Acknowledge" link to
>> acknowledge the
>>> problem, new problems (e.g. new errors in
>> /var/adm/messages) reported by the
>>> check_logfiles plugin get ignored.
>>>
>>> I asked on the nagios-users list if there was a way to
>> acknowledge a problem
>>> reported by a plugin like check_logfiles without ignoring
>> future problems.
>>> Nobody came up with a way, so I assume this is new
>> functionality needed in
>>> Nagios.
>>>
>>> I realize we can syslog an "okpattern" string and
>> check_logfiles will then
>>> clear, but I'm looking for something using the Nagios web
>> (and external
>>> command_file) interfaces. Using the Nagios "Acknowledge"
>> link would be ideal,
>>> since that's what folks are going to be using to
>> acknowledge other problems.
>>> I'm using Nagios version 3.0.5 and check_logfiles version
>> 2.4.1.3. We configure
>>> check_logfiles as a volatile service and use state staulking.
>>>
>>> Thanks for providing these great tools! Please let me know
>> if something doesn't
>>> make sense or if I'm missing something.
>> You could most likely achieve what you want with adaptive monitoring.
>> When the service goes to HARD CRITICAL, run an event handler
>> that change
>> the service command to a dummy critical check. To change it back you
>> could either submit a passive check that triggers the event handler to
>> re-apply the check command, or use a dummy contact whose notification
>> command do it upon receiving an acknowledgement.
>>
>> - --
>> Thomas
> 
> Hi,
> 
> I also have a similar problem with logfile monitoring and suggest to
> implement some kind of "aknowledgement handler".
> In this handler you can do everything you need to process the error.

I agree it would be a nice thing to have event handlers being fired off
on every command received by a host/service (available as an option to
avoid breaking current handlers), though in this specific case
(acknowledgments) you could have a dummy user whose notification command
is your handler, and upon receiving an acknowledgment you can do
whatever you want.

At the same time it would be nice to have a global event handler command
option for every command unrelated to a specific host/service (there are
already global handlers options for host and services). Besides the
million of things that would be done with it, it could also be used for
command auditing. Combined with http access-logging, it can be very easy
to see who sent a command and when.

- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJHGw/6dZ+Kt5BchYRAoH0AKCGoy517MN6Stdn6LK+eCFaRkP4BwCg1+/5
OAIRPDE9r01yOcPcHJjArD0=
=+2B6
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/




More information about the Developers mailing list