Service-Prüfungen (Service Checks)
Zurück | Kapitel 5. Die Grundlagen | Weiter

## Service-Prüfungen (Service Checks)

Einführung

Die grundlegenden Tätigkeiten von Service-Prüfungen werden hier beschrieben...

Wann werden Service-Prüfungen durchgeführt?

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.

Abhängigkeiten und Prüfungen

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.

Parallelisierung von Service-Prüfungen

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.

Service-Zustände

Services, die geprüft werden, können in einem von vier unterschiedlichen Zuständen sein

- OK

- WARNING

- UNKNOWN

- CRITICAL

Service-Statusermittlung

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.

Service-Statusänderungen

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.

Zurück | Nach oben | Weiter
Host-Prüfungen (Host checks) | Zum Anfang | Aktive Prüfungen (Active Checks)

© 2009-2012 Icinga Development Team, http://www.icinga.org