Seite 5: Plug-ins

Inhaltsverzeichnis

Plug-ins

Jetzt ist der Moment gekommen, einen genaueren Blick darauf werfen, wie ein Plug-in mit Nagios kommuniziert. Es gibt zwei Informationen zurück, nämlich einen String, der im Webinterface und den Benachrichtigungen verwendet wird, sowie im Returncode den eigentlichen Status. Definiert sind 0 für "OK", 1 für "Warning", 2 für "Critical" und 3 für "Unknown". Da die Plug-ins eigenständige Programme sind, kann man einen Check zunächst auf der Kommandozeile mit den nötigen Parametern testen, bevor man ihn in die Nagios-Konfiguration einbindet. Jedes Plug-in sollte mit dem Parameter --help oder -h eine Hilfe zu seinen Parametern ausgeben. Als Beispiel dient ein lokaler Check auf den Füllgrad des root-Dateisystems des Nagios-Servers mit Hilfe des Plug-ins check_disk. Auf der Kommandozeile könnte das im Plug-in-Verzeichnis /usr/local/nagios/libexec/ so aussehen:

nagios # ./check_disk -w 60% -c 20% -p /DISK WARNING – free space: / 974 MB (54% inode=-);| /=813MB;715;1430;0;1788nagios # echo $? 1

Die Ausgabe kann mit der Version des Plug-ins variieren. Hier sieht man auch eine optionale Eigenschaft der Nagios-Plug-In-Ausgabe: Im Webinterface oder der Alarm-E-Mail sieht man nur den Teil des Strings bis zum Pipe-Symbol. Alles ab der Pipe behandelt Nagios als so genannte Perfomance Data. Dieser leicht zu parsende String können zum Beispiel Add-Ons verwendet, um Trendgraphiken zu erstellen.

Die Parameter -w und -c sind typisch für viele Plug-ins und definieren die Schwellenwerte, ab denen ein Check in den Zustand "Warning" beziehungsweise "Critical" wechselt. Der echo-Befehl gibt den Returncode aus, dessen Wert 1 dem Status "Warning" entspricht.

Funktioniert der Check auf der Kommandozeile wie gewünscht, trägt man ihn in die Datei checkcommands.cfg ein. Der Festplatten-Check ist dort bereits definiert:

define command{ command_name check_local_disk command_line $USER1$/check_disk -w $ARG1$ – -c $ARG2$ -p $ARG3$}

Hier sieht man ein weiteres Feature der Nagios-Konfiguration, die Verwendung von Makros. Das sind von $-Zeichen begrenzte Strings, die Nagios direkt vor der Ausführung durch den entsprechenden Wert ersetzt. Eigene Makros können in der Konfigurationsdatei resource.cfg als $USER1$ bis $USER32$ definiert werden. $USER1$ enthält in der Beispieldatei resource.cfg den Pfad zu den Plug-ins.

Zusätzlich lassen sich die Makros $ARG1$ bis $ARG32$ in der Service-Definition belegen. Mit diesem Check Command kann man nun in services.cfg die Abfrage einrichten. Dafür kopiert man den vorhandenen PING-Check und trägt als service_description einen möglichst aussagekräftigen Namen und als check_command den eben definierten command_name samt Parametern ein. Damit man auch bei einer "Warning" eine Benachrichtigung erhält, kann man die notification_options um ein "w" für "Warning" erweitern. Der Check des Plattenfüllstand des Nagios-Servers könnte damit so aussehen:

define service{   use generic-service   host_name             nagios   service_description   DISK: /   check_period          24x7   normal_check_interval 5   retry_check_interval  1   max_check_attempts    3   contact_groups        linux_admins   notification_interval 120   notification_period   24x7   notification_options  w,u,c,r   check_command         check_local_disk!60%!20%! /}

