B. Brandel
Wer jederzeit den Überblick über sein Rechnernetz hat, kann Probleme schon im Vorfeld erkennen und eingreifen, bevor wichtige Server oder Netzkomponenten ausfallen. Ein wichtiges Hilfsmittel bei dieser Aufgabe ist das kostenlose Netz- und Server-Managementsystem Nagios, das seit kurzem im Universitätsrechenzentrum erprobt wird mit dem Ziel, Ihnen als unseren Kunden eine noch höhere Verfügbarkeit unserer Netzdienste bieten zu können.
Wozu Netz- und Server-Überwachung?
Als Kunden und Nutzer unseres Universitätsrechenzentrums haben Sie den berechtigten Anspruch, dass Ihnen unsere IT-Infrastruktur für Ihre Arbeit möglichst störungsfrei zur Verfügung steht. Da gelegentliche Probleme bei Hard- und Software unvermeidbar sind, ist die Strategie des URZ daher, Funktionsstörungen bei wichtigen Serverdiensten und Netzkomponenten möglichst frühzeitig zu bemerken und zu beheben.
Um die Verfügbarkeit unserer Systeme weiter zu erhöhen, erprobt das URZ seit kurzem das Open-Source-Monitoring-Tool Nagios, das von Ethan Galstadt ursprünglich für Linux enwickelt wurde und unter [1] für fast alle Unix-Derivate frei verfügbar ist. Netz- und Server-Überwachung mit Nagios bedeutet also keine "Orwell'sche Überwachung" von Nutzeraktivitäten, sondern einzig und allein die Überwachung der Funktionalität unseres Netzes und der darüber angebotenen Services zu Ihrem Nutzen.
Was kann Nagios?
Nagios kontrolliert über das Netz kontinuierlich die Verfügbarkeit von Services und meldet dem zuständigen Administrator, wenn ein Dienst nicht mehr korrekt läuft oder die Belastung seines Servers gewisse Schwellenwerte überschreitet. So erfährt man schnell, wenn ein Novell-Server-Cluster nicht mehr erreichbar ist, ein Router oder Switch Probleme macht oder wenn eine Systemplatte voll ist. Da Nagios diese Prüfungen kontinuierlich vornimmt, bemerkt es die Krisenherde oft, bevor sie den Nutzern Probleme bereiten.
Nagios überwacht Netzdienste wie z.B. SMTP, IMAP, HTTP und DNS, kann Rechnerressourcen wie Prozessorlast und freien Festplattenplatz überprüfen. Nagios kann aber auch Windows-Systeme überwachen und auch alle Netzkomponenten, die das Protokoll SNMP verstehen. Wenn Nagios ein Problem entdeckt, führt es die zuvor definierten Aktionen durch und benachrichtigt die verantwortlichen Personen.
Aufbau von NagiosNagios ist zwar ein komplexes Produkt, aber - basierend auf Plug-Ins - sehr modular aufgebaut. Der Nagios-Prozess selbst ruft nur die Plug-Ins für die eigentlichen Prüfungen auf und sorgt anschließend für die Auswertung der Resultate. Falls Administratoren zu informieren sind, startet er dann noch die entsprechenden Benachrichtigungs-Plug-Ins. In der Grundversion sind schon zahlreiche Plug-Ins enthalten, die bereits die wichtigsten Checks realisieren. Weitere Plug-Ins sind auch unter [2] und [3] erhältlich bzw. lassen sich relativ einfach selbst programmieren.
Plug-Ins im Detail
Beim Plug-In-Aufruf werden verschiedene Parameter übergeben, insbesondere der zu überprüfende Host. Als Antwort erhält Nagios dann einen von 4 Statuswerten zurück: OK, Warning, Critical oder Unknown. Bei einer flüchtigen Störung verschickt Nagios noch keine Alarmmeldungen. Erst wenn sich eine Statuswertänderung (z.B. von OK auf Critical auf Grund einer Störung) in den Folgetests bestätigt, wird sie als solche akzeptiert. Konkret bedeutet dies, dass Nagios beim ersten Statuswertwechsel erst einmal in den Zustand Soft geht und erst, wenn sich der neue Statuswert bei weiteren Checks bestätigt, in den Zustandstyp Hard wechselt.
Benachrichtigungsmechanismus
Erst jetzt prüft Nagios anhand konfigurierbarer Filterregeln, ob es nun Benachrichtigungen verschicken muss. Sollte sich z.B. der aufgefallene Host in einer geplanten Downtime befinden oder der Vorfall außerhalb der eingetragenen Benachrichtigungszeiten eingetreten sein, unternimmt Nagios nichts. Erst wenn alle Filter es erlauben, verschickt Nagios die Meldung per E-Mail, Pager oder SMS an die zuständigen Personen. Wenn der Störungszustand weiter anhält oder sich wieder stabil zum Guten wendet, läuft dasselbe Prozedere ab, d.h. Nagios prüft wiederum, ob und wen es informieren soll. Das Benachrichtigungssystem von Nagios erlaubt auch ein Eskalationsmanagement, beispielsweise kann Nagios besonders hartnäckige Störungen auch an die IT-Leitungsebene weiter melden.
Installation von Nagios 2.0
Seit Oktober 2005 gibt es ein sehr gutes Buch von Wolfgang Barth [4], das das System- und Netz-Monitoring basierend auf Version Nagios 2.0 detailliert beschreibt. Bei der Installation von Nagios haben wir uns eng an die Installationshinweise in Kapitel 1 dieses Buches gehalten und Nagios 2.0 mit den vom Autor empfohlenen Installationsparametern und Pfadangaben direkt aus den Quellen übersetzt.
Vor der Installation müssen Sie allerdings zuerst prüfen, ob alle von Nagios benötigten Bibliotheken in Ihrem System installiert sind. Bei unserm 64-Bit Xeon-System unter SuSE 10.0 fehlten insbesondere die Entwickler-Versionen der "GD Graphics Library" von Thomas Boutell [6], von "Open-LDAP" und vom WWW-Server "Apache 2". Diese mussten somit nachinstalliert werden. Außerdem wurden vorsorglich alle bereits installierten SuSE-Pakete der Nagios-Version 1.3 deinstalliert. Anschließend muss der Quellcode von [1] heruntergeladen und ausgepackt werden. Da Nagios nicht unter "Root"-Rechten laufen sollte, müssen der Nutzer nagios sowie die gleichnamige Gruppe angelegt werden. Damit der WWW-Server apache2 auf bestimmte geschützte Bereiche von Nagios zugreifen kann, wird zusätzlich noch die Gruppe nagcmd (Nagios Command Group) benötigt.
Im nächsten Schritt (siehe [4], Kapitel 1) werden die Nagios-Quellen konfiguriert. Nach erfolgreichem Durchlauf aller Tests liefert Nagios eine Konfigurationsübersicht. Anschließend wird mit den üblichen make-Befehlen die eigentliche Übersetzung und Installation durchgeführt. Dabei wird auch eine Beispielkonfiguration miterzeugt, auf die Sie bei der Erstellung Ihrer eigenen Konfiguration aufbauen können. Schließlich müssen Sie noch dafür sorgen, dass das Nagios-Startskript in die Systemstartliste eingetragen wird, damit Nagios bei jedem Hochfahren des Systems automatisch gestartet wird. Damit ist die Installation von Nagios abgeschlossen.
Installation der Plug-Ins
Die Plug-Ins müssen gesondert von [1] heruntergeladen und installiert werden. Da die Plug-Ins eine Sammlung selbstständiger Einzelprogramme sind, kann man jederzeit ein einzelnes Plug-In durch eine neuere Version ersetzen oder auch weitere Plug-Ins hinzufügen. Da Nagios und seine Plug-Ins von unterschiedlichen Teams entwickelt werden, haben die Plug-Ins auch eine andere Versionsnummer. Aktuell ist momentan die Version 1.4.2.
Die Plug-Ins werden ähnlich wie Nagios selbst konfiguriert und installiert (siehe [4], Abschnitt 1.2). Fehlermeldungen und Warnungen während der Konfiguration sollte man durchaus beherzigen - vielleicht müssen auch noch Linux-Pakete nachinstalliert werden. Im Gegensatz dazu sind fehlgeschlagene Tests beim Installationsvorgang kein Grund zur Aufregung, denn die Installations-Testroutinen selbst sind zum Teil fehlerhaft. Statt dessen sollte man sowieso alle Plug-Ins vor ihrem ersten Einsatz manuell per Kommandozeilenaufruf testen. Weitere Plug-Ins finden Sie im contrib-Verzeichnis. Sie können bei Bedarf direkt ins Plug-In-Verzeichnis kopiert werden (falls es Shell- oder Perl-Skripte sind) oder benötigen zuvor noch (bei C-Programmen) einen Übersetzungslauf. Hartnäckiger Plug-Ins, die sich einer Installation beharrlich widersetzen, wird man mit Hilfe der Mailingliste [7] Herr.
Konfiguration des WWW-Interfaces
Überblick über Ihre überwachten Systeme erhalten Sie mit dem WWW-Frontend, das mit Nagios mitgeliefert wird. Um die WWW-Schnittstelle zum Laufen zu bringen, muss der WWW-Server (bei uns apache2) entsprechend konfiguriert werden (siehe [4], Abschnitt 1.3), damit er das Basis-WWW-Verzeichnis von Nagios und die Nagios-CGI-Dateien findet und letztere auch ausführen kann. Nach einem Neustart von apache2 erscheint dann die Nagios-Hauptseite im WWW-Browser unter http://<nagios-servername>/nagios.
Aus Sicherheitsgründen empfiehlt es sich, den Zugriff auf das WWW-Interface des Nagios-Servers nur von ausgewählten Hosts aus zu erlauben und auf sensible Bereiche wie Systemzustandsinformationen und Kommandos grundsätzlich nur mit Passwortauthentifizierung zu gestatten. Die Wahl einer SSL-Verschlüsselung ist ebenfalls empfehlenswert, damit keine Klartext-Passwörter übers Netz gehen. Leider ist letztere in [4] nicht beschrieben, was bei einem Buch von 472 Seiten Umfang durchaus wünschenswert gewesen wäre.
Vorgehensweise bei der Konfiguration
Nagios ist ein sehr komplexes Produkt. Daher sind auch seine Konfigurationsmöglichkeiten sehr umfangreich. Es empfiehlt sich deshalb, zuerst ein Minimalsystem zu konfigurieren und dieses danach schrittweise zu erweitern. Damit vermeiden Sie eine unnötig lange Fehlersuche und Sie gelangen schneller zum Ziel.
Geeignete Konfigurationsdateien für Ihren Nagios-Einstieg finden Sie an folgenden Orten:
Wir wählten die Methode, uns an die Datei- und Verzeichnisstrukturen von [4] zu halten, und bauten die benötigten Dateien aus beiden Quellen in der in [4], Kapitel 2, empfohlenen Form zusammen.
Zentrale Konfigurationsbausteine von Nagios
Wie in [4], Abschnitt 2.1, beschrieben haben wir alle Konfigurationsdateien von Nagios im Verzeichniss /etc/nagios/ bzw. in dessen Unterverzeichnis /etc/nagios/mysite abgelegt:
In /etc/nagios/ finden Sie die allgemeinen Konfigurationsdateien:
Die Konfigurationsdateien, in denen Sie die Objekte Ihrer eigenen IT-Umgebung (Rechner, Netzkomponenten, Services) und Ihrer IT-Organisationsstruktur (Zuständigkeiten, Benachrichtigungswege) abbilden, befinden sich alle im Unterverzeichnis /etc/nagios/mysite. Die wichtigsten werden in den nächsten Abschnitten kurz vorgestellt.
Schließlich gibt es noch das Unterverzeichnis /etc/nagios/sample. Es enthält Musterdateien, die der Nagios-Installation beiliegen und die Sie als Vorlagen zur der Erweiterung der Grundkonfiguration verwenden können. Einen grafischen Überblick mit dem Zusammenspiel der Konfigurationsdateien einer anderen Nagios-Beispiel-Installation finden Sie bei Herrn Genzel (Uni Hohenheim) (siehe [9]).
Was soll Nagios in Ihrem Netz überwachen?
Was die Netz- und System-Verantwortlichen vor allem interessiert, ist die Frage, ob die Dienste auf Ihren Servern und Netzkomponenten funktionieren. Beim Auftreten von Problemen möchten Sie schnell deren eigentliche Wurzel erkennen können.
Wenn z.B. Ihr WWW-Server nicht antwortet, möchten Sie daher wissen,
Damit Nagios Ihnen darauf die richtige Antwort geben kann, müssen Sie Nagios zuerst beibringen, wie Ihre Netztopologie aufgebaut ist.
Beschreibung Ihrer Netztopologie für Nagios
Dazu müssen Sie in /etc/nagios/mysite/hosts.cfg alle Hosts definieren, deren Dienste Sie überwachen wollen. Um Nagios Ihre Netztopologie zu beschreiben, geben Sie bei jedem Host außer seiner IP-Adresse auch seine(n) Parents -Knoten an, das ist der nächstgelegene Netzknoten zwischen Host und Nagios-Server. Bei Hosts ohne Eltern geht Nagios davon aus, dass sie direkt mit dem Nagios-Server verbunden sind (siehe auch [4], Kapitel 4). So entsteht eine Baumstruktur Ihres Netzes mit dem Nagios-Server als Wurzel und den überwachten Hosts als Ästen und Blättern (vgl. die Abbildung auf der nächsten Seite).
Definition der Service-ChecksObjektbausteine von Nagios
Im vorigen Abschnitt wurden die Host- und Service-Konfigurationsdateien beschrieben, in denen Sie Ihre IT auf Nagios abbilden können (siehe [4], Kapitel 2). Im Unterverzeichnis /etc/nagios/mysite finden sie noch weitere Konfigurationsdateien, z.B. zur Definition von Kontakten und Kommandos. All diese Dateien setzen sich aus verschiedenen Objektbausteinen zusammen. Die wichtigsten sind Hosts, Services, Kontakte und Kommandos:
Nagios kann alle Systeme, die IP-Adressen besitzen, beobachten, insbesondere Server, Switches, Router und auch wichtige Clients. Sie werden als Hosts konfiguriert. Das Host-Objekt beschreibt den zu überwachenden Netzknoten und enthält u.a. die IP-Adresse, die Parents (die nächstgelegenen Netzknoten in Richtung Nagios-Server) sowie das Kommando, das feststellen soll, ob der Host lebt.
Wenn ein Dienst (z.B. IMAP-Server) überwacht werden soll, muss er als Service definiert werden. Ein Nagios-Service existiert nie unabhängig von einem Host und ist daher immer ein Host-Service-Paar. Ein Service muss daher immer auch den Host oder eine Hostgruppe sowie einen Namen und einen Plug-In-Aufruf samt Übergabeparametern enthalten. Zwei Services können auch den gleichen Namen (z.B. PING ) tragen, aber zu unterschiedlichen Hosts gehören.
Contacts sind alle Kontaktpersonen, die im Problemfall Benachrichtigungen erhalten. Kontakt-Objekte verwendet Nagios außerdem, um einem User über das WWW-Frontend genau die Dinge anzuzeigen, für die er als Kontakt-Person genannt ist. Hosts und Services außerhalb seines Verantwortungsbereichs bekommt er nicht zu sehen. Im Contacts -Objekt kann festgelegt werden, zu welchen Zeiten eine Kontaktperson über Statusänderungen der überwachten Dienste (Warning, Unknown, Critical, Recover) und Systeme (Down, Unreachable, Recovery, None) informiert wird. So kann man z.B. einstellen, dass die Leitungsebene nur von kompletten Serverausfällen erfährt, während die Webmaster über Probleme bei den WWW-Services sofort informiert werden.
Alles, was Nagios tun soll, muss in Command -Objekten definiert werden. Das sind v.a. die Plug-Ins und die Benachrichtigungsprogramme (per E-Mail oder SMS).
Verwendung von Templates und Gruppen
Nagios bezeichnet seine Bausteine nicht von ungefähr als Objekte, denn sie können ihre Eigenschaften auch von Vorlagen (Templates ) erben. Mit diesem in Nagios 2.0 üblichen Ansatz wird die Konfiguration deutlich übersichtlicher ([4], Abschnitt 2.11). Mehrere Hosts, Services und Contacts können auch zu Gruppen (Novellserver, WWW-Dienste, Webmastergruppe) zusammengefasst werden. Damit lassen sich dann bestimmte Objekte (z.B. Services oder Benachrichtigungen) auf eine ganze Gruppe (z.B. Rechner oder Personen) anwenden. Außerdem können Gruppen im WWW-Interface gemeinsam dargestellt werden. Damit werden sowohl die Konfiguration als auch die Ergebnisse übersichtlicher.
Inbetriebnahme von Nagios ([4], Kapitel 3)
Nachdem nun Nagios samt Plug-Ins installiert ist und eine Minimalkonfiguration samt WWW-Interface eingerichtet ist, kann Nagios endlich in Betrieb gehen. Die Konfiguration wird nochmals mit nagios -v /etc/nagios/nagios.cfg überprüft. Wenn hier keine Fehler aufgetreten sind, kann Nagios mit /etc/init.d/nagios manuell gestartet werden. Bei Konfigurationsänderungen genügt übrigens eine nochmalige Konfigurationsprüfung (s.o.) mit anschließendem reload: /etc/init.d/nagios reload. Ein Neustart von Nagios ist weder notwendig noch empfehlenswert!
Das WWW-Interface von Nagios
Nagios läuft nun, aber wenn keine Probleme auftreten, werden Sie nichts von Nagios hören. Um jederzeit einen Überblick über das System zu haben, gibt es das WWW-Interface von Nagios, das wir bereits (s.o.) konfiguriert haben. Sie greifen darauf über http://<nagios-servername>/nagios zu (siehe [4], Abschnitt 3.3):
Unter Monitoring sehen Sie nach erfolgreicher Anmeldung aus verschiedenen Blickwinkeln den Zustand der überwachten Hosts und Dienste, auf die Sie laut CGI-Konfiguration zugreifen dürfen. Sie können sich auch eine Zusammenfassung der aufgetretenen Service- und Host-Probleme anzeigen lassen:
Unter Reporting können Sie sich Überwachungsreports über verschiedene Zeiträume ausgeben lassen:
Unter Configuration erhalten Sie eine tabellarische Darstellung Ihrer Konfiguration.
Über das WWW-Interface lässt sich Nagios sogar in Grenzen steuern: Dazu müssen Sie in der zentralen Konfigurationsdatei nagios.cfg den Parameter check_external_commands=1 gesetzt haben. Dann können Sie den Zustand eines Checks manuell beispielsweise mehrmals auf Critical setzen und dem System damit einen Störfall vorgaukeln. So können Sie prüfen, ob die Benachrichtigungsmechanismen im Ernstfall wirklich fuktionieren.
Der Nagios Remote Plug-In Executor (NRPE)
Bisher wurden nur Service-Checks beschrieben, die zentral vom Server aus durchgeführt wurden. Nagios bringt aber auch einen Mechanismus mit, der dezentral auf einem überwachten System auf Anfrage des Nagios-Servers ein lokales Plug-In ausführt und dessen Resultat an den Nagios-Server zurückmeldet. NRPE-Plug-Ins sind auch für Microsoft-Betriebssysteme erhältlich und die beste Methode, diese zu überwachen.
Abschließende Bemerkungen und Ausblick
Es ist weder möglich noch beabsichtigt, Nagios in diesem Artikel umfassend darstellen. Viele interessante Aspekte mussten aus Platzgründen weggelassen werden. Dazu gehören z.B. die "Event Handler", die bei Erreichen eines kritischen Zustands Kommandos ausführen können wie z.B. den Neustart des WWW-Services.
Einen sehr guten Artikel über Nagios 1.3 mit weiteren technischen Details finden Sie in Ausgabe 3/2006 der Zeitschrift c't [5]. Wenn Sie schließlich Nagios professionell für größere Netze einsetzen möchten, finden Sie im Buch von Barth [4] erschöpfende Informationen.
Wir hoffen, dass wir Ihnen einen ersten Eindruck über die Leistungsfähigkeit von Nagios vermitteln konnten. Uns im Universitätsrechenzentrum jedenfalls hat das Produkt überzeugt. Daher werden wir Nagios als weiteren Service für Sie nun auch im Produktionsbetrieb auf unserem Campus einsetzen.
Literatur:
[2] http://nagiosplug.sourceforge.net/
[4] Wolfgang Barth, Nagios, System- und Netzwerk-Monitoring, Open Source Press GmbH, München, 2005
[5] Götz Rieger, Netzwerk unter Kontrolle, c't 3/06, S. 206-211
[7] http://lists.sourceforge.net/lists/listinfo/nagiosplug-help
[8] http://linux.swobspace.net/projects/nagios/nagioscfg.html (WWW-Seite zu [4])
[9] http://www.rz.uni-hohenheim.de/~genzel/
Ansprechpartner im URZ: | Zimmer: | Telefon: | Mail: |
Bernhard Brandel | IN: HB-204 | -1888 | bernhard.brandel |
Tomasz Partyka | EI: eO-107 | -1668 | tomasz.partyka |