Es gibt einen zweiten Teil, der fast drei Jahre danach einfach fällig war.

In den letzten Wochen habe ich oft an die ersten Nagios™ Konferenzen (TM) und die vielen Gespräche von damals denken müssen. Ethan hatte über drei Jahre den mehr oder weniger gleichen Foliensatz dabei und die Nerds der Community haben sich meist fünf Minuten nach dem Opening auf dem Gang versammelt um sich wahnsinnig darüber aufzuregen, dass es wieder nichts Neues gibt. Eine Core-Alternative zu Nagios gab es nicht und so wurde all das, was Nagios nicht ordentlich erledigt hat, mit selbstgestrickten Add-ons erledigt. Der frühere NetSaint bzw. Nagios-Core hätte vermutlich mit so manchem Heimnetzwerk des ein oder anderen Bloglesers von heute Schwierigkeiten gehabt, aber es waren ja bekanntlich auch andere Zeiten. Auch die NDOUtils waren (sind es heute noch) ein absoluter Schrott und haben den Ruf von Datenbanken in der Nagios/Icinga – Community nachhaltig beschädigt. Das vielen kleinen Schwächen die Nagios damals hatte sind mit Sicherheit Hauptgrund dafür, dass es heute eine gigantische Community gibt, die sich für die eigenen Erweiterungen schon immer mehr begeistern konnte, als für eine fertig installierbare.

choose

2009 ist es einigen der deutschen Nagios-Community (wir waren sogar Advisors… uuuuuuh) zu doof geworden und wir haben Nagios geforked. Dafür haben wir damals viel Lob aber auch Prügel bezogen und mussten gefühlt 100.000 mal erklären, warum und wieso es dazu gekommen ist. Gut fünf Jahre später gibt es unzählige Alternativen zu Nagios und nahezu alles ist besser als die ursprüngliche Lösung. Neben der Liebhaberei für das eigene Projekt und da bin ich als Icinga-Fred natürlich nicht ganz unabhängig, gehört es jedoch zu meiner regelmässigen Aufgaben einen Blick auf die alternativen Lösungen zu werfen. Dabei möchte ich nicht auf die vielen “Core-Veredler” eingehen, die das System für ihre Produkte verwenden, sondern auf die wirklich zugrundeliegenden Projekte.

Nagios

Während ein Nagios 3 (und das gilt mit Ausnahme von Shinken eigentlich für alle Cores) ohne Addons schnell an seine Lastgrenzen gestossen ist, hat Nagios 4 mit seinem Workerkonzept hier den größten Schmerz beseitigt. Im Vergleich zu allen bisherigen Änderungen ist der Schritt zu Nagios 4 mit Sicherheit der richtigste und wichtigste in den letzten Jahren. Für die einfache Überwachung ist Nagios so noch immer eine gute Alternative, da man nahezu unter jedem Stein einen Admin findet, der sich damit auskennt und die Marke Nagios auch die nächsten Jahre noch die stärkste Verbreitung haben wird. Vermutlich wird in 10 Jahre noch der ein oder andere Fork als “nagiosähnlich” an den Vorgesetzten verkauft, um die Entscheidung positiv zu beeinflussen.

Wer Enterprise-Features möchte muss eigentlich Nagios XI kaufen, aber das ist aus meiner Sicht das Geld nicht wert. Wer ein kommerzielles Produkt/Veredeler sucht, sollte sich da eher Op5 Monitor oder OpsView ansehen, denn das Produkt aus Minnesota ist totaler Murks.

Naemon

Naemon ist der jüngste Fork in der großen Familie und dürfte sich aus Sicht des Sourcecodes noch nicht groß von Nagios 4 unterscheiden. Neben dem persönlichen Zorn von Andreas Ericsson, dem man nach getaner Arbeit in den Hintern getreten hat, ist die Unabhängigkeit zu Nagios auch for Op5 von nicht unerheblicher Bedeutung. Der früherer Partner Nagios hat sich gerade in den USA zu einem Konkurrenten entwickelt und Op5 agiert dort sehr erfolgreich. In beiden Motivationen sehe ich jedoch nichts Negatives, da die schwedischen Kollegen auch viel Geld in die Entwicklung investieren und daraus viele auch mit Nagios oder Merlin profitiert haben. Mit Thruk als Standardinterface und einer inkludierten Livestatus-Schnittstelle verlässt Naemon etwas die Core-Ecke und man wird in den nächsten Monaten sehen wie es weitergeht. Der Kompromiss zwischen Kompatibilität und Innovation ist eine Bürde, die wir auch bei Icinga immer wieder tragen müssen.