Die Direktive normal_check_interval legt hier fest, dass Nagios diesen Check alle fünf Minuten aufrufen soll. Wenn er nicht "OK" zurückliefert, probiert Nagios es im Minutentakt erneut (retry_check_interval). Zunächst führen Fehlschläge nur zum eingangs erwähnten "soften" Fehlerzustand. Beim dritten erfolglosen Versuch (max_check_attempts) ändert sich das zu einem "Hard"-Status, der die Benachrichtigungs-Kette in Gang setzt. Damit ein längerer Ausfall nicht zu einer Nachrichtenflut führt, verschickt Nagios erst nach 120 Minuten im Nicht-OK-Status die nächste Nachricht (notification_interval). Hier wird auch die Benutzung der $ARGn$-Makros deutlich: Im check_command stehen durch Ausrufezeichen getrennt die Parameter, die das Plug-in in diesem Service-Check mitbekommt. So kann man verschiedene Partitionen mit unterschiedlichen Schwellwerten mit einem einzigen Check Command überwachen.

Nach einem /etc/init.d/nagios reload erscheint jetzt der neue Service "DISK: /" im Webinterface als Pending und nach einiger Zeit mit einem Status. Lautet der "Warning" oder "Critical", sollte Nagios nach Erreichen der max_check_attempts eine E-Mail an die eingetragenen Contacts schicken. Ist dies nicht der Fall, sollte man die service_notification_options und die service_notification_period überprüfen; vielleicht ist es über dem Kennenlernen von Nagios Abend geworden und in der contacts.cfg ist "workhours" eingetragen. Zum Test des Benachrichtigungssystems kann auch das Plug-in check_dummy dienen, das immer einen per Parameter bestimmten Returncode zurückliefert.

Netzwerkchecks

Bisher prüft der Nagios-Server nur sich selbst. Der eigentliche Zweck eines Monitoring-Systems ist aber die Überwachung von Diensten und Betriebsparametern über das Netzwerk. Netzwerkdienste wie Web- oder Mailserver kann Nagios prüfen, indem es darauf zugreift. Dafür stellt das Plug-in check_tcp einfach eine Verbindung zum angegebenen Port her und prüft die Antwort auf einen darüber verschickten String. Daneben gibt es eine Vielzahl von Plug-ins, die bestimmte Protokolle auswerten, zum Beispiel check_http. Als beispielhaftes Opfer dient der auf dem Nagios-Server laufende Apache. Da er wie beschrieben eine Benutzerauthentifizierung erfordert, muss man dem Plug-in über den Parameter -a Nutzernamen und Passwort mitgeben:

nagios # ./check_http -I 127.0.0.1 -u /nagios/ -w 1 -c 5 -a aadmin:geheimHTTP OK HTTP/1.1 200 OK – 909 bytes in 0.013 seconds

Bei diesem Plug-in sind die Schwellen -w und -c Antwortzeiten des Servers in Sekunden; der Parameter -u gibt die relative URL an, die Perfomance-Daten sind der Übersichtlichkeit halber nicht dargestellt. Das vordefinierte Check Command check_http enthält keine Benutzerauthentifizierung, sodass man am besten ein neues definiert. Das Kennwort sollte dabei nicht in einer Datei stehen, die jeder lesen kann. In der Grundkonfiguration dürfen nur die Mitglieder der Unix-Gruppe nagios und der Benutzer nagios selbst auf die Datei resources.cfg zugreifen, sodass ein Passwort darin relativ sicher liegt. Hier trägt der Admin also Benutzernamen und Passwort als Benutzermakros ein:

$USER3$=aadmin$USER4$=geheim

Ein passendes Check Command sieht dann so aus:

define command{ command_name check_http_auth command_line $USER1$/check_http -I $HOSTADDRESS$- -u $ARG1$ -a $USER3$:$USER4$ -w $ARG2$ -c $ARG3$}

In das Makro $HOSTADDRESS$ trägt Nagios die IP-Adresse des Hosts ein, der im host_name-Eintrag der Service-Definition steht.

define service{   service_description Nagios-Webserver   host_name           nagios   check_command       check_http_auth!/nagios/!1!5...

Nach einem Reload des Nagios-Servers taucht jetzt der Check als Pending im Webinterface auf, nach kurzer Zeit sollte der Status dann auf "OK" wechseln. Viele Netzwerkgeräte wie Switches und Router geben über das Simple Network Management Protocol (SNMP) ihren Betriebszustand bekannt. SNMP-Kenner nutzen dazu das Plug-in check_snmp, dem sie OID, Hostname und Community String sowie die Schwellenwerte übergeben. Eine SNMP-Einführung würde den Rahmen dieses Artikels sprengen.