zurück zum Artikel

Wer ein Netzwerk betreibt, möchte gerne wissen, ob Server und Router reibungslos arbeiten. Das Monitoring-System Nagios beobachtet beliebige Bestandteile eines Netzwerkes und schlägt Alarm, wenn irgendetwas aus dem Ruder läuft.

Ob Hard- oder Software, Ausfälle sind nicht zu vermeiden. Um auf eine Störung frühzeitig reagieren zu können, werden Monitoring-Systeme eingesetzt. Sie überwachen per Netzwerk die Verfügbarkeit von Diensten und informieren den Administrator, wenn etwas nicht mehr im grünen Bereich läuft. So erfährt er schnell, wenn der Web-Server nicht mehr antwortet, der Drucker klemmt oder eine Server-Platte vollgelaufen ist. Da das Monitoring-System solche Dienste ständig prüft, bemerkt es Ausfälle meistens, bevor sie den Usern Probleme bereiten. Und wenn das System Trends in der Verfügbarkeit erfasst, gibt es dem Admin sogar wertvolle Hinweise für die Kapazitätsplanung.

Als statusorientiertes, Plug-in-basiertes Monitoring-Framework hat sich in den letzten Jahren das unter der GPL stehende Nagios [1] (früher Netsaint genannt) etabliert. Der Nagios-Prozess selbst kümmert sich nur um den Aufruf der Plug-ins für die eigentlichen Prüfungen und um die Auswertung der Ergebnisse und die Benachrichtigung, die wiederum über Plug-ins geschieht. Nagios läuft auf allen üblichen Unix-Varianten inklusive Linux. Es überwacht zusätzlich auch Windows-Systeme und Netzwerkkomponenten, die das Protokoll SNMP [2] sprechen. Die mitgelieferten Plug-ins werden in einem eigenen Projekt auf Sourceforge [3] gepflegt und bieten schon eine Vielzahl von Checks. Nagios-Plug-ins lassen sich auch einfach in beliebigen Programmiersprachen selbst entwickeln. Eine weitere Anlaufstelle für Plug-ins jeglicher Art ist das Portal NagiosExchange.org [4].

Nagios ruft ein Plug-in mit einer Reihe von konfigurierbaren Parametern wie etwa dem zu prüfenden Host auf, und erhält den Status zurück; entweder "OK", "Warning", "Critical" oder "Unknown". Nagios kennt zwei Status-Typen: "Soft" und "Hard", mit denen versucht wird, falsche Alarme zu vermeiden. Etwas vereinfacht geht der Zustand eines Checks nach einem Statuswechsel zunächst in den Typ Soft und erst nach einer definierbaren Anzahl von Wiederholungen, die das gleiche Ergebnis liefern, in den Typ Hard über.

Bei einem solchen Statuswechsel oder wenn der Zeitpunkt für eine erneute Benachrichtigung gekommen ist, durchläuft das Ereignis die Filterkette, die in der Abbildung rechts dargestellt ist. Erst wenn alle Filter eine Benachrichtigung erlauben, verschickt Nagios sie beispielsweise per E-Mail, SMS [5] oder Pager an einzelne Kontaktpersonen oder Gruppen. Der gesamte Vorgang ist umfassend konfigurierbar; so können zum Beispiel verschiedene Kontaktgruppen zu unterschiedlichen Zeiten oder nacheinander benachrichtigt werden.

Installation

Installation

Nagios liegt zurzeit für den produktiven Einsatz in der stabilen Version 2.5 vor. Als Beispiel für die Installation dient Suse Linux 10.1, das leider nur die veraltete Version 1.3 mitbringt. Da das Release 2 von Nagios eine ganze Reihe von Verbesserungen mitbringt, sollte es 1.3 vorgezogen werden. Dafür muss man aber den Compiler anwerfen und die Sourcen selbst übersetzen.

