<p dir="ltr"><br>
On 12 Dec 2012 19:10, "Jochen Bern" <<a href="mailto:Jochen.Bern@linworks.de">Jochen.Bern@linworks.de</a>> wrote:<br>
><br>
> On 11.12.2012 22:56, Jim Avery wrote:<br>
> > We want to send an SMS notification if the UPS goes on to battery, but only<br>
> > if it has been on battery for more than, say, five minutes.  I had hoped<br>
> > that first_notification_delay would give me that possibility.  Obviously as<br>
> > this is a passive check [...]<br>
> ><br>
> > Please forgive me that I don't understand the programmatical issues well<br>
> > enough to see if any of the proposed solutions so far will fit this use<br>
> > case.<br>
><br>
> I'ld say that our discussion is perpendicular to the issue you raise -<br>
> or, in other words, that first_notification_delay is unlikely to<br>
> suddenly work the way you want afterwards.<br>
><br>
> You see, while everyone just calls it "passive checks", the terminology<br>
> in the web UI - "active checks disabled" - is more correct. (Yes, a<br>
> service *could* have active *and* passive check results going into it.<br>
> I've just never seen a working setup doing that, or a use case seriously<br>
> asking for it.) Using "passive checks" means that Nagios can forget<br>
> about scheduling commands for that service, ever; waiting for events and<br>
> reacting to them is all that's required.<br>
><br>
> Asking that Nagios now *should* schedule a notification being sent<br>
> first_notification_delay after receiving a non-OK passive result sort of<br>
> negates the entire concept.<br>
><br>
> What I'ld try in your place is to write the (last) trap into a cache<br>
> file, and then run an *active* check looking for the reported state *and<br>
> timestamp*, possibly differentiating WARNING/CRITICAL based on the latter.<br>
>                                                                 J. Bern</p>
<p dir="ltr">Thanks Jochen,</p>
<p dir="ltr">yes it's probably unreasonable of me to expect the notification logic to become so far divorced from the active check scheduler given that we are where we are.  And to be honest in my environment there is only (currently) this one particular case where it's an issue, crafting a plugin to do pretty much what you suggest shouldn't be a Big Deal.</p>

<p dir="ltr">In fact your comment about mixing active and passive checks got me thinking I could probably have Nagios actively check the relevant OID every few minutes as well as receiving the passive traps.   I would then get all of the events properly logged, but also would be able to delay the notification by setting max_check_attempts and check_frequency appropriately or even better use a service escalation so short-duration events can be notified by email but longer duration events notified by SMS too.</p>

<p dir="ltr">Cheers, and thanks again,</p>
<p dir="ltr">Jim</p>