Getting re-notified while in a HARD state

[Paul M. Dubuc]

Frank Bulk wrote:
> I have a few existing and self-developed plugins that output details of the
> HARD state:
>
> 	CRITICAL: critical 1, warning 1
> 	Detail 1
> 	Detail 2
>
> What I'd like to do is to be able to be re-notified if, while in the HARD
> state, the number and/or details change.  For example, if the above would go
> to:
>
> 	CRITICAL: critical 2, warning 1
> 	Detail 1
> 	Detail 2
> 	Detail 3
>
> Anyone have an approach that works?  The documentation doesn't indicate it's
> possible, but I'm sure others have encountered this before and perhaps
> they've worked through a solution.
>
> Kind regards,
>
> Frank

I don't think there's a simple way to do this without having your notification 
command store the value of the $SERVICEOUTPUT$ macro for the host + service 
for comparison on the next try. Then you would have to set is_volatile on the 
service and have the notification command suppress the notification if the 
$SERVICEOUTPUT$ doesn't change.

Another thing you can do is tell Nagios to log the hard state status when only 
the $SERVICEOUTPUT$ changes by setting the stalking_options in the service. 
Then, if you have something that watching the log file you can trigger 
notifications with that.  If only this state stalking feature would have an 
option to send notifications in addition to logging you would be set.

Hope this helps,
Paul Dubuc

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
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