Für eine Server-Installation empfiehlt es sich immer, mit einer möglichst schmalen Basis anzufangen. Im Fall von Suse Linux 10.1 bedeutet das, während der Installation unter "Desktop" "Auswählen -> Andere" den Textmodus zu wählen. In dieser Minimalkonfiguration fehlen für Nagios nur noch wenige zusätzliche Pakete. Am einfachsten rüstet man sie in der Software-Auswahl mit der Selektion "C/C++ Compiler und Werkzeuge" nach und nimmt zusätzlich die Pakete Apache2, gd, libjpeg-devel und openssl-devel mit. Nach dem Ja zu den Abhängigkeiten kann es wie gewohnt mit der Installation weitergehen.

Nachdem man das frisch installierte System gebootet hat, muss das Paket gd-devel installiert werden. Da es leider nicht auf den als Download erhältlichen Medien ist, muss das Paket von Suse heruntergeladen [6] werden. Ein einfaches rpm -ivh gd-devel-2.0.32-23.i586.rpm erledigt dann die Installation. Dann werden nur noch die Sourcen [7] für Nagios 2.5, die Plug-ins und NRPE benötigt.

Zunächst werden die benötigten Benutzer und eine Gruppe angelegt, sowie die Gruppenmitgliedschaften geklärt.

useradd nagiosgroupadd nagiosmkdir /usr/local/nagioschown nagios.nagios /usr/local/nagiosuseradd nagcmdgroupmod -A nagcmd wwwgroupmod -A nagcmd nagios

Dann wird das tar-Archiv mit dem Nagios-Sourcecode entpackt und die Sourcen konfiguriert und kompiliert. Das Kommando ./configure --help gibt Auskunft über weitere Parameter, die den Build-Vorgang beeinflussen.

tar xfvz nagios-2.5.tar.gzcd nagios-2.5./configure --with-command-group=wwwmake all

Eine Reihe von make install-Kommandos verteilen dann Nagios, ein Startskript und einen Satz Dateien auf der Festplatte, darunter auch eine Beispielkonfiguration in /usr/local/nagios/etc/:

make installmake install-initmake install-commandmodemake install-config

Nagios selbst bringt noch keine Plug-ins mit. Das Kompilieren und die Installation der offiziellen Nagios Plug-ins ist aber nach dem Entpacken des tar-Archivs mit dem klassischen Dreisprung (./configure; make; make install) in dem entstandenen Verzeichnis erledigt.

Noch einfacher gestaltet sich das Übersetzen des "Nagios Remote Plugin Executor", einfach entpacken, in das Verzeichnis wechseln und los:

./configuremake all

Auf dem Nagios-Server wird vom NRPE das Plug-in check_nrpe gebraucht, das mit cp src/check_nrpe /usr/local/nagios/libexec/ am richtigen Platz landet.

Statt die Nagios-Plug-ins und NRPE selbst zu kompilieren, kann man sie auch guten Gewissens aus dem SuSE-10.1-Repository installieren, da die Versionen nicht zu sehr hinter dem aktuellen Stand zurückliegen. Allerdings stehen sie dann in einem anderen Verzeichnis, was bei der weiteren Konfiguration zu beachten ist.

Grundkonfiguration

Grundlegendes zur Konfiguration

Die grundlegenden Bausteine der Nagios-Konfiguration sind Contacts, Hosts und Services. Contacts sind Personen, die Benachrichtigungen erhalten können, also meistens die Administratoren. Die zu überwachenden Systeme werden als Hosts konfiguriert, egal ob es sich um Server, Switches [8] oder andere Geräte handelt, Hauptsache, sie haben eine IP-Adresse. Um einen Dienst (wie einen Webserver) oder einen Betriebsparameter (zum Beispiel die Systemauslastung) überwachen zu können, muss er als Service definiert werden. Das Format der Konfigurationsdateien heißt in Nagios-Lingo "Template-Based Object File".