Shinken

Shinken wurde vor einigen Jahren auch als Core-Replacement auf der Devel-Liste vorgeschlagen und führte nach Ablehnung zu einem eigenen Projekt. Das Nagios die Python basierte Entwicklung nicht angenommen hat, kann ich durchaus verstehen, denn wir würden einen Java-Rewrite in Icinga auch ablehnen (zumindest vermute ich das). Die Geschwindigkeit mit der Shinken in den ersten Monaten neue Features und Code rausgekurbelt hat, war ehrlich gesagt beängstigend, aber in der Zwischenzeit ist es deutlich ruhiger geworden. Während Shinken in Frankreich nach wie vor sehr erfolgreich ist und Jean Gabès auch eine Firma gegründet hat, dümpelt es außerhalb der Grand Nation etwas vor sich rum. Warum Shinken nicht den Erfolg hat, den es aus Sicht der technischen Neuimplementierung und Performance haben könnte, liegt aus meiner Sicht an drei Gründen. Eine Hürde ist das entkoppelte Architekturkonzept, dass fachlich begründet und berechtigt, für viele Nutzer in kleineren Umgebungen aber zu kompliziert und fehleranfällig ist. Logischerweise möchte jeder ein Tool der Enterprise-Klasse entwickeln, aber 90% der Anwender haben eben nicht mehr als 100 Hosts und da reicht ein simpler Core einfach aus. Gerade die ersten Versionen hatten noch mit erheblichen Code-Quality-Problemen und Memory-Leaks zu kämpfen, die uns von weiterer Verwendung etwas abschreckten. Das dritte Problem ist die französische Sprache. Zwar sind Website und Dokumentation in Englisch vorhanden, jedoch findet ein Großteil der Community-Kommunikation in Französisch statt. Das ist zwar romantisch, sperrt jedoch viele Nutzer aus und bindet sie nicht an das Projekt.

OMD

Eigentlich ist OMD ja eher eine Veredelung aber aufgrund der großen Verbreitung gehört es einfach in diesen Post. OMD ist eine charmante Alternative, welche die Installation von Core und Add-ons vereinfacht und auch mehrere Instanzen parallel verwalten kann. In Bezug auf Komfort können sich viele Core-Projekte hier eine Scheibe abschneiden, da es einem wirklich einfach gemacht wird, zwischen verschiedenen Cores zu wechseln, Instanzen zu löschen oder neu anzulegen. Um dies anbieten zu können, ist OMD aber auch gezwungen verschiedene Kompromisse einzugehen. So werden alle Add-ons und die dafür notwendigen Libraries mit OMD geliefert, um für eine reibungsloses Zusammenspiel zu sorgen. Dieser Luxus umschifft jedoch auch die eigentliche Systempacketierung und deren Sicherheits- und Updatemechanismen. Wer also mit Yum oder Apt ein Update einspielt, aktualisiert eben nicht die vom OMD-Paket verwendete Version. Dies gilt unabhängig von OMD natürlich auch für alle anderen Cores und Add-ons die ohne Paketierung aus den Sourcen kompiliert oder von Github geklont werden. Aktuell ist OMD natürlich auch von der überwiegenden Kompatibilität der verwendenden Komponenten abhängig, damit sich Core und Oberfläche nach belieben konfigurieren lassen. An einigen Stellen ist die Veränderung des Cores schon heute nicht mehr ohne Änderungen möglich, wenn alternative Features von bspw. Shinken verwendet werden. Da unterschiedliche Projekte und Teams langfristig zu Differenzierung führen, wird die Zukunft zeigen, welche Cores und Oberflächen langfristig Teil von OMD bleiben.

