Monitoring Evolution


Seit unserem letzten Artikel „Quo vadis Nagios?“ über das Monitoring-System Nagios und die unterscheidlichen Alternativen, wie Icinga oder Shinken, sind schon wieder zwei Jahre vergangen. In dieser Zeit hat sich an den Entwicklungen um Nagios selbst nicht viel getan, sehr wohl aber bei vielen anderen Opensource Projekten, die mit Nagios kompatible Monitoring-Lösungen darstellen. Nachdem unsere eigene Nagios-Installation und die einiger Kunden mittlerweile in die Jahre gekommen ist und es einige Punkte gibt, bei denen wir mit unserem aktuellen Monitoring-System nicht mehr ganz zufrieden sind, haben wir uns nun Zeit genommen, um die zwei großen Opensource Projekte Shinken und Icinga noch einmal genauer unter die Lupe zu nehmen. Dazu haben wir beide Systeme parallel installiert und getestet. Unsere Erkenntnisse und Erfahrungen mit den beiden Systemen werden wir im folgenden Abschnitt näher erläutern.

 

Shinken & Skonf

Die grundsätzlichen Informationen über Shinken findet man bereits in unserem Artikel „Quo vadis Nagios?“, weshalb ich an dieser Stelle nicht weiter darauf eingehen werde.
Im Vergleich zum Nagios bringt Shinken ein eigenes, webbasiertes Konfigurationstool mit, das dem Benutzer die Konfiguartion seiner Shinken-Installation erleichtern soll. Ein interessantes Feature stellt dabei die selbstständige Service-Erkennung, beim Hinzufügen von neuen Hosts, dar. Die Oberfläche an sich wirkt recht schlicht und modern. Leider konnten wir Skonf für unsere Tests nicht verwenden, da es nach der Installation nic
ht von selbst funktionierte und wir es auch nach mehrmaligem Versuchen nicht geschafft haben, es richtig zu konfigurieren. Jegliche Änderungen im Skonf waren auch nach einem Neustart von Shinken nicht in der Konfiguration

zu sehen. Eine Dokumentation ist zwar im offiziellen Wiki vorhanden, dort sind aber nicht alle Features, Konfigurationsmöglichkeiten und Probleme aufzufinden und die Community ist aktuell zudem noch recht klein. Insgesamt fanden wir den Ansatz aber durchaus interessant und hoffen, dass wir das Skonf-Interface in Zukunft auch mal funktionierend ausprobieren können.

shinken-ui

Detail-Ansicht eines Hosts in der Shinken UI


Icinga

Icinga ist einer der wohl bekanntesten Nagios-Forks und zeichnet sich vor allem durch seine aktive Entwicklung und Kompatibilität zur Nagios-Konfiguration aus. Genau so, wie auch bei Shinken, kann man prinzipiell einfach seine bestehende Nagios-Konfiguration importieren und weiter verwenden. Außerdem hat das Icinga Team im Laufe der Jahre viele der nervigen Nagios-Bugs behoben und damit das Gesamtsystem etwas stabiler gemacht. Ein großer Vorteil im Vergleich zu Shinken sind die vorhandenen Dabian-Pakete für die einfache Installation und Wartung von Icinga und seinem Zubehör.

Icinga-Legacy

Detail-Ansicht eines Hosts in der Icinga Classic-UI


Icinga-Web

Abgesehen von der altbekannten Nagios-Weboberfläche bringt Icinga auch noch eine neue, auf Ajax basierende und schicke Weboberfläche mit. Sie benötigt die Verwendung eine IDO-Datenbank, welche als Schnittstelle zwischen dem Webinterface und der eigentlichen Icinga-Installation dient. Diese neue Oberfläche sorgt für eine übersichtliche und strukturierte Darstellung der aktuellen Zustände und bietet außerdem die Möglichkeit, bestimmte Befehle an den Icinga-Daemon zu senden, um beispielsweise die aktiven Checks oder die Benachrichtungen zu aktivieren. Falls man zusätzlich zum Monitoring auch noch ein Reporting-System, wie beispielsweise Jasper, einsetzt, kann man dieses sehr einfach in Icinga und Icinga-Web integrieren.

Icinga-Web

Service-Status Ansicht von Icinga-Web


Shinken vs. Icinga

Durch viele Versuche, die wir mit beiden Systemem durchgeführt haben und Dinge, die wir mit den beiden Systemen getestet haben, haben wir viele neue Erfahrungen gesammelt.

