Nagios vs. Naemon

1
09.09.2015ǀ ǀ Monitoring
Naemon oder Nagios: Wer ist stärker beim Monitoring?

Naemon oder Nagios: Wer ist stärker beim Monitoring?

Ende 2013 kündigte der Hauptentwickler von Nagios 4 einen neuen Fork namens Naemon an. In diesem Artikel nehmen wir den Nagios-Ableger genauer unter die Lupe und beantworten die Frage, ob und wann ein Wechsel zu Naemon sinnvoll ist. Umbrella Management-Systeme wie das Nagios-basierte Projekt openITCOCKPIT können beide Systeme verwalten, sodass der Anwender die freie Wahl zwischen den beiden Monitoring-Engines hat. Dennoch ist es für den Anwender wichtig zu wissen, für welche Einsatzszenarios sich die beiden Systeme besser eignen.

Moderne Nagios-Installationen greifen im Hintergrund auf viele Tools zurück, die dem Benutzer seine gewohnte Arbeitsumgebung zur Verfügung stellen. In diesem Zusammenhang sollte auf die Kompatibilität der einzelnen Komponenten geachtet werden.

Core
Im Moment ist die Differenz zwischen Naemon und Nagios für den Anwender gering. Die größten Unterscheide finden sich aktuell im Quellcode. So bietet Naemon seit der Version 0.8.0 einen Query Handler, der von externen Applikationen verwendet werden kann, zum Beispiel für Statusabfragen.

So kann der Query Handler in einer Installation mit Distributed Monitoring in Verbindung mit dem phpNSTA dafür genutzt werden, um die Statusdaten der Satelliten an Naemon auf dem Mastersystem zu übermitteln. Der Query Handler bietet gegenüber der klassischen nagios.cmd oder Checkresults-Datei den Vorteil einer Flusskontrolle. Der Query Handler ist im Nagios Core zwar auch im Ansatz implementiert, allerdings nicht in einer so ausgereiften Version wie bei Naemon. Eine Übermittlung von Checkresults in Nagios ist daher noch nicht möglich.

In der Konfiguration von Naemon gibt es eine kleine, aber nützliche Neuerung: So können Event Broker Module über das Schlüsselwort „define module {…}„ nicht nur direkt über die Hauptkonfigurationsdatei naemon.cfg geladen werden, sondern aufgeteilt in eigene Konfigurationsdateien mit eigenen Parametern.

Ein weiterer Unterscheid liegt in der Implementierung des Aufrufs der Plugins. So verursachte ein Nagios 4.0.8 System bei einer Anzahl von 50.000 Servicechecks diverse CPU-Fehler, die zum Systemabsturz führten. Bei Naemon konnten wir dieses Verhalten nicht beobachten.

Plugins
Ein großer Vorteil von Nagios ist die Vielzahl vorhandener Plugins und die einfach gestaltete Plugin-API. Sie ermöglicht dem Administrator, eigene Plugins für Nagios in einer beliebigen Programmiersprache zu entwickeln. Dem Naemon Projekt ist es wichtig, die Kompatibilität zu dieser API zu erhalten. Aus diesem Grund können alle Plugins für Nagios eins zu eins mit Naemon verwendet werden.

Die Community
Wie bereits in der Einleitung erwähnt, basiert eine moderne Nagios-Installation auf vielen Komponenten. Viele Monitoringsysteme, die auf Nagios basieren, verwenden diese Komponenten. Auch das Monitoring-Projekt openITCOCKPIT fasst sie zusammen und und verwendet sie im Hintergrund automatisch.

Die bekanntesten Erweiterungen, die openITCOCKPIT nutzt, sind:

  • NDOUtils: Stellt eine Verbindung zwischen Nagios und einer MySQL Datenbank zur Verfügung (Nagios Developer Team)
  • Mod_Gearman: Ein System zur Lastenverteilung über mehrere Satellitensysteme (Sven Nierlein)
  • Livestatus: Eine arbeitsspeicherbasierende Datenbank zur Aufbewahrung von Statusergebnissen (Mathias Kettner)

Projekte wie Mod_Gearman werden aktuell nur für Naemon weiterentwickelt. Diesen Trend konnten wir in vielen Bereichen der Nagios Community beobachten. Dazu kommt, dass die Entwicklung des Forks frischer Wind in die Entwicklung gebracht hat. So wird Naemon auf GitHub entwickelt, sodass die Community aktiv am Code mitarbeiten kann. Das war bei Nagios bis zum Zeitpunkt des Naemon-Forks nur bedingt möglich.

Auch die Verbreitung von Naemon ist aus unserer Sicht besser als bei Nagios. Für verschiedene Distributionen stehen Pakete für eine einfache Installation zur Verfügung. Bei Nagios muss hingegen immer aus dem Quellcode kompiliert werden, sofern man eine andere Version verwenden möchte, als im Paketmanager der Distribution enthalten ist.

Fazit
Nagios ist nicht tot! Die Entwicklung von Nagios und Naemon kann parallel auf GitHub verfolgt werden. Allerdings werden viele Neuerungen für Naemon entwickelt, die besonders für große Systeme und Distributed Monitoring von Vorteil sind. Auch die Nagios Community setzt zunehmend auf Naemon.

Aufgrund der Kompatibilität zwischen  Nagios auf Naemon lässt sich ein Wechsel problemlos durchführen. Zu beachten ist, dass Naemon auf Nagios 4 basiert und das System zuvor mit Nagios 4 betrieben werden muss. Ein Update von Nagios 3 auf Nagios 4 ist aber mit ein wenig Zeitaufwand leicht möglich.

Diese Artikel könnten Sie auch interessieren:

Tags: , , ,

Daniel Ziegler - Softwareentwickler Als Senior Developer im Nagios-Projekt openITCOCKPIT ist Daniel spezialisiert auf alle Spielarten von Systemmonitoring mit Open Source.
Webprofile von Daniel: XING, Blog

Ein Gedanke zu „Nagios vs. Naemon

  1. Pingback: Interview: "Open Source bedeutet Arbeit ohne Grenzen"

Kommentar schreiben

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.