Servermonitoring mit Nagios: Build und Konfiguration in Ubuntu
Servermonitoring mit Nagios: Build und Konfiguration in Ubuntu
Um die Verfügbarkeit komplexer IT-Infrastrukturen zu gewährleisten, müssen diese automatisiert überwacht werden. Hierfür gibt es diverse Monitoringsoftware auf dem Markt, eine davon ist Nagios [1]. Nagios vereint eine Sammlung von Modulen, die zur Überwachung, beispielsweise von Netzwerken, Hosts und Diensten, genutzt werden kann. Nagios selbst ist als Software frei verfügbar und steht unter der GNU GPL. Es steht als fertige Binary für diverse Linux-Distributionen zur Verfügung, ebenso besteht die Möglichkeit, den Quellcode von der Website zu beziehen und die Binary selbst zu kompilieren. Dieses Vorgehen möchte ich im folgenden Artikel demonstrieren und eine Anleitung geben, wie Nagios kompiliert und für den ersten Betrieb konfiguriert werden kann. Bevor ich damit startete, gibt es einen kleinen Exkurs zum Aufbau von Nagios, zu den Grundbegriffen und zum Verwendungszweck.
Nagios zeichnet sich dadurch aus, dass es auf einer objektorientierten Konfiguration aufbaut, die sich wie folgt unterteilt:
Hosts
Services
Kommandos
Kontakte
Hosts werden üblicherweise über eine IP-Adresse definiert und angesprochen. Hierbei kann es sich um einen physischen Server, aber auch um einen anderen beliebigen Endpoint handeln, der Services bereitstellt, die es zu überwachen gilt. Services können Dienste oder Eigenschaften sein, die für den Betrieb der IT-Infrastruktur von Bedeutung sind. Das heißt, ein Ausfall oder eine Unregelmäßigkeit dieser Services muss zeitnah signalisiert werden. Oft überwachte Dienste sind z. B. HTTP-Server, Mail- oder Datenbankserver. Nicht nur Dienste können überwacht werden, häufig empfiehlt es sich auch, z. B. den freien Speicherplatz eines Hosts zu überwachen. So können Fehler verhindert werden, die auftreten können, wenn kein Speicherplatz mehr zur Verfügung steht, weil beispielsweise eine Datenbank erhaltene Daten dauerhaft persistieren muss. Die Kommandoobjekte führen die eigentliche Überwachung der Services in definierten Zeitabständen durch und melden, wenn eine nicht erwartete Reaktion der Services auftritt. Gemeldet werden diese Unregelmäßigkeiten oder Ausfälle an Kontaktobjekte. Das können E-Mails sein, SMS oder ein anderer Kommunikationskanal.
Im Anschluss an diese Einführung werde ich aufzeigen, wie ein Nagios-Server aufzusetzen ist. Hierfür benötigt man ein Linux-Derivat, in unserem Fall Ubuntu, den GCC-Compiler und abhängige Komponenten. Zur Auslieferung und Steuerung des Nagios-Servers verwende ich einen Apache-HTTP-Server inklusive PHP-Modul. Mit diesen Komponenten ist der Nagios Core lauffähig, kann allerdings noch keine Hosts oder Services überwachen. Die eigentliche Überwachungsfunktionalität ist in Modulen, den Nagios-Plug-ins, ausgelagert. Diese Plug-ins führen die eigentlichen Überwachungsanfragen aus, z. B. HTTP-Abfragen, um die Erreichbarkeit einer Website zu überwachen.
Nagios bietet dank der Plug-ins mehrere Möglichkeiten der Überwachung an, u. a. Überwachung auf Protokollebene, Überwachung interner Eigenschaften und passive Überwachung. Die Überwachungen auf Protokollebene ermöglichen es, unterschiedlichste Netzwerkgeräte zu überwachen, unabhängig davon, welches Betriebssystem sich auf ihnen befindet. Die Überwachung interner Eigenschaften, die nicht an eine Netzwerkschnittstelle propagiert werden, gestalten sich je nach (Betriebs-)System unterschiedlich schwierig. Abhilfe schaffen hier Dienste wie das Simple Network Management Protocol (SNMP), die interne Eigenschaften zur Überwachung nach außen propagieren.
Die Nagios-Plug-ins melden nach ihrer Beendigung – also der Abfrage eines Dienstes oder eines Hosts – den ermittelten Status als Portable Operating System Interface (POSIX) konform an den Nagios Core.
ok, Wert 0: Das Objekt ist in Ordnung
warning, Wert 1: Es gab eine Warnmeldung
critical, Wert 2: Kritischer Fehler
unknown, Wert 3: Der Status kann nicht ermittelt werden
Bei vielen Plug-ins können Grenzwerte konfiguriert werden, ab wann der Wert 1 (warning) und ab wann der Wert 2 (critical) zurückgeliefert werden soll. So kann z. B. für das HTTP-Plug-in festgelegt werden, dass der Wert 0 bis zu einer Antwortzeit von 0,5 Sekunden, der Wert 1 zwischen 0,5 und einer Sekunde und ab Antwortzeiten größer als eine Sekunde der Wert 2 zurückgegeben wird. Auf diese Weise kann besser eingeschätzt werden, inwieweit ein Fehlerzustand kritisch oder nur eine Ausnahme ist. Steigt im eben genannten Beispiel die Antwortzeit kontinuierlich an, ist eher davon auszugehen, dass ein Problem vorliegt, als wenn es schlagartig und einmalig passiert. Um solche Zustände korrekt zu bewerten, bedarf es einer weiteren Einstellung, die von Nagios als states bezeichnet wird. Liefert ein Plug-in statt 0 eine 2 zurück, setzt Nagios einen soft state und zählt einen Counter hoch. Die Standardkonfiguration...