Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III

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.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Icinga, Nagios, Naemon, OMD, Check_MK, Op5 oder Shinken – Teil II

Einen Vergleich der oben genannten Tools hatte ich vor fast drei Jahren einmal gemacht. Seitdem ist viel passiert (SPOILER-ALARM: Nicht bei allen) und ich dachte es wäre mal wieder an der Zeit für ein heiteres Core-Bashing. Ich mache aber keinen Feature-Vergleich, um festzustellen, wer mehr Checks in der Minute ausführen kann. Es geht mir mehr um die Agilität und die strategische Ausrichtung des Projekts. Und in den nächsten Tagen folgt nochmal ein detaillierter Artikel zum Thema Metriken, also schon mal den Sekt kaltstellen.

Grundsätzlich versuche ich bei der Bewertung folgende Kriterien einzubeziehen:

  • Aktivität des Projekts aus Sicht der Code-Basis
  • Aktivität der Community
  • Aktuelle Roadmap und Features
  • Und last but not least, meine persönliche und rein subjektive Sicht

Da wir mit Op5 noch einen Neuen (nicht im Business, aber in der Vergleichsrunde) haben, starten wir gleich durch und fangen an mit… Shinken:
Shinken
Es mag an dem allgemeinen Trend zur veganen Ernährung liegen, aber um Shinken ist es in den letzten Monaten sehr ruhig geworden. Auf dem verlinkten GitHub-Repo ist seit Oktober letzten Jahres nichts mehr in den Master committed worden, was nicht wirklich einen guten Eindruck macht. Auch die Website ist vollkommen veraltet und das Forum scheint offline zu sein. Jetzt denkt man im ersten Moment, das Ding ist komplett tot, aber auf Shinken Enterprise hat man zumindest die Jahreszahl im Footer aktualisiert und es wird hier auch gearbeitet.
Eine Roadmap habe ich auch nach längerer Recherche nicht gefunden. Ich konnte lediglich entdecken, dass Jean Gabès an einem Discovery-Tool mit dem Namen Kunai arbeitet. Vor einigen Monaten ging es in der Community etwas rund und Shinken, eigentlich ja mal als Fork von Nagios gedacht, wurde selbst geforked. Das neue Projekt nennt sich Alignak und hat bereits den Preis für den kompliziertesten Namen einer Monitoring Software gewonnen.
In Frankreich ist Shinken noch immer eine Nummer, da es im Toolkatalog der Behörden als eine Art Standard für Monitoring definiert ist. Features, Roadmap und somit der verbunden Mehrwert sind nahezu nicht ersichtlich und die Website besteht eigentlich nur aus ganz viel heißer Luft.
Mein Fazit: Es tut mir leid, Jean, aber wie bei Austern die zu lange in der Sonne standen, würde ich die Finger von Shinken lassen.
Op5
Ehrlich gesagt habe ich die Kollegen in Schweden lange aus dem Auge verloren. Erst ein paar Gespräche auf der OSMC im letzten Jahr und die Info, dass Andreas Ericsson nicht mehr dort arbeitet, haben meine Aufmerksamkeit wieder mal auf die Freunde im Norden gelenkt. Auch wenn der verwendete Core Naemon, welcher als “unabhängiges” Projekt hier nochmal ein eigenes Kapitel spendiert bekommt, nicht im GitHub von Op5 zu finden ist, wird dort sonst viel gemacht. Sowohl bei Ninja (dem Webinterface) also auch bei Merlin (der Datenbank und HA-Komponente) wird viel fleißig gebohrt und geschraubt.
Der eigentlich verwendete Core spielt schon seit vielen Jahren für Op5 keine große Rolle, denn als Veredler geht es ihnen vielmehr um Integration und die Erweiterung mit eigenen Add-ons und Tools. Was Neuigkeiten angeht, wird man auch bei Op5 nicht richtig fündig. Das Tech-News-Archive hat seit einigen Monaten keine Neuerung mehr gesehen und eine richtige Roadmap findet man auch nicht.
Strategisch sehe ich Op5 heute da, wo wir vor 8 Jahren hin wollten. Alle möglichen System-Management-Disziplinen aus einem Guss zu kombinieren, sodass der User nichts mehr machen muss. Die Welt hat sich aber verändert und so würde man heute eher Graylog oder den ElasticStack favorisieren, bevor man den integrierten op5 Logger verwendet. Der Naemon-Core und alle anderen Add-ons sind in hoher Qualität miteinander verbunden und der User hat mit der eigentlichen Open-Source-Software nichts zu tun. Somit ist Op5 für mich auch kein Open-Source-Tool und will es vermutlich auch nicht wirklich sein. Die kostenlose Lizenz, die eine Verwendung von 20 Geräten erlaubt, ist in meinen Augen eher ein Marketinginstrument.
Mein Fazit: Op5 Monitor ist ein solides Produkt und wer alles aus einer Box haben möchte, fährt damit mit Sicherheit besser als mit NagiosXI. Der Vorteil der vollintegrierten Lösung ist an dieser Stelle aber auch der größte Nachteil des Werkzeugs. Gerade in den Bereichen Metriken und Loghandling wird es in den nächsten Jahren um seine Bedeutung kämpfen müssen.
Check_MK
Beginnen wir das ganze Thema sachlich: Files sind nicht die Lösung für jedes Problem, NEIN, NEIN, NEIN! Somit wäre das durch und mein strategischer Kampf für die Daseinsberechtigung einer Datenbank im Bereich Monitoring wäre erledigt. Im Bereich des Source-Codes waren die Kollegen aus München schon immer sehr aktiv und so geht es auf deren Git-Repo zu wie in der Münchner S-Bahn zur Rush-Hour. Trotzdem habe ich auch bei Check_MK vergeblich versucht, eine Roadmap zu finden und wurde lediglich im Bereich des Konferenz-Archivs in den vergangenen Jahren fündig. Sollte es eine Public-Roadmap geben, freue ich mich über einen Hinweis.
Nachdem ich mich ein bisschen auf dem Demo-System umgesehen haben, konnte ich dort keine wesentlichen Neuerungen finden. Bei der Durchsicht der letzten Commits wurde jedoch klar, dass sehr viel Energie in den Support der eigenen Check_MK-Checks geht. Die massive Anzahl der integrierten Checks sind für den User mit Sicherheit komfortabel, aber auch eine Bürde für die Entwickler. Wenn man die investierte Zeit hochrechnet, dürfte das mit Sicherheit zulasten von Investition gehen.
Mein Fazit: Vor drei Jahren hatte ich folgendes geschrieben “Ehrlich gesagt glaube ich aber auch, dass Check_mk in der Zwischenzeit eher mit geschlossenen Systemen Op5 Monitor oder OpsView zu vergleichen ist”. Ich würde sagen, die Annahme hat sich vollends bestätigt. Die Dokumentation auf der Website ist gut strukturiert und detailliert, aber ansonsten kann man über Strategie und Ausrichtung fast nichts finden. Persönlich war ich darüber hinaus nie ein Fan von Auto-Discovery, da es aus meiner Sicht alles das nicht ist, was “Infrastructure as Code” sein sollte. Das Check_mk trotzdem eine große Fangemeinde kann ich nachvollziehen, aber die ist einfach heute isolierter als in der Zeit des reinen Addon-ons.
OMD
Das eigentliche OMD-Projekt scheint es in der Form nicht mehr zu geben. Die Kollegen von Check_MK haben sich aus dem Projekt offensichtlich zurückgezogen und so idled die Website, deren Ownership bei Mathias liegt, eher vor sich hin. Tot ist das Thema jedoch nicht, da sich die Freunde von Consol dem Projekt angenommen haben. Die Weiterentwicklung erfolgt auf deren GitHub-Account und somit geht es mit dem Produkt ordentlich voran. Auf einer eigenen Seite wird der Unterschied zwischen OMD von Consol und dem Legacy-OMD – das sich aus meiner Sicht erledigt hat – detailliert erläutert.
Der eingeschlagene Weg von OMD gefällt mir. Wenn ich auch mit dem gebündelten Ansatz so meine Probleme habe, bietet es eine sehr einfache Möglichkeit ein Monitoringsystem hochzuziehen. Der User hat dann immer noch die Wahl zwischen Naemon und Icinga und es gibt reichlich Innovation hinsichtlich Metriksystemen wie Graphite und Prometheus. Auch LMD, was als schnelles Bindeglied zwischen unterschiedlichen Livestatus-Cores und dem Webinterface verstanden werden darf, ist bereits mit dabei.
Eine Roadmap im klassischen Sinn konnte ich auch hier nicht finden, aber Gerhard hat erst vor einigen Wochen einen kurzen Abriss über 6 Jahre OMD gegeben. Die 45 Minuten sind mit Sicherheit gut investiert.
Mein Fazit: Wer eine gebündelte Monitoringlösung sucht und auf Open Source wert legt, sollte sowohl von Check_MK als auch von Op5 die Finger lassen. Hier empfiehlt sich der Einsatz von OMD. Die Kollegen sind seit vielen Jahren im Bereich Monitoring aktiv, wissen worauf es ankommt und verweilen nicht auf dem Status Quo.
Naemon
Naemon ist letztendlich ja das Ergebnis eines frustrierten Andreas, der von den Nagios-Freunden kurz nachdem er Nagios 4 fertig gestellt hatte, aus dem Projekt gekegelt wurde. Warum genau Nagios Enterprises den Bruch mit Andreas vollzogen hat, habe ich erst von zwei Jahren auf der PuppetConf erfahren, hier wird es jedoch leider nicht landen.
Auf dem GitHub-Repo gibt es durchaus Aktivität und erst vor zwei Tagen ist mit Version 1.0.6 ein neues Release erschienen. Das Projekt wird in den letzten Jahren eigentlich ausschließlich von Sven Nierlein am Leben gehalten und ist laut meinem Kenntnisstand auch der bevorzugte Core in OMD. Laut Website gab es in den letzten Monaten keine großen Features sondern lediglich Bugfixes.
Für das Projekt wäre es mit Sicherheit schön, wenn es mehr Contributors hätte. Ich weiss wie anstrengend der “Betrieb” eines solchen Projekts ist und zolle hier Sven Respekt, dass er das Ding weiter in Bewegung hält. Um ehrlich zu sein, sieht es jedoch im Moment für mich nicht so aus, als ob da die Post abgeht.
Mein Fazit: Wer mit dem Funktionsumfang von Nagios zufrieden ist, aber a) mit “denen” nichts zu tun haben will und b) auch Livestatus gleich fertig mit dabei haben will, ist mit Naemon gut bedient. Auch wenn nicht viele Features dazu kommen, wird das Projekt am Leben gehalten und das reicht für ein “eingefrorenes” Featureset vollkommen aus.
Nagios
Mein Fazit: Wem Nagios reicht, soll bitte Naemon nehmen.
Icinga
Zugegeben bin ich nicht der Richtige, um Icinga objektiv zu beurteilen, da ich mit der Software und vor allem den Personen einfach zu viel zu tun habe. Aber die Aktivität des Projekts ist sicher mit Abstand konkurrenzlos. Erst vor einigen Tagen ist das Projekt weg vom privaten Redmine zu GitHub gezogen. Das in der Regel vier bis fünf Personen in Vollzeit an Icinga arbeiten ist natürlich ein Grund für die starke Aktivität.
Mit Icinga 2 haben wir mit Sicherheit die Kruste von Nagios abgelegt und gerade die Konfiguration bietet eine Vielzahl an Möglichkeiten, die es sonst in dem Bereich nicht gibt. Eine große Herausforderung stellt noch das geerbte Datenbankschema da, das in großen Umgebungen immer mal wieder Schwierigkeiten bereiten kann. Eine alternative Lösung dafür zu schaffen, welche sowohl Livedaten sehr schnell, aber auch historischen Daten sehr lange zur Verfügung stellt, ist unsere Aufgabe für 2017. Dies wird sowohl im Core als auch bei Icinga Web 2 zu einer Vielzahl von Änderungen führen und somit den Großteil unserer Zeit in Anspruch nehmen.
Strategisch positioniert sich Icinga eher gegen eine gebündelte Lösung. Das Projekt kümmert sich um Core und Web und hat im letzten Jahr seine Anstrengungen in Richtung Integrationen intensiviert. Dies schließt beispielsweise die fertige Integration für Chef und Puppet aber auch Themen wie IcingaBeats mit ein. Auch der Icinga Director, der unterschiedlichste Quellen für die Konfiguration zusammenfassen kann, erfreut sich sehr starker Beliebtheit.
Mein 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 zusammenbauen, profitiert dann aber auch von der Flexibilität, die er sich damit erarbeitet hat. 
Feedback willkommen
Wie bereits angedeutet handelt es sich hierbei um eine subjektive Betrachtung und sie erhebt nicht den Anspruch auf Vollständigkeit. Sollte ich jemanden zu Unrecht falsch beurteilen oder eine Aussage nicht korrekt sein, bitte ich um einen Hinweis und werde den Post entsprechend korrigieren. Habe ich jemanden zurecht schlecht beurteilt, so muss er damit leben.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Fully packed to reduce heating – OSMC 2016 – Tag 1

OSMC 2016Auch dieses Jahr begann für mich wieder mit Tag 0, dem Workshop-Tag. Ich durfte Thilo bei einem voll ausgebuchten “Advanced Graphing”-Workshop assistieren, während nebenan Lennart und Thomas einen sehr praktischen “Icinga 2”-Workshop auf Basis der Beispiele aus ihrem Buch hielten. Für den Elastic-Stack waren David und Simon vor ebenfalls vollem Haus tätig, während Michi in entspannter Kleingruppe seine Teilnehmer in das Arbeiten mit Git eingewiesen hat. Und wie immer ging es nach den Workshops nahtlos weiter mit Fachsimpelei beim Abendessen und der anschließender Feuerzangen-Bowle auf dem Nürnberger Christkindles-Markt.
So richtig los ging Tag 1 dann wie immer mit Bernds Begrüßung, bei der sich schon zeigte, dass wir dieses Jahr mit über 300 Teilnehmern einen neuen Besucherrekord vorweisen konnten. Aus seiner Begrüßung stammt auch das Zitat, das ich als Titel für den diesjährigen Konferenzbericht gewählt habe. Zusätzlich zur eigentlichen Begrüßung stellte Bernd auch ganz stolz Netways Web Services vor, unsere neue Software-as-a-Service-Plattform vor. Aktuell zum freien Ausprobieren kann ich jedem empfehlen zumindest mal einen Blick darauf zu werfen, wer noch einen externen Satelliten für seine “Icinga 2”-Umgebung sucht. Und natürlich haben wir es uns nicht nehmen lassen James Fryman zum Geburtstag zu gratulieren.
Dieses Jahr fiel es mir wirklich durchgängig schwer mich für einen Talk zu entscheiden, daher empfehle ich jedem gleich vorweg gespannt auf das Konferenz-Archiv zu warten, um nicht nur das Wichtigste aus Vorträgen, die ich mir angeschaut habe mitzubekommen, sondern aus allen. Für den ersten Vortrag fiel meine Wahl auf Monica Sarbu mit “Monitor your Infrastructure with Elastic Beats” um mich über die aktuelle Entwicklung der Beats zu informieren. Interessant war auch wie die verschiedenen Beats genutzt werden können um relativ einfach Monitoring-Informationen aus Containern rauszubekommen. Eine Aufgabe, die ich doch als herausfordernd betrachte. Zusätzlich gab es nebenbei viele weitere nützliche Informationen, so kann beispielsweise Elasticsearch nun effektiver auch als “Timeseries Database” genutzt werden.
James Fryman hatte mit “Metrics are for chumps – Understanding and overcoming the roadblocks to implementing instrumentation” nicht nur wieder sein Talent für die Namensgebung eines Vortrags bewiesen, sondern hat es mit seiner humorvollen Art geschafft klar aufzuzeigen warum Metriken ein grundlegendes Feature sein sollten. Denn ohne Metriken lässt sich keine Aussage über Kapazität, Verbesserung oder Verschlechterung treffen und man muss sich auf Intuition oder Glück verlassen. Seine Präsentation enthielt nebenbei noch Tipps wo man Metriken abgreifen sollte, wie man Dev und Ops dazu bekommt die Wichtigkeit von Metriken zu verstehen und vieles mehr, wie immer sehr sehens- und hörenswert.
Tom hatte zu seinem Vortrag “Ein Jahr mit dem Icinga Director” volles Haus woran sich das Interesse an der graphischen Konfiguration ablesen lies. Von der einfachen Installation über manuelle Nutzung, Automatisierung, Agent-Deployment bis zum Ausblick auf geplante Features war alles in einer Stunde geboten. Ich denke mal nach dem Vortrag war nicht nur ich vom Director begeistert. Wenn man dann noch weiß wie viel Differenz zwischen offizieller und tatsächlicher Entwicklungszeit liegt, möchte man Tom doch glatt mit einem Gläschen oder auch Fläschchen Wein für weitere Features in Nachtarbeit motivieren! 😉
Nach der wie jedes Jahr üppigen Stärkung ging es für mich weiter mit Gerhard Laußer und “Open Monitoring Distribution 2016+”. Ein kurzer historischer Abriss und schon ging es zur OMD Labs Edition in die Consol die ganzen modernen Tools wie InfluxDB, Grafana und Icinga 2 integriert, so dass auch diese einfach als Teil von OMD zu installieren sind. Die Edition 2016 bringt dann noch zusätzlich Ansible für Neuinstallation, Update, Plugin-Verteilung und Inter-Site-Connections und den “Livestatus Multi Daemon” der Cache, Aggregierung, Sortierung und Formatierung für verschiedene Livestatus-Installationen bietet sowie Prometheus für Cloud-Monitoring.
Michael Medin gab uns in “Automated monitoring with Icinga and NSClient++” zusätzlich zum eigentlichen Thema Pro-Tipps zum Thema Präsentation. Allein die Neuerungen der letzten und nächsten Versionen aufzuzählen würde wohl den Rahmen sprengen. Interessant ist der von Michael angestrebte Paradigmen-Wechsel von aktiven Abfragen zu passivem Real-Time-Monitoring inklusive Metriken und automatischer Konfiguration.
Dieses Jahr mal was neues für mich, denn statt dem Vortrag des Icinga-Projekts wollte ich Shlomi Zadok zu “Security & Compliance automation and reports with Foreman” sehen, schließlich hat man nicht immer die Chance den Entwickler (in diesem Fall des Foreman-OpenSCAP-Plugins) persönlich zu hören. Neben der allgemeinen Erklärung was Foreman so ist, ging es natürlich primär um Compliancereports, welche ich bereits vor einer Weile in einem Blogpost behandelt habe. Die geplanten Erweiterungen klingen genau wie meine Wunschliste: Mehr Informationen und Anpassen der Profile in der Oberfläche sowie Ausführen der Remediation-Skripte via Remore Execution.
Natürlich will ich dem geneigten Leser auch die Neuigkeiten rund um Icinga nicht verschweigen. Fangen wir klein an mit dem überarbeiteten Dashboard, Performance-Verbesserungen in “Icinga 2″s Datenbankschnittstelle, Support für die “Icinga 2”-API als Kommandotransport in Icinga Web 2 sowie Verschönerungen wie die Möglichkeit Ankündigungsbanner zu schalten. Und machen groß weiter mit dem Cube, der Datawarehouse-Funktionalitäten für Icinga Web 2 bringt, sowie dem aktualisierten Businessprocess Module.
Nach dem Konferenztag geht es nun zur Abendveranstaltung in die Indabahn um gemeinsam der Völlerei zu frönen und sich weiter zum Thema Monitoring auszutauschen. Es werden sicher wieder die verschiedensten Personen und Projekte zusammenfinden und ich werde versuchen morgen zu berichten.
Hier mal ein paar erste Eindrücke:
 

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

OSMC 2014: Der Countdown läuft – nur noch 64 Tage

Reiko, hold di heut mit sei’m Traktor ab und fährt mit dir durch eine “Monitoring-Landschaft auf Basis von OMD“.

OSMC? Was soll das denn sein und wer sind die netten Menschen in diesen Videos? Die Open Source Monitoring Conference (kurz: OSMC) ist die internationale Plattform für alle an Open Source Monitoring Lösungen Interessierten, speziell Nagios und Icinga. Jedes Jahr gibt es hier die Möglichkeit sein Wissen über freie Monitoringsysteme zu erweitern und sich mit anderen Anwendern auszutauschen. Die Konferenz richtet sich besonders an IT-Verantwortliche aus den Bereichen System- und Netzwerkadministration, Entwicklung und IT-Management. Und die netten Menschen, die Ihr in unseren Videos zur OSMC seht, gehören dazu. 2014 wird die OSMC zum 9. Mal in Nürnberg stattfinden.