[icinga-users] Requiring multiple successful plugin runs to return to OK state?

Wolfgang wnd at gmx.net
Tue Jul 10 20:52:49 CEST 2018

Looking at the Icinga 1.x documentation ("5.8.4 Hard states", 
it says:

Hard states occur for hosts and services in the following situations:


    When a host or service check results in a non-UP or non-OK state and
    it has been (re)checked the number of times specified by the
    /max_check_attempts/ option in the host or service definition. This
    is a hard error state.


    When a host or service transitions from one hard error state to
    another error state (e.g. WARNING to CRITICAL).


    When a service check results in a non-OK state and its corresponding
    host is either DOWN or UNREACHABLE.


    When a host or service recovers from a hard error state. This is
    considered to be a hard recovery.

I'd say that the behaviour hasn't changed so returning to an OK-state 
will result in a HARD state.

Am 10.07.2018 um 18:55 schrieb Edgar Fuß:
> In order to move to a hard non-ok state, a service can require multiple (i.e. max_check_attempts) unsuccessful runs of the check plugin.
> Is there a way to require multiple successful plugin runs in order to return to a (hard) ok state?
> I have printers where, if toner is low (not empty), from time to time, the 1104 entry vanishes from the Printer Alert Table for several seconds, only to return at another index shortly after.
> As I'm using a combination of SNMP traps and table polling, the trap sent upon removal immediately make my printer-toner service switch to OK, after which it takes some time (one trap sent upon table re-apperance and two polls) to return to WARNING. Even if I remove traps from the equation, my table poll may happen during the some-second period the 1104 is gone.
> I do know about flapping, but that's not what I want. I want protection from transient success, like I'm protected from transient failures.
> _______________________________________________
> icinga-users mailing list
> icinga-users at lists.icinga.org
> https://lists.icinga.org/mailman/listinfo/icinga-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.icinga.org/pipermail/icinga-users/attachments/20180710/1c4e975d/attachment.html>

More information about the icinga-users mailing list