How to handle 'single bad' or 'trap' messages?

Steve Shipway s.shipway at auckland.ac.nz
Wed Feb 9 21:36:38 CET 2005


>We have the requirement of handling what I call a 'single bad' message.
>When such an event happens, somebody would need to aknowledge 
>the message and the status should turn to OK.

We handle this one of two ways (depending on the needs).

1. Set up passive service, which receives the alerts.  Have state stalking
on the criticals.  max_check_attempts is 1.  Check_period is never.  We also
set up a freshness check with a 2-hour timeout that calls a script returning
an 'OK'.  This makes all alerts disappear after 2 hours of silence.  This is
OK in some cases (if you havent heard anything for a certain period of time,
assume it's OK) but not others.

2.  Set up a passive service, with critical state stalking.  When people go
to acknowledge the alert, it gets the normal 'man at work' icon.  When the
problem is solved, you go in again and submit a manual passive 'OK' to reset
the state.  This is better when you don't want the state to clear until
you've done the task.

By using (1) and a lower freshness threshold and >1 max_check_attempts, you
can make an SNMP trap sink which will show an alert provided it is currently
receving more than X alerts within a set time period.  This is handy to
alert if we start getting a flurry of failed login attempts (each triggering
a SNMP auth trap) but not alert for just a single one where I mistype the
password.

Steve



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
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





More information about the Users mailing list