Einleitung
Event Handler sind optionale Befehle, die ausgeführt werden können, wenn ein Host die Dienst seinen Status wechselt. Hauptsächlich werden Event Handler (besonders bei Diensten) eingesetzt, um Nagios automatisch und proaktiv Probleme beheben zu lassen, bevor es überhaupt zu einem Ausfall kommt oder ein User etwas davon merkt oder ein Administrator benachrichtigt wird. Ein anderes Potential von Event Handlern liegt darin, Ergebnisse von Dienst- und Host-Überprüfungen z.B. in eine externe Datenbank zu schreiben.
Arten von Event Handlern
Es gibt zwei Hauptarten von Event Handlern die definiert werden können. Dienst- und Host-Event Handler. Der Event Handler-Befehl wird (optional) in jeder Host- und Dienst-Definition angegeben. Da diese Event Handler mit einem bestimmten Dienst oder Host verknüpft sind, werden wir sie hier "lokale" Event Handler nennen. Falls ein lokaler Event Handler für einen Dienst oder Host definiert wurde, wird dieser ausgeführt, sobald der entsprechende Host oder Dienst seinen Status wechselt.
Man kann auch globale Event Handler definieren, die ausgeführt werden, wenn jeder Dienst oder Host seinen Status wechselt. Hierfür benutzt man die global_host_event_handler- und global_service_event_handler-Optionen in der Haupt-Konfigurationsdatei.
Wann werden Event Handler-Befehle ausgeführt?
Befehle von Dienst- und Host-Event Handlern werden ausgeführt, wenn ein Dienst oder Host:
Sie fragen was "softe" und "harte" Stati sind? Sie werden hier beschrieben.
Ausführungsreihenfolge von Event Handlern
Globale Event Handler werden immer vor irgendwelchen lokalen Event Handlern eines spezifischen Hosts oder Dienstes ausgeführt werden.
Event Handler-Befehle selbst schreiben
In den meisten Fällen sind Event Handler-Befehle Shell- oder Perl-Skripte. Das Skript sollte auf jeden Fall die folgenden Makros als Argumente entgegennehmen:
Makros von Dienst-Event Handlern: $SERVICESTATE$, $STATETYPE$, $SERVICEATTEMPT$
Makros von Host-Event Handlern: $HOSTSTATE$, $STATETYPE$, $HOSTATTEMPT$
Das Skript sollte die Werte der Argumente die übergeben werden überprüfen und dann je nach Wert entsprechende Aktionen ausführen. Der beste Weg zu verstehen, wie Event Handler arbeiten sollten, zeigt das folgende Beispiel. Glücklicherweise gibt es ein Skript weiter unten. Es gibt noch weitere beispielhafte Event Handler-Skripte in dem eventhandlers/-Unterverzeichnis des Quellcodes von Nagios. Einige dieser Skripte demonstrieren, wie man externe Befehle nutzen kann, um redundante Überwachungs-Server zu implementieren.
Zugriffs- und Ausführungsrecht von Event Handler-Befehle
Jeder Event Handler-Befehl der konfiguriert werden kann, wird mit den gleichen Rechten ausgeführt, wie sie der User besitzt unter dem Nagios auf der Maschine läuft. Dies lässt ein Problem mit Skripten erkennen, die z.B. versuchen sollen System-Dienste neu zu starten, denn hierfür sind (oder zumindest sollte es so sein) grundsätzliche Root-Rechte erforderlich.
Um solche Aufgaben zu bewältigen, sollte man dem Nagios-User genau so viele Rechte geben, wie nötig um die gewünschten Befehle auszuführen. Ein möglicher Weg um dies zu erreichen ist die Implementierung von sudo. Die Installation ist allerdings Ihr Job, man sollte sich also die Dokumentation anschauen und entscheiden, ob man diesen Weg geht.
Event Handler-Befehle debuggen
Wenn man Event Handler-Befehle debuggen will, sollte man die Protokollierung der Dienst-"Retries", Host-"Retries" und Event Handler-Befehle aktivieren. Alle diese Protokoll-Optionen werden in der Haupt-Konfigurationsdatei gesetzt. Die Aktivierung dieser Optionen erlaubt es genau zu sehen wann und warum Event Handler-Befehle ausgeführt werden.
Wenn Sie die Event Handler-Befehle debugged haben, sollte man die Protokollierung der Dienst- und Host-"Retries" evtl. wieder abschalten. Diese können das Logfile sehr schnell aufblasen, ausser es wurde die Rotation der Logdateien aktiviert.
Beispiel eines Dienst-Event Handlers
Das folgende Beispiel nimmt an, dass ein HTTP-Server auf der lokalen Maschine überwacht werden soll und restart-httpd als der Event Handler-Befehl definiert wurde. Ausserdem wird angenommen, dass die <max_check_attempts>-Option auf den Wert 4 oder grösser gesetzt wurde (d.h. der Dienst wird vier Mal überprüft, bevor ein echtes Problem erkannt wird). Eine beispielhafte Dienst-Definition (nur mit den Feldern die hier interessieren) könnte wie folgt aussehen...
define service{
host_name somehost
service_description HTTP
max_check_attempts 4
event_handler restart-httpd
...andere Dienst-Variablen...
}
Wurde bei einem Dienst ein Event Handler definiert, muss dieser Event Handler auch als befehlt angelegt werden. Man beachte die Makros in der Befehlszeile, die man an den Event Handler übergibt - diese sind wichtig!
define command{
command_name restart-httpd
command_line /usr/local/nagios/libexec/eventhandlers/restart-httpd $SERVICESTATE$ $STATETYPE$ $SERVICEATTEMPT$
}
Nun schreibt man das entsprechende Event Handler-Skrpt (dies ist die /usr/local/nagios/libexec/eventhandlers/restart-httpd-Datei).
#!/bin/sh # # Event Handler-Skript um den Web-Server auf der lokalen Maschine neu zu starten # # Achtung: Dieses Skript startet den Web-Server neu, wenn drei Mal (in einem soften Status) # versucht wurde den Dienst zu erreichen oder der Web-Dienst aus entsprechenden # Gründen in einen harten Fehler-Status wechselt. # # In welchem Status befindet sich der HTTP-Dienst? case "$1" in OK) # Der Dienst ist wieder erreichbar, es ist also nichts zu tun... ;; WARNING) # Wir kümmern uns hier nicht über warnende Stati, da der Dienst möglicherweise immernoch # normal läuft... ;; UNKNOWN) # Wir wissen nicht was evtl. einen unbekannten Status verursacht, deswegen tun wir nichts... ;; CRITICAL) # Aha! Der HTTP-Dienst scheint ein Problem zu haben - vielleicht sollten wir den Web-Server # neu zu starten... # Ist dies ein "softer" oder ein "harter" Status? case "$2" in # der Dienst befindet sich in einem "soften" Status, d.h. Nagios verursacht gerade die # Dienst-Überprüfungen erneut durchzuführen, bevor es einen "harten" Status ausgibt und # die Kontaktpersonen informiert... SOFT) # Der wievielte Versuch einer Dienst-Überprüfung wurde gerade ausgeführt? # Man sollte den Web-Server nicht bei dem ersten Versuch neu starten, da es evtl. # nur ein Fehlalarm ist! case "$3" in # Der Web-Dienst wird erst neu gestartet, wenn wenn vorerst drei Mal versucht wurde # den Dienst zu erreichen. # Falls die Überprüfung ein viertes Mal fehlschlägt (nachdem wir den Web-Server # neu gestartet haben), wechselt der Status in einen "harten" Fehler-Status und # Nagios informiert die Administratoren über das Problem. # Hoffentlich startet dieses Skript den Web-Dienst erfolgreich neu, so das die # vierte Überprüfung hoffentlich eine "softe" Wiederherstellung liefert. Falls dies # der Fall ist wird niemand informiert, da das Problem automatisch von Nagios # behoben wurde! 3) echo -n "Restarting HTTP service (3rd soft critical state)..." # Aufruf des Init-Skriptes zum Neustart des HTTPD-Servers /etc/rc.d/init.d/httpd restart ;; esac ;; # Der HTTP-Dienst ist trotz des Neustarts des Dienstes in einen "harten" Status gewechselt. # Geben wir ihm trotzdem eine letzte Chance, trotzdem die Administratoren bereits von # Nagios über das Problem informiert wurden (ausser es wurden Benachrichtigungen für diesen # Dienst deaktiviert). HARD) echo -n "Restarting HTTP service..." # Aufruf des Init-Skriptes zum Neustart des HTTPD-Servers /etc/rc.d/init.d/httpd restart ;; esac ;; esac exit 0 |
Das oben gezeigte Beispiel-Skript versucht den Web-Server auf der lokalen Machine in zwei verschiedenen Instanzen neu zu starten - einmal nachdem zum dritten mal versucht wurde den Dienst zu erreichen und einmal nachdem der Dienst in einen "harten" Fehler-Status gewechselt. ist. Der harte Status sollte eigentlich erst garnicht auftreten, da das Skript den Server bereits im "soften" Status (nach dem dritten Überprüfungs-Versuch) neu gestartet haben sollte.
Es sollte beachtet werden, dass der Dienst-Event Handler nur ausgeführt wird, wenn der Dienst das erste Mal in einen "harten" Status wechselt. Dies verhindert das Nagios fortlaufend versucht den Web-Server neu zu starten, nachdem sich dieser in einem "harten" Status befindet. Wir haben es bereits ohne Erfolg zwei Mal auf diesem - sehr einfachen aber hilfreichen - Weg versucht, nun muss wohl ein Administrator per Hand ran.