Dabei ist es dem Nagios-Daemon relativ egal, in welchen Dateien diese Objekte konfiguriert sind. Zum Start benötigt er die Hauptkonfigurationsdatei nagios.cfg, in der die restlichen Konfigurationsdateien eingelesen werden. Das hat den Vorteil, dass man die Dateien aufteilen kann, wie es den eigenen Anforderungen entspricht. Ein gängiges Schema, das auch in den folgenden Beispielen verwendet wird, ist in dieser Tabelle dargestellt.

Kommentare in den Dateien leitet wie üblich ein "#" ein. Die Objekte der Konfiguration wie Contacts und Hosts können ihre Eigenschaften von Vorlagen erben. Dazu gehören auch Templates, unvollständig definierte Objekte, die man als Basis für die eigentlichen Konfigurationsobjekte benutzt. Dabei überschreiben in den abgeleiteten Objekten gesetzte Parameter die der Templates. Eine Definition wird mit der Direktive register 0 zum Template erklärt. Zusätzlich kann man von jedem registrierten Konfigurationsobjekt weitere Objekte ableiten. Eine gute Idee ist es, die Beispieldateien für spätere Betrachtung einmal komplett in Sicherheit zu kopieren. Beim anschließenden Bearbeiten sollten die Templates (erkennbar am register 0) erhalten bleiben und alle anderen Beispieldefinitionen angepasst oder auskommentiert werden.

First Contact

Nach der Installation befindet sich in dem Verzeichnis /usr/local/nagios/etc/ eine Handvoll Konfigurationsdateien. Für die folgenden Beispiele müssen die Dateien checkcommands.cfg-sample, misccommands.cfg-sample, resource.cfg-sample, cgi.cfg-sample und nagios.cfg-sample um das -sample erleichtert werden, so dass sie auf .cfg enden. Die Beispielkonfiguration bringt die beiden Dateien minimal.cfg-sample und bigger.cfg-sample mit, die eine sehr knappe und eine deutlich ausführlichere Konfiguration enthalten. Um die Konfigurations-Objekte auf einzelne Dateien zu verteilen, kann man die entsprechenden Teile aus den Beispielen als Vorlage in die neuen Dateien kopieren und anpassen.

Als ersten Schritt muss der Administrator mindestens einen Contact, Host und Service so eintragen, wie sie in seinem Netz tatsächlich existieren. Zunächst sollte er einen oder mehrere Kontakte in die neu anzulegende Datei contacts.cfg eintragen. Das sieht beispielsweise so aus:

define contact{   contact_name                  aadmin   alias                         Andi Admin   service_notification_period   workhours   host_notification_period      workhours   service_notification_options  w,u,c,r   host_notification_options     d,u,r   service_notification_commands notify-by-email   host_notification_commands    host-notify-by-email   email                         aadmin@example.com}

Den contact_name benutzt Nagios nur intern, er muss daher nicht mit einem User-Account [9] übereinstimmen. Als alias trägt man sinnvollerweise den vollen Namen dieses Kontakts ein. Die service_notification_period und die host_notification_period legen fest, in welchen Zeiträumen Nagios Benachrichtigungen an diesen Kontakt verschickt.

Die Buchstaben w, u, c und r in den service_notification_options stehen für "Warning", "Unknown", "Critical" und "Recover" und legen fest, bei welchen Statusänderungen eines Service der Kontakt eine Nachricht erhält. Ein n (none) sorgt hier dafür, dass Nagios nie eine Nachricht schickt. Entsprechend legt der Parameter host_notification_options fest, ob der Kontakt von Statusänderungen eines Hosts erfährt. Möglich sind d(own), u(nreachable), r(ecovery) und n(one). So lässt sich beispielsweise festlegen, dass der Chef nur von kompletten Server-Ausfällen erfährt, während der Web-Admin über seinen Dienst auf dem Laufenden bleibt.

