33.2 Netzwerkmonitoring mit Nagios 

Nagios (www.nagios.org) erfüllt als Nachfolger des populären NetSaint alle Anforderungen, die wir im letzten Abschnitt an ein Netzwerkmonitoringtool gestellt haben:
- Überwachen von Rechnern und Diensten
Man kann diverse Dienste (z. B. HTTP, SMTP, POP3, FTP, ...) sowie auch ganze Rechner (über PING) überwachen. Außerdem kann man auch Ressourcen wie Festplattenplatz, CPU-Auslastung oder den Speicherverbrauch kontrollieren.
- Flexibles Benachrichtigungssystem
Natürlich kann man auch konfigurieren, wer wie kontaktiert werden soll, wenn Probleme auftreten. Dazu gehört neben der obligatorischen E-Mail-Benachrichtigung auch der Support von SMS-Nachrichten oder von anderen benutzerdefinierten Möglichkeiten.
-
- Die verschiedenen Benutzer des Systems kann man außerdem in unterschiedlichen Kontaktgruppen organisieren, auf die man die unterschiedlichen Problemfälle verteilen kann.
- Pluginsystem und proaktive Problemlösung
Über ein einfaches Pluginsystem kann man auch selbst Servicechecks schreiben, die dann von Nagios regelmäßig ausgeführt beziehungsweise überprüft werden.
-
- Außerdem kann man mittels Event-Handlern auch einfache Maßnahmen zur proaktiven Problemlösung definieren.
- Webinterface
Neben den erwähnten Möglichkeiten der E-Mail-Benachrichtigungen kann man den Status der überwachten Systeme auch über ein State-of-the-art-Webinterface betrachten. Zu diesem gehört auch ein WML-Interface, sodass Sie den Status der Rechner selbst von unterwegs via Handy abfragen können.
Open Source!
Gehen wir also näher auf die Software ein. Nagios steht unter der GNU General Public License und ist damit als freie Software für jeden verfügbar. Als Voraussetzungen für die Installation genügen bereits ein einfacher Linux-Rechner mit Webserver (am besten Apache) sowie die GD-Bibliothek, die aber auch bei jeder Distribution mit dabei sein sollte.
Nachdem es installiert – und vor allem konfiguriert – worden ist, kann man sich mit Nagios nicht nur über aufgetretene Probleme informieren lassen, sondern sich auch schöne Statistiken ansehen.
Abbildung 33.1 Netzwerkmonitoring mit Nagios
Nur haben die Götter vor die Grafik leider die Konfiguration gesetzt, die bei einem Netzwerkmonitoringsystem natürlich nicht von selbst erfolgen kann. Aus diesem Grund wollen wir uns an dieser Stelle etwas näher mit dieser Thematik auseinandersetzen, da die Maßnahmen, die sich aus den Meldungen ergeben, wieder vollkommen in den Aufgabenbereich eines Systemadministrators fallen.
Da die Konfiguration also naturgemäß recht komplex werden kann, verweisen wir für Detailfragen wieder einmal auf die Webseite des Projektes, www.nagios.org, und auf die dort verlinkte ausführliche Dokumentation.
33.2.1 Die Installation 

