Performance und Handling großer Nagios-Infrastrukturen vereinfachen

Nagios hängt in den Seilen. Das weltweite Netzwerk des Chemiekonzerns erfordert eine fünfstellige Anzahl von Checks pro Minute, eine schier unmögliche Aufgabe für den Monitoring-Server [1]. Experten gehen davon aus, dass heutige Maschinen etwa zwei- bis dreitausend Checks pro Minute schaffen, mehr gilt als schwierig. Spätestens wenn die Überwachung eine heterogene Landschaft aus Windows-, Linux- und Unix-Servern sowie diversen Appliances umfasst, stoßen auch der Nagios Remote Plugin Executor (NRPE, [2]) und die klassischen Nagios-Strukturen an ihre Grenzen.

Pflegebedürftig

Damit nicht genug: Das Monitoring für ein derart großes Netzwerk zu konfigurieren und zu pflegen bedeutet eine Menge Aufwand. Bei Änderungen muss der Admin sowohl am Client als auch am Nagios-Server die Konfiguration von Hand aktualisieren. Sind an verschiedenen Standorten mehrere Admins im Spiel, kommt einiges an Kommunikation und Organisation hinzu, um die Einträge immer auf dem aktuellen Stand zu halten. Aufwand und Kosten steigen exponentiell mit der Anzahl der Niederlassungen, Hosts und Admins.

Deshalb fing der Münchner Mathias Kettner 2008 an, für einen Kunden ein neuartiges Nagios-Plugin zu entwickeln, das all diese Probleme auf einen Schlag lösen soll. Seit April 2009 ist seine Arbeit als Check_mk [3] unter der GPL frei verfügbar. An Dokumentation und Entwicklern fehlt es zwar eindeutig noch, doch die "gute Akzeptanz" in der Community stimmt ihn optimistisch.

Zusammengefasst

Sein Konzept ist denkbar simpel: Wie beim Nagios-Plugin Check_multi [4] tritt als Client-Agent an die Stelle zahlreicher einzelner Nagios-Checks ein einfaches Shellskript, das seine Ergebnisse per Passive Check an den Server übergibt. Pollt sein Gegenpart auf dem Nagios-Server den Client, spuckt dieser alle Ergebnisse auf einen Schlag an den Server aus (Abbildungen 1 und 2). Zusätzlich erkennt der Agent auf Wunsch selbst, welche Services auf dem Host laufen, eine Konfiguration ist nicht nötig.

Die Rechnung ist einfach: Anstelle einer Verbindung pro Check kann dieses System Hunderte von Checks mit einer Verbindung erledigen. Und weil Check_mk auf dem Nagios-Server auf Wunsch automatisch für jeden Client maßgeschneiderte, vorkompilierte Python-Programme erstellt, ergibt sich laut Entwickler ein Performance-Boost um das Drei- bis Vierfache im Vergleich zum normalen Nagios-Setup, bei dem der Server auf Dauer immer länger werdende Konfigurationen parsen muss.

Abbildung 1: Wenn Nagios seine Hosts abklappert, ist pro Check eine Verbindung notwendig.

Abbildung 2: Der Check_mk-Agent übermittelt Hunderte Ergebnisse auf einmal, auf dem Server erledigt für jeden Host ein individuelles Python-Programm die Auswertung und übergibt die gesammelten Daten.