Die beiden _commands (vordefiniert in misccommands.cfg) legen fest, auf welchem Weg Nagios eine Nachricht an diesen Contact absetzt. Damit der Versand per E-Mail funktioniert, muss das lokale Mail-System eingerichtet sein, was sich relativ einfach mit dem YaST-Modul "Netzwerkdienste->Mail Transfer Agent" erledigen lässt.

In der Datei contactgroups.cfg werden die Kontakte zu Gruppen zusammengefasst; jede Gruppe erhält einen Namen und einen Alias. Als members werden die Kontakte aus der contacts.cfg mit ihrem contact_name eingetragen:

define contactgroup{   contactgroup_name  linux_admins   alias              Die Linux-Kenner   members            aadmin}

Ein Host, ein Host!

Jetzt wird die Datei hosts.cfg angelegt und der Nagios-Server als erstes zu überwachendes System konfiguriert. Am einfachsten kopiert man die beiden define host-Blöcke aus der Datei minimal.cfg-sample. Der erste Block ist das Template generic-host, das einige allgemein übliche Schalter setzt. Der zweite Block leitet dann mit einer use-Direktive einen konkreten Host ab. In die Parameter host_name, alias und address gehören ein Nagios-interner Kurzname, ein Langname sowie die Loopback-Adresse des Servers, in die contact_groups auf eine oder mehrere existierende Kontaktgruppen:

