… geht der Platzhirsch des Opensource-Monitoring langsam in den altersbedingten Ruhestand?

Unter Opensource freundlichen Admins ist Nagios längst ein Synonym für Netzwerkmonitoring, so wie es die Marke Tesa für durchsichtige Kleberollen ist. So auch für uns bei WorNet. Unsere ersten Installationen haben wir vor ca. zehn Jahren betrieben, damals hießen sie noch „Netsaint“, bevor sich das Projekt wegen Markenrechts-Streitereien umbenennen musste. Der Netsaint überzeugte damals durch sein Featurereichtum, seine Zuverlässigkeit und das einfach zu verstehende Konzept. Man konnte sogar auf recht simple Weise eigene Check-Plugins schreiben und einbinden. Auch heute noch ist der Nagios die bekannteste und mit Abstand am häufigsten eingesetzte Monitoring-Lösung, die auch im Enterprise-Segment einen festen Platz innehält. Nagios stellt wohl den defakto Standard für Netzwerk-Monitoring-Systeme dar.

Wem ist nicht schon mal der Gedanke gekommen, dass Nagios nicht mehr State of the Art sein könnte? Denn leider ist seine Technik unter der Haube nicht annähernd so fulminant aufgestiegen, wie seine Popularität. Das Projekt ist anfangs schnell gewachsen und bald stellte sich heraus, dass die Architektur die benötigten Erweiterungen nicht tragen würde, weshalb neue Features nicht in den Code des Nagios-Core aufgenommen wurden, sondern über zahlreiche Schnittstellen als Plugins und externe Dienste beigelegt wurden. Als eine der letzten Core-Features wurden die Notification-Escalations implementiert, sie haben bis heute nicht den eigentlich erforderlichen Reifegrad erhalten. Aber auch modulbasierte Erweiterungen gerieten wenig später ins Stocken, so ist die Datenbankschnittstelle namens NDO-Utils seit dem Jahr 2005 nicht über das Beta Stadium hinaus gekommen.
Vor drei Jahren kam mit Nagios 3.0 die letzte nennenswerte Neuerung heraus. Seitdem hörte man hauptsächlich die entnervte Community darüber klagen, dass eingereichte Patches vom Nagios-Erfinder und einzigem Programmierer Ethan Galstad monatelang unbeachtet liegen gelassen werden, bevor es wenige von ihnen in den Quellcode schaffen. Der Herr des Nagios scheint nicht wirklich an einer Weiterentwicklung interessiert zu sein. Möglicherweise hängt das auch mit seiner kostenpflichtigen Enterprise-Lösung zusammen, die er vertreibt.

Alternativen
Aus heutiger Sicht muss man sich durchaus wundern, warum keines der zahlreichen neueren Monitoring-Projekte, wie z.B. Zenoss, OpenNMS oder Zabbix, die zum Teil deutlich moderner, performanter und einfacher zu handhaben sind, bisher in der Lage war, dem Nagios nenneswert Schneid abzukaufen. Sicherlich hat das mit der riesigen Benutzer- und Entwicklergemeinde zu tun, die sich über die Jahre um das System gebildet hat und unaufhörlich neue Plugins und Addons hervorbringt. Trotzdem finden sich Anzeichen für einen kommenden Umbruch, denn eine Erneuerung ist längst überfällig.

Dass es bald an der Zeit ist, auf eine weniger angestaubte Monitoring-Lösung umzusatteln, ist mir bewusst geworden, als ich letztes Jahr mehrere Anfragen von Kunden zum Thema Monitoring bekam und bei den Recherchen feststellen musste, dass sich die Technik seit nunmehr fünf Jahren kaum verändert hatte. Ich hatte einfach ein schlechtes Gefühl dabei, Technik bei Kunden einzuführen, die wenig weiterentwickelt zu werden scheint, obwohl es sich offensichtlich noch immer um das Standard Werkzeug handelte.
Die Suche nach Alternativen ergab schließlich eine Reihe moderner und lebendiger opensource Projekte. Darunter ein Projekt namens Icinga, das aus Frust über den Entwicklungsstau bei Nagios im Jahre 2009 aus einem Nagios Code-Fork hervorgegangen war. Sie konnten einige gute Entwickler ins Boot holen und der ganzen Angelegenheit neuen Schwung verleihen – Incinga kommt mit einer modernen Ajax-basierten Weboberfläche daher und hat den eigentlichen Nagios auch in anderen Belangen längst hinter sich gelassen. Es lässt sich mit weniger Aufwand installieren und betreiben, weil wichtige Module fester Bestandteil des Pakets geworden sind, die man bisher selbst „hinfrickeln“ musste. Die Konfiguration von Icinga ist derzeit noch zu 100% Nagios kompatibel. Sehr vielversprechend.
Woran aber letztlich auch Icinga krankt, ist der kaum wartbare, über zehn Jahre gewachsene Code und die nicht zeitgemäße Architektur. Auf lange Sicht ist damit nämlich kaum noch ein Blumentopf zu gewinnen. Es wäre längst ein Code-Rewrite fällig gewesen.

