Open Source im professionellen Einsatz
Linux-Magazin 06/2015
© hxdbzxy, 123RF

© hxdbzxy, 123RF

Warum Anwender ihre Monitoring-Lösung wechseln

Chance zum Umsteigen

Sehr viele Firmen sind mit der kostenlosen Monitoring-Lösung Nagios unterwegs, einige würden gern auf eine andere umsteigen. Das Linux-Magazin hat sich umgehört, wie es Abtrünnigen ergangen ist.

798

Freie Monitoring-Systeme oder zumindest kostenlose gibt es ziemlich viele, doch wer Ansprüche auf umfangreiche und vielfältige Überwachungsmöglichkeiten geltend macht, kommt schnell auf der Nagios-Schiene an. In den mehr als 15 Jahren seiner Existenz hat es nicht zuletzt wegen seines Plugin-Konzepts eine beispiellose Verbreitung erfahren und eine gut funktionierende Community geschaffen.

Das bedeutet allerdings nicht, dass jedermann mit dieser Vorherrschaft rundum zufrieden ist. Zumindest der freien Version haftet hartnäckig der Ruf an, mit einer steigenden Anzahl von Checks Performanceprobleme zu bekommen und umständlich konfigurierbar zu sein. Die kommerzielle Version dagegen kann Vor-Ort-Support außerhalb der USA nicht gewährleisten. Auch sind die Verträge kein Schnäppchen.

Nicht wenige Anwenderfirmen denken über Alternativen nach oder sind gar schon umgestiegen. Ziele können von Nagios abgeleitete Lösungen sein. Die reichen von Icinga (das als Icinga2 aber keinen Nagios-Code mehr enthält) oder Naemon bis zu Neu-Implementierungen wie Shinken und kommerziell gehandelten Ablegern wie etwa OP5, Neteye, Groundwork oder Snagview.

Das Linux-Magazin hat im März nach Anwendern gesucht, die sich nach einer anderen Lösung umgesehen haben. Alle bekamen wenige einfache Fragen nach ihrer Umgebung, dem Motiv ihres Wechselwillens und ihrer aktuellen Zufriedenheit nach dem Umstieg gestellt. Der Artikel fasst die Antworten zusammen.

Zwei Probleme

Die Kritik an Nagios, die Ausgangspunkt für Umstiegswünsche war, konzentriert sich im Wesentlichen auf nur zwei Punkte, und die korrelieren mit der Größe der zu überwachenden Umgebung. Erster Punkt ist die aufwändige Konfiguration über große Textdateien. Zigtausend Textzeilen mit Hunderten Abhängigkeiten sind manuell eben nur schwer zu warten. Das zweite Problem betrifft die Performance und wirkt sich eher in großen Umgebungen aus. Da das klassische Nagios kein Multithreading beherrscht und seine Checks seriell abarbeitet, zwingen die dabei anfallenden Laufzeiten zu sehr großen Checkintervallen.

Verlängert man diese Intervalle nicht, dann starten bei voneinander abhängigen Checks die nachfolgenden bevor die vorangehenden beendet sind. Im Ergebnis skaliert die klassische Architektur ohne eine Möglichkeit der Parallelisierung nur schlecht. Über die kommerzielle Version Nagios XI lässt sich an dieser Stelle nichts sagen, weil sie keiner der Umfrageteilnehmer im Einsatz hatte.

Sowohl das Problem mit der Wartbarkeit als auch das mit der Performance bestehen schon lange und entsprechend zahlreich sind die Lösungsansätze: Als Mittel für eine bessere Skalierbarkeit, die überdies häufig auch der Verfügbarkeit zugutekommt, präsentieren sich Module wie etwa Mod_gearman, das die Checks auf verschiedene Queues verteilt, die parallel von mehreren Rechnern abgearbeitet werden.

Auch Shinken kennt verteilbare Workerprozesse. Icinga realisiert Distributed Monitoring, Check_MK ist mit verschiedenen Ansätzen am Start, um Performance-Engpässe zu überwinden, OP5 setzt auf das Load-Balancer-Modul Merlin und so weiter und so fort.

