Samstag, 31. Juli 2010


Artikel

Juli 2006 | Artikel

Nagios: Netzwerküberwachung Open Source Fortsetzung, Teil 4

Teil 1   Teil 2   Teil 3   Teil 4   

Host- und Servicegruppen
Hostgruppen werden definiert, um Zustandsanfragen auf eine Hostgruppe anwenden zu können, anstatt jeden einzelnen Host auszuwählen. So kann es z.B. eine Gruppe Linux-Server geben, auf die dann ein Servicecheck die CPU-Auslastung abfragt. Da diese Anfrage für jeden Linux-Server identisch aussieht, bietet sich die Definition über eine Hostgruppe an. Um gerade bei vielen Hosts nicht die Übersicht zu verlieren, lassen sich im Nagios-Webinterface verschiedene Sichtweisen auf die Hostgruppen generieren.
Neu in der Version 2 sind die Servicegruppen, mit denen sich Services über mehrere Hosts hinweg bündeln lassen. Soll z.B. der Geschäftsprozess "Produktion" überwacht werden, lassen sich alle nötigen Dienste, die für die Produktion kritisch sind, überwachen und in einer Servicegruppe zusammenfassen:
  • die Netzwerkverbindungen der involvierten Hosts
  • die SAP-Instanz, z.B. auf einem Windows 2003 Server
  • eine DB2-Instanz auf einem Linux-Datenbankserver
  • ein Etiketten-Drucker
Fällt nun einer dieser Services aus, so wird die Servicegruppe "Produktion" als kritisch gekennzeichnet, der Admin sieht im Webinterface, dass die Produktion steht und kann sofort eingreifen.
Servicecheck
Nach der Einrichtung eines ersten Hosts müssen die zu überwachenden Dienste definiert werden. Im NagiosQL findet sich unter ÜBERWACHUNG | SERVICES die Konfigurationsmaske der Service-Überprüfungen. Abbildung 3 zeigt als Beispiel eine lokale Festplattenplatz-Überprüfung des Wurzelverzeichnisses (/). Oben angefangen, wird zuerst ein Konfigurationsname definiert (unter diesem Namen wird auch das Konfigurationsfile unter /etc/nagios/services abgespeichert). Unter Hostname wird der lokale Host ausgewählt und im Folgenden ein Servicename definiert. Ein sprechender Servicename ist hier wichtig, da dieser später im Nagios-Webinterface angezeigt wird und ggf. auch von Dritten verstanden werden soll. Der Konfigurationsname darf im Gegensatz zum Servicenamen doppelt vorkommen und dient für NagiosQL als eine Art Filter.
Bei den Prüfeinstellungen muss sowohl eine Prüfperiode als auch die Anzahl der maximalen Prüfungen analog zur Host-Konfiguration eingerichtet werden.
Das Prüfintervall wird in OK und Nicht-OK eingeteilt, OK definiert das Zeitintervall zwischen zwei Prüfungen, sofern der erste Check positiv verlaufen ist. Wenn allerdings der erste Check negativ ausfällt, entscheidet der Nicht-OK-Parameter über das Zeitintervall, um den nächsten Check auszuführen. In der Regel sollte dieser Wert deutlich geringer sein als das OK-Prüfintervall.
Der Prüfbefehl check_local_disk steht als Alias für das check_disk- Plug-in, um den lokalen Festplattenplatz auf Linux-Systemen zu überprüfen. Die komplette Befehlsreihe enthält die Variablen bis , die an die Parameter –w (arning) –c (ritical) und –p (artition) geknüpft sind. "Warning" und "Critical" sind die Schwellwerte in Prozent oder aber auch mit Mengenangaben für den noch freien Festplattenplatz, die Partition ist selbsterklärend. Detailliertere Informationen zum check_disk- Plug-in liefert die Hilfe unter /usr/lib/nagios/plugins/check_disk –help.
Nagios – der erste Start
Damit Nagios starten kann, benötigt er alle in der nagios.cfg definierten Konfigurationsdateien, auch wenn diese leer sind. Über NagiosQL sollte in jeder Konfigurationsmaske, sofern nicht schon geschehen, auf KONFIGDATEI SPEICHERN geklickt werden, damit die Konfiguration aus der Datenbank generiert und auf Dateiebene gespeichert wird. Bevor Nagios über die Shell das erste Mal gestartet wird, kann über NagiosQL eine Syntaxüberprüfung aufgerufen werden: WERKZEUGE | NAGIOS STEUERN | KONFIGURATIONSDATEI PRÜFEN. Diese Syntaxüberprüfung ist identisch mit dem Konsolenbefehl linux:# nagios -v /etc/nagios/nagios.cfg.
In großen Umgebungen mit vielen Checks kann die Performance von Nagios noch optimiert werden. Für eine erste Hilfe bei der Optimierung hält Nagios einen Parameter vor, der nach Ausgabe der Performancedaten auch mögliche Optimierungsmöglichkeiten vorschlägt: linux:# nagios –s /etc/nagios/nagios.cfg.
Letztendlich wird mit dem Befehl /etc/init.d/nagios start Nagios gestartet. Sollte Nagios nicht starten, liefert der Syntaxcheck die Fehlermeldungen zurück. Aufgeteilt in "Warning" und "Error", sind Warnungen rein informativ und lassen einen Start von Nagios trotzdem zu. Unter webserver/nagios sollte eine einfache Überprüfung des lokalen Hosts bereits laufen.
Als kurze Exkursion sei im Kasten "NRPE-Installation" die Installation von NRPE unter Linux erläutert, die anderen Überprüfungen mittels SSH und SNMP-Get lassen sich über die Hilfe (check_plugin --help) recht einfach und schnell konfigurieren.
Zum Schluss dieses Artikels sei mein herzlicher Dank noch an Nagios-Erfinder Ethan Galstad gerichtet, der mir bei der Fertigstellung des Artikel geholfen hat. Thanks, Ethan!
Nagios 3 – ein Ausblick
Kurz nach der Veröffentlichung der Nagios 2.0 stable gab Ethan Galstad auch bereits die Eckpfeiler der neuen Version 3 bekannt:
  • Multi-Instanz-Datenbank-Support (Konfiguration, Status- und Eventinformationen)
  • Weboberfläche auf PHP basierend
  • mehrzeilige Ausgabe von Plug-in-Informationen
  • User-definierbare Objektvariablen, wie z.B. Raum 4b, Rack 53.24, Portnummer 21
  • Mehrsprachigkeit
  • anpassbare Themes
  • verbessertes Reporting
  1. http://www.nagios.org
  2. http://sourceforge.net/projects/nagiosplug/
  3. http://www.nagiosexchange.org
  4. http://www.nagiosql.org
  5. http://nagios.sourceforge.net/docs/2_0/flapping.html
  6. http://nagios.sourceforge.net/docs/2_0/whatsnew.html
  7. http://www.miwi-dv.com/nrpent/
  8. http://nsclient.ready2run.nl

Teil 1   Teil 2   Teil 3   Teil 4   

Kommentare