Check_MK

Aus dem eigentlichen Plugin zur Optimierung von Client-Checks ist in den letzten Jahren ein eigenes Ökosystem entstanden. Mit Livestatus hat Mathias einen De-facto-Standard für den Core-Zugriff geschaffen, den auch andere Projekte wie Icinga2 und Naemon unterstützen müssen. Mit verschiedenen Erweiterungen für die Überwachung von Events, Geschäftsprozessen und Management der Konfiguration ist das Projekt zunehmend unabhängiger von anderen Add-ons und ein eigener Micro-Core, der die notwendigen Restarbeiten übernimmt ist bereits vorhanden, jedoch Subskriptionskunden vorbehalten. Das mehr und mehr Features in dem geschlossen System isoliert sind, macht es für den Nicht-Linux-Admin zwar einfacher, erschwert aber auch zunehmend die Integrations- und Erweiterungsmöglichkeiten. Der Nutzer muss sich hier klar zwischen einem hochintegrierten, aber auch starren System auf der einen und einem komponentenbasierten System, mit etwas weniger Komfort auf der anderen Seite entscheiden. In Bezug auf Usability gilt für check_mk die nahezu gleiche Argumentation wie für OMD, wobei letzt genanntes sich aktuell der Unterstützung möglichst vieler Komponenten verschreibt. Meiner Meinung nach wird es in naher Zukunft immer schwieriger die vorhandenen und verständlichen Interessen zwischen Produkt auf der einen und Open Source Toolset auf der anderen Seite unter einen Hut zu bringen. Ehrlich gesagt glaube ich aber auch, dass check_mk in der Zwischenzeit eher mit geschlossenen Systemen Op5 Monitor oder OpsView zu vergleichen ist.

Icinga

Icinga hat es sich viele Jahre zur Aufgabe gemacht die vorhandenen Probleme des alten Cores zu eliminieren und den Nutzern darüber hinaus benötigte Features im Bereich Webinterface, Reporting und Usability bieten. Bereits seit 1,5 Jahren arbeitet das Team am Core-Nachfolger Icinga2, welcher in den nächsten Wochen finalisiert und bereits in einigen größeren Installationen eingesetzt wird. Hier ist der Bruch mit der alten Konfiguration mit Sicherheit die größte Herausforderung. Die Unterstützung einer Vielzahl von IP-Adressen pro Host sind nur ein Beispiel für diesen Konflikt. Des weiteren grenzt sich Icinga schon seit dem ersten Tag mit der Unterstützung einer relationalen Datenbank von seinen Begleitern ab und wird dies auch in Zukunft weiter tun. Es wird viel Arbeit notwendig sein um den ein oder anderen Nutzer von dem Sinn zu überzeugen, aber hier Usability und Stabilität wichtige Voraussetzung und outstanding Features hoffentlich Motivation genug. Während sich Nagios, Icinga und Naemon (ggf. auch mit der Unterstützung von mod_gearman und Livestatus) nicht viel nehmen, erfolgt mit Icinga2 ein echter Einschnitt in das seit Jahrzehnten unveränderte Konfigurationsschema. Wenngleich die Community neue Features wünscht, möchte man nicht wirklich große Veränderungen und so wird Icinga2 beweisen müssen, dass sich die Mühe lohnt. Mit nativer Unterstützung von Livestatus und Graphite, einem Cluster-Stack und sehr hoher Performance sind die ersten Schritte gemacht. Unser Augenmerk wird darauf liegen in den Bereichen Usability, Performance und Maintenance ganz vorne zu sein und trotzdem die Türen für andere Add-ons im Ökosystem offen zu halten.

Fazit

Ich spar mir an dieser Stelle eine Zusammenfassung meine Ausführungen und möchte es dem Leser überlassen seinen Schluss daraus zu ziehen. Falls sich jemand falsch behandelt oder missverstanden fühlt, so möge er mir das gerne mitteilen und/oder sich mit einem Kommentar daran beteiligen.

Wer sich nicht entscheiden kann sollte einfach mal alles ausprobieren, ordentlich vergleichen und zum Schluss Icinga nehmen 🙂

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.