Understanding "Maximum number of check attempts for host / service"

Hello,

Let’s assume, both numbers have been set to 2. The manual reveals, that the first check with the result “critical” does not lead to an alarm (instead the host / service is considered to be in a “soft critical” state). What does it actually mean?

Presumably there will be no notification (in our case sending of an email). But … does the web frontend of Check_MK reveal the soft critical state of the host or service? Or is it skipped as well? Does it appear green? There is a chance, that Check_MK differentiates in between hosts and services regarding that.

What about services, whose first checks lead into a warning state? Is there a “soft warning state” as well? As the case may be … how are these treated by Check_MK? To make it short: Do the abovementioned rules have any impact in terms of delaying the revelation of services’ warning states?

Much thanks in advance!

Best regards,
Andreas

Hi @sysadminad and welcome to the check*mk** community.

Yep, you got it right. A soft state is not notified by the system. In your views you can decide if you like to show the soft or hard state of your hosts/services.

The major reason for this is, as you expected, to delay notifications, because some josts or services can get one check run bad but the next one is good again. You don’t want to bother your people that much with notifications.

2 Likes

Much thx for your quick response, tosch! What about the possibilitiy of the abovementioned rules having an impact in terms of delaying the revelation of services’ warning states? Or to put it differently … are these rules about critical host/service states only? Best wishes, Andreas

Antworten in Deutsch sind mir grundsätzlich auch genehm. :wink:

Hallo,

Deutsch ist auch schön :stuck_out_tongue_winking_eye:

Also generell gibt es sowohl für Hosts als auch für Services soft- und hard-States. Die Rules können also sowohl für Hosts als auch für Services unterschiedlich eingestellt werden.

Und ja, diese Rules verzögern generell die Alarmierung, aber man muss auch die Rules der Zeitabstände für die Host-, bzw. Service-Checks beim Fehlerfall (Retry check interval for service checks, Retry check interval for host checks) beachten, die ebenfalls einen Einfluss haben.

Wir schweifen ab. :wink: … Freilich gibt es noch weitere Einstellmöglichkeiten. Ich würde aber gern erst einmal die vorbenannten im Detail verstehen. Und aktuell weiß ich nicht darum, wie es sich mit Diensten verhält, die eben nicht kritisch eingestuft werden - sondern lediglich eine Warnung ausgegeben wird. Werde diese Zustände von den oben benannten Regeln erfasst, oder nicht? Selbst im Handbuch wird immer nur von kritischen Systemzuständen gesprochen - “soft critical”, “hard critical”. Aber was ist mit “soft warning”, “hard warning”? Gibt es solcherlei?

Viele Grüße
Andreas

Es gibt auch die WARN States als soft-states, das ist korrekt. Nur bei bei STALE oder OK gibt es diese nicht, das sind immer hard-States.

Also auch wenn dein Service oder Host in WARN wechselt, wird dieser von den Regeln, die du eingangs erwähntest, beeinflusst.

1 Like

Ich bedanke mich sehr für die Klarstellung. Viele Grüße, Andreas

Keine Ursache, immer wieder gerne bei Unklarheiten.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.