BUG? - Issues with "notification count" for escalation

[frakka (Matteo Fracassetti)]

@andreas-doehler

I think this is not easily achievable. The problem here is the following.

The core logic

State change from OK → WARN - the core triggers the first notification (Nr.1) - the core sends this to the notification subsystem and don’t knows if there is are real notification going outside.
Next state change from WARN → CRIT - for the core this is the second notification for this problem.
And so on until the service reaches again the OK state. Then all starts again from 0.

I’m not a developer so I don’t understand how much difficult is but I think that those counters should be incresed by the notification subsystem and not by the core (or that a different counter should exists if “SERVICENOTIFICATIONNUMBER” and “HOSTNOTIFICATIONNUMBER” are used even for other use).
In this way is very difficult (impossible I think) to configure a reliable escalation procedure based on notification numbers because those counters dont’ count the “notifications” but the “state transitions” of the services.

@andreas-doehler

With the rule “Notified events for services” you can define on a per service basis what should be notified directly from the core.

Ok but If I disable (for example) the notification for transition to warning state I loss this events also on the checkmk dashboard, right? And this rule is not configurable on time periods basis.

@andreas-doehler

I don’t know how it counts with a status change like - ok → warn → crit - > warn → crit

I’ll try.