Beginnen wir also mit der Installation. Am besten laden Sie sich die aktuellste Version von der Webseite herunter und entpacken die Dateien in einem Verzeichnis Ihrer Wahl. Anschließend sollten Sie einen eigenen Benutzer samt Gruppe für die Software und das spätere Installationsverzeichnis – am besten /usr/local/nagios – anlegen.
# tar -xzf nagios-1.1.tar.gz # mkdir /usr/local/nagios # adduser nagios
Listing 33.14 Die eigentliche Installation vorbereiten
Quelltext konfigurieren
Als Nächstes kann man in dem entpackten Verzeichnis das configure-Skript aufrufen, bei dem man einige Parameter nicht vergessen sollte:
../configure --prefix=prefix --with-cgiurl=cgiurl --with-htmurl=htmurl --with-nagios-user=user --with-nagios-grp=group
Listing 33.15 Die Software vor dem Übersetzen an das eigene System anpassen
- Mit »prefix« gibt man das Installationsverzeichnis an, normalerweise ist das /usr/local/nagios.
- Die »cgiurl« wird die URL angeben, unter der man später die CGIs ansprechen will, normalerweise /nagios/cgi-bin [Achtung: Am Ende der URL darf kein Slash stehen!].
- Analog gibt die »htmlurl« die URL der späteren HTML-Seiten an, normalerweise /nagios/.
- Schließlich sollte man den eben angelegten Benutzer samt dessen Gruppe (standardmäßig ist beides »nagios«) angeben.
Quelltext übersetzen
Als Nächstes kann man die Software übersetzen und die entsprechenden Dateien an ihren zukünftigen Platz im Dateisystem verschieben. Falls gewünscht, kann man sich auch ein Initskript erstellen lassen:
# make # make install # make install-init
Listing 33.16 Übersetzen, installieren und Initskript erstellen
Möchte man auch noch einen Satz von Standardkonfigurationsdateien installieren, die man dann später nur noch anpassen muss, reicht es aus, make erneut zu bemühen:
# make config # make install-config
Listing 33.17 Beispielkonfiguration installieren
Verzeichnisstruktur
Wechselt man nun mit cd /usr/local/nagios in das Installationsverzeichnis von Nagios, kann man sich dort die Verzeichnisstruktur der Software näher ansehen:
Verzeichnis | Beschreibung |
bin/ |
Der Nagios-Server an sich befindet sich in diesem Verzeichnis. |
etc/ |
Hier befinden sich die Konfigurationsdateien. Dazu später mehr. |
libexec/ |
In dieses Verzeichnis sollten die Plugins installiert werden. |
sbin/ |
Die CGIs für das Webinterface befinden sich hier. |
share/ |
die HTML-Dateien für das Webinterface sowie die Dokumentation |
var/ |
das Verzeichnis für die Logfiles |
Installieren der Plugins
Wie bereits aus der Tabelle zur Verzeichnisstruktur ersichtlich ist, müssen als Nächstes die Plugins separat heruntergeladen und ins Verzeichnis libexec/ installiert werden.
Plugins für Servicechecks
Die Plugins sind dabei entweder Skripte oder zu kompilierende Binarys, die die Service- und Hostchecks erst durchführen. Natürlich können Sie so, wenn Sie sich bereits fertige Skripte oder Codes als Vorbild nehmen, auch eigene Plugins für Nagios schreiben.
Das Webinterface
Nachdem wir die Software übersetzt und die Plugins installiert haben, ist als Nächstes das Webinterface an der Reihe. Es muss dem Webserver – in unserem Beispiel wollen wir auf den viel genutzten Apache eingehen – »gesagt« werden, wo die CGI-Skripte und die HTML-Dateien zu finden sind. Immerhin haben wir diese ja nicht in die DocumentRoot, also das »Stammverzeichnis des Webservers« installiert.
Webserver vorbereiten
Beginnen wir dazu mit dem Alias für die CGI-Skripte. Die folgenden Zeilen bewirken, dass wir die URL /nagios/cgi-bin ansprechen können, wobei in Wirklichkeit auf die Skripte in /usr/local/nagios/sbin zugegriffen wird. Dieses Verzeichnis wird beim Kompilieren durch den Parameter --cgiurl angegeben:
ScriptAlias /nagios/cgi-bin/ /usr/local/nagios/sbin/ <Directory "/usr/local/nagios/sbin/"> AllowOverride AuthConfig Options ExecCGI Order allow,deny Allow from all </Directory>
Listing 33.18 Den Alias für die CGI-Skripte setzen
Als Nächstes müssen wir noch die --htmlurl /nagios auf das Verzeichnis share/ unserer Installation umleiten:
Alias /nagios/ /usr/local/nagios/share/ <Directory "/usr/local/nagios/share"> Options None AllowOverride AuthConfig Order allow,deny Allow from all </Directory>
Listing 33.19 Den Alias für die Nagios-HTML-Dateien setzen
Nun kann man den Apache mit dem Befehl
# apachectl restart
Listing 33.20 Apache neu starten
neu starten und bereits versuchen, das Webinterface über
http://localhost/nagios/
anzusprechen. Natürlich werden noch keine Informationen angezeigt, da das Monitoring erst noch konfiguriert werden muss; das Webinterface kann man aber schon betrachten.
Passwortschutz
Meistens ist es ganz sinnvoll, den Zugriff auf die Nagios-Software per htaccess zu beschränken. Um diesen Schutz zu konfigurieren, muss man zuerst im share/- und sbin/-Verzeichnis der Nagios-Installation eine .htaccess-Datei mit folgendem Inhalt anlegen:
AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users require valid-user
Listing 33.21 Die .htaccess-Datei
Mit dem Kommando htpasswd kann man anschließend die /usr/local/nagios/etc/ htpasswd.users mit dem -c-Switch anlegen und mit Benutzernamen und Passwörtern füllen:
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
Listing 33.22 Den User »nagiosadmin« hinzufügen
Möchte man weitere Nutzer hinzufügen, so entfällt die Option -c, und man gibt als einziges Argument den anzulegenden Benutzernamen an.
33.2.2 Die Konfiguration 