Der Einrichtugngsaufwand ist bei Shinken zwar etwas höher, als bei Icinga, aber insgesamt machen beide Monitoring-Systeme nach der Installation auf den ersten Blick einen guten Eindruck. Die Integration von PNP4Nagios, NagiosQL, etc. ist bei beiden prinzipiell möglich, allerdings gibt es dabei beim Einrichtungsaufwand einige Unterschiede. Shinken hat aktuell eine kleine Community und die Dokumentation ist sehr knapp. Das erschwert vor allem Neulingen, tiefer in die Konfiguration und das Funktionsprinzip der Software einzusteigen und man ist daher bei Problemen mehr auf sich selbst angewiesen. Die Erst-Einrichtung gestaltet sich daher bei Shinken wesentlich aufwändiger und schwieriger, als bei Icinga. Im laufenden Betrieb funktionierte Shinken zwar ohne größere Probleme, aber der Konkurrent Icinga lief merklich stabiler und arbeitete besser mit den zusätzlich installierten Plugins/Add-Ons zusammen. Näheres zu den zwei wichtigsten Plugins gibt es in den folgenden Absätzen.


PNP4Nagios

Auch das Plugin zur Erfassung und Darstellung von Performance-Daten, der Nagiosgrapher ist mittlerweile in die Jahre gekommen und wird nicht mehr aktiv weiterentwickelt. Daher haben wir uns auch hier eine Alternative gesucht und uns für das Tool PNP4Nagios entschieden, welches eine eigene Weboberfläche bietet und zudem gut mit Icinga oder Shinken zusammenarbeitet. Wie auch bei Nagiosgrapher werden die Monitoring-Daten in einer RRD-Datei gespeichert und anschließend graphisch aufbereitet und angezeit. Ob es sich bei den Daten um die CPU-Auslastung oder die Werte eines Temperatursensors handelt, ist dabei vollkommen unerheblich. Die Graphen können im Anschluss komfortabel für bestimmte Zeiträume generiert und auch als PDF exportiert werden.

PNP4Nagios

Ansicht des Ping-Graphs in der PNP4Nagios Weboberfläche


NagiosQL und Nconf

NagiosQL ist ein graphisches Konfigurationstool, mit dem man über ein Webinterface die Nagios-/Icinga-/Shinken-Konfiguration erstellen und anpassen kann. Dadurch spart man sich die Arbeit mit den vielen verschiedenen Konfiguratiosndateien und kann dadurch schnell und gezielt Änderungen vornehmen. Im Handumdrehen lassen sich so neue Servicechecks, Hosts, Escalations oder auch Benachrichtungen hinzufügen und bestehende bearbeiten.

NagiosQL ist in PHP geschrieben und läuft auf jedem Apache-Webserver. Es benötigt lediglich eine zusätzliche MySQL Datenbank, um die Konfiguration zu speichern. Nach der erfolgreichen Änderung der Einstellungen werden dann jeweils die Nagios-kompatiblen Konfigurationsdateien generiert und das Monitoringsystem neugestartet, sodass die neue Konfiguration wirksam wird.

NagiosQL

Service-Übersicht von NagiosQL

Die Installation und Konfiguartion von NagiosQL selbst ist etwas komplizierter, aber wenn es dann einmal fertig eingerichtet ist, funktioniert es wurnderbar. In unserem Test war die Integration ind Shinken etwas umständlicher und es war ein bisschen Handarbeit nötig, um das ganze dann vollständig zum Laufen zu bekommen. NagiosQL ist aber ohne weiteres mit Icinga kompatibel und die Installation klappt ohne größere Probleme.
Außerdem haben wir auch das Tool Nconf einmal etwas genauer betrachtet und gestestet. Dabei mussten wir allerdings recht schnell feststellen, dass Nconf keinen mit NagiosQL vergleichbaren Funktionsumfang bietet und wir es noch mit eigenen Lösungen ergänzen müssten.
Für uns stellt daher NagiosQL, trotz seiner etwas altbacken wirkenden Oberfläche, einen vernünftigen Ersatz für die schon deutlich in die Jahre gekommene, bisherige Lösung dar. Das Projekt ist Opensource und wird aktiv entwickelt, weshalb wir das Tool natürlich besonders gerne verwenden.


Fazit

Shinken machte für uns insgesamt einen eher unfertigen und durchwachsenen Eindruck, weshalb wir der noch relativ jungen Software vor dem produktiven Einsatz noch etwas Zeit zur Entwicklung lassen. Einen sehr positiven Eindruck macht dagegen die Nagios-Alternative Icinga. Das Zusammenspiel mit NagiosQL und PNP4Nagios, deren Integration ins Gesamtsystem und der normale Betrieb funktionierten ohne Probleme. Abgesehen von kleineren Konfigurationsunterschieden im Vergleich zum alten Nagios, läuft Icinga sehr stabil und macht alles in allem einen soliden Gesamteindruck.

Aus diesem Grund haben wir Icinga, zusammen mit einigen weiteren Komponenten, als Hauptbestandteil für unseren „Monitoring-Server 2013“ gewählt. Damit bieten wir unseren Kunden ein modulares und skalierbares System, das sich vor allem durch Stabilität, Aktualität und eine komfortable Bedienung auszeichnet.

IT bleibt spannend!

Euer Andreas Erhard

Quo vadis Nagios?


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

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

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

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

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

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

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

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

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

IT bleibt spannend!

Viele Grüße
Euer Hannes Wilhelm

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