die Anfrage ist wahrscheinlich nur eine Kleinigkeit;
wir haben Windows-Systeme, die in unregelmäßigen Zeiten neu starten.
Aufgrund das Windows-Dienste überwachte werden, werden diese in unserem Dashboard natürlich sofort angezeigt, dass diese nicht verfübar sind und werden als “CRIT” oder “WARN” angezeigt.
Das Ziel ist, wenn diese Systeme neu starten, dass die Benachrichtigungen für alle Services, also Windows-Dienste, Ping, usw. erst nach 15 Minuten auf “CRIT” gehen, wenn in dieser Zeit die Services nicht wieder in dieser Zeit gestartet wurden. Ich habe das schon in “Normal check interval for service checks” eingestellt, dass scheint aber nicht zu funktionieren.
Es sollen aber keine Benachrichtigungen als Mail o.ä. versendet werden, es geht lediglich die Anzeige im Service-Dashboard.
Das lässt sich nicht ändern. Wenn Checkmk feststellt, dass ein Service CRIT ist, ist natürlich auch die Anzeige CRIT.
Das einzige, was sich verzögern lässt, ist die Erzeugung von Notifications (mit “Maximum number of check attempts” z.B.). Dann ließe sich in der Anzeige auch nach Soft und Hard State filtern.
die Richtlinien habe ich auch bereits verwendet, bin aber nicht zum eigentlichen Ergebnis gekommen. Betrifft das nicht eher die “Benachrichtigung” wenn Alerts verwendet werden, also, wenn ein Service nicht mehr “Ok” ist, wird erst später z.B. eine Mail an den Kontakt versendet?
Ja. Wie Robert schon sagte, kommst Du um das Crit in der GUI nicht rum. Das einzige was noch ginge, wäre eine View zu erstellen, die Problem Services darstellt und auf “service state type” = hard gefiltert ist. Den Hard State kann man mit “Maximum number of check attempts” verzögern.
Falls der “unregelmäßige Restart” der Windows Systeme nicht total ungeplant ist, könntest du das System selbst (oder von einem dritten System, dass auch den Reboot triggert) natürlich für jeden Reboot noch eine 15 Minuten Downtime auf den jeweiligen Host setzen. Dann werden die Probleme aus der GUI ausgeblendet. (Also zumindest von allen typischen Dashboards/Problem views)
Wurde hier erst vor kurzem besprochen: Downtime per API
Der Neustart ist ungeplant. Es handelt sich um Citrix VDI-Systeme, 24x7, die nach einer Abmeldung des Anwender grundsätzlich neu starten, damit diese Systeme für die nächsten Anwender in einem bereinigten Zustand wieder zur Verfügung gestellt werden. Und da die Dienste hier ein paar Minuten länger brauchen, und ggf. auch mehrere Maschinen neu starten, z.B. wenn eine neue vDisk zur Verfügung gestellt wird, sieht das Service-Dashboard entsprechend aus. Und das wollte ich somit vermeiden.
ok dann wirds schwierig falls der Mechanismus der nach dem Logout des Users den Reboot ausführt nicht durch Scripte erweitert werden kann. Ginge das?
Alternative: du baust für die Hosts recurring downtimes, z.B. alle 2 Stunden für 2 Stunden (oder auch 24x1h in 24 Regeln) in der du die Flexible Downtime von 15 Minuten einträgst, dann ist der Host ab dem Moment wo er DOWN geht für 15 Minuten in Downtime. Und das darf dann 1x pro Stunde passieren. (Hinweis: recurring downtimes sind ein CEE feature, der Nagios Core kann das leider nicht.)
die Alternative kommt etwa in die Richtung, was das eigentliche Ziel war,
ich werde das mal für einen Zeitraum versuchen auf Basis “Host”.
Ist meine Vermutung richtig, wenn die Richtlinie aktiviert wird, die Verfügbarkeit der betroffenen Systeme, etwas verfälscht wird, wenn diese in dem Zeitplan nicht gebootet werden? Immerhin stehen diese ja dann als “Down” obwohl diese ja eigentlich “Ok” wären.
nein die Verfügbarkeit ist davon nicht betroffen, denn die flexible Downtime ist quasi nur eine Downtime in Bereitschaft, diese wird erst aktiviert wenn der Host auf DOWN wechselt. Solang dein Host UP ist, wird also jeder Service alert regulär erfasst.
Ab dem Down Moment greift dann die flexible Downtime für die definierte Länge auf den Host + implizit somit seine Services.
Allerdings habe ich die Anpassungen in Recurring downtimes for services gemacht. Repeat und duration auf eine Stunde, Flex auf 15 Minuten. Die Services sind zwar im ersten Moment auf CRIT, gehen aber dann nach einem kurzen Moment auf Downtime. Aber kommt der eigentlichen Anforderung sehr nahe!!