Nach der Installation läuft zwar Nagios bereits, aber ein Monitoring findet noch nicht statt. Dazu muss das System erst korrekt konfiguriert werden, was in diesem Abschnitt besprochen werden soll. Am besten beginnen wir dazu mit einem Überblick über die wichtigsten der zahlreichen Konfigurationsdateien:
Hauptkonfiguration
- etc/nagios.cfg
In der Hauptkonfigurationsdatei kann man alle möglichen Einstellungen für Nagios vornehmen, wie beispielsweise wo die restlichen Konfigurationsdateien zu finden sind, welche Logfiles angelegt werden sollen oder wie sich das Monitoring bezüglich der einzelnen Checks genau verhalten soll.
- etc/cgi.cfg
In dieser Konfigurationsdatei kann man zahlreiche Einstellungen für die CGIs treffen, so zum Beispiel, welche Nagios-Benutzer auf welche Funktionen Zugriff erhalten, falls eine Authentifizierung verwendet wird.
- Resource Files
Neben den beiden Hauptkonfigurationsdateien gibt es weitere Konfigurationsdateien, die man dann über die etc/nagios.cfg einbinden kann. Ein Typ dieser zusätzlichen Konfigurationseinstellungen sind die Resource Files (meist nur etc/resource.cfg), in denen man sensible Informationen wie Logins für eine Datenbank oder auch Makros speichern kann. Aus Sicherheitsgründen sind diese Informationen den CGIs nicht zugänglich.
Objekte definieren
- Object Configuration Files
Diese Dateien bindet man ebenfalls über die nagios.cfg ein, und hier endlich definiert man das eigentliche Monitoring. Für Nagios ist es egal, ob Sie einen Service (Dienst) oder einen zu überwachenden Rechner definieren, allerdings teilt man die recht umfangreichen Optionen meist auf mehrere Dateien auf: - etc/hosts.cfg
Hier definiert man die zu überwachenden Rechner samt Namen und IP-Adressen. Dazu benötigt man die weiter unten erklärten host-Objekte. - etc/services.cfg
Hier kann man die zu überwachenden Dienste definieren, die zwei wichtige Eigenschaften besitzen: den Rechner(n), auf dem sie laufen, sowie den Befehl beziehungsweise das Plugin, das für den Check verwendet werden soll. - etc/commands.cfg
Die bei den Servicedefinitionen benötigten Dienste kann man auch als Objekte anlegen, was einem die Angabe der genauen Syntax bei jedem einzelnen zu konfigurierenden Dienst ersparen kann. - etc/contacts.cfg
Hier kann man einzelne Benutzer samt E-Mail-Adresse oder anderer Benachrichtigungsmethoden eintragen sowie angeben, bei welchen Dringlichkeitsstufen verschiedener Events sie kontaktiert werden sollen. - etc/*groups.cfg
Ob Rechner oder Kontakte: Beides kann und sollte man auch zu Gruppen zusammenfassen, um die Administration komplexer Netzwerke zu vereinfachen. Diese Gliederung ist vor allem für das Benachrichtigungssystem sinnvoll.
- Weitere Objekttypen
Es gibt noch viele weitere Objekttypen, die gerade für komplexe bis sehr komplexe Netzwerke interessant werden können. Für eine Dokumentation zu diesen Features seien Sie erneut auf die Webseite verwiesen, da weitere Details den Rahmen des Buches sprengen würden.
-
- Denken Sie allerdings daran, dass die eben vorgestellten Dateien nicht unbedingt so auf Ihrem Nagios-Server vorhanden sein müssen – schließlich können Sie in der nagios.cfg flexibel einstellen, woher Ihre Objektdefinitionen kommen sollen.
Im Folgenden wollen wir weniger die Konfiguration von Nagios selbst (über die nagios.cfg beziehungsweise die cgi.cfg) erläutern, da diese standardmäßig recht sinnvoll und im Allgemeinen weniger interessant ist.
Stattdessen möchten wir lieber auf die umfangreichen Objektdefinitionen eingehen, die das Monitoring Ihres Netzwerks erst ermöglichen. Aus diesem Grund seien Sie erneut auf die Webseite des Projekts samt zugehöriger Dokumentation verwiesen, falls Fragen zur Konfiguration offen bleiben sollten.
Hostobjekte
Rechner definieren
Prinzipiell in jeder Object-Configuration-Datei kann man host-Objekte definieren, meist wird dazu jedoch die etc/hosts.cfg genutzt. Möchte man nun einen neuen Rechner zur Überwachung hinzufügen, kann man dort eine entsprechende Definition ablegen:
define host{ host_name Rechnername alias Alias address IP (parents Rechnernamen) (check_command Kommando) max_check_attempts # notification_interval # notification_period timeperiod notification_options [d,u,r] }
Listing 33.23 Ein Host-Objekt
Man gibt dem Objekt mit dem Rechnernamen zuerst einen eindeutigen Bezeichner, auf den man sich dann in der weiteren Konfiguration von Nagios auch beziehen kann. Der Alias dagegen wird verwendet, um den Rechnernamen über das Webinterface anzuzeigen.
Es folgt natürlich die obligatorische IP-Adresse. Wenn sich irgendwelche anderen Systeme wie zum Beispiel Router zwischen dem Host und dem Monitoringsystem befinden, werden diese im optionalen Parameter parent angegeben.
Ist ein Rechner an?
Das check-Kommando ist recht wichtig, um zu überprüfen, ob der Host noch »up« ist. Meist gibt man hier das standardmäßig in der commands.cfg definierte Kommando check-host-alive an, das schlicht einen Ping auf den Rechner versucht. Lässt man diesen Parameter weg, wird das System nicht überprüft und immer als »up« angenommen.
Als Nächstes muss man angeben, wie oft im Fehlerfall überprüft werden soll, bevor eine Nachricht abgeschickt beziehungsweise der Rechner als »down« deklariert wird. In so einem Fall werden entsprechende Kontakte alle notification_interval Minuten wieder informiert.
Eine timeperiod ist auch ein Objekt, über das man definieren kann, in welchem Zeitraum ein Rechner oder ein Dienst überwacht werden soll. Meist gibt man hier den in der etc/timeperiods.cfg definierten Zeitraum 24x7 an, der den Rechner ohne Unterbrechung kontrolliert.
Zum Schluss kann man noch einstellen, wann ein Admin benachrichtigt werden soll: wenn der Rechner »down« (d) geht, wenn er »unreachable« (u) ist, also ein Parent »down« geht und der Rechner nicht mehr zu erreichen ist, und/oder wenn er wieder »up« (r, engl. recover) ist.
Es gibt noch eine ganze Reihe weiterer möglicher Optionen, die wir aber nicht näher betrachten wollen.
Hostgruppen
Verknüpfung mit Kontakten
Was in der Definition zu einzelnen Rechnern noch fehlte, war natürlich die Verknüpfung mit entsprechenden Kontakten, die im Problemfall informiert werden sollen. Dazu fasst man nämlich mehrere Rechner zu einer »Gruppe« zusammen, indem man wieder einen Objektnamen samt Alias vergibt und der Gruppe eine Kontaktgruppe sowie natürlich ein bis mehrere durch Komma getrennte Mitglieder zuordnet. Die Mitglieder sind dabei selbstverständlich wieder Hostobjekte.
define hostgroup{ hostgroup_name Gruppenname alias Alias contact_groups Kontaktgruppen members Mitglieder }
Listing 33.24 Hostgruppen
Durch diese auf den ersten Blick komplexe Struktur kann man sehr sinnvolle und realitätsnahe Konfigurationen für das Monitoring schaffen. Und dies ist schließlich das Ziel, das wir mit der Software verfolgen.
Um letzte Fragen zu klären, wollen wir uns aber einmal ein kurzes Beispiel eines Hostobjekts sowie einer dazugehörigen Hostgruppe ansehen: |
define host{ host_name fileserver alias Data Store address 192.168.1.1 check_command check-host-alive max_check_attempts 5 notification_interval 30 notification_period 24x7 notification_options d,u,r } define hostgroup{ hostgroup_name servers alias Serverraum #1 contact_groups linux-admins members fileserver,mailserver }
Listing 33.25 Host samt Hostgruppe
Diese Konfiguration sollte mit den Erläuterungen der Objekttypen eigentlich selbsterklärend sein. Das einzige, was Sie nicht verwundern sollte, ist die hier nicht weiter definierte Kontaktgruppe linux-admins. Da wir auf Kontaktgruppen erst später eingehen, haben wir diese Definition hier nämlich noch offengelassen.
Serviceobjekte
Serverdienste definieren
Bereits angesprochen wurden auch die Serviceobjekte. Das Wort »Service« bezeichnet dabei nicht nur klassische Dienste wie HTTP, FTP oder POP3, sondern auch jede andere »messbare« Eigenschaft eines Rechners.
So kann man über Serviceobjekte auch den Plattenplatz, die Anzahl momentan eingeloggter Benutzer, die Prozessorauslastung oder was auch immer überprüfen. Allerdings sollte man immer darauf achten, nicht zu viele Informationen zu sammeln, damit das Wichtige nicht untergeht.
define service{ host_name Rechnername service_description Beschreibung check_command Kommando max_check_attempts # normal_check_interval # retry_check_interval # check_period timeperiod notification_interval # notification_period timeperiod notification_options [w,u,c,r] contact_groups Kontaktgruppen }
Listing 33.26 Serviceobjekte in der etc/services.cfg
Der Rechnername bezieht sich auf ein host-Objekt, auf dem dieser Dienst läuft beziehungsweise dessen Zustand überwacht werden soll. Ansonsten ist vor allem wieder das Kommando wichtig, bei dem oft auf eines der mitgelieferten Plugins zurückgegriffen wird.
Ähnlich wie die bereits erläuterten notification-Optionen verhalten sich auch die check-Optionen. So kann man über die check_period-Option kontrollieren, wann das Monitoring stattfinden soll (z. B. 24x7), oder mittels der interval-Optionen festlegen, wie regelmäßig die Überprüfungen wiederholt werden sollen.
Wann informieren?
Zu den notification_options ist allerdings noch eine weitere Option – (w) für Warnungen – hinzugekommen. Schließlich gibt es für Dienste drei Zustände: »ok«, »warning« und »critical«, während es mit »up« und »down« für Rechner an sich nur zwei messbare Zustände gibt.
Über die Option contact_groups kann man wie bei den Hostgruppen eine oder mehrere Kontaktgruppen angeben, die im Problemfall benachrichtigt werden.
Kontakte und Kontaktgruppen
Verantwortliche angeben
Daher wollen wir als Nächstes auch schon dieses Feature behandeln. Zu einem Kontakt gehört wie immer bei Nagios der Objektname, der »richtige« Name als Alias sowie natürlich neben den bereits bekannten Benachrichtigungsoptionen eine – optionale – E-Mail-Adresse.
define contact{ contact_name Kontakt alias Alias host_notification_period timeperiod service_notification_period timeperiod host_notification_options [d,u,r,n] service_notification_options [w,u,c,r,n] service_notification_commands notify-by-email host_notification_commands host-notify-by-email (email E-Mail) }
Listing 33.27 Kontakte in der etc/contacts.cfg
Natürlich gibt es auch für Kontakte noch weit mehr als die hier aufgeführten Optionen und damit natürlich auch mehr Möglichkeiten, wie eine Benachrichtigung erfolgen kann. Daher ist die E-Mail-Adresse als eine Kontaktoption unter vielen auch nicht zwingend für dieses Objekt erforderlich.
Um einen Kontakt nun aber mit einem Hostgruppen- oder Serviceobjekt verknüpfen zu können, benötigt man eine Kontaktgruppe. Auch wenn in einer solchen Gruppe nur ein einziger Kontakt steht, ist sie notwendig, damit man den Kontakt in Nagios nutzen kann:
define contactgroup{ contactgroup_name Kontaktgruppe alias Alias members Mitglieder }
Listing 33.28 Kontaktgruppe in der etc/contactgroups.cfg
Die Mitglieder einer solchen Gruppe sind natürlich wieder die entsprechenden Objektnamen, die durch Kommas getrennt werden. Aber sehen wir uns dazu ein einfaches Beispiel an: |
define contact{ contact_name jploetner alias Johannes Plötner service_notification_period 24x7 host_notification_period 24x7 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 jploetner@localhost } define contactgroup{ contactgroup_name admins alias Administratoren members jploetner, swendzel }
Listing 33.29 Ein Beispiel
Dieses Beispiel sollte eigentlich selbsterklärend sein. Man definiert zuerst den Kontakt und fügt ihn schließlich einer Kontaktgruppe hinzu.
Kommandodefinition
Plugins integrieren
Wir haben bei den Host- und den Serviceobjekten bereits auf die Kommandos Bezug genommen, mit denen diese entsprechend überwacht wurden. Dort konnte man entweder direkt einen Befehl eingeben oder eben auf ein definiertes Kommandoobjekt Bezug nehmen.
Ein solches Kommandoobjekt definiert man wie folgt:
define command{ command_name Kommando command_line Kommandozeile }
Listing 33.30 Kommandodefinition in der etc/commands.cfg
Dabei kann man in der Kommandozeile auch Makros nutzen, die mit einem Dollarzeichen beginnen müssen. Ein Beispiel soll diesen Sachverhalt verdeutlichen: |
define command{ command_name check_pop command_line /usr/local/nagios/libexec/ check_pop -H $HOSTADDRESS$ }
Listing 33.31 Ein Beispiel
In diesem Beispiel wird das Kommando check_pop definiert, das ein gleichnamiges Skript im libexec/-Verzeichnis mit dem entsprechenden Rechnernamen als Argument aufruft.
Wenn die Plugins installiert wurden, dann hat man schon eine ganze Reihe sinnvoller Kommandos zur Verfügung. Im Folgenden soll eine kleine Übersicht über die wichtigsten Skripte und Programme gegeben werden. Für eine ausführliche Übersicht sei Ihnen aber immer noch die Dokumentation der Plugins selbst ans Herz gelegt.
33.2.3 Die Plugins 

Wie bereits angedeutet, besitzt Nagios selbst keinerlei Möglichkeiten, irgendeinen Dienst oder Rechner zu überwachen. Die Software verlässt sich voll und ganz auf die Plugins, die diese »Intelligenz« übernehmen.
Die Intelligenz
Bekanntermaßen unterscheidet Nagios allerdings zwischen Hostchecks und Servicechecks, die beide auf dieselbe Pluginarchitektur zurückgreifen. Der einzige Unterschied besteht darin, dass bei einem Hostcheck bei jedem Nicht-OK-Wert bei der Rückgabe angenommen wird, dass der Rechner »down« ist.
Dass man die Plugins schließlich über Kommandodefinitionen einbindet, die man dann in den Host- und Serviceobjekten angeben kann, sollte mittlerweile auch klar sein.
check_tcp
Portscan
Dieses Plugin ist eines der einfachsten und gleichzeitig wichtigsten Plugins. Über dieses Plugin kann man nämlich überprüfen, ob ein Port auf einem entfernten Rechner offen oder geschlossen ist. Mit dieser Information kann man dann den Rückschluss ziehen, ob der entsprechende Dienst läuft oder abgestürzt ist.
Ruft man das Plugin auf der Kommandozeile ohne Parameter auf, so wird ein Hilfetext mit allen verfügbaren Parametern ausgegeben:
# ./check_tcp No arguments found Usage: check_tcp -H host -p port [-w warn_time] [-c crit_time] [-s send_string] [-e expect_string] [-q quit_string] [-m maxbytes] [-d delay] [-t to_sec] [-v]
Listing 33.32 Die Parameter des Plugins
In einer Kommandodefinition könnte man das Plugin also zum Beispiel wie folgt ansprechen:
define command{ command_name check_port_cups command_line $USER1$/check_tcp -H $HOSTADDRESS$ -p 631 }
Listing 33.33 Beispiel: check_tcp
In dem Beispiel wollen wir also einen Check definieren, der einen laufenden CUPS-Server überprüft. Dazu nutzen wir zwei Makros: Das in der etc/resource.cfg definierte $USER1$-Makro spart uns die Angabe des vollständigen Pfadnamens zum Pluginverzeichnis, und zur Laufzeit von Nagios wird das Makro $HOSTADDRESS$ durch die Adresse des zu überprüfenden Rechners ersetzt. |
In einem Serviceobjekt könnte man nun wie folgt den CUPS-Server überwachen lassen:
define service{ host_name printserver,testserver service_description CUPS check_command check_port_cups ... }
Listing 33.34 CUPS-Server überwachen
check_ping
Rechnerstatus berechnen
Für Hostchecks möchte man natürlich am liebsten ICMP-Echo-Pakete mittels ping verschicken. Zu diesem Zweck gibt es das Plugin check_ping, das meist wie folgt als Kommando definiert wird:
define command{ command_name check-host-alive command_line $USER1$/check_ping -H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -p 1 }
Listing 33.35 check-host-alive
Das check-host-alive-Kommando ist uns aber schon in der Definition der Hostobjekte begegnet, wo wir es als sinnvolles Standardkommando zur Überprüfung des Hoststatus vorgestellt hatten.
NRPE und NSCA
Richtig interessant wird Nagios allerdings erst, wenn Erweiterungen wie NRPE beziehungsweise NCSA ins Spiel kommen. Diese Dienste laufen auf dem zu überwachenden Rechner und können Nagios diverse Informationen wie noch verfügbare Plattenkapazität, Prozessorauslastung oder Speicherauslastung mitteilen.
Aktive vs. passive Checks
Mit NRPE kann man dabei aktive Checks realisieren: Man installiert auf dem Clientsystem – die Software gibt es für Windows und Unix – den NRPE-Dienst und auf dem Nagios-Server das check_nrpe-Plugin. Entsprechend konfiguriert, überprüft Nagios nun über das Plugin regelmäßig den Status des Systems.
Setzt man dagegen NCSA ein, so kann man passive Checks realisieren. Dies ist zum Beispiel nützlich, wenn das zu überwachende System hinter einer Firewall sitzt. Mit dieser Software baut nämlich der Client regelmäßig selbst die Verbindung zu der auf dem Nagios-Server laufenden Software auf.
Wie Sie sehen, kann man mit Nagios sehr komplexe Monitoringstrukturen umsetzen. Da das Thema aber sehr komplex ist, wollen wir es bei diesem Einblick in die Thematik belassen und Sie ein letztes Mal auf die verfügbare Dokumentation verweisen.