© Christian Hänsel/pixelio.de

Seit Mitte Dezember letzten Jahres ist der erste Release Candidate verfügbar, nun steht die stabile Version Nagios 3.0 unmittelbar vor der Veröffentlichung. Ihr Chefentwickler, Nagios-Erfinder Ethan Galstad, schildert in diesem Beitrag, welche Neuerungen auf die Admins warten.

Nagios 3 bietet in Sachen Performance und Flexibilität die bisher größten Fortschritte in der neunjährigen Nagios-Geschichte [1]. Ich bin überzeugt, dass jeder, der heute mit Nagios 2 oder einer früheren Version arbeitet, davon profitiert. Die Installation geht nun noch leichter von der Hand und es lassen sich noch größere Umgebungen überwachen.

Neuerungen für Plugins

Die Plugin-Schnittstelle in Nagios 3 bietet endlich eines der Features, das die Anwender in den letzten Jahren am häufigsten verlangten: mehrzeilige Ausgaben für Plugins, die damit mehr Status-informationen oder Performancedaten zurückgeben können. Diese Änderung haben die Entwickler so implementiert, dass die Kompatibilität mit älteren Plugins gewahrt bleibt.

Gelockert haben sie auch die Beschränkungen für die Datenmenge, die ein Plugin insgesamt liefern darf. Nagios 3 akzeptiert nun bis zu 4 KByte Daten, bevor es den Output beschneidet, um sich vor Überflutung zu schützen.

Weitere Neuerungen betreffen den optional eingebetteten Perl-Interpreter. In der Vergangenheit integrierten einige Distributoren diesen Interpreter per Default in ihre Nagios-Pakete. Das führte zu Problemen, weil zum einen nicht alle Plugins mit ihm laufen und zum anderen der Interpreter selbst häufig Memory Leaks verursachte. Um dieses Problem zu lösen, braucht der Admin nun nicht mehr länger Nagios aus den Quellen selbst zu kompilieren, sondern er kann den Interpreter mit einer Konfigurationsoption abschalten.

Außerdem lassen sich Plugins, die mit dem eingebauten Perl nicht zurechtkommen, nun mit einer Direktive versehen, die bestimmt, dass ein externes Perl sie ausführt. Das ist besonders dann nützlich, wenn der Anwender nur ausnahmsweise auf einen externen Interpreter ausweichen will, in allen andren Fällen aber die höhere Performance der eingebauten Version vorzieht.

Benutzer-Variable

Mit Nagios 3 erhält der Anwender die Möglichkeit, eigene Variablen in Host-,Service- und Kontakt-Definitionen zu verwenden. Diese benutzerdefinierten Variablen speichern zusätzliche Informationen, die zum Beispiel bei der Zusammenarbeit von Nagios mit anderen Applikationen – etwa Trouble-Ticket-Systemen – nützlich sind. Auf die Werte der Variablen greifen Makros zu, sodass sie in eigenen Kommandos für Checks, Benachrichtigung oder Ereignis-Behandlung verwendbar sind. Ein Beispiel könnte so aussehen:

define host{
 host_name      linux-server
 ; Custom MAC_ADDRESS variable;
 _mac_address   00:06:5B:A6:AD:AA
 ; Custom INVENTORY_ID variable:
 _inventory_id  A03569J
 ; Custom LOCATION variable:
 _location      Room 451, Lessig Hall
 ...
}

Obwohl Nagios selbst die besonderen Variablen nicht nutzt, gibt es sie an externe Applikationen weiter. Ein Benachrichtigungs-Skript wäre so etwa in der Lage, den Admin darüber zu informieren, wo der ausgefallene Server steht.

Mehr Zeit-Einstellungen

Die Definitionsmöglichkeiten für Zeitperioden haben in Nagios 3 eine wesentlich Erweiterung erfahren und erlauben jetzt sehr viel flexiblere Einstellungen für geplante Wartung, Ferienzeiten oder etwa die Rufbereitschaft.

