In den meisten Fällen werden Sie Icinga nutzen, um Ihre Hosts und Services mit Hilfe von regelmäßig geplanten aktiven Prüfungen zu überwachen. Aktive Prüfungen können genutzt werden, um ein Gerät oder Service gelegentlich "abzufragen". Icinga unterstützt auch einen Weg, Hosts und Services passiv zu überwachen statt aktiv. Die Hauptmerkmale von passiven Prüfungen sind wie folgt:
passive Prüfungen werden von externen Anwendungen/Prozessen veranlasst und ausgeführt
Ergebnisse von passiven Prüfungen werden an Icinga zur Verarbeitung übermittelt
Der Hauptunterschied zwischen aktiven und passiven Prüfungen ist, dass aktive Prüfungen von Icinga veranlasst und ausgeführt werden, während passive Prüfungen von externen Applikationen durchgeführt werden.
passive Prüfungen sind nützlich, um Services zu überwachen, die
von Natur aus asynchron sind und nicht effektiv durch Abfrage ihres Zustands auf einer regelmäßig geplanten Basis überwacht werden können
sich hinter einer Firewall befinden und nicht aktiv vom überwachenden Host aus geprüft werden können
Beispiele für asynchrone Services, bei denen sich eine passive Überwachung lohnt, sind u.a. SNMP-Traps und Sicherheits-Alarme. Sie wissen nie, wie viele (falls überhaupt) Traps oder Alarme Sie innerhalb eines vorgegebenen Zeitfensters erhalten, so dass es nicht sinnvoll ist, ihren Status alle paar Minuten zu überwachen.
Passive Prüfungen werden auch genutzt, um verteilte oder redundante Überwachungsinstallationen zu konfigurieren.
Hier nun mehr Details, wie passive Prüfungen arbeiten...
eine externe Applikation prüft den Status eines Hosts oder Service.
die externe Applikation schreibt die Ergebnisse der Prüfung in das external command file.
das nächste Mal, wenn Icinga das "external command file" liest, wird es die Ergebnisse aller passiven Prüfungen zur späteren Verarbeitung in eine Queue stellen. Dieselbe Queue, die für die Speicherung von Ergebnissen von aktiven Prüfungen genutzt wird, wird auch für die Speicherung von Ergebnissen von aktiven Prüfungen verwendet.
Icinga wird periodisch ein check result reaper event ausführen und die Ergebnis-Queue abfragen. Jedes Service-Prüfungs-Ergebnis, das in der Queue gefunden wird, wird in der gleichen Weise bearbeitet - unabhängig davon, ob die Prüfung aktiv oder passiv war. Icinga kann abhängig vom Prüfergebnis Benachrichtigungen senden, Alarme protokollieren, usw.
Die Verarbeitung von aktiven und passiven Prüfungsergebnissen ist tatsächlich identisch. Dies erlaubt eine nahtlose Integration von externen Applikationen mit Icinga.
Um passive Prüfungen in Icinga zu aktivieren, müssen Sie folgendes tun:
setzen Sie die accept_passive_service_checks-Direktive auf 1.
setzen Sie die passive_checks_enabled-Direktive in Ihren Host- und Service-Definitionen auf 1.
Wenn Sie die Verarbeitung von passiven Prüfungen global deaktivieren wollen, setzen Sie die accept_passive_service_checks-Direktive auf 0.
Wenn Sie die Verarbeitung von passiven Prüfungen nur für ein paar Hosts oder Services deaktivieren wollen, nutzen Sie die passive_checks_enabled-Direktive in den Host- und/oder Service-Definitionen.
Externe Applikationen können passive Prüfungsergebisse an Icinga übermitteln, indem sie ein PROCESS_SERVICE_CHECK_RESULT external command in das "external command file" schreiben.
Das Format des Befehls lautet wie folgt:
[<Zeitstempel>] PROCESS_SERVICE_CHECK_RESULT;<host_name>;<svc_description>;<return_code>;<plugin_output>
wobei...
timestamp ist die Zeit im time_t-Format (Sekunden seit der UNIX-Epoche), zu der die Service-Prüfung durchgeführt (oder übermittelt) wurde. Bitte beachten Sie das einzelne Leerzeichen nach der rechten Klammer.
host_name ist der Kurzname des Hosts, der mit dem Service in der Service-Definition verbunden ist
svc_description ist die Beschreibung des Service wie in der Service-Definition angegeben
return_code ist der Return-Code der Prüfung (0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN)
plugin_output ist die Textausgabe der Service-Prüfung (also die Ausgabe des Plugins)
Anmerkung: ein Service muss in Icinga definiert sein, bevor Sie passive Prüfungen für ihn abliefern
können! Icinga wird alle Prüfergebnisse für Services ignorieren, die nicht konfiguriert waren, bevor es das letzte Mal (neu)
gestartet wurde.
Ein Beispiel-Shell-Script, wie man passive Service-Prüfungsergebnisse an Icinga übermittelt, finden Sie in
der Dokumentation zu sprunghaften Services.
Externe Applikationen können passive Host-Prüfungsergebisse an Icinga übermitteln, indem sie ein PROCESS_HOST_CHECK_RESULT external command in das "external command file" schreiben.
Das Format des Befehls lautet wie folgt:
[<timestamp>] PROCESS_HOST_CHECK_RESULT;<host_name>;<host_status>;<plugin_output>
wobei...
timestamp ist die Zeit im time_t-Format (Sekunden seit der UNIX-Epoche), zu der die Host-Prüfung durchgeführt (oder übermittelt) wurde. Bitte beachten Sie das einzelne Leerzeichen nach der rechten Klammer.
host_name ist der Kurzname des Hosts (wie in der Host-Definition angegeben)
host_status ist der Status des Hosts (0=UP, 1=DOWN, 2=UNREACHABLE)
plugin_output ist die Textausgabe der Host-Prüfung (also die Ausgabe des Plugins)
Anmerkung: ein Host muss in Icinga definiert sein, bevor Sie passive Prüfungen für ihn abliefern können!
Icinga wird alle Prüfergebnisse für Hosts ignorieren, die nicht konfiguriert waren, bevor es das letzte Mal (neu) gestartet
wurde.
Icinga versucht bei passiven Prüfungen - anders bei aktiven Prüfungen - nicht festzustellen, ob der Host DOWN oder UNREACHABLE ist. Statt dessen nimmt Icinga das passive Prüfergebnis als den wahren Status des Hosts und versucht nicht, den wahren Host-Status mit Hilfe der Erreichbarkeitslogik zu ermitteln. Dies kann Probleme verursachen, wenn Sie passive Prüfungen von einem entfernten Host übermitteln oder Sie ein verteiltes Überwachungs-Setup haben, in dem Eltern/Kind-Verhältnisse unterschiedlich sind.
Sie können Icinga anweisen, die passiven Prüfergebnisse DOWN/UNREACHABLE-Zustände mit Hilfe der translate_passive_host_checks-Variable in ihre "sauberen" Zustände zu übersetzen. Mehr Informationen wie dies funktioniert, finden Sie hier.
Anmerkung: Passive Host-Prüfungen werden normalerweise als HARD-Zustände
behandelt, falls nicht die passive_host_checks_are_soft-Option aktiviert
ist.
Wenn eine Applikation, die sich auf dem gleichen Host wie Icinga befindet, passive Host- oder Service-Prüfungsergebnisse sendet, kann es die Ergebisse einfach direkt in das "external command file" schreiben wie oben skizziert. Allerdings können entfernte Hosts das nicht so einfach tun.
Um es entfernten Hosts zu erlauben, passive Prüfungsergebnisse an den überwachenden Host zu senden, hat Ethan Galstad das NSCA-Addon entwickelt. Das NSCA-Addon besteht aus einem Daemon, der auf dem Icinga-Host läuft und einem Client, der auf entfernten Hosts ausgeführt wird. Der Daemon lauscht auf Verbindungen von entfernten Hosts, führt mit den Ergebnissen einige grundlegende Gültigkeitsprüfungen durch und schreibt die Prüfergebnisse direkt in das "external command file" (wie oben beschrieben). Mehr Informationen über das NSCA-Addon finden Sie hier.
© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com