Trotz dieser Vielfalt sind die Teilnehmer der Umfrage zum überwiegenden Teil nur zu zwei anderen Lösungen migriert: nämlich zu dem blutsverwandten Check_MK oder artübergreifend zu Zabbix. Alle Antwortenden waren anschließend zufriedener als zuvor.

Dass Systemarchitekt Hubert Bösl Performanceprobleme mit Nagios hatte, wundert nicht, wenn man die Dimensionen betrachtet: Aktuell überwacht er 5714 Systeme mit 63684 Services im Flughafen München (Abbildung 1). Die Palette der Geräte ist breit: Darunter finden sich Netzwerkkomponenten von Cisco, Speichersysteme von EMC und Netapp, USVs, Rechner mit Windows-, Linux- und Solaris-Betriebssystem, Server von Fujitsu und HP, virtualisierte Systeme unter ESX und Hyper-V, Webserver, SAP- und Datenbankserver (Oracle, MS SQL, MySQL), Load Balancer, Veritas-Cluster (Symantec HA), CCTV-Kameras, selbst geschriebene Applikationen und mehr.

Abbildung 1: Der Flughafen München überwacht eine sehr große IT-Landschaft heute mit Check_MK.

Alles auf einer Konsole

Die Entscheidung für Check_MK beeinflusste der Wunsch, alle Störungsmeldungen auf einer zentralen Konsole zu sammeln. Mit Software von der Stange war das nicht möglich. Das überzeugendste Angebot für die Programmierung einer solchen Konsole legte Mathias Kettner vor, weshalb dessen Check_MK den Zuschlag erhielt. Anfang 2014 stellte man von Nagios Core auf Check_MK mit Microcore um – inzwischen hat sich die Belastung des Monitoring-Servers bei der gleichen Anzahl Services um sage und schreibe 80 Prozent reduziert.

Auch das zweite Problem, die Konfiguration, ließ sich damit verbessern. Hubert Bösl meint: "Zum Anfang war ich kein Freund von automatischer Inventarisierung, wie Check_MK sie mit den Agenten bietet. In Nagios war man ja auch gewohnt jeden Service zu definieren, der überwacht werden soll. Im Laufe der letzten zwei Jahre haben wir diese Eigenschaft jedoch schätzen gelernt. Wir legen nur noch ein Regelwerk fest, das bestimmt, was überwacht wird und was nicht. Dieses Regelwerk leitet sich zu 90 Prozent aus unserer CMDB oder dem Netzwerkmanagement-Tool ab. Dabei kommen uns die SNMP-Agenten von Check_MK sehr entgegen. Im Einzelfall muss der Admin nur noch die IP-Adresse angeben und das System per SNMP ansprechen. Dann kann er die Services aussuchen, die zu überwachen sind."

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 4 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Check_mk

    Check_mk hat zurzeit Rückenwind: Es gilt nicht mehr als schnödes Nagios-Plugin und seine Oberfläche Multisite lässt die Konkurrenz alt aussehen. Doch wird Check_mk diesem Ruf in der Praxis gerecht?

  • Geballter Durchblick

    Sieben prominente Nagios-Entwickler brachten letzten Oktober eine angepasste und erweiterte Nagios-Variante heraus: OMD, die Open Monitoring Distribution. Ihr spendierten sie Installationspakete und zahlreiche Addons. Im Testlabor hinterließ OMD einen guten Eindruck.

     

  • Check_MK 1.1.11i2 mit Dashboard und verbesserter Weboberfläche

    Mathias Kettner hat seine Nagios-Erweiterung Check_MK in der Innovation-Release 1.1.11i2 freigegeben.

  • Ableger im Aufwind

    Unter neuem Namen, aber mit der bewährten Mischung praxisorientierter Beiträge zum Thema Monitoring, führte die Netways Open Source Monitoring Conference (OSMC) auch in ihrer vierten Ausgabe mehr als 250 Teilnehmer in Nürnberg zusammen.

  • Auf einen Blick

    In großen Netzen mit vielen Hosts und Admins stößt die klassische Nagios-Konfiguration an Grenzen. Das universelle Client-Agent-Plugin Check_mk benötigt für beliebig viele Checks nur eine Abfrage pro Client und kann die auf dem Host zu überwachenden Services automatisch erkennen.

comments powered by Disqus

Ausgabe 11/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.