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

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.

Be a speaker at the OS Monitoring Conference this year!

 

We have some strong points for you to be a speaker at the Open Source Monitoring Conference 2018.

  1. Add new research to your list – Talk about your newest findings in development at the OSMC.
  2. Increase your productivity –  Writing a paper with your findings, tips, tricks and skills increases your number of activities.
  3. Be the OS Monitoring Agent of Change! – Do you think your ideas and thoughts can bring positive change to the OS community? If you do, the Open Source Monitoring Conference is the perfect platform for you to share your ideas with the community.
  4. Monitor your social life – Meet up with fellow experts and enjoy the opportunity to exchange and reflect with other OS monitoring enthusiasts.

Let’s do this! Submit your talk here. 

Keya Kher

Autor: Keya Kher

Keya hat im Oktober 2017 ihr Praktikum im Marketing bei NETWAYS gestartet. Seitdem lernt sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat viele Erfahrungen im Social Media Marketing und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich gerade nicht kreativ auslebt, entdeckt sie die Stadt oder schmökert im ein oder anderen Buch. Ihr Favorit ist “The Shiva Trilogy”.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins

This entry is part 3 of 8 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute gehen wir der Frage nach wann und wie Plugins installiert werden sollten, was besonders wichtig bei Systemen mit icinga Benutzern zum Gegensatz nagios zu beachten ist. Auf z.B. RedHat-Systemen besteht das Problem, dass der Prozess Icinga 2 unter dem Benutzer icinga läuft, aber unteranderem das Plugin check_icmp oder auch check_dhcp nur vom Benutzer root oder einem Mitglied der Gruppe nagios mittels suid-Bit ausgeführt werden können.

# ls -l /usr/lib64/nagios/plugins/check_icmp
-rwsr-x---. 1 root nagios ... /usr/lib64/nagios/plugins/check_icmp

Das Ändern der Gruppenzugehörigkeit mit Puppet ist wenig hilfreich, da leider bei einem Update des Paketes nagios-plugins die alten Berechtigungen wieder hergestellt werden. Man könnte nun natürlich den Benutzer icinga und das Paket nagios-plugins explizit vor der Klasse icinga2 managen, verliert dann jedoch die Paketkontrolle über die uid und muss das Home-Directory, Shell und weitere Eigenschaften per Hand in Puppet entscheiden. Klarer ist die Methode genau diese Sachen dem Paket zu überlassen und erst danach icinga in die Gruppe nagios aufzunehmen.

yumrepo { 'icinga-stable-release':
  ...
}
->
package { [ 'icinga2', 'nagios-plugins' ]:
  ensure => installed,
}
->
user { 'icinga':
  groups => [ 'nagios' ],
}
->
class { '::icinga2':
  manage_package => false,
}

Um dieses Vorhaben umzusetzen ist es erforderlich die benötigten Repositories zuerst einzubinden, hier mit yumrepo angedeutet, dann die Pakete zu installieren, den Benutzer anzupassen und erst dann die Klasse icinga2 zu deklarieren.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

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

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.

PNP4Nagios RRD Single/Multiple Storage

pnp4nagiosFür alle die das Nagios Plugin PNP4Nagios mit Icinga2 einsetzen, werden eventuell schon über folgende Fehlermeldung gestolpert sein,
oder noch stolpern:

/var/log/messages:
NPCD[65119]: ERROR: Executed command exits with return code '7'

/var/log/pnp4nagios/perfdata.log:
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Timeout after 15 secs. ***
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Deleting current file to avoid NPCD loops
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Please check your process_perfdata.cfg
Einstellung:
'/etc/pnp4nagios/process_perfdata.cfg'
Option
RRD_STORAGE_TYPE = SINGLE

Ab der PNP-Version 0.6 ist es möglich, die Performance-Daten nicht in einer einzelnen RRD-Datenbank (SINGLE), sondern in mehreren RRD Datenbanken (MULTIPLE) zu speichern.
Diese Einstellung in der Konfigurations-Datei sollte NICHT global verändert werden, da PNP4Nagios nach dieser Umstellung auf MULTIPLE sofort beginnt, neue RRD-Files anzulegen. Alte Daten gehen damit sofort verloren!

