Eine Monitoring-Suite erfüllt mehr Aufgaben, als neu aufgetretene Fehler zu detektieren. Anwender sollten bei der Auswahl nicht zu anspruchslos sein und auch Lösungen abseits von Nagios ins Kalkül ziehen.

Monitoring überwacht nicht nur, ob Server und Dienste in Betrieb sind, sondern auch, ob sich Dienste innerhalb erwarteter Parameter bewegen. Ein Admin möchte beispielsweise die Speicherauslastung eines Storagesystems gecheckt wissen, um rechtzeitig Maßnahmen gegen volllaufende Volumes zu ergreifen. Oder ihn interessiert, dass immer gleiche Anfragen den eigenen Webserver fluten.

Neben dieser technischen Sichtweise, die eine bestmögliche Qualität der Dienste sicherstellen will, gibt es wirtschaftliche Ziele, die Monitoring-Anwender verfolgen. So kann ein Ausfall zu großen Arbeitszeitverlusten führen oder zu einem Imageverlust oder Kunden könnten gar Regressforderungen stellen. Andere setzen Monitoring ein, um notfalls den Beweis führen zu können, dass ihr Dienstleister die zugesicherte Verfügbarkeit (SLA) nicht gewährleistet hat.

Den Status der einzelnen Systeme und Dienste zum aktuellen Zeitpunkt zu überwachen und daraus den Gesundheitszustand der gesamten IT zu bestimmen, das ist Aufgabe des Statusmonitoring – Nagios ist der Platzhirsch auf genau dieser Lichtung. Er benutzt vier Status, um den Zustand eines Objekts zu kategorisieren:

• OK: Der Service läuft innerhalb normaler Parameter.
• Warning: Der Dienst hat einen Schwellenwert überschritten und bedarf weiterer Beobachtung.
• Critical: Der Service überschreitet einen kritischen Schwellenwert, ein Eingreifen der Admins ist notwendig.
• Unknown: Die Überprüfung hat nicht stattgefunden, weshalb keine Einordnung möglich ist.

Nagios setzt die Zustände optisch-intuitiv in eine Ampel-Symbolik um. Da kein Admin während seiner Schicht auf Nagios-Ampeln starren will, bedarf es eines Eskalations- und zumindest Reaktionsmechanismus für den Fehlerfall. Mit Hilfe konfigurierter Benachrichtigungen sendet das System bei einem bestimmten Status automatisch E-Mails oder SMS an eine Empfängerliste.

Speziell an Nagios gefällt der modulare Aufbau: Der Nagios-Kern enthält keine Tests, die Service- und Host-Checks erledigen externe Plugins. Das Setup passiert in Konfigurationsdateien, deren Lesbarkeit mit wachsenden Strukturen leidet.

Langzeitobservation

Überdies möchten manche Systembetreiber Status-quo-Messungen über längere Zeit speichern und einer Trendanalyse unterziehen – eine große Vielfalt an Darstellungsmethoden ist hier wünschenswert. Der Trend erlaubt es, Engpässe frühzeitig zu erkennen und in Ruhe mit neuer Hard- und Software gegenzusteuern. Diese Spielart bezeichnet die Literatur als Verlaufsmonitoring, Munin oder auf Cacti fußende Produkte sind Vertreter dieser Spezies, Check_mk dagegen liefert sowohl eine Verwaltungsoberfläche für Nagios als auch Darstellungen des Langzeitverhaltens.

Bei aller Notwendigkeit weist Monitoring auch Nachteile auf: So übt das Überwachen eines Hosts einen Einfluss auf diesen aus – in kurzen Intervallen ausgeführte Agenten oder Nagios’ Möglichkeit, Programme auf den Untersuchungszielen auszuführen, sind hier zu nennen. Hinzu kommt der Umstand, dass jedes Monitoring nur so zuverlässig arbeitet, wie die Administratoren, die es konfiguriert haben. Gleichwohl: Wegen des technischen Aufwands oder der erforderlichen finanziellen Mittel auf Monitoring zu verzichten, wäre der falsche Weg.

Dass eine qualifizierte Mehrheit auf Nagios setzt, ist sicherlich kein Zufall [1]. Dass es Alternativen gibt, aber auch nicht. Denn einerseits empfinden viele Admins die Nagios-Konfiguration als unnötig komplex, andererseits skaliert das Check-Konzept offenbar schlecht. Das Linux-Magazin hat Leser befragt, wie sie es mit Alternativen halten. Das Ergebnis gibt’s gleich.