Nach ca. 1,5 Jahren dachte ich mir heute das es mal wieder an der Zeit wäre meinen Monitoring-Tool-Vergleich zu aktualisieren. Schließlich musste ich nach 30 Minuten Recherche feststellen, dass mich die Rohrkrepierer der vergangenen Jahre nicht im Stich gelassen haben und weiter mit einem hohen Grad an Inaktivität glänzen. Auch die anderen Projekte blieben im Groben meiner Einschätzung treu und so war ich schon kurz davor meinen Texteditor zu schließen.
Beim Schließen eines der Browser-Tabs bin ich dann jedoch auf ein schönes Video meiner Freunde von Nagios gestoßen und das musste ich einfach verarbeiten. Dazu aber erst am Ende mehr, denn ihr sollt das Ergebnis meiner Arbeit ja auch erstmal lesen.
Wie auch in den vergangenen Posts behandle ich hier nur die Systeme, welche aus dem ursprünglichen Nagios-Ökosystem entsprungen sind. Wer es gerne etwas breiter haben möchte, dem sei der Besuch der diesjährigen OSMC besonders ans Herz gelegt. Noch nie hatten wir so ein vielfältiges und umfangreiches Programm wie 2018 und freuen uns auf viele bekannte aber auch uns unbekannte Referenten. Auf jeden Fall anmelden und dabei sein.
Los geht’s mit einem gekürzten Update und Überblick der aktuellen Landschaft:
Shinken: Im Master gab es dieses Jahr ganze 6 commits und man hat irgendwie den Eindruck das die Luft bei den Freunden etwas raus ist. Auch auf der Enterprise Website sind die letzten News vom April 2016 und ich würde sagen das Ding ist tot. Ich kann mich auch an einige Tweets erinnern, in denen die Entwickler selbst aufeinander los gegangen sind, kann sie jedoch aktuell nicht finden.
Fazit: Ich werde es in Zukunft nicht mehr weiter betrachten, da es sich mit Shinken etwa so verhält wie mit Bratwurstgehäck. Ne gute Idee, wenn es frisch ist, jedoch sollte man die Finger davon lassen wenn es zu lange rumliegt.
Op5: Die Kollegen aus Schweden sind seit Jahren immer fleißig am Werk und seitdem sie Naemon an Stelle von Nagios verwenden, fokussieren sie sich noch mehr auf ihre beiden Hauptkomponenten Merlin und Ninja. Diese werden auch ordentlich als Open Source Projekte und sehr transparent vorangetrieben. Klar ist natürlich das Op5 selbst einen anderen Revenue-Stream hat und mit dem veredelten Produkt Op5 Monitor auf dem Markt aktiv ist. Was mir nicht eingeht ist ihr Logging Produkt Op5 Log Analytics. Natürlich verstehe ich den geschäftlichen Hintergrund und das Ziel dem eigenen Kunden eine Komplettlösung aus einer Hand zu verkaufen. Warum man bei Op5, ähnlich wie bei Nagios, glaubt die Elastic-Lösungen nochmal mit einem eigenen Logo und ergänzendem Flickwerk versehen zu müssen ist mir schleierhaft. Da würde es soviel andere Dinge geben, mit denen sich die Jungs schnell ein Alleinstellungsmerkmal schaffen könnten, aber sie werden schon ihre Gründe haben. UPDATE: Ich habe gerade gesehen das Op5 erst vor wenigen Tagen von der ITRS Gruppe übernommen worden ist. Bleibt also spannend, was die neue Mutter, welche bereits ähnliche Lösungen im Portfolio, daraus macht.
Fazit: Ich denke noch immer, dass Op5, besser gesagt Op5 Monitor, eine solide Unternehmenslösung ist, mit der man sehr viele Anwendungsfälle lösen kann. Wie bei allen Veredlern ist der Schritt über den Standard hinaus immer etwas schwieriger, aber zugegeben braucht das auch nicht jeder. Open Source ist es natürlich nur bedingt, da die Kernkomponenten zwar offen entwickelt werden, aber die fertige Lösung natürlich der USP von Op5 und somit kostenpflichtig ist.
Check_MK: Erstmal Gratulation zur neuen Website und dem Rebranding! Nachdem ich dort schon einige Monate nicht mehr war, ist mir das als erstes positiv aufgefallen. Beim Rest scheint sich im Großen und Ganzen nicht viel verändert zu haben. Das will jetzt nicht heissen das die Kollegen aus München nichts machen, aber ich kann einfach nichts finden. Auf der Website wurde die Screenshot-Section bereits aktualisiert, aber das Demo System hat zumindest noch das alte Design. Auch das Changelog gibt mir keinen Aufschluss auf grundlegend neues, sondern listet überwiegend Bugfixes. Falls jemand der es besser weiß die entsprechenden Infos für mich hat werde ich es gerne nachtragen. Ich hab mir noch ein paar Videos von der Check_MK Konferenz reingezogen, konnte aber nichts finden, was mir jetzt besonders aufgefallen ist.
Fazit: Wenn ich mir ansehe, was die Kollegen so voran treibt, verhält es sich im Fazit ähnlich wie bei Op5. Wenngleich mir bei Op5 das Webinterface besser gefällt, vermute ich das Check_MK die technisch stärkere Lösung ist, da sie sich den käuflichen Varianten auch vom Nagios-Core befreit hat und schon seit vielen Jahren seinen CMC verwendet. Auch gibt es eine API, aber auch Check_MK ist aus meiner Sicht nicht für Automatisierung gemacht, sondern verfolgt einen ganzheitlichen und integrierten Ansatz. Check_MK kümmert sich selbst um Verteilung und Installation seiner Software und zielt auf einen Markt ab, der eine vollintegrierte Lösung haben möchte. Richtig sinnvoll geht das dann aber nur mit der Enterprise- oder Managed-Service Edition.
OMD: Die Freunde von Consol schrauben weiter erfolgreich an ihrem OMD Labs (für welches wohl im September die nächste Version ansteht). Die Zusammenarbeit mit Check_MK hat sich ja schon vor einiger Zeit aufgelöst und so sind aus dem ehemaligen Gemeinschaftsprojekt nun zwei Lösungen entstanden. OMD Labs ist der eigentlichen Idee, nämlich unterschiedlichsten Komponenten für den User einfach zusammenzuschnüren, treu geblieben und sehr aktiv. Besonderes Augenmerk hat man in den letzten Versionen dem Thema Prometheus und der besseren Integration geschenkt. Nach wie vor werden verschiedenen Monitoring-Cores unterstützt und unter Thruk als zentraler Oberfläche zusammengeführt.
Fazit: Wer keine Lust, keine Zeit oder einfach keine Not hat, einzelne Monitoring-Komponenten zu installieren und anschließend zu konfigurieren, dem möchte ich OMD Labs ans Herz legen. Es ist eine solide und offene Open Source Lösung, welche kontinuierlich weiterentwickelt wird und stark vom Service-Know der beteiligten Personen profitiert. In Richtung Management-Sichten, Reporting usw. hat Check_MK mit Sicherheit mehr zu bieten, aber eben erst in den bezahlten Versionen. Hinzu kommt, dass es um OMD herum einen Community gibt und die ehemalige Check_MK Community in andere Kanäle abgewandert ist. Wer übrigens alternativ zu RRD Graphen will, kann das mit der Check_MK Raw Edition ebenfalls nicht machen und sollte gleich OMD nehmen.
Naemon: Sowohl OMD Labs („Hauptcore“) als auch Op5 setzen auf Naemon als Monitoring-Engine. Neben Sven Nierlein schrauben auch einige andere Entwickler an Naemon und es gibt regelmäßig neue Versionen. Bei den Änderungen scheint es sich jedoch eher um kleinere Bug-Fixes und Änderungen zu halten und es sieht nicht so aus, als ob grundlegende Änderungen erfolgen. Grundsätzlich ist das aus der Perspektive der oben genannten Hauptnutzer auch verständlich, da sie die fehlenden Features des Cores in den Frameworks drum herum übernehmen. Beispiel wäre hier API oder direkt Graphing-Integration. Naemon wiederum besteht auch aus dem Core, Livestatus und Thruk als Ersatz für die alten Nagios-CGIs. Aus meiner Sicht ist nicht zu erwarten das hier groß etwas passiert, jedoch können User im Vergleich zu Shinken durchaus davon ausgehen, das auftretende Issues bearbeitet werden und zeitnah in eine Release fließen.
Fazit: Ich persönlich wüsste nicht warum man Naemon standalone einsetzen sollte und würde Interessenten gleich zur Verwendung von OMD Labs raten. Dort bekommen sie zum einen die notwendigen Add-ons mit dazu und können gleich das vorhandene Site-Management nutzen. Als simples Monitoring im kleinen Umfeld mag es aber durchaus seinen Dienst verrichten. Wer am Core selber etwas mehr Features benötigt ist mit Icinga2 sicherlich besser bedient, muss sich dann aber natürlich mit einer anderen Konfigurationssprache auseinandersetzen.
Centreon: Die französischen Kollegen blieben bisher in meinem Vergleich etwas unbeachtet. Das liegt in der Hauptsache einfach daran, dass wir und ich persönlich sehr wenig damit zu tun haben und Centern selten in anderen Umgebungen antreffen. Centreon (früher CES Standard) ist fully Open Source und steht samt Modulen und Webinterface auf der Website zum download bereit. Auch in ihrem Git sind die Kollegen recht aktiv und schrauben an den eigenen Komponenten, welche für die darauf aufbauenden Enterprise-Komponenten benötigt werden. Die Vergleichsmatrix zwischen Nagios und Centreon macht eigentlich auch einen sehr guten Eindruck, jedoch bin ich nicht dazu gekommen das System zu installieren und einem fachlichen Test zu unterwerfen.
Fazit: Ehrlich gesagt weiß ich zu wenig um deren aktuellen Entwicklungsstand um wirklich ein Fazit abzugeben. Um einen Eindruck zu gewinnen empfehle ich den Besuch des Demo-Systems, was wirklich solide aussieht und viele Features mitbringt, welche Op5 oder Check_MK nur gegen Einwurf von Münzen zur Verfügung stellen. Ich freue mich, dass Centreon dieses Jahr auch wieder auf der OSMC dabei ist und werde die Gelegenheit nutzen mit den Damen und Herren zu sprechen und mir das System zeigen zu lassen. Wenn ein Leser dieses Posts noch ein paar Anregungen dazu hat, dann bitte her damit.
Icinga: Im letzten Jahr ist nach außen sehr viel in den Modulen, wie bspw. dem Director passiert, welcher vor einigen Wochen in der Version 1.5 erschienen ist. Wir bereits vor zwei Jahren angekündigt arbeitet das Team gerade mit Hochdruck an der IcingaDB. Mit ihr wollen die Entwickler auch der letzten verbliebenen Nagios-Komponente (zumindest Schema und Funktionsweise) leb wohl sagen. Dabei handelt es sich aber nicht nur um ein neues DB-Schema um Auswertungen komfortabler zu gestalten. Es wird eben auch eine strikte Trennung zwischen Persistenten und Volatile Daten geben, um Millionen an Check sowohl im Core als auch im Web-Interface zu ermöglichen. Letztgenanntes bekommt eben dann auch ein neues Monitoring-Modul, welches ebenfalls an die neue Architektur angepasst werden muss. Da hier ein Großteil der verfügbaren Entwickler-Ressourcen reingesteckt wird, sind Themen wie NoMa und auch die Mobile-App etwas in Verzug geraten. Vergessen sind sie aber nicht, keine Sorge. Was Icinga stark macht ist der hohe Komfort bei der Integration anderer Lösungen und die Unterstützung einer Vielzahl von Konfigurationsmanagement-Lösungen. Gerade in größeren Umgebungen spielt Icinga hier seine Stärke aus. Auf Basis der neuen Architektur wird dann auch dem Thema Micro-Services eine stärkere Beachtung zukommen, da hier oft sehr volatile Anwendungen überwacht und das Monitoring quasi sekündlich an die neuen Rahmenbedingungen angepasst werden muss.
Fazit: Icinga ist dann das richtige Werkzeug, wenn man die am Markt befindlichen Lösungen für Metriken, Logmanagement, Konfigurationsmanagement usw. nach dem best-of-breed Ansatz kombinieren will. Der Anwender muss hier definitiv ein bisschen mehr Hand anlegen, um die unterschiedlichen Lösungen zusammenzubauen, profitiert dann aber auch von der Flexibilität, die er sich damit erarbeitet hat.
Das Fazit hat sich im Vergleich zum Vorjahr lustigerweise nicht geändert, wenngleich wir in vielen Punkten in Richtung einer besseren Integration und leichteren Installation arbeiten. Aber dazu gibt es in den nächsten Monaten noch vieles zu erzählen 🙂
Nagios: Als die Nagios-Konferenz in den USA mangels Teilnehmer im letzten Jahr abgesagt wurde hatte ich wirklich Mitleid. Es ist mir ein Rätsel, wie man ein Produkt und seine Community, welche im Übrigen für alle oben stehenden Produkte verantwortlich ist, an die Wand fahren kann. Nagios hatte einst alle Zügel in der Hand und die Entwickler haben nur so um die Möglichkeit der Mitarbeit gebettelt. Für die Benutzer war es das Beste was passieren konnte und so steht heute eine Produkt- und Ideenvielfalt zur Verfügung, welches es ohne Versagen von Nagios nicht gegeben hätte. Open Source at its finest würde ich sagen. Wir blicken sicherlich auf eine schwierige gemeinsame Vergangenheit zurück, aber letztendlich ist der Markt groß genug und ich gönne jedem, der hart daran arbeitet, seinen Erfolg. Bei Recherche der Nagios-Website sind mir dabei drei wesentliche Sachen und Neuerungen aufgefallen:
- Auch Nagios hat sich vor vielen Jahren versucht die unterschiedlichen Projekte zu vergleichen und scheinbar haben sie diese Vergleiche auch ab und an aktualisiert. Die Vergleiche sind leider für jedes andere Produkt absolut lächerlich und entbehren jeder Grundlage. Dacia vergleicht sich ja in der Regel auch nicht mit Audi.
- Ich hab mit der Demo ihres Log-Servers, Produktname Nagios Log Server, etwas gespielt und finde das Produkt eigentlich nicht schlecht. Wie bei Op5 stellt sich mir zwar die Frage ob man mit einer reinen Open Source Variante wie Elastic(Stack) oder Graylog nicht besser fährt, aber ich habe den Eindruck das man sich bei dem Produkt Mühe gegeben hat.
- Am Core wird eigentlich nach wie vor „nichts“ gemacht. Zwar gab es im letzten Jahr eine Enhancement-Release (4.4.0), aber das war eher auch nur Kleinigkeiten. Wie weit Nagios und Naemon da in der Zwischenzeit auseinander sind kann ich schwer beurteilen, ich habe aber nicht den Eindruck, dass es signifikante Unterschied. Im Vergleich zu den anderen Veredlern hätte Nagios ja eigentlich alles in der Hand, aber scheinbar keinen Druck, Not oder auch Know-how.
Fazit: Es ist mir schleierhaft, wie und warum Nagios sich noch immer gegen andere Veredler wie Naemon oder Op5 durchsetzen kann. Klar haben sich alle anderen über die letzten Jahre vom Nagios-Core entkoppelt und sind nicht mehr auf Nagios angewiesen. Auf der anderen Seite sind alle anderen wesentlich innovativer, wenn es um das komplette Produkt geht.
Das oben angesprochene Highlight ist für mich jedoch das Nagios-Produkt-Video, welches ich auf der Landing-Page gefunden habe. Das Video mit dem Titel „Nagios – Customers First“ bewirbt so ziemlich jede Branche auf dem Planeten, sagt aber ca. nix über Monitoring aus. Aber unterhaltsam ist es, daher bitte sehr:
Für Feedback bin ich gerne offen und wenn sich jemand ungerecht behandelt fühlt, möge sie oder er es mich bitte wissen lassen. Wenn es darauf hin etwas zu korrigieren oder klarzustellen gibt, werde ich das auch machen.
