No, the expectation with Icinga is that once a check has failed (by which I
mean, it has a warning or critical result, rather than OK), and that has
happened for max_check_attempts times, the alert is raised.
Why would you not want to know about an alert once you’ve decided (from
max_check_attempts) that it’s a genuine alert?
Alternatively, if you don’t want to know about it, surely it’s not (yet)
anything real, so you should increase max_check_attempts so that you wait
longer before deciding it’s a real thing to be dealt with?
the max_check_attempts defines after how many check attempts a new hard state is reached.
I would like to setup for e.g. that it should be checked 5 times before it enters in the soft state.
The point is that I use a shell plugin, I wrote myself, to check whether updates are available for the clients. The updates are carried out with unattended upgrades. Unattended upgrades carries out the updates a little delayed and as a result I have warnings in Icininga in the soft state that I do not want. Only when the update e.g. after a day it was not installed I want a warning in Icinga.
It’s all about that no unnecessary update warnings are displayed in Icinga.
If that does not work, that the soft state can be delayed, there is another possibility that warnings for existing updates for the clients only e.g. be displayed after a day?