[Icinga-devel] Introducing a soft-OK state

Wolfgang wnd at gmx.net
Wed Sep 19 17:17:18 CEST 2018

AFAIK a soft state is (should be) entered when an object changes from an 
UP/OK to a non-ok state and changes to a hard state when the max check 
attempts are exceeded or the object returns an UP/OK return code.

A notification might be sent when a hard state is reached.

You might have tested some things prior to looking at the code. Sharing 
that will probably enable others to confirm your findings.

Am 19.09.2018 um 16:45 schrieb Edgar Fuß:
> Is this list alive? If not, what's the preferred way to discuss topics like this?
> I'm working on introducing a soft-OK state. I have services that intermittently report OK despite being non-OK (in case someone cares: printers where Alerts vanish from the prtAlert table for a few seconds to re-appear at another position) and I guess such a feature would be useful in general.
> The idea is to add a min_recover_attempts attribute to a Service object, defaulting to 1.
> The place to add the logic (minus introduction of the attribute, documentation etc.) is Checkable::ProcessCheckResult().
> However, the logic in there is convoluted beyond belief. I ended up with a table listing all the possible state transitions and corresponding values of bool variables and if conditions.
> Some of the expressions are overly complicated, some useless, some harmful, some don't match the comments.
> Worst example (yet):
> if (IsStateOK(old_state) && old_stateType == StateTypeSoft)
> 	send_notification = false; /* Don't send notifications for SOFT-OK -> HARD-OK. */
> 1. There is no such thing as soft OK (yet).
> 2. If there were a soft OK state, the expression would supress notifications for soft OK -> hard CRITICAL
> 3a. For non-volatile checkables, send_notification would be false anyway for soft OK -> hard OK (it's false for any soft -> OK transition)
> 3b. For volatile checkables, send_notifications is set to false for any OK -> OK transition just below.
> So, before adding a soft-OK state I would like to clean up that logic.
> However, for some conditions, I'm unsure what the intended behaviour is.
> I'd also like someone to double-check my corretions.
> _______________________________________________
> icinga-devel mailing list
> icinga-devel at lists.icinga.org
> https://lists.icinga.org/mailman/listinfo/icinga-devel

More information about the icinga-devel mailing list