© hxdbzxy, 123RF
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.
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.”
Problem Performance
Ähnlich lagen die Dinge auch bei Thorsten Kohlhepp von DENIC, der zentralen Registrierungsstelle für alle Domains unterhalb der Toplevel-Domain ».de« . Die Registry mit Rechenzentren in Frankfurt und Amsterdam sowie mehreren Server-Standorten weltweit überwacht rund 1000 Systeme, die bereits auf mehrere Nagios-Umgebungen mit maximal 530 Systemen (Versionen 3.00 bis 3.2.2) verteilt sind. Das größte Problem auch hier: die Performance. Zudem war auch der Administrationsaufwand ein Sorgenkind.
Bei DENIC führte das zu einer Entscheidung für Zabbix (Abbildung 2). Die Admins erwarteten vor allem, bei einer monolithischen Lösung weniger Aufwand treiben zu müssen als bei der Integration mehrerer Tools wie Graphite, Collectd, Nagios oder Mod_gearman.
Abbildung 2: Beliebt ist Zabbix nicht zuletzt wegen seiner flexiblen Visualisierungsmöglichkeiten.
“Weiterer Pluspunkt war die Automatisierung des Monitorings durch die Autoregistration in Zabbix”, berichtet Thorsten Kohlhepp. “Zurzeit lassen wir neu aufgesetzte virtuelle Maschinen sich selbst in Zabbix registrieren. Über eine Automatik bekommen dann die Maschinen ihre jeweiligen Checks über Templates angehängt. Somit ist für die Neuaufnahme von Hosts nichts mehr zu tun. Damit sind wir äußerst zufrieden. Gerade auch, weil wir bereits mehr Checks in Zabbix prüfen als wir das in Nagios hatten und die Performance der Monitoring-Umgebung keine Beeinträchtigung zeigt.”
In dasselbe Horn stößt ein Mitarbeiter eines Medizinischen Dienstes der Krankenversicherung in einem deutschen Bundesland (Name ist der Redaktion bekannt). Auch hier waren es in erster Linie Skalierungsprobleme, nachdem mit Nagios Core 3.5.1 rund 3000 Services auf etwa 400 Hosts überwacht wurden. Die Institution blieb bei Nagios, verwendet aber gleichzeitig das Brokermodul »mod_gearman« zur Lastverteilung. Das Ergebnis stellt die Anwender zufrieden: Eine deutliche Lastreduktion durch Verteilung auf Satellitensysteme ist erreicht und die dafür nötigen Konfigurationsänderungen hielten sich in Grenzen.
Auch Hendrik Strohschein aus der IT-Abteilung der Drogeriemarktkette Dirk Rossmann GmbH stand vor einem Performanceproblem. Bei ihm überwachte Icinga 1 damals 350 Serversysteme mit zirka 10000 Services. Das führte zu der beschriebenen Zwangsverlängerung der Checkintervalle und schließlich zum Wechsel zu Check_MK. Damit monitort Rossmann heute 900 Netzwerk- und Serversysteme mit rund 30000 Services im 60-Sekunden-Takt.
Die Passiv-Checks von Check_MK haben dabei nicht nur die Geschwindigkeitsengpässe beseitigt, auch von anderen Vorteilen hat Hendrik Strohschein profitiert: Von der großen Zahl vorgefertigter Checks, von der bequemen Administration über das Web-GUI Wato, das auch Nicht-Spezialisten bedienen können, oder von der guten Abstimmung aller beteiligten Komponenten.
Er meint: “Wir haben mit Check_MK als Agent in der Praxis von Anfang an sehr gute Erfahrungen gemacht. Kommerzielle Lösungen haben sich in der Evaluierung mangels wirklicher Vorteile sowie des damit verbundenen Strategiewechsels (Vendor-Lockin) als keine Alternative herausgestellt. Andere Lösungen im Nagios-Umfeld haben den Praxistest bei uns nicht bestanden. Die Verwendung von Check_MK mit der Nutzung der weiteren Ergänzungen (Multisite, Wato, PNP4Nagios, Nagvis) hat auf Anhieb in der Praxis funktioniert und konnte (fast) alle Anforderungen abbilden.”
Die klassischen Probleme Performance und Konfiguration waren auch für den Gruppenleiter IT bei einer kirchlichen Einrichtung ausschlaggebend (beide sind der Redaktion bekannt), der 85 Hosts und 1600 Services mit Nagios 3.5 im Blick zu behalten versuchte. Insbesondere als auch virtuelle Systeme in die Überwachung einbezogen werden sollten, verschärfte sich das Performanceproblem drastisch und bewog zum Umstieg auf Check_MK.
Nicht zuletzt die Möglichkeit, über einen längeren Zeitraum sukzessiv zu migrieren, sprach für diese Lösung. Zufrieden sind die Anwender aber auch mit der Vielzahl mitgelieferter Plugins, dem übersichtlichen Dashboard oder der Performance, die kaum mehr von der Anzahl überwachter Systeme abhängt.
Wartungsaufwand
Bei Jörg S., Administrator und Entwickler der Dögel GmbH, war es dagegen der Konfigurations- und Wartungsaufwand, der den Anstoß zur Umstellung gab. Bei dem IT-Dienstleister aus dem Raum Halle (Saale) waren zwar nur rund 80 Hosts mit Nagios 3.4.1 zu überwachen, aber das mühsame Editieren der Konfigurationsdateien empfand Jörg S. dennoch als lästig. Außerdem waren dazu Rootrechte nötig, sodass sich die Aufgabe nicht beliebig delegieren ließ.
“Glücklicherweise stieß ich sehr schnell auf Zabbix”, berichtet er weiter, “sodass ich dort auch direkt hängen geblieben bin. Zabbix hat eine breite Community, wo einem schnell geholfen wird bei Problemen. Des Weiteren kann ich wirklich alles über das Webinterface verwalten. Neue Hosts anlegen wird dank der vordefinierten Templates zu einer Sekundensache. Der Administrator ist vollkommen flexibel, und Zabbix bietet alles, was heutzutage nötig ist. Das reicht vom Eskalationsmanagement bis hin zu den Benachrichtigungen via SMS oder Jabber. Da ist alles dabei.”
Ab etwa 150 Servern mit rund 1500 Services erschien auch Andreas Sebald der Konfigurationsaufwand bei der Arbeit mit Textdateien als zu groß. Heute überwacht der IT-Leiter im Öffentlichen Dienst insgesamt 727 Server mit 8091 Diensten, darunter Server und Netzwerkkomponenten bis hin zu digitalen Thermometern, mit dem Web-basierten grafischen Administrationstool Wato (Abbildung 3) von Check_MK.
Abbildung 3: Das moderne Webinterface von Check_MK.
Spezielle Anforderungen hat Jürgen Kahrs von der Media Mobil Communication GmbH in Bremen. Seine rund 90 Beobachtungsobjekte sind nicht nur Server, sondern vor allem Satellitenverbindungen zu Schiffen und Bohrinseln in der ganzen Welt, die das Unternehmen mit Internet und VoIP-Telefonie versorgt. Die Anzahl der Beobachtungsobjekte ist zwar mit knapp 100 nicht übermäßig hoch und auch die 1400 Services halten sich im Rahmen, aber die Konfiguration mit über 20000 Zeilen Text und sehr vielen Abhängigkeiten bewegt sich an der Grenze der Wartbarkeit. Im Moment lässt sie sich nur durch ein Shellskript automatisch generieren. Weil Nagios stabil und Standard unter Debian ist, blieb Jürgen Kahrs der Software treu und ist zur neueren Version 3.4.1 gewechselt.
Besonders viele Nagios-Abkömmlinge hat Volker Stoppe untersucht, nachdem er eine über längere Zeit gewachsene Nagios-Installation als “kaum noch wartbar” einstufen musste. Zu Beginn der Recherche nach einer Alternative rangierten denn auch die Nagios-artigen Systeme ganz vorne auf seiner Liste. Die Ernüchterung folgte allerdings auf dem Fuße, als der Blick auf die Lizenzkosten von Groundwork oder OP5 fiel. Also suchte er nach einer Open-Source-Lösung.
Eine solche fand Volker Stoppe in Zabbix, was er bis heute für die richtige Entscheidung hält. “Die Kollegen kommen mit Zabbix gut zurecht. Sehr beliebt sind die grafischen Auswertungen der gesammelten Daten, in denen sie den Zeitraum und Zeitpunkt flexibel bestimmen können. Da dies auch mit verschiedenen Datenpunkten und Graphen gleichzeitig erfolgen darf, entstanden hierdurch schon neue Erkenntnisse über die eigene Systemumgebung. Auf positive Resonanz stieß auch die Möglichkeit, sich die Problemereignisse an einem bestimmten Zeitraum in der Vergangenheit anzusehen.”
Webinterface unzeitgemäß
Bei Zabbix landete schließlich auch Sandra Bluhm, zuständig für Enterprise-Server bei Versatel Deutschland, einem Anbieter von Daten-, Internet- und Sprachdiensten mit eigenem Glasfasernetz.
“Nagios wurde 2002 als zentrales Überwachungssystem eingeführt und 2012 durch Zabbix abgelöst. In Nagios v3.2 überwachten wir zirka 670 Hosts. Heute sind es rund 1000 Hosts mit deutlich mehr Parametern als zuvor mit Nagios. Hauptkritikpunkt an Nagios waren das komplizierte und veraltete Webinterface, die damit verbundenen Probleme bei der Konfiguration sowie die Performance. Zabbix überzeugte uns durch die Möglichkeiten des mitgelieferten Agenten, durch das intuitive Webinterface sowie durch die Visualisierung der gesammelten Werte.”
Sandra Bluhm ist mit der Wahl von Zabbix bis heute sehr zufrieden. “Aber es gibt auch Punkte, die wir gegenüber Nagios vermissen, zum Beispiel eine Host- und nicht Trigger-basierte Verfügbarkeitsberechnung.”
Einen anderen Gesichtspunkt bringt Harald W. Spiel, der als Linux- und MySQL-Administrator für einen größeren Konzern arbeitet. Dort monitorte er 500 Server und rund 100 Netzwerkkomponenten mit zwei Nagios-Instanzen.
Er meint: “Nagios ist gut bei Linux-Servern, hat aber Defizite bei Windows-Servern und SNMP. Daneben spielte die Performance eine Rolle.” Aus seiner Sicht ist Check_MK “das universellere System, mit dem sich sowohl Server als auch Netzwerkkomponenten gut überwachen lassen”. Mit Check_MK, Wato, Multisite und Pnp4nagios beobachtet er heute zirka 1200 Server und 400 Netzwerkkomponenten.
Fazit
Sehr große klassische Nagios-Installationen ohne Zusätze bekommen offenbar regelmäßig Probleme mit der Performance. Doch schon bei einer moderaten Größenordnung kann die Wartbarkeit der Konfigurationsdateien in Frage gestellt sein. Zumindest für die Leistungsschwierigkeiten gibt es auch unter Nagios Lösungen, dennoch sehen sich die meisten in dieser Situation eine größere Auswahl an Alternativen an. Die Umfrageteilnehmer wählten daraus dann mehrheitlich Check_MK oder Zabbix.
Beide Lösungen haben zufriedene Anwender. Die Entscheidung wird sich an persönlichen Präferenzen orientieren und daran, ob man lieber einzelne Tools selber integriert oder zu einer monolithischen Lösung tendiert, bei der alle Teile von vornherein verflochten sind.
