docNagios vs Zabbix - Distributed Systems Group
download 
Denúncia Transcrição
Nagios vs Zabbix - Distributed Systems Group
Nagios vs Zabbix Andreas Bretschneider - 0327444 Michael Opitz - 0828257 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 Einführung 2 2 Ausfallserkennung und Notifications 2.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 7 9 3 Graphische Darstellung 10 3.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 Lern- und Konfigurationsaufwand 12 4.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5 Performance 5.1 Nagios . 5.2 Zabbix . 5.3 Fazit . . und . . . . . . . . . Hochverfügbarkeit 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6 Community-Unterstützung, Weiterentwicklung und Erweiterbarkeit 15 6.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7 Sonstige Unterschiede 17 8 Fazit 18 1 Einführung 2 Zusammenfassung Es gibt eine große Anzahl von OpenSource Netzwerküberwachungssystemen, die für unterschiedliche Zielgruppen und Einsatzzwecke designt wurden. Direkte und ausführliche Vergleiche solcher Systeme findet man jedoch nicht im Netz. Ein Vergleich dieser Überwachungssystemen würde die Wahl des Überwachungssystems für Netzwerkadministratoren wesentlich erleichtern. Im folgenden werden die 2 OpenSource Netzwerküberwachungssysteme Nagios [6] und Zabbix [5] anhand von unterschiedlichen Kriterien verglichen. Dadurch kann sich der Leser am Ende ein Bild machen, welches System für ihn am besten geeignet ist. 1 Einführung OpenSource Netzwerküberwachungssysteme unterscheiden sich in vielerlei Hinsicht. Manche Systeme zum Beispiel sind eher für Langzeitüberwachung, also hauptsächlich zur Generierung von Graphen aus z.B.: SNMP-Daten, geeignet. Manche sind nur für Kurzzeitüberwachung, also hauptsächlich zur Überprüfung ob ein entsprechender Host bzw. ein Service auf diesem Host gerade läuft, geeignet. Wieder andere versuchen beide Aspekte in einer Gesamtlösung zu kombinieren. Die Frage, die sich dabei ein Netzwerkadministrator vielleicht stellt ist: Wie gut deckt ein bestimmtes Überwachungssystem meine Bedürfnisse und Anforderungen ab? Um eine Antwort auf diese Frage zu geben, haben wir im folgenden die beiden bekannten OpenSource Netwerküberwachungs-Lösungen Nagios und Zabbix anhand von folgenden Kriterien verglichen: • Ausfalls-Erkennungs— und Notification-Möglichkeiten (Sektion 2). • Unterschiede in der graphischen Darstellungsmöglichkeit (Sektion 3). • Lern- und Konfigurationsaufwand der beiden Software-Systeme (Sektion 4). • Performance/Skalierbarkeit und Hochverfügbarkeit (Sektion 5). • Community-Unterstützung, Weiterentwicklung und Erweiterbarkeit (Sektion 6). 2 2 Ausfallserkennung und Notifications 3 Ausfallserkennung und Notifications Das Erkennen von Ausfällen von Hosts und daraufhin das Versenden von Notifications an eine oder mehrere Personen gehört zum Herzstück eines jeden Überwachungssystems. Um den Ausfall eines Systems erkennen zu können gibt es unterschiedliche Typen von Überprüfungen. Zunächst einmal gibt es die Möglichkeit ein Service direkt auf (Layer-7) Protokoll-Ebene zu testen. Für einen Web-Server bedeutet dies beispielsweise, dass HTTP-Requests gemacht werden würden und der HTTP-Response des Servers auf Status-Codes und/oder auf einen Response-String geprüft wird. Eine weitere Art einen Server zu überwachen stellen sogenannte Agents dar. Ein Agent ist eine spezielle Software, die am zu überwachenden System installiert wird und dann diverse Daten, wie etwa CPU-Auslastung, laufende Prozesse, belegter Speicher, . . . an den Überwachungsserver schickt. Auf Basis dieser Daten kann dann entschieden werden, ob sich der Server in einem kritischen Zustand befindet oder nicht. Die letzte Art einen Server zu testen sind SNMP-Requests, was vor allem bei Netzwerkgeräten wie Switches oder Router eingesetzt wird. So knnen Statistiken über die Auslastung der Interfaces erstellt werden, um so beispielsweise eventuelle Bandbreitenengpässe im Netzwerk erkennen zu können. Eines der Haupt-Unterscheidungsmerkmale bei Überwachungssystemen ist die Behandlung von Dependencies. Wenn man Dependencies bei der Konfiguration nicht berücksichtigt, kann es vorkommen, dass man mit Benachrichtigungen über Ausfälle überhäuft wird, da Hosts, welche hinter einem ausgefallenen Gerät liegen, ebenfalls vom Überwachungssystem den Zustand “Ausgefallen” zugewiesen bekommen (siehe Abb. 1). Eine weitere wichtige Frage, die man sich stellen sollte ist wann und an welche Personen Notifications versendet werden sollen. Es ist in der Regel wichtig bei einem ausgefallenen Host nur eine gewisse Personengruppe, die für den ausgefallenen Host zuständig ist, zu alamieren. Darüber hinaus kann eine Anforderung sein, dass man zu verschiedenen Tageszeiten unterschiedliche Personengruppen benachrichtigt. Schließlich kann es möglich sein, dass es eine Art Bereitschaftsdienst in einer Firma gibt, bei dem unterschiedliche Personen zu unterschiedlichen Tagen verantwortlich für einen gewissen Teil des Netzwerks sind. Außerdem sollte man klären wie die entsprechenden Personen benachrichtigt werden sollen. Möchte man bei einem Ausfall eine SMS an die betreffenden Personen schicken, oder “genügt” eine einfache E-Mail? Möglicherweise ist es außerdem sinnvoll für unterschiedliche Hosts unterschiedliche Benachrichtigungs-Arten zu wählen. Fällt beispielsweise ein wichtiger WebServer aus, so sollte man eine SMS verschicken, ist aber der Papiervorrat 2 Ausfallserkennung und Notifications 4 Abbildung 1: Bei einem Ausfall von Router 1 sollte es möglich sein nur über den Ausfall des Routers 1 benachrichtigt zu werden, nicht aber über einen Ausfall des Routers 2, dessen Status ja eigentlich aus Sicht des Überwachungsservers Unbekannt ist. eines Druckers knapp, so reicht unter Umständen eine einfache E-Mail. Wenn ein Interface eines Hosts sich in einem sogenannten “Flapping”Zustand befindet, also periodisch auf die Zustände UP und DOWN wechselt, dann kann es bei manchen Netzwerüberwachugnstools passieren, dass für jeden dieser Zustandswechsel eine Benachrichtigung generiert wird. Dadurch werden die betroffenen Personen allerdings mit vielen unnötigen Benachrichtigungen “zugemüllt”. Idealerweise erkennt eine Überwachungssoftware diesen Umstand und verschickt dafür nur eine einzige Benachrichtigung. Desweiteren kann es manches Mal erforderlich sein einen Host bzw. einen Service, der auf einem Host läuft wegen Wartungsarbeiten kurzzeitig zu deaktivieren, da z.B.: ein Sicherheitspatch eingespielt werden muss. Für solche Zwecke ist es sinnvoll Notifications für einen Host bzw. ein Service auf einem Host kurzzeitig am Überwachungssystem deaktivieren zu können, um nicht unnötige Benachrichtigungen zu versenden. Neben sogennanten aktiven Checks, die vom Netzwerküberwachungssystem selbst initiiert werden, ist es außerdem noch erforderlich passive Checks, die von einem externen Gerät kommen, wie etwa SNMP-Traps, in das System zu integrieren. 2 Ausfallserkennung und Notifications 5 (a) Trifft eines der Statements zu, so (b) Oben: die Services auf dem Host vor dem wird keine Notification an die Person ver- Ausfall. Unten: Der HTTP-Service ist ausgeschickt. fallen - aber es wurde nur eine Notification an 2 Kontakte für den HTTP-Service verschickt. Abbildung 2: Ausfallerkennung bei Nagios. 2.1 Nagios Die Checks in Nagios werden grundsätzlich ausschließlich über Plugins durchgeführt. Ein Plugin ist einfach nur ein ausführbares Script/Programm, das vom Nagios-Daemon ausgeführt wird und dessen Rückgabewert einen Status repräsentiert, der letzten Endes (abhängig von der genauen Konfiguration) im Überwachugnssystem angezeigt wird. Darüber hinaus wird die StandardAusgabe des Plugins im Überwachungssystem angezeigt um eventuell zusätzliche Fehlerinformationen den verantwortlichen Personen anzeigen zu können. Außerdem können von einem Plugin auch sogenannte Performance-Daten — das sind numerische Werte, wie etwa die Dauer des HTTP-Requests oder die Anzahl der fehlerhaften Packete bei einer SNMP-Interface-Abfrage — durch Ausgabe der entsprechenden Werte vom Plugin auf die Standard-Ausgabe ausgewertet werden. Grundsätzlich wird bei Nagios ein Service eher über eine Abfrage mittels dem entsprechenden Layer-7 Protokoll getestet. Falls dies nicht möglich ist, existieren aber auch SNMP-Plugins, die sogar ber 2 Ausfallserkennung und Notifications 6 den Package-Manager von diversen populären Distributionen (etwa Debian) verfügbar sind. Darüber hinaus gibt es für Agent-basierende Überwachung das NRPE-Addon, welches CPU-Auslastung und Ähnliche Daten eines Linux-, Windows-, BSD,- Mac-,. . . -Systems dem Überwachungssystem mitteilen kann. Nagios unterscheidet prinzipiell zwischen Hosts und Services, die auf Hosts laufen können. Hosts können einen der folgenden States haben: • UP • DOWN • UNREACHABLE Die States welche ein Service annehmen kann sind: • OK • WARN • CRITICAL • UNKNOWN Zwischen Hosts können Dependencies aus Sicht des Nagios-Servers konfiguriert werden. Zwischen Services können ebenfalls Abhängigkeiten definiert werden (siehe Abb. 2(b)). Dadurch kann man beispielsweise auch eine Abhängigkeit für eine Web-Applikation machen, die auf ein internes Webservice zugreifen muss, um seine Tätigkeit zu erfüllen. Einer Host- oder Service-Gruppe können im Nagios mehrere Kontaktgruppen zugewiesen werden. Darüber hinaus kann spezifiziert werden in welchen Zeitraum eine Gruppe eine Nachricht empfangen kann und in welchen Zeitraum ein Host bzw. Service eine Benachrichtigung “erzeugen” kann. Außerdem kann man konfigurieren über welche Zustnde (UP, DOWN, UNREACHABLE, OK, WARN, CRITICAL, UNKNOWN) man benachrichtigt werden will. Einem Kontakt kann ein Kommando zugewiesen werden, das ausgeführt wird, wenn eine Notification verschickt werden soll. Dieses Script kann nun beispielsweise eine E-Mail versenden, eine SMS verschicken, per IM die entsprechende Person benachrichtigen,. . . Einem Kontakt bzw. einer -gruppe kann aber immer nur eine einzige Zeitspanne bzw. eine Notification-Art zugewiesen werden. Um beispielsweise unterschiedliche Notification-Arten (z.B.: in der Dienstzeit der Versand einer E-Mail, außerhalb der Versand einer SMS) zu konfigurieren muss man Kontakte mehrfach anlegen. 2 Ausfallserkennung und Notifications 7 Zusätzlich bietet Nagios auch Flapping-Detection und das Versetzen von Hosts und Services in einen Wartungsmodus an. Der Wartungsmodus kann, anders als bei einer Änderung der Konfiguration (z.B. Erstellen eines neuen Hosts), über das Webinterface aktiviert werden. In Abbildung 2(a) wird nochmals zusammengefasst wann eine Notification an einem Kontakt versendet wird. Ist diese Art der Benachrichtigung zu unflexibel, so kann die Benachrichtigungslogik auch in das Script eingebaut werden, das verwendet wird um Benachrichtigungen wegzuschicken. Dem Script können sämtliche Macros übergeben werden und das Script kann daraufhin leichter intelligentere Benachrichtigungen verschicken. SNMP-Traps und Ähnliche Benachrichtigungen von “außen” können ebenfalls über Nagios verarbeitet werden [13]. 2.2 Zabbix (a) Die Konfiguration von “Items” bei Zabbix. (b) “Items” werden “Trigger” zugewiesen. (c) “Actions” bestimmen welche Gruppen benachrichtigt werden, wenn ein “Trigger” eintritt. Abbildung 3: Die grundlegende Zabbix-Konfiguration. 2 Ausfallserkennung und Notifications 8 Überprüfungen können in Zabbix über eine Agent-Software (“zabbix agent”), SNMP oder eigens geschriebene Plugins durchgeführt werden. Es gibt aber auch einige rudimentäre integrierte Layer-7 Protokoll-Checks, wie etwa HTTP oder SMB. An Zuständen kennt Zabbix im Gegensatz zu Nagios nur OK und PROBLEM, allerdings erlaubt Zabbix die Spezifikation der “Severity” (Wichtigkeit) eines Services. Die Severity des Service wird durch farbliche Hervorgehoben angezeigt. Ähnlich wie bei Nagios können bei Zabbix Hosts, die zu Hostgroups zusammengefasst werden, konfiguriert werden. Neben Hosts können, so wie auch bei Nagios, Templates definiert werden, die dann einem Host zugewiesen werden können. Einem Host (und auch einem Template) weißt man in der Regel anschließend sogenannte “Items” zu (siehe Abb. 3(a)). “Items” sind Werte, die man am entsprechenden Host abfragen will. Darunter fallen vor allem SNMPWerte, die man Abfragen möchte, oder auch Agent-Abfragen (z.B.: CPUAuslastung, . . . ) und externe Scripte, mit denen man etwas prüfen möchte. Items können auch numerische Werte zurückliefern, die über einen gewissen Zeitraum hinweg gespeichert und grafisch angezeigt werden können. Items können zu sogenannten Applications (Anwendungen) gruppiert werden, was zur besseren Übersicht beiträgt. Um nun überhaupt Nachrichten verschicken zu können müssen zunächst noch Trigger konfiguriert werden (siehe Abb. 3(b)). Ein Trigger bezieht sich immer auf ein vorher konfiguriertes Item und prüft mittels einer “Expression” (einem logischen Ausdruck) ob zum Beispiel der letzte Wert eines Items den Wert 0 hatte, da zum Beispiel der Host nicht mehr auf PINGs antwortet. Expressions können sich auch auf Zeitspannen und Durchschnittswerte beziehen. Zwischen Triggers können Dependencies definiert werden. Die eigentlichen Nachrichten werden durch sogenannte Actions verschickt (siehe Abb. 3(c)). Actions werden grundsätzlich dann ausgeführt wenn ein Trigger “triggert” (also die Bedingung des Trigger zutrifft). Zusätzlich müssen aber noch die Bedingungen der Action erfüllt sein. So kann man zum Beispiel konfigurieren, dass eine bestimmte Action nur dann ausgeführt werden soll, wenn die Hostgruppe, des ”Verursachers“einen bestimmten Wert hat. Sind alle Bedingungen erfüllt so wird die eigentliche Aktion, nämlich das Senden einer Nachricht an eine oder mehrere Host-Gruppen, eingeleitet. Ähnlich wie bei Nagios gibt es auch hier die Möglichkeit externe Kommandos aufzurufen und ggf. auch, falls das System zu unflexibel ist, zusätzliche Benachrichtigungslogik in externe Scripte auszulagern. Flapping Detection und einen Wartungsmodus hat Zabbix in der Version 1.6.X nicht, allerdings sind diese Funktionalitäten bereits für die nächste 2 Ausfallserkennung und Notifications 9 Version geplant. Dafür können mit Zabbix auch Web-Anwendungen getestet werden indem eine Reihe von HTTP-Requests definiert wird, mit denen eine Seite abgefragt werden soll. Die Response-Geschwindigkeit wird dabei automatisch geplottet. Um SNMP-Traps empfangen zu können muss bei Zabbix, ähnlich wie bei Nagios, auch Zusatzaufwand investiert werden [15]. 2.3 Fazit Bei Zabbix wird im Vergleich zu Nagios eher Agent-basierende Überwachung und SNMP-basierende Überwachung eingesetzt, da defaultmäßig nicht viele Plugins mitgeliefert werden, die direkt über das Layer 7 Protokoll Anwendugnen überprüfen. Nichtsdestotrotz ist es bei Zabbix theoretisch möglich auch solche Tests durch selbsgeschriebene Plugins einzuführen, allerdings stellt das einen Mehraufwand dar. Dafür sind besonders durch XML-Templates, die die zu testenden MIB-Werte eines entsprechenden Netzwerkgerätes vorkonfigurieren, bei SNMP-basierenden Überwachungssystemen nützlich. Den Einsatz von Agent-Software sollte man sich vorher überlegen, schließlich muss die Agent-Software auf allen Rechnern bei Upgrades und eventuellen Sicherheitslücken geupdatet werden, während der SNMP-Agent normalerweise mit dem Betriebssystem selbst, bzw. durch den Package-Manager geupdatet wird. Beide Lösungen besitzen einen umfassenden Support für Benachrichtigungen und Ausfalls-Erkennung. Nagios hat für Hosts, die von komplett ausgefallenen Hosts im Netzwerk “verdeckt” werden einen Extra-Zustand UNKNOWN bzw. UNREACHABLE. Für Zabbix kann man dafür die “Severity”, also die “Wichtigkeit” eines einzelnen Services konfigurieren. Zabbix bietet darüber hinaus sehr gut integrierte Web-Checks an, mit denen man Web-Anwendungen sehr komfortabel testen kann. Für Nagios muss man sich dafür erst entweder ein eigenes Plugin oder ein bestehendes OSS-Plugin suchen, und hat dann meistens aber kein Webinterface zur Verfügung über das man den Test konfigurieren kann. Die Bereich in denen Zabbix (1.6.X) noch Aufholbedarf hat ist vor allem der Wartungsmodus von Hosts und Services sowie die Flapping Detection. Das Einbinden von externen Benachrichtigungen, wie etwa SNMP-Traps, ist bei beiden Systemen etwas aufwändiger als das Konfigurieren von selbst initierten Checks. 3 Graphische Darstellung 3 10 Graphische Darstellung Durch die eine übersichtliche graphische Darstellung der Netzwerk-Topologie auf sogenannten Maps kann man schnell erkennen wo sich im Netzwerk ein ausgefallener Host befindet und welche Hosts man aufgrund eines Ausfalls nicht mehr überprüfen kann. Mittels Graphen kann man sich vor allem SNMP-Daten anzeigen lassen und so feststellen ob es vielleicht irgendwo im Netz zu BandbreitenEngpässen kommt oder Ähnliches. 3.1 Nagios (a) Eine NagVis Map. (b) Die Standard-Nagios Map. Abbildung 4: Visualisierungsmöglichkeiten in Nagios. Nagios bietet standardmäßig nur die Anzeige von einer Netzwerk-Map an, die per Default alle konfigurierten Hosts im Netzwerk anzeigt. Man kann die Hosts auf der Map aber auch nach Hostgruppen filtern und so nur ein Subset von Hosts anzeigen. Die Map wird automatisch aus der Konfiguration erstellt und man kann dadurch relativ gut die Parent-Child-Beziehungen (Dependencies) zwischen den einzelnen Hosts überprüfen. Darüber hinaus gibt es verschiedene Darstellungsformen der Map (kreisförmig, hierarchisch, . . . ). Bei vor allem eher kleineren Netzen ist dies recht nützlich, da man so ohne Zusatzaufwand eine automatisch generierte Map bekommt, bei größeren Netzen mit vielen Hosts wird diese Standard-Darstellung aber recht schnell zu unübersichtlich. Die Map kann durch in Konfigurationsdateien explizit angegebene X,YKoordinaten angepasst werden und man kann Hosts auch individuelle Graphiken zuweisen. Allerdings ist vor allem die Spezifikation von X,Y-Koordinaten recht aufwändig. 3 Graphische Darstellung 11 Zusätzlich bietet Nagios auch eine 3D Map an, für die aber wiederum explizit X-, Y- und auch Z-Koordinaten für jeden Host angegeben werden müssen und die deswegen auch eher selten verwendet wird. Bei vor allem größeren Netzen, bei denen man mehrere Maps für unterschiedliche Teile des Netzwerkes haben will, ist man daher auf Addons wie NagVis (siehe Abb. 4) angewiesen, mit denen auf einer Web-Oberfläche per Drag and Drop und mittels eines Hintergrundbilds (meistens einem Netzplan, den man bei einem größeren Netz sowieso haben sollte) seine Maps zusammenstellen kann [12]. Dies erfordert aber wiederum zusätzlichen Installationsaufwand und außerdem integrieren sich solche Addons im Normalfall nicht besonders gut mit der Nagios-Oberfläche sondern wirken eher wie fremde Applikationen, die auf dem selben Server unter einer anderen URL laufen. Graphen, die z.B. SNMP-Werte plotten sind in Nagios standardmäßig nicht integriert. Man muss dafür zu Addons wie etwa PNP4Nagios greifen [14]. Alternativ kann man auch eine ganz andere Netzwerküberwachungslösung wie Cacti oder MRTG einsetzen, die auf das Rendering solcher Graphen spezialisiert ist. 3.2 Zabbix Abbildung 5: In Zabbix sind verschiedene graphische Features bereits integriert. 4 Lern- und Konfigurationsaufwand 12 Bei Zabbix sind sowohl Maps als auch Graphen standardmäßig integriert. Maps müssen so wie bei NagVis explizit konfiguriert werden. Dafür ist die Konfiguration von Maps sehr gut in das Zabbix-Webinterface integriert. Es können selbstverständlich auch mehrere Maps konfiguriert werden, die jeweils einen Teilbereich im Netzwerk abbilden. Dadurch können auch größere Netze durch mehrere Maps übersichtlich dargestellt werden (siehe Abb. 5). Graphen können bei Zabbix automatisch für alle numerischen Werte (wie etwa SNMP-Interface-Abfragen, aber auch Agent-Abfragen) per Knopfdruck geplottet werden, was einen enormen Konfigurationsaufwand erspart. Neben den Linien-artigen Graphiken kann man sich außerdem Pie-Charts aus den Daten erstellen lassen. Maps und Graphen können auf sogenannten Screens aggregiert werden (siehe Abb.: 5). 3.3 Fazit Bei vor allem größeren Netzen kann Zabbix bei der visuellen Aufbereitung Punkten. Nagios ist zwar bei kleineren Netzen übersichtlicher, da dort die automatisch erstellte Status-Map sehr übersichtlich ist, und man leichter ausgefallene Rechner im Webinterface findet. Bei größeren Installationen muss man sich auf Zusatz-Addons wie etwa NagVis und den Nagios Business Process Addons verlassen, mit denen man übersichtlichere Maps und aggregierte Status-Ansichten anzeigen lassen kann. Desweiteren bietet Nagios standardmäßig keinen Support für das Plotten von beispielsweise SNMP-Daten, während Zabbix diese auf Knopfdruck erstellen kann. Wer also ohne viel Aufwand investieren zu wollen viele Graphen sich anzeigen lassen will, sollte Zabbix bevorzugen. 4 Lern- und Konfigurationsaufwand Auch der Lern- und Konfigurationsaufwand ist ein wichtiger Aspekt bei einem Netzwerküberwachungssystem. Möchte man schnell mehrere Hosts hinzufügen oder eine Änderung an einem bestehenden Host machen, so sollte dies für einen geübten Netzwerktechniker keinen allzu großen Zeitaufwand darstellen. Der Lernaufwand, den man investieren muss um das System zu konfigurieren sollte möglichst gering sein. Schließlich möchte man erreichen, dass sich möglichst viele Mitarbeiter mit dem System auskennen, dass falls jemand unvorhergesehen durch beispielsweise Krankheit ausfällt, ein anderer für ihn einspringen kann. Falls der Lernaufwand recht hoch ist, bedeutet das dass 4 Lern- und Konfigurationsaufwand 13 sich möglicherweise aus Kostengründen nur wenige Personen in das System einarbeiten können. 4.1 Nagios Nagios wird standardmäßig über Konfigurationsdateien mit einem Texteditor konfiguriert. Die Konfigurations-Sprache unterstützt Konzepte wie Vererbung durch Templates, wodurch das Anlegen eines oder mehrerer neuer Hosts nicht besonders aufwändig ist vorausgesetzt man hat seine Hosts geschickt in Hostgroups gruppiert und/oder verwendet geschickt Templates. Der Nachteil davon ist, dass man die Konfigurationskonzepte und das Notification-System dafür erst einmal gut verstehen muss Alternativ falls man keine guten Unix-Kenntnisse hat, kann man auch ein Konfigurations-Addon wie etwa NConf installieren [8], mit den man Nagios über ein PHP-basierendes Webinterface konfigurieren kann. Dadurch erhöht sich aber der Installations- und ggf. auch der Upgrade-Aufwand. Insgesamt ist der Lernaufwand von Nagios eher hoch, da man standardmäßig keine visuelle Unterstützung durch eine Web-Oberfläche hat und man sich diverse Konfigurations-Konzepte einarbeiten muss. 4.2 Zabbix Zabbix wird standardmäßig über ein Webinterface konfiguriert. Dadurch und dem eher leichter zu verstehenden Notification-Konzept hat man bei Zabbix einen eher geringeren Lernaufwand. Abgesehen von der Installation und sonstigen Upgrade-Arbeiten braucht man für die Konfiguration selbst keine besonders guten Unix-Kenntnisse. Wenn man allerdings viele Hosts auf einmal erstellen möchte entsteht beim Konfigurieren unter Umständen ein höherer (Klick-)Aufwand. 4.3 Fazit Hat man gute Unix-Kenntnisse und kann gut mit einem Editor und ggf. einer Scriptsprache umgehen mit der man schnell viele Dateien für viele Hosts erstellen kann, dann ist Nagios in Hinblick auf den Konfigurationsaufwand Zabbix eher vorzuziehen. Dafür muss man aber einen höheren Lernaufwand in Kauf nehmen. Ist man eher weniger geübt mit Editoren und Scriptsprachen, so sollte man sich für Zabbix entscheiden. 5 Performance und Hochverfügbarkeit 5 14 Performance und Hochverfügbarkeit Vor allem in großen Netzwerken kann es eine Rolle spielen Daten der einzelnen Netzwerkgeräte möglichst effizient abzufragen, sodass kein unnötiger Netztraffic entsteht. Durch zu viele Einzelrequests, die allesamt lange dauern kann unter Umständen die Überwachungssoftware selbst ausgebremst werden, da zu viele Anfragen verarbeitet werden müssen. Darüber hinaus kann es manches Mal eine Anforderung sein das Überwachungssystem hochverfügbar auszulegen, sodass beim Ausfall eines Servers ein Backup-Server einspringt und das Monitoring übernimmt. 5.1 Nagios In riesigen Umgebungen können unter Umständen Plugins, die Hosts für jeden zu überwachenden Wert einzeln abfragen, zu Performance-Problemen führen. Es existieren allerdings diverse Lösungen für dieses Problem. So kann man zum Beispiel mehrere Nagios-Server einsetzen, die jeweils einen Teil eines Netzwerks monitoren und dann die Resultate an einem zentralen Server aggregieren [2]. Nagios 3 bietet außerdem eine Option an, um die Sicht von mehreren verteilten Servern auf das Netzwerk zu ”normalisieren”, sodass man immer eine konsistente Sicht auf das Netzwerk hat. Darüber hinaus gibt es die Möglichkeit Plugin-Ergebnisse durch WrapperPlugins zu cachen, wodurch ebenfalls die Skalierbarkeit und Performance gesteigert werden kann [9]. Hochverfügbarkeit kann für Nagios kann beispielsweise mittels Heartbeat [4] und DRBD [3] (bzw. einem SAN) erreicht werden [10]. Insgesamt können wir also sagen, dass es sehr große Nagios-Installationen gibt, man allerdings wie bei vielen anderen Bereichen zusätzliche Arbeit investieren muss, damit das System gut skaliert und ausfallsicher ist. 5.2 Zabbix Ähnlich wie Nagios kann man mit Zabbix auch ein verteiltes Monitoring auf mehreren Zabbix-Servern durch sogenannte Proxies betreiben, die diverse Status-Daten dann an einen zentralen Zabbix-Server weiterleiten [1]. Um die Ausfallssicherheit gewährleisten zu können kann ähnlich wie bei Nagios Heartbeat und DRBD (für die Konfigurations-Dateien) eingesetzt werden. Dadurch dass Zabbix eine Datenbankanbindung benötigt, in dem es den Status der einzelnen Hosts speichert, muss diese ebenfalls in irgendeiner Art und Weise redundant ausgelegt werden. Wie genau das letztendlich implementiert werden kann hängt von der konkreten Datenbank ab, die zum 6 Community-Unterstützung, Weiterentwicklung und Erweiterbarkeit 15 Einsatz kommt. Zusammenfassend kann man sagen, dass auch Zabbix für größere Umgebungen geeignet ist, man aber vor allem bei einem Heartbeat Setup wieder zusätzliche Arbeit investieren muss. 5.3 Fazit Performancemäßig sind beide Lösungen ziemlich gleich zu bewerten. Durch die größere Verbreitung von Nagios gibt es zwar mehr Nagios-Installationen bei größeren Firmen und dadurch auch mehr Lösungen und Anleitungen zu bekannten Problemen, allerdings ist die Konfiguration eines Zabbix-Proxies komfortabler als die Konfiguration einer verteilten Nagios-Umgebung. Für die Hochverfügbarkeit werden in der Regel bei beiden Lösungen ähnliche Techniken verwendet. Bei Zabbix muss man sich zusätzlich um die Redundanz der Datenbank kümmern. 6 Community-Unterstützung, Weiterentwicklung und Erweiterbarkeit Gerade die Community-Unterstützung ist bei Open-Source-Projekten sehr wichtig, da man dadurch kostenlose Hilfestellungen bei Problemen bekommt, bzw. im Internet (in Mailinglisten, Foren, IRC-Channel-Logs . . . ) auf bereits bekannte Probleme von anderen Leuten Lösungen findet. Darüber hinaus bedeutet eine größere Community im Falle von Netzwerküberwachungssoftware auch mehr vorgefertigte Plugins, die unterschiedlichste Services und Netzwerkgeräte auf Funktionalität prüfen. Durch eine höhere Entwicklungsgeschwindigkeit werden die von der Community gemeldeten Fehler schneller ausgebessert und darüber hinaus schneller neue Features integriert, die die Arbeit des Netzwerkadministrators (hoffentlich) erleichtern. Durch eine gute Erweiterbarkeit ist es möglich das Überwachungssystem in andere Systeme gut zu integrieren und das System seinen individuellen Bedürfnissen anzupassen. 6.1 Nagios Nagios ist das bekannteste OpenSource Überwachungssystem und hat eine dementsprechend große Community. Es gibt eine eigene Konferenz über die Software, bei der Experten ihre Erfahrungen austauschen können. Der IRCChannel wird ungefähr von 120 Usern besucht. 6 Community-Unterstützung, Weiterentwicklung und Erweiterbarkeit 16 Nagios profiliert vor allem durch seine gute Erweiterungsmöglichkeiten. Die Software selbst bietet zwar “nur” das sehr orthogonale Plugin-Interface, mit den man durch das Aufrufen von beliebigen Programmen/Scripten Statusinformationen über Hosts integrieren kann, ein “Command-File”-Interface, über das man von externer Quelle aus Status-Informationen von Hosts in Nagios integrieren kann (z.B.: SNMP-Traps), sowie ein Event-Broker-Interface, an das Statusmeldungen weitergeleitet werden können. Nichtsdestotrotz gibt es zahlreiche Plugins für das Plugin-Interface, die diverse Netzwerk-Geräte prüfen, sowie zahlreiche Addons, die das Interface erweitern [7]. Darunter fallen unter Anderem die NDO-Utils, die die Status-Meldungen von Nagios über das Event-Broker-Interface in eine Datenbank schreiben können von der aus viele andere Addons, wie etwa NagVis, auf Status-Informationen zugreifen können, um diese in diesem Fall auf einem Netzwerkplan zu visualisieren. Die Entwicklungsgeschwindigkeit von Nagios ist dadurch, dass nur ein einziger US-Entwickler daran arbeitet und dieser nicht besonders gut mit der Community zusammenarbeitet und in der Vergangenheit nicht viele Patches integriert hat, eher träge. Dies ist auch ein Grund dafür, dass das Projekt geforkt wurde. Der sehr vielversprechende Fork Icinga, der von nahmhaften Personen aus der Community weiterentwickelt wird und abwärtskompatibel zu Nagios ist, liegt mittlerweile in einer 1.0er Version vor [11]. Ziel des Projektes ist es das etwas betagte Webinterface zu modernisieren, den Datenbank-Support zu integrieren, sowie diverse zusätzliche Addons zu integrieren. Dabei soll die Grundarchitektur und damit auch die Abwärtskompatibilität erhalten bleiben. 6.2 Zabbix Obwohl Zabbix eine etwas kleinere Community hat als Nagios findet man durchaus genügend Hilfestellungen zu Problemen, Erfahrungswerte und dergleichen. Es exisiteren für Zabbix eher weniger Addons und Plugins als für Nagios, was teilweise auch daran liegt, dass viele Dinge bereits in der Software integriert sind. Zwar existiert ein ähnlich orthogonales Plugin-Interface wie für Nagios, allerdings werden bei Zabbix eher die Standard-SNMP-Plugins und der Zabbix-Agent für Abfragen verwendet. Die Entwicklungsgeschwindigkeit ist im Vergleich zu Nagios schneller und die Beziehung zwischen Community und Entwickler “gesunder”. 6.3 Fazit Legt man viel Wert auf Erweiterbarkeit, so sollte man sich eher für Nagios entscheiden. Durch die Vielzahl an Addons existieren für sehr viele Anfor- 7 Sonstige Unterschiede 17 derungen bereits Lösungen. Muss man dennoch einmal selbst Hand anlegen und selbst ein Plugin oder Addon schreiben, so findet man durch die bereits existierenden Addons und Plugins genug Beispiel-Code und Leute, die einem ggf. bei Fragen helfen können. Ist man mit dem Standard-Zabbix-Umfang allerdings zufrieden, so sollte man sich für Zabbix entscheiden. Bei vielen Addons kann es unter Umständen nämlich beim Upgrade zu Problem kommen. Verhält sich eine neue Nagios Version anders als ein Vorgänger so kann es sein dass ein Addon durch diese Änderungen nicht mehr funktioniert (es “breaked”). Man kann sich das so vorstellen als würde man eine Brücke zwischen 2 Versionen bauen. Macht man ein Upgrade einer Version, so droht diese Brücke zusammenzubrechen. 7 Sonstige Unterschiede Abbildung 6: Das Dashboard in Zabbix kann personalisierte Informationen über Server anzeigen. Legt man als Netzwerk-Verantwortlicher vor allem Wert auf das Einrichten von unterschiedlichen User-Accounts, die allesamt für einen Teilbereich des Netzwerks zuständig sind und eine dementsprechend personalisierte Oberfläche haben wollen, sollte man sich für Zabbix entscheiden. Zabbix bietet für jeden User ein personalisiertes ”Dashboard“an, auf dem man sich Informationen, Maps und Graphen jener Hosts anzeigen lassen kann, für die man auch zuständig ist (siehe Abb. 6). Damit sieht man den Status seines Teilbereiches vom Netzwerk stets auf einen Blick. User-Accounts werden standardmäßig in der Datenbank gespeichert, in der auch die MonitoringDaten abgelegt werden. Man kann allerdings auch eine Anmeldung über LDAP aktivieren. Dabei ist nur zu beachten, dass der Verzeichnisdienst-Server Literatur 18 möglichst redundant ausgelegt werden sollte, da man sich unter Umständen beim Ausfall des LDAP-Servers nicht mehr am Überwachungsserver anmelden kann. Nagios bietet kein personalisierten Features wie etwa Dashboards für unterschiedliche User an. Die Authentifizierung erfolgt in der Regel über HTTPBasic- bzw. HTTP-Digest-Authentication, die nur über den Web-Server gehandelt wird. Daher ist es auch möglich eine LDAP-basierende Anmeldung, oder auch eine “gemischte” Anmeldung (File-basierend + LDAP) zu implementieren. Eine weitere unter Umständen nützliche Funktion von Zabbix ist NetzwerkDiscovery, die es ermöglicht durch periodische PINGs in einem Sub-Netz neue Hosts zu finden. 8 Fazit Zabbix ist eine gut integrierte All-In-One Lösung, die sich auch für größere Netzwerke eignet, vorausgesetzt man es schafft in der tabellarischen Ansicht über die Hosts die Übersicht zu behalten. Der Lernaufwand ist im Vergleich zu Nagios geringer, da der Notification-Prozess nicht allzu kompliziert ist, und man vor allem ein benutzerfreundliches, visuelles Webinterface hat, in dem man sofort alle möglichen Konfigurationsparameter sieht. Hat man allerdings umfassende Unix-Kenntnisse und möchte man sich das System nach seinen eigenen Vorstellungen anpassen, so wird man bei Zabbix wohl oder Übel mehr Aufwand investieren müssen als bei Nagios. Nagios kann vor allem gegenüber Zabbix mit Erweiterbarkeit punkten. Hat man gute Unix-Kenntnisse und kann gut mit einem Editor und einer Scriptsprache umgehen, so kann man mit zusätzlichen Lernaufwand auch größere Konfigurationsänderungen schnell durchfürhen. Durch die autogenerierte Status-Map hat man in kleineren Netzen sofort eine gute Übersicht über das Netzwerk, aber auch in größeren Netzen kann sie als Kontrolle ”fuer die richtige Konfiguration von Dependencies dienen. Man sollte sich aber natürlich stets vor Augen halten, dass eine Vielzahl von installierten Addons auch einen großeren Upgrade-Aufwand bedeuten kann. Längerfristig wird sich diese Situation mit dem Icinga-Fork wohl bessern. Literatur [1] 14. Use of Proxies [Zabbix]. http://bit.ly/8dCjrA, Abruf: Sonntag, 20. Dezember 2009 Literatur 19 [2] Distributed Nagios. http://bit.ly/7C4mCy, Abruf: Sonntag, 20. Dezember 2009 [3] DRBD:What is DRBD. http://www.drbd.org/, Abruf: Sonntag, 20. Dezember 2009 [4] HomePage: Linux HA. http://www.linux-ha.org/, Abruf: Sonntag, 20. Dezember 2009 [5] Homepage of Zabbix. http://zabbix.com, Abruf: Sonntag, 20. Dezember 2009 [6] Nagios. http://nagios.org/, Abruf: Sonntag, 20. Dezember 2009 [7] Nagios Exchange. http://exchange.nagios.org, Abruf: Sonntag, 20. Dezember 2009 [8] NConf - Enterprise Nagios configurator. http://www.nconf.org, Abruf: Sonntag, 20. Dezember 2009 [9] NETWAYS GmbH - check cache. http://bit.ly/4yEn4h, Abruf: Sonntag, 20. Dezember 2009 [10] Netways Nagios HA Presentation. Sonntag, 20. Dezember 2009 http://bit.ly/8a6Cr1, Abruf: [11] Open Source Monitoring - Icinga. Sonntag, 20. Dezember 2009 http://www.icinga.org, Abruf: [12] Project News — NagVis.org. http://nagvis.org, Abruf: Sonntag, 20. Dezember 2009 [13] SNMP Traps - NETWAYS GmbH. Sonntag, 20. Dezember 2009 http://bit.ly/7HbJ1D, Abruf: [14] start [pnp4nagios.org]. http://www.pnp4nagios.org/, Abruf: Sonntag, 20. Dezember 2009 [15] Using Zabbix to capture SNMP-Traps [Zabbix]. http://bit.ly/4AWvU6, Abruf: Sonntag, 20. Dezember 2009