define host{   use generic-host   host_name      nagios   alias          Nagios-Server   address        127.0.0.1   check_command  check-host-alive   contact_groups linux_admins...

Alle Host-Definitionen enthalten übrigens eine Direktive check_command check-host-alive, die festlegt, wie der Status eines Hosts überprüft wird. Typischerweise geschieht dies mit einem Ping [10]. Wie die Kontakte fasst man auch die Hosts in Gruppen zusammen, hier in der neuen Datei hostgroups.cfg. In members kommen die host_names der Mitglieder:

define hostgroup{   hostgroup_name linux-boxes   alias          Linux-Server   members        nagios}

Zum Schluss muss mindestens ein Service definiert werden. Als erster Check bietet sich der Test der Netzwerkverbindung an, was zwar auf demselben Host nicht sehr spannend, dafür aber leicht einzurichten ist. Analog zum Erstellen der hosts.cfg werden in die neue Datei services.cfg die ersten beiden define service-Blöcke aus minimal.cfg-sample kopiert. Damit erhält man ein Template und die Definiton eines Service "PING". Den host_name dieses Blocks ändert man auf den Namen des Nagios-Servers aus hosts.cfg. Um einen Check auf mehreren Hosts auszuführen, trägt man als host_name einfach mehrere durch Kommata getrennte Hostnamen ein, ein "*" sorgt dafür, dass Nagios alle definierten Hosts prüft. Außerdem gibt es den Parameter hostgroup_name, mit dem Host-Gruppen angegeben werden können. Die in contact_groups eingetragenen Kontaktgruppen erhalten Benachrichtigungen über den Status dieses Service, hier wird die in contactgroups.cfg definierte Kontaktgruppe eingetragen.

Um die grundlegende Konfiguration fertigzustellen, werden noch die Definitionen der Zeiträume für Checks und Benachrichtigungen benötigt. Am besten verwendet man hier die Beispiele aus bigger.cfg-sample und kopiert sie in eine neue Datei timeperiods.cfg. Die in der Abbildung rechts aufgeführten Dateien escalations.cfg und dependencies.cfg sind optional. In escalations.cfg kann man später Eskalationen definieren, durch die ab einer bestimmten Anzahl von Benachrichtigungen eine andere oder weitere Kontaktgruppen benachrichtigt werden. In dependencies.cfg werden Abhängigkeiten definiert.

Jetzt muss der Nagios-Daemon noch dazu gebracht werden, die neuen Konfigurationsdateien zu benutzen. Dazu wird in nagios.cfg der cfg_file= Eintrag für minimal.cfg gelöscht oder auskommentiert und die Kommentarzeichen vor den entsprechenden Einträgen für die benutzten Dateien entfernt. Ob man escalations.cfg und dependencies.cfg als leere Dateien anlegt oder die Zeilen in nagios.cfg auskommentiert lässt, ist dabei ganz egal.

Mit dem Befehl /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg prüft der gewissenhafte Admin nun die Konfiguration. Syntaktische oder inhaltliche Fehler werden dabei gnadenlos angekreidet. Wenn dann ein Things look okay – No serious problems were detected during the pre-flight check das OK gibt, ist der Moment gekommen, mit einem beherzten /etc/init.d/nagios start den Nagios-Server in Gang zu setzen. Das Startskript testet vorher zur Sicherheit auch mit nagios -v die Konfiguration. Jetzt ist der Nagios-Server ohne Murren gestartet und man sieht und hört … nichts. Solange keiner der Checks fehlschlägt und alle Hosts erreichbar sind, verhält sich Nagios vollkommen still. Um sich vom erfolgreichen Start zu überzeugen, kann man einen Blick in die Logdatei /usr/local/nagios/var/nagios.log werfen.

Webinterface

Schön bunt: das Webinterface

Nagios bringt aber glücklicherweise ein umfangreiches Webinterface mit, das Überblick über das System verschafft. Bevor es aber soweit ist, muss zunächst der Webserver in der Datei /etc/apache2/conf.d/nagios.conf konfiguriert werden. Das könnte zum Beispiel mit konfigurierter Zugangsberechtigung so aussehen:

ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin/<Directory /usr/local/nagios/sbin/>   Options ExecCGI   order deny,allow   deny from all   allow from 127.0.0.1   AuthName "Nagios Access"   AuthType Basic   AuthUserFile /usr/local/nagios/etc/htpasswd.users   Require valid-user</Directory><br />Alias /nagios /usr/local/nagios/share/<Directory /usr/local/nagios/share/>   Options None   order deny,allow   deny from all   allow from 127.0.0.1   AuthName "Nagios Access"   AuthType Basic   AuthUserFile/usr/local/nagios/etc/htpasswd.users   Require valid-user</Directory>

Zunächst ist der Zugriff auf das Webinterface nur vom lokalen Rechner erlaubt. Um auch von anderen PCs zugreifen zu können, muss man die beiden allow from-Direktiven um ein entsprechendes Netzwerk oder eine IP-Adresse erweitern, zum Beispiel

allow from 127.0.0.1 192.168.1 

für das Netzwerk 192.168.1.0/24 [11]. Wem die unverschlüsselte Verbindung mit Recht unheimlich ist, der findet auf der Nagios-Website ein Beispiel für verschlüsselten Zugriff per https [12].

Die letzten vier Zeilen in den beiden oben gezeigten Directory-Blöcken weisen den Web-Server an, nur Benutzern Zugriff zu gewähren, die sich mit Benutzername und Passwort anmelden. Die Passwörter werden in diesem Fall in der Datei /usr/local/nagios/etc/htpasswd.users nachgeschlagen. Dazu müssen die Benutzer angelegt werden, der erste mit

htpasswd2 -c /usr/local/nagios/etc/htpasswd.users aadmin 

alle weiteren ohne das -c. Der Name muss dem contact_name aus der Host- oder Service-Definition entsprechen, denn anhand dieser Kombination bestimmt Nagios, wer was zu sehen bekommt. Zusätzlich erhält jeder Benutzer Zugriff auf die Funktionen des Webinterface, für die er durch die mit authorized_for_ beginnenden Parameter in cgi.cfg autorisiert ist. Wenn also bei dem Zugriff auf eine Funktion des Webinterfaces eine Meldung über unzureichende Berechtigungen erscheint, muss in der cgi.cfg nachgebessert warden.

Nach einem /etc/init.d/apache2 start steht unter http:///nagios/ die Web-Oberfläche des Nagios-Servers zur Verfügung.

Wenn der Nagios- und auch der Web-Server laufen, sollte man sich die Zeit nehmen, das Webinterface zu erkunden. Neben verschiedenen Ansichten der überwachten Services und Hosts kann man sich auch Zusammenfassungen von Service- und Host-Problemen anzeigen lassen. Es gibt unter anderem eine Übersicht über Benachrichtigungen, ein Eventlog, eine Darstellung der Konfiguration.

Über das Webinterface lässt sich Nagios in Grenzen auch steuern. Zum Beispiel kann ein Admin einen Host bei einem bekannten Problem temporär von der Überwachung ausnehmen. Dazu muss er aber zunächst in nagios.cfg den Parameter check_external_commands=1 setzten und Nagios neu starten. Damit wird das "External Command File" verwendet, eine named pipe, durch die die Außenwelt mit dem Nagios-Prozess kommunizieren kann.

Nach der ganzen Arbeit möchte man jetzt nicht nur vor dem Monitor sitzen und ein grünes "OK" bewundern. Um das Webinterface und den Versand von Benachrichtigungen zu testen, bietet das Webinterface die Möglichkeit, den Status eines Checks zu setzen. Hierzu klickt man auf den Servicenamen und kommt in eine Detailansicht. Unter "Service Commands" gelangt man über den Punkt "Submit passive check result for this service" zu einem Formular. Übergibt man Nagios jetzt als "Check Result" ein "Critical" und als "Check Output" einen beliebigen String, hat man das Grün schnell in ein leuchtendes Rot verwandelt. Allerdings nur so lange, bis Nagios auf die Idee kommt, dass es Zeit für einen aktiven Check ist. Über diesen Mechanismus kann man sehr schön überprüfen, ob nach Erreichen der im Webinterface unter "Attempts" aufgeführten Anzahl der Checks die E-Mail-Benachrichtigung ausgelöst wird. Man muss nur schnell genug mit dem Webinterface sein …

Plug-ins

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 [13] 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 [14] 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 [15] (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.

Remote Plug-ins

Nagios Remote Plug-in Executor

Auf Servern lässt sich zwar SNMP einrichten, um Betriebsparameter wie Systemlast oder Festplattenfüllstand zu übermitteln. Doch Nagios bringt auch einen eigenen Mechanismus dafür mit, den Nagios Remote Plug-in Executor (NPRE). Das ist ein Daemon, der auf Anfrage des Nagios-Servers ein lokales Plug-in ausführt und das Ergebnis zurückgibt. NRPE ist samt Plug-ins auch für Microsoft Windows verfügbar und einer der Wege, dieses Betriebssystem mit Nagios zu überwachen. Dazu etwas später mehr.

Zunächst muss auf dem zu überwachenden Host NRPE und die benötigten Plug-ins installiert werden. Hat man die Plug-ins und NRPE selbst gebaut, kann man die entsprechenden Dateien auf den Host kopieren, dies wird aber nur von Erfolg gekrönt sein, wenn die Linux-Version des Hosts nicht zu sehr von der des Nagios-(Build-)Servers abweicht. Da Abwärtskompatibilität ein steiniges Feld ist, macht man sich das Leben leichter, wenn man einigermassen aktuelle NPRE-Versionen als Pakete installieren kann. Dies ist für Suse 10.1 und andere aktuelle Linux-Distributionen der Fall. Ein weiterer Vorteil ist, dass die Pakete typischerweise Konfigurationsdateien als Vorlage mitbringen. Ist man auf ein neues Plug-in Feature angewiesen oder möchte man eine ältere Distribution monitoren, bleibt einem meist nur der Compiler, um an eine aktuelle Version zu kommen.

Jetzt wieder zurück zu dem Beispiel Suse 10.1: Hier werden die Pakete nagios-nrpe und nagios-plugins benötigt, die bei der Download-Version aus dem Internet geholt werden müssen. Dazu müssen noch einge Pakete installiert werden, um die Abhängigkeiten aufzulösen, namentlich perl-Crypt-DES, perl-Digest-HMAC, perl-Net-SNMP und xinetd. Nach der Installation muss in der Datei /etc/xinetd.d/nagios-nrpe disable=no und eventuell only_from=<Nagios-Server IP> eingetragen werden. In /etc/services fehlt die Zeile

nrpe 5666/tcp # NRPE

Schließlich veranlasst der Aufruf xinetd restart xinetd, die neue Konfiguration zu lesen.

Da NRPE aus Sicherheitsgründen keine Parameter zu den Checks annehmen sollte, muss der Check vollständig auf dem Host in der Konfigurationsdatei /etc/nagios/nrpe.cfg definiert werden. Das könnte für den Test einer Partition [16] hda1 so aussehen:

command[disk1]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/hda1

Über den Namen in eckigen Klammern ruft das Plug-in check_nrpe vom Nagios-Server aus diesen Check auf:

check_nrpe -H <IP-Adresse> -c disk1

In checkcommands.cfg kann der Nagios-Admin ihn wie jeden anderen Check benutzen:

define command{  command_name check_nrpe  command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$} 

Schließlich trägt er den zu überwachenden Host und Service in die Konfiguration ein:

define service{   host_name           webserver   service_description DISK:hda1   check_command       check_nrpe!disk1...

NRPE für Windows

Für Microsoft Windows stellt das Projekt NRPE_NT [17] den NRPE bereit. Das ZIP-Archiv entpackt man in ein passendes Verzeichnis und installiert NRPE auf der Kommandozeile mit \<Pfad>\bin\NRPE_NT.exe -i als Dienst. Dazu sind Administrator-Rechte erforderlich. Passende Plug-ins gibt es bei NagiosExchange [18] unter Categories/Check Plug-ins [19], unter anderem das Paket "Basic NRPE_NT Plug-ins". Das bin-Verzeichnis aus diesem Archiv entpackt man ins bin-Verzeichnis des NRPE_NT-Verzeichnisses und überschreibt dabei einfach die alte Konfigurationsdatei nrpe.cfg.

Danach kommentiert man den Parameter blowfish_secret aus, trägt in allowed_hosts die Adresse des Nagios-Servers ein und passt in den "Command Definitions" die Pfade und Parameter an. Anschließend startet ein Admin NRPE über Verwaltung/Dienste in der Systemsteuerung und überprüft den korrekten Start im Ereignisprotokoll.

Benachrichtigung per SMS

Benachrichtigung per SMS

Nicht alle Admins hängen außerhalb ihrer Bürozeiten ununterbrochen an der E-Mail. Daher steht die Benachrichtigung über Serverausfälle per SMS eigentlich immer auf der Wunschliste. Man könnte einfach als E-Mail-Adresse das SMS-Gateway des Mobilfunkproviders angeben, also beispielsweise email 0160xxxxxx@t-d1-sms.de. Doch die Standard-Mails von Nagios sind zu lang für eine SMS. Abhilfe schafft das Kommando (host-)notify-by-epager als (host_)notification_commands eines Contacts, das eine knappe Nachricht per E-Mail an die Adresse im Feld pager der Kontaktdefinition schickt.

Diese Methode hat aber leider einige Mängel: Die meisten Mobilfunkprovider erlauben nur eine bestimmte Anzahl E-Mails pro Tag und verlangen erhebliche Gebühren für den Empfang. Der größte Schönheitsfehler ist aber die Abhängigkeit von der E-Mail-Infrastruktur samt Internetanbindung. Vielleicht wollte Nagios aber gerade den Ausfall des E-Mail-Gateway melden …

Ein sichererer Ansatz ist es daher, ein Handy über USB [20] oder die serielle Schnittstelle direkt mit dem Nagios-Server zu verbinden. Der Versand erfolgt dann über Tools wie gnokii [21] für Nokia-Handys, die Nagios-FAQ bietet eine kurze Anleitung [22].

Eine andere Möglichkeit ist der Versand über eine Einwahl beim Mobilfunkprovider mit Pagingtools wie zum Beispiel YaPS, was allerdings auch ziemlich ins Geld gehen kann. Beide Programme liegen der Suse-Distribution schon bei.

Am sinnvollsten ist es, E-Mail- und SMS-Benachrichtigungen zu kombinieren, zum Beispiel während der Bürozeiten per Mail zu warnen und nachts oder am Wochenende den Admin auf dem Handy zu belästigen. Dazu legt man pro Admin zwei Contact-Einträge an, die sich in den vier Einträgen service_notification_period, host_notification_period, service_notification_commands, host_notification_commands unterscheiden.

Eine weitere Möglichkeit ist die Verwendung von Host- und Service-Escalations. So ist es möglich, zunächst Benachrichtigungen per E-Mail zu versenden und erst bei einem länger andauernden Problem auch SMS zu verschicken. Ein Blick in die Dokumentation weist hier den richtigen Weg. Sie liegt im HTML-Format der Software bei, steht aber auch online [23] zur Verfügung. Zusätzlich ist sie direkt über das Nagios-Webinterface zu erreichen. Neben der Dokumentation existiert eine Sammlung von FAQs sowie die obligatorischen Mailinglisten.

Dieser Artikel kann nur einen Einstieg in Nagios vermitteln, mit der Beschreibung aller Funktionen lässt sich mühelos ein Buch füllen. Dazu gehören "Event Handler", die beim Statuswechsel Kommandos ausführen können, um zum Beispiel einen nicht reagierenden Serverdienst neu zu starten. Oder die Installation als verteiltes System, in dem mehrere Nagios-Server ihre Ergebnisse an einen zentralen übermitteln, der für die Auswertung zuständig ist. (je [24]) ()

URL dieses Artikels:
https://www.heise.de/-221683

Links in diesem Artikel:
[1] http://www.heise.de/netze/software/default.shtml?prg=34227
[2] http://www.heise.de/glossar/entry/Simple-Network-Management-Protocol-395168.html
[3] http://nagiosplug.sourceforge.net/
[4] http://www.nagiosexchange.org/
[5] http://www.heise.de/glossar/entry/Short-Message-Service-396643.html
[6] http://download.opensuse.org/distribution/SL-10.1/inst-source/suse/i586/
[7] http://www.nagios.org/download/#stable
[8] http://www.heise.de/glossar/entry/Switch-396339.html
[9] http://www.heise.de/glossar/entry/Account-398713.html
[10] http://www.heise.de/glossar/entry/Ping-397515.html
[11] http://www.heise.de/netze/lib/netzwerk-rechner.shtml?ip=192.168.1.0;cidr=24
[12] http://www.heise.de/glossar/entry/Hypertext-Transfer-Protocol-398281.html
[13] http://www.heise.de/glossar/entry/Port-398693.html
[14] http://www.heise.de/glossar/entry/Uniform-Resource-Locator-398705.html
[15] http://www.heise.de/glossar/entry/Simple-Network-Management-Protocol-395168.html
[16] http://www.heise.de/glossar/entry/Partition-397415.html
[17] http://www.miwi-dv.com/nrpent/
[18] http://www.nagiosexchange.org/
[19] http://www.nagiosexchange.org/Check_Plugins.21.0.html
[20] http://www.heise.de/glossar/entry/Universal-Serial-Bus-394747.html
[21] http://www.gnokii.org/
[22] http://www.nagios.org/faqs/viewfaq.php?faq_id=220
[23] http://nagios.sourceforge.net/docs/2_0/toc.html
[24] mailto:je@heise-netze.de

Copyright © 2006 Heise Medien