Code-Rewrite
Genau diesen Ansatz verfolgte der Franzose Jean Gabès, der vor eineinhalb Jahren als proof of concept eine komplette Neuimplementierung des Nagios in der modernen Scriptsprache Python programmiert hat. Ursprünglich wollte er damit den Nagios-Chef überzeugen, diesen Rewrite als neue Codebasis für kommende Nagios-Versionen zu verwenden. Die wesentlich kleinere Einstiegshürde für neue Entwickler durch den modernen Code und dessen Erweiterbarkeit wären von großem Vorteil gewesen. Ethan Galstad hat den Vorstoß wohl bis heute nicht kommentiert. Aus diesem Grunde hat Jean Gabès begonnen das Projekt unter dem Namen „Shinken“ selbst und als eigenständige Nagios Alternative weiter zu betreiben. Es ist seit Version 0.4 angeblich für den Enterprise Einsatz geeignet.

Shinken
Shinken ist kein monolithisches Tool mehr, sondern wurde in mehreren aufgabenbezogenen Prozessen programmiert. So gibt es mehrere Prozesse, die ohne sich gegenseitig zu blockieren, unabhängig voneinander arbeiten und nicht zwingend auf ein und dem selben Server laufen müssen. Diese Komponenten heißen Arbiter, Scheduler, Poller, Reactionner und Broker; Details kann man auf der Webseite nachlesen. Von Vorteil ist dabei die Möglichkeit auf einfache Weise ein verteiltes System einzurichten. Verteilte Konfigurationsdateien werden, im Gegensatz zum Nagios, von Shinken dann selbst synchronisiert. Als persönliches Monitoring Highlight sehe ich folgendes Feature, das es beim Shinken seit der letzten Release gibt: Zeitbasierte Escalations! Ein weiteres Killerfeature, und eines, das den geplagten Nagios-Escalation Benutzern als Frohe Botschaft präsentiert werden kann. Laut Webseite sind mittlerweile alle bisherigen Features des Nagios in Shinken implementert, was mich voll spannender Erwartung in die Zukunft blicken lässt.

Fazit
Wichtig für eine einfache Migration ist die Kompatibilität zu Nagios an gewissen Stellen. Die mühsam gesammelten, modifizierten oder selbst gestrickten Checkplugins stellen beispielsweise eine wichtige Grundlage dar. Ob die zahlreichen Peripherie-Tools wie zum Beispiel Nagstamon, Nagroid oder das Nagios-Plugin weiterhin einsetzbar bleiben, bleibt zu hoffen.
Vielleicht können wir mit Shinken jedoch endlich ein Ei über die altertümliche Nagiosproblematik schlagen. Zwar habe ich bisher noch keine praktischen Erfahrungen mit Shinken machen können, doch klingt die bisherige Information derart vielversprechend, dass ich die nächste Gelegenheit sicherlich nutzen werde, um diese Möglichkeit, unser Monitoring endlich wieder auf moderne Beine zu stellen, ausgiebig zu testen. Ich werde mich melden, wenn es dazu Erfahrungswerte gibt. Alles in allem ist und bleibt der Nagios jedoch einstweilen das Standard-Monitoring-Tool, auch wenn er früher oder später durch einen vielversprechenden, weil zukunftsträchtigen Shinken oder eines der anderen modernen Projekte verdrängt werden wird. Icinga ist jetzt bereits eine gute Alternative.

Wer übrigens darüber hinaus aufgeschlossen für komplett andere opensource Monitoring-Ansätze ist, der sollte sich eines der anderen beliebten Systeme wie Zenoss, Zabbix oder OpenNMS ansehen.

IT bleibt spannend!

Viele Grüße
Euer Hannes Wilhelm

Quellen:
http://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
http://de.wikipedia.org/
http://www.icinga.org/
http://www.shinken-monitoring.org
http://www.linuxtechnicalreview.de/Foren/Monitoring/Shinken-neues-Nagios-Release-oder-Nagios-Nachfolger