In den Vorgängerversionen war der Admin auf die Festlegung von Arbeitstagen beschränkt, die sich jede Woche ohne Ausnahme wiederholten. Nun sind auch Ausnahmen möglich. Solche Abweichungen dürfen sich in der neuen Version auf bestimmte Tage eines Monats, einzelne Kalendertage oder Folgen von Tagen beziehen, wie das Listing 1 demonstriert.

01 define timeperiod{
02         timeperiod_name         samples
03 
04         ;### Normal rotating weekdays
05         sunday   00:00-24:00         ; Every Sunday of every week
06 
07         ;### Single days/dates
08         monday 3 00:00-24:00         ; Dritter Montag jeden Monats
09         day 2    00:00-24:00         ; Zweiter Tag jeden Monats
10         february 10 00:00-24:00      ; February 10th of every year
11         february -1 00:00-24:00      ; Letzter Februartag des Jahres
12         friday -2 00:00-24:00        ; Zweiter bis letzter Freitag
13                                        jeden Monats
14         thursday -1 november 00:00-24:00; Letzter Donnerstag
15                                        im November jeden Jahres
16         1999-01-28  00:00-24:00      ; 20. Januar 1999
17 
18         ; ### Day/date ranges
19         2007-01-01 - 2008-02-01 00:00-24:00  ; 1.1, 2007 - 1.2. 2008
20         monday 3 - thursday 4 00:00-24:00    ; Dritter Montag bis vierter Donnerstag/Monat
21         day 1 - 15  00:00-24:00              ; 1. bis 15. Tag jeden Monats
22         day 20 - -1 00:00-24:00              ; 20. bis letzter Tag im Monats
23         july 10 - 15 00:00-24:00             ; 10. bis 15. Juli jeden Jahres
24         april 10 - may 15   00:00-24:00      ; 10.4. bis 15.5. jeden Jahres
25         tuesday 1 april - friday 2 may 00:00-24:00 ; Erster Dienstag
26                                 bis zweiter Freitag im Mai
27 ; ### Day/date ranges with skip intervals
28         : Jeder driite Tag vom 1, Januar bis zum 1. Februar:
29         2007-01-01 - 2008-02-01 / 3 00:00-24:0
30         ; Jeder siebente Tag ab dem 1. April 2008 (für immer):
31         2008-04-01 / 7   00:00-24:00
32         ; Jeder zweite Tag zwischen 3. Montag und dem 4. Donnerstag/Monat
33         monday 3 - thursday 4 / 2   00:00-24:00
34         ; Alle fünf Tage zwischen dem 1. und dem 15. jeden Monats:
35         day 1 - 15 / 5       00:00-24:00
36         ; Jeder zweite Tag zwischen dem 10. und 15. Juli jeden Jahres:
37         july 10 - 15 / 2            00:00-24:00
38         ; Alle sechs Tage zwischen dem 1, Dienstag und dem zweiten
39         ; Freitag jeden Jahres
40         tuesday 1 april - friday 2 may / 6  00:00-24:0
41         }

Die neuen Möglichkeiten, Zeiträume festzulegen, machen es einfach, ein rotierendes Schichtsystem für die Admins abzubilden, die Rufbereitschaft haben. Wechseln sich beispielsweise John und Bob im Wochenrhythmus damit ab, dann könnte ein entsprechender Zeitplan so aussehen:

define timeperiod{
timeperiod_name john-oncall
;alle 14 Tage ab 3.1.2006
2008-02-03 / 14 00:00-24:00
;jeder zweite Montag ab 4.2.2008
2008-02-04 / 14 00:00-24:00
;jeder zweite Dienstag ab 5.2.2008
2008-02-05 / 14 00:00-24:00
;jeder zweite Mittwoch ab 6.2.2008
2008-02-06 / 14 00:00-24:00
...
}

Für Bob lässt sich ein entsprechender Zeitplan definieren, der den Rest der Zeit abdeckt. Die Kontakt-Definitionen nähmen dann folgendermaßen auf diese Zeitpläne Bezug:

define contact{ 
   contact_name john 
   host_notification_period john-oncall    
   service_notification_period john-oncall  
   ... 
}

Ändert sich der Wechselrhythmus nicht, ist das schon alles, um die Zeitpläne für John und Bob bis in alle Ewigkeit festzulegen. Komplexere Schemata, die auch Feiertage und Ferien berücksichtigen, finden sich in der Nagios-Dokumentation [2]. Derartige Zeitpläne ließen sich in früheren Nagios-Versionen überhaupt nicht anlegen, sodass die neuen Möglichkeiten sicherlich all denen Erleichterung verschaffen, die sich bis jetzt mit separaten Skripten und Ähnlichem behelfen mussten.

Benachrichtigungen

Auch die Logik für Benachrichtigungen ist mit Nagios 3 deutlich flexibler und einfacher geworden. Statt oder neben Kontaktgruppen kann der Admin jetzt auch individuelle Kontakte definieren – zuvor musste ein Kontakt immer zu mindestens einer Gruppe gehören.

Außerdem ist es nun möglich, Benachrichtigungen zu verzögern. Das ist beispielsweise für kurzzeitige, flüchtige Probleme in nicht besonders kritischen Systemen nützlich. Hier erledigt sich die Störung möglicherweise von selbst, bevor Nagios den verzögerten Alarm auslöst. Auch wer sich nicht mitten in der Nacht beim ersten Anzeichen einer Störung aus dem Bett klingeln lassen will, kann sich dieser Technik bedienen. Ähnliches gilt für geplante Auszeiten.

Schließlich kann Nagios 3 nun auch einen Alarm auslösen, wenn es wiederholte Statuswechsel eines Service erkennt, ein Anzeichen, dass der Dienst zu flackern beginnt. Das Beispiel in Listing 2 zeigt, wie die neuen Optionen zu verwenden sind.

01 define host{
02  host_name development-web-server
03  ;Individual contacts to notify
04  contacts bob,john
05  ;Contact groups to notify
06  contact_groups admins,developers
07  ;Delay the first problem
08  ;notification for 10 minutes
09  first_notification_delay 10
10  ;Notify on all events, ncluding flapping
11  ;and scheduled downtime events
12  notification_options   d,u,r,f,s
13  ...
14 }

Ein anderes neues Feature der Benachrichtigungs-Logik sind die benutzerspezifischen Benachrichtigungen (Custom Notifications). Sie lassen sich über das Webinterface oder ein externes Kommando auslösen und erlauben es, wichtige Statusinformationen mehreren zuzuleiten. Dadurch muss man im Notfall nicht mehr nach Pager- oder Handy-Nummern oder Ähnlichem kramen – wenn diese Informationen in der Nagios-Konfiguration hinterlegt sind.

Nagios kann dann bei einem kritischen Ereignis automatisch einen bestimmten Personenkreis benachrichtigen und sich dafür über die ansonsten geltenden Beschränkungen hinwegsetzen. Zwei Optionen erlauben es ihm, von der normalen Logik abzuweichen:

• Der Admin kann bestimmen, dass die Benachrichtigung einer
  Gruppe von Kontakten zugeht, und zwar unabhängig davon, ob
  andere Einstellungen festlegen, dass manche dieser Personen zu
  dieser Zeit mit gewöhnlichen Meldungen nicht zu behelligen
  sind (Abbildung 1).
• Der Admin kann die benutzerspezifische Meldung per Broadcast an
  alle erreichbaren Kontakte verschicken, die für diesen Host
  oder Service konfiguriert sind. Das hilft besonders bei
  Notfällen, wenn es darauf ankommt, alle Beteiligten so schnell
  wie möglich in Kenntnis zu setzen.

Abbildung 1: In Notfällen benachrichtigt Nagios einen erweiterten Personenkreis und setzt sich dabei über Beschränkungen hinweg, die für den Regelbetrieb gelten.

Komplett überarbeitete Host-Checks

Eine der bedeutsamsten Verbesserungen überhaupt – insbesondere mit Blick auf die Performance – bringen die vollständig überarbeiteten Host-Checks mit sich. In den Vorgängerversionen waren diese Host-Checks für viele Admins ein gefürchtetes Nadelöhr, besonders bei Netzwerkausfällen in sehr großen Umgebungen. In dieser Situation konnte sogar das komplette Monitoring durch eine Flut vergeblicher Kontaktversuche nahezu zum Stillstand kommen. Das Entwicklerteam hat aus diesem Grund den größten Teil des dafür verantwortlichen Code überarbeitet. Das Resultat sind etliche Verbesserungen:

Cached Host-Checks: Nachdem Nagios einen Statuswechsel entdeckt hat, initiiert es normalerweise eine aktive Überprüfung des betroffenen Hosts, um den aktuellen Status zu verifizieren und die richtigen Benachrichtungen anzustoßen beziehungsweise die richtigen Eventhandler aufzurufen. Während dieser On-Demand-Checks setzt es andere Kontrollen so lange aus, bis es sich über den Zustand des kritischen Hosts im Klaren ist. Geraten gleichzeitig sehr viele Hosts in diese Lage, bildet sich der schon beschriebene Engpass.

Ein neues Caching-Feature erlaubt es der Nagios-Version 3 nun, auf solche Checks wenn möglich zu verzichten. Die neu hinzugekommene Option »cached_host_check_horizon« ermöglicht dem Admin festzulegen, innerhalb welches Zeitraums Nagios die Ergebnisse zurückliegender Host-Checks als noch gültig ansehen und daher auf eine neuerliche Überprüfung verzichten soll.

Stellt der Admin diesen Zeithorizont auf beispielsweise 30 Sekunden ein, dann sieht Nagios im Fall eines On-Demand-Checks zuerst nach, wie alt die letzte Statusmeldung von diesem Host ist. Ist sie jünger als eine halbe Minute, geht Nagios davon aus, dass ihr Ergebnis noch gültig ist, verzichtet auf den Check und spart damit entsprechend Ressourcen. Nur wenn das neueste Ergebnis älter als eine halbe Minute ist, sieht Nagios neuerlich nach.

Cached Hosts-Checks sind allerdings kein Allheilmittel, sondern eher ein Kompromiss zwischen Genauigkeit und Performance: Ein größerer Zeithorizont verbessert zwar die Performance, senkt aber die Zuverlässigkeit der Statusinformationen. Beide Effekte muss der Admin ausbalancieren.

Parallele Host-Checks: Nagios 2 und frühere Versionen führten Host-Checks immer nacheinander aus. Das hielt den gesamten Monitoring-Prozess auf und führte besonders in großen Installationen zu Performance-Problemen. Nagios 3 dagegen kann die meisten dieser Kontrollen parallelisieren. Kombiniert mit den gecachten Checks verwandelt sich die alte Engstelle sogar in einen Beschleuniger.

Besonders wirkungsvoll erweist sich diese neue Fähigkeit bei den so genannten Re-Checks, also jenen Prüfläufen, die Nagios in konfigurierbarer Anzahl anstößt, bevor es einen erkannten Statuswechsel endgültig weitermeldet. Auch diese Checks können nun parallel zu den übrigen Monitoring-Prozessen ablaufen und beeinträchtigen die Performance nicht mehr.

Bessere Routen-Erkennung: Erkennt Nagios einen Statuswechsel bei einem Host im Netzwerk (worunter in diesem Fall typischerweise ein Router, Switch, Hub oder Ähnliches zu verstehen ist), dann löst es ebenfalls eine Überprüfung der von ihm abhängigen Geräte (der logischen Eltern und Kinder) aus.

Das ist einerseits erforderlich, um Netzwerkausfälle frühzeitig zu erkennen, und erlaubt es zum anderen, die wichtige Unterscheidung zwischen einem ausgefallenen und einem unerreichbaren Host zu treffen. Den Ablauf illustriert die Abbildung 3: Wird beim Check ein Statuswechsel bei Switch-A erkannt, überprüft Nagios rekursiv auch dessen Eltern und Kinder.

Die Routen-Erkennungslogik in Nagios 3 übertrifft die seiner Vorgänger, indem sie alle möglichen Zweige in kürzester Zeit erkennt und testet. Die Vorgängerversionen übersahen zuweilen einzelne Zweige im ersten Schritt, was den ganzen Prozess verzögerte. Auch bei der Geschwindigkeit hat die neue Version die Nase vorn. Früher lief der ganze Prozess zur Verfolgung aller Wege seriell ab, was bei großflächigen Ausfällen zu hohen Latenzen führte. Nagios 3 unterteilt den Prozess nun in einzelne Schritte, die es parallelisieren kann.

Abbildung 2: Neuerdings kann Nagios das Ergebnis eines Host-Checks für eine einstellbare Zeit als gültig betrachten und während dieser Periode auf eine neuerliche Überprüfung verzichten. Das spart Ressourcen – allerdings zu Lasten der Genauigkeit.

Abbildung 3: Ändert sich der Status von Switch A, verfolgt Nagios alle von ihm ausgehenden Wege und überprüft die mit ihm verbundenen Hosts rekursiv.

Statusfragen

Eine der Herausforderungen, vor denen Admins in verteilten oder redundanten Nagios-Umgebungen mit mehreren Nagios-Servern stehen, ist die Normalisierung der Netzwerk-Sichten der einzelnen Server. Befinden sich die Server in unterschiedlichen Subnetzen, was oft notwendig und sogar empfehlenswert ist, kann das zu Differenzen in ihrer Sicht auf die zu beobachtenden Hosts und das Netzwerk führen.

Ein Beispiel beschreibt die Abbildung 4. In diesem Setup haben die beiden Hosts Nagios-A und Nagios-B eine unterschiedliche Sicht auf das Netzwerk. Gesetzt den Fall, Router-A und Router-C fallen aus, dann wertet Nagios-A den Router-A als »Down« und Router-C als »Unreachable«, Nagios-B dagegen sieht Router-A als »Unreachable« und Router-C als »Down«. Tauschen sich Nagios A und B nun über ihre Beobachtungen aus, wie das in einer verteilten oder redundanten Umgebung unumgänglich ist, kommt es zum Konflikt.

Abbildung 4: Welcher Router ist ausgefallen, welcher unerreichbar? Das hängt vom Standpunkt ab. Nagios 3 löst Konflikte, die sich in verteilten Umgebungen aus der unterschiedlichen Sichtweise ergeben.

Nagios 3 löst dieses Problem mit Hilfe der Option »translate_passive_host_checks«, die solche vom Standpunkt abhängigen Sichtweisen der beiden Hosts ineinander übersetzt, sodass zwischen den Hosts ein Konsens über die Lage der Dinge entsteht.

Was bringt die Zukunft?

Nagios 3 beinhaltet noch zahlreiche weitere Verbesserungen, über die der Abschnitt “What\’s new?” in der offiziellen Nagios-Dokumentation detailliert Auskunft gibt [2]. Was kommt aber jetzt als Nächstes? Die Entwickler wollen sich im Laufe des Jahres auf das geplante neue Webinterface konzentrieren. Die aktuelle Oberfläche hat sich in den vergangenen neun Jahren kaum verändert und hat damit ein neues Design redlich verdient. Künftig soll sie im modernen Look erscheinen, vom Anwender mit Stylesheets und Themes dem eigenen Geschmack anpassbar sein, mit einigen Ajax-Tricks aufwarten und die Integration der zahlreichen Nagios-Addons noch weiter erleichtern. (jcb)