Die grundlegenden Tätigkeiten von Service-Prüfungen werden hier beschrieben...
Services werden durch den Icinga-Daemon geprüft
in regelmäßigen Intervallen, wie sie durch die check_interval und retry_interval-Optionen in Ihren Service-Definitionen festgelegt sind.
nach Bedarf bei vorausschauende Host-Abhängigkeitsprüfungen.
Prüfungen nach Bedarf werden als Teil der vorausschauenden Service-Abhängigkeitsprüfungs-Logik durchgeführt. Diese Prüfungen helfen sicherzustellen, dass die Abhängigkeitslogik so genau wie möglich ist. Falls Sie die Service-Abhängigkeiten nicht nutzen, wird Icinga keine Service-Prüfungen nach Bedarf durchführen.
zwischengespeicherte Service-Prüfungen (cached service checks)
Die Performance von Service-Prüfungen nach Bedarf kann signifikant durch den Einsatz von "cached checks" erhöht werden, die es Icinga erlauben, auf eine Service-Prüfung zu verzichten, wenn es feststellt, dass ein relativ frisches Prüfungsergebnis genügt. Cached checks werden nur dann einen Performance-Gewinn ergeben, wenn Sie Service-Abhängigkeiten nutzen. Mehr Informationen zu "cached checks" finden Sie hier.
Sie können Service-Ausführungs-Abhängigkeiten definieren, die Icinga von der Statusprüfung eines Service abhalten in Abhängigkeit vom Status ein oder mehrerer anderer Services. Mehr Informationen zu Abhängigkeiten finden Sie hier.
Geplante Service-Prüfungen laufen parallel. Wenn Icinga eine geplante Service-Prüfung ausführt, wird es die Service-Prüfung veranlassen und dann zu anderen Arbeiten zurückkehren (Host-Prüfungen ausführen, etc.). Die Service-Prüfung läuft in einem Kind-Prozess, der vom Haupt-Icinga-Prozess aufgerufen wird ("fork()ed"). Wenn die Service-Prüfung beendet ist, wird der Kind-Prozess den Haupt-Icinga-Prozess (seinen Eltern-Prozess) über das Ergebnis informieren. Der Haupt-Icinga-Prozess wird dann das Prüfungsergebnis behandeln und geeignete Aktionen durchführen (Eventhandler starten, Benachrichtigungen senden, usw.).
Service-Prüfungen nach Bedarf laufen ebenfalls parallel, falls notwendig. Wie bereits vorher erwähnt kann Icinga auf die eigentliche Ausführung einer Service-Prüfung nach Bedarf verzichten, wenn es das gespeicherte Ergebnis einer relativ frischen Service-Prüfung benutzen kann.
Services, die geprüft werden, können in einem von vier unterschiedlichen Zuständen sein
OK
WARNING
UNKNOWN
CRITICAL
Service-Prüfungen werden mit Hilfe von Plugins durchgeführt, die den Status OK, WARNING, UNKNOWN oder CRITICAL zurückliefern können. Diese Return-Codes der Plugins werden direkt in die Service-Zustände übersetzt. Beispielsweise wird das WARNING-Ergebnis eines Plugins zu einem WARNING-Status eines Service führen.
Wenn Icinga den Status von Services prüft, ist es in der Lage festzustellen, wenn ein Service zwischen OK-, WARNING-, UNKNOWN- und CRITICAL-Zuständen wechselt und geeignete Maßnahmen ergreifen. Diese Zustandsänderungen resultieren in verschiedenen Statustypen (HARD oder SOFT), was zum Auslösen von Eventhandlern und dem Versenden von Benachrichtigungen führen kann. Service-Statusänderungen können auch zum Auslösen von Host-Prüfungen nach Bedarf führen. Das Erkennen und Behandeln von Statusänderungen ist das, worum es sich bei Icinga handelt.
Wenn Service-Statusänderungen zu oft erfolgen, werden sie als "flatternd" (flapping) angesehen. Icinga kann erkennen, wenn Services anfangen zu flattern, und kann Benachrichtigungen unterdrücken, bis das Flattern stoppt und sich der Service-Status stabilisiert. Mehr Informationen über die Erkennungslogik des Flatterns finden Sie hier.
Eine Erklärung finden Sie unter "Frische-Prüfungen / freshness".
© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com