Auf Grund der Performance ist es nicht sinnvoll, global mit RRD_STORAGE_TYPE = MULTIPLE zu arbeiten, da die Anzahl der RRD-Datenbanken und somit auch der Disk-I/O während der Updates sich vervielfachen würde. Deshalb sollte man überlegen, welche Nagios Checks mit dieser Einstellung gefahren werden.
Bestehende RRD-Datenbanken können über einen Konverter (Perl-Skript) '/usr/libexec/pnp4nagios/rrd_convert.pl' konvertiert werden.

Folgende Ausgabe bekommt man bei Ausführung des Perl-Skriptes:

Usage: /usr/libexec/pnp4nagios/rrd_convert.pl --check_command=
--cfg_dir= [ --list_commands ]
[ --dry-run ]
[ --tmp_dir= ]
[ --no_structure_check ]

Schaut dann so in etwa aus:

rrd-convert

# sudo -su icinga /usr/libexec/pnp4nagios/rrd_convert.pl --cfg_dir=/etc/pnp4nagios/ --check_command=disk --dry-run

Search pattern disk
XML Files analyzed 129
XML Files found 7
XML Files without RRD 0
Old XML Files ignored 0
Number of unique check_commands 15
Dry run? [YES]
Temp Directory /tmp/rrd_convert

This is only a 'dry run'. The new RRD Files are stored in '/tmp/rrd_convert'

Start Converter [n|y]?:y
File 1/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk__.dump
Manipulating /tmp/rrd_convert/icinga2-disk__.dump
............ done 47999 lines
Restoring File
/tmp/rrd_convert/icinga2/disk____.rrd
... done
File 2/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk.dump
Manipulating /tmp/rrd_convert/icinga2-disk.dump
............ done 48424 lines
Restoring File
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_manifests-a11d1078b1b1f2e3bdea27312f6ba513.rrd
/tmp/rrd_convert/icinga2/disk__vagrant.rrd
/tmp/rrd_convert/icinga2/disk__.rrd
/tmp/rrd_convert/icinga2/disk__boot.rrd
/tmp/rrd_convert/icinga2/disk__home.rrd
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_modules-41d422e93c9413f221fcbaa64a7964b7.rrd
... done
DONE

Schauen Sie doch einfach mal auf unserer Webseite vorbei, wir biete Schulungen zu vielen interessanten OpenSource-Themen an.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Braintower Gateways erben iSMS Features

braintower_logo Seit vielen Jahren setzen wir im Bereich SMS Alarmierung für Icinga sehr erfolgreich auf das MultiTech iSMS.
Neben der sehr simplen Einrichtung, der Netzwerkanbindungsmöglichkeit und dem Versenden von SMS über die Weboberfläche, bietet das Gerät eine HTTP-Schnittstelle für den Versand von SMS. Dadurch wird eine Integration in Monitoring Lösungen um ein vielfaches einfacher. Als weitere Option bietet das Gerät die Möglichkeit eingehende SMS an einen Webserver weiterzuleiten, was es in unserem Fall erlaubt, Alarmmeldungen von Icinga 2 mit einer simplen Antwort SMS zu Acknowledgen.

Für die Braintower Gateways gibt es seit letzter Woche die neue Firmware Version 3.3.0, welche das Gateway um einige interessante Funktionen erweitert. Eines dieser Features ist das SMS Routing, mit welchem SMS Nachrichten per Mail, SMS oder per Web-Call weitergereicht werden können.

Darüber hinaus wurde die API-Funktion des Gateways erweitert und ist nun vollständig kompatibel zu der MultiTech iSMS API. Wer bisher also ein iSMS sein eigen nennt, kann ohne Probleme auf ein Braintower Gateway umsteigen. Eine Erweiterung der Basis-Funktion (welche die API-Kompatibilität bereits inkludiert), ist über eine Vielzahl von Zusatz-Features möglich. Sofern das Gateway identisch eingerichtet wird (Benutzer, IP, etc.), kann eine nahtlose Alarmierung erfolgen – ohne Anpassungen an Skripten oder Software durchführen zu müssen.

Darüber hinaus ist unser iSMS Notification Plugin mit dem SMS Routing Feature zu 100% kompatibel mit Braintower. Somit ist nun neben einer Alarmierung auch ein Acknowledgen von Alarmmeldungen in Icinga möglich.

Übrigens: Wer bereits ein Braintower-Gateway mit dem SMS-Weiterleitungs-Feature erworben hat, kann ein Upgrade für das SMS Routing direkt nachkaufen.

Da wir auch immer wieder einmal diverse Kunden-Anfragen zum Thema GFI FaxMaker erhalten, ob wir passende Gateways anbieten können, ist die Antwort simpel: Ja!

Offiziell supportet wird seitens des Herstellers das MultiTech iSMS. Mit dem neuen Firmware-Update werden nun auch Braintower Gateways unterstützt.

Anbei noch ein kurzer Überblick zu den Änderungen zu Version 3.3.0:

Verbesserungen
[SMSGW-546] – Es ist möglich, die Scripts sendsms.pl und smsack.cgi aus dem NETWAYS iSMS Nagios / Icinga Plugin zu verwenden.
[SMSGW-606] – Es wurde eine Dokumentation zum Ersetzen von Geräten anderer Hersteller durch das Braintower SMS Gateway hinzugefügt.
[SMSGW-618] – Das Gateway ist zusätzlich auf Port 81 erreichbar.
[SMSGW-597] – Das Nachrichten-Routing kann nun Nachrichten auch an Ziele per HTTP weiterleiten.
[SMSGW-608] – HTTP-Ziele beim Nachrichten-Routing sind nun editierbar.
[SMSGW-612] – Es ist möglich, mehr als ein HTTP-Ziel pro Regel beim Nachrichten-Routing zu konfigurieren.
[SMSGW-624] – HTTP-Ziele sind bei Nachrichten-Routing auch auf eingehende Emails anwendbar.
[SMSGW-627] – Im Nachrichten-Routing wird nun ein Hinweis angezeigt, wenn kein SMTP Server konfiguriert wurde.
[SMSGW-634] – Das Feature Nachrichten-Routing kann nun kostenpflichtig lizenziert werden.
[SMSGW-607] – Das Feature SMS Weiterleitung ist nun Bestandteil des Nachrichten-Routings, jedoch mit verringerter Funktionalität. Kunden, die das Feature SMS Weiterleitung lizenziert haben, können eine Upgrade-Lizenz zur Nutzung des Nachrichten-Routings erwerben.
[SMSGW-619] – Die Gestaltung der Weboberfläche wurde verbessert.
[SMSGW-675] – Es wurden zahlreiche Übersetzungen verbessert.
[SMSGW-623] – Die Regeln zur Überprüfung gültiger Rufnummern bei der HTTP API wurden erweitert.
[SMSGW-641] – Es wurden neuen FAQ Artikel hinzugefügt (Syslog, API per HTTPS, SIM Karten Formfaktor, Einbindung in Centreon, Icinga 2 und WhatsUp Gold, Import und Export des Adressbuchs, Technische Daten).

Fehlerbehebungen
[SMSGW-604] – Beim Nachrichten-Routing wird die konfigurierte Absenderadresse nun korrekt gesetzt.
[SMSGW-614] – Die Whitelist der E-Mail-to-SMS Funktionalität wurde korrigiert.
[SMSGW-616] – Der Suchen und Ersetzen Bereich beim Nachrichten-Routing wird nicht mehr doppelt angezeigt.
[SMSGW-617] – Die E-Mail-Gruppen-Benachrichtigung beim Nachrichten-Routing wurde korrigiert.
[SMSGW-622] – Bei E-Mail-zu-SMS wurde die fehlende Online-Hilfe ergänzt.
[SMSGW-615] – Die Produktbezeichnung in Benachrichtigungs-Emails wurde korrigiert.
[SMSGW-628] – Nachrichten wurden teilweise sowohl über Email-zu-SMS als auch über das Nachrichten-Routing versendet.

Sie haben Interesse an unseren angebotenen Produkten oder wünschen eine Beratung? Nehmen Sie einfach direkt Kontakt mit uns auf oder besuchen Sie unseren Online-Shop für weitere Informationen. Wir stehen Ihnen gerne zur Verfügung!

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".