Zabbix OpenSource Monitoring

Hallo zusammen.

Ich habe seit einigen Jahren das Zabbix Monitoring im Einsatz und wollte hier einmal kurz anreißen, wie meine Erfahrungen mit dem Ganzen sind und was es für Pros und Cons gegenüber etwa PRTG gibt.

Installation und Einrichtung:

Zu Beginn habe ich mir Gedanken gemacht, wie es mit dem Betriebssystem darunter aussieht. Bei Dolibarr (Open Source ERP) habe ich die Erfahrung gemacht, dass eine Windows VM nicht so performant daherkommt, wie eine auf Ubuntu Server basierende Maschine. Zabbix ist jedoch aktuell sowieso nur auf Linux-Basis installierbar.

Daher habe ich mich auch aktuell hierbei für einen Ubuntu Server (20.04) entschieden. Auf einem Raspberry Pi läuft das Ganze auch einwandfrei.

Die Installation des Ubuntu Servers ist schnell gemacht und mit der Anleitung auf der Zabbix Homepage gelangt man in unter 20 Minuten auf das Zabbix Frontend. Es gibt auch schon vorgefertigte Pakete und Images für die Installation oder virtuelle Instanzen für verschiedene Hypervisoren mit Standard-Werten.

Zabbix Download und Installationsanleitungen für verschiedene Linux Betriebssysteme:
https://www.zabbix.com/download

Achtung!

Hier gibt es in der Installations-Anleitung jedoch eine kleine Schwachstelle. Auf manchem PC oder in einer virtuellen Maschine kann der Schritt, bei dem das DB Schema und initiale Daten importiert werden, einige Zeit dauern. Das Terminal scheint nichts mehr zu tun und der Cursor blinkt fröhlich vor sich hin. Hier unbedingt abwarten (ca. 2 Minuten), bevor man aus Ungeduld zu voreilig mal STRG + C drückt.

Dies sollte meiner Meinung nach Erwähnung in der Anleitung finden.

Nach der nicht wirklich langwierigen Installation geht es weiter mit dem Web Frontend. Mit Admin / zabbix wird sich angemeldet. Ich habe aus alter Gewohnheit einen neuen Super-Admin erstellt, den Standard-Admin und den Guest Benutzer direkt in die Gruppe "disabled" gesteckt und damit deaktiviert.

Zabbix startet zunächst mit einer weißen Oberfläche im leicht gefüllten Dashboard. Dieses habe ich aus persönlicher Präferenz auf das dunkle Thema geändert und zunächst alle sogenannten Widgets erst einmal entfernt. Hinterher habe ich dann die Widgets hinzugefügt, welche ich auf einem Blick nach der Anmeldung vor mir haben möchte. Das Einrichten von benutzer-bezogenen Dashboards ist leichtgängig und schnell erledigt.

Hier eine Beispiel für ein Dashboard mit Problemfällen und der Übersicht des Servers (wie viele Hosts, etc.):


Hatte auch zu Beginn eine kleine Karte der Infrastruktur angelegt, welche Spaß gemacht hat zu gestalten, jedoch hinterher den Blick vom Wesentlichen etwas ablenkte. Daher entfernte ich die Karte wieder. Aber immerhin habe ich als Admin die Möglichkeit so etwas zu erstellen.

Die Benutzeroberfläche ist standardmäßig in Englisch gehalten. Man kann diese jedoch auch mit wenigen Kniffen auf Deutsch umstellen.

Nicht alles ist übersetzt worden und manchmal ist die Englische Oberfläche einfach akkurater.

Dazu müssen drei Dinge durchgeführt werden.:

• Zunächst die Deutsche Sprache für das Frontend "generieren" mit dem Befehl sudo dpkg-reconfigure locales .
• Anschließend muss die Deutsche Sprache noch in der folgenden Datei auf sichtbar gestellt werden: /usr/share/zabbix/include/locales.inc.php. Hat man die Datei mit seinem favorisiertem Editor geöffnet, nach de_DE suchen und den am Ende der Zeile stehenden Wert von "false" auf "true" ändern.
• Nun noch den Apache Dienst in meinem Fall neu starten mit sudo service apache2 restart und man kann bei allen Benutzern die Sprache umstellen.

Das Monitoring

Kommen wir nun zum Herzstück. Hier ist die Lernkurve deutlich steiler als bei PRTG beispielsweise, wo ich mir im "Klicki-Bunti-Verfahren" einzelne Sensoren zusammenstellen kann.

Zabbix ist in der Lage via JMX, IPMI, SNMP oder einem für alle gängigen Betriebssysteme vorhandenen Agent Daten zu sammeln.

Hier ein paar Bilder der Erstellung eines SNMP Hosts:

Grundlegende Daten, wie Name, welche Gruppe, welches Interface und welche IP:


Im Feld "Group" kann alles eingetragen werden. Gibt es schon etwas ähnlich lautendes, wird dieser Eintrag vorgeschlagen oder es wird vom System automatisch eine neue Gruppe erstellt.

Reiter Template und Zuordnung:


Für den exemplarischen "Kühlschrank" wähle ich das Template Module ICMP Ping. Damit wird überwacht, ob das Gerät antwortet oder nicht. Kann das Gerät beispielsweise über SNMP mehr übertragen, müsste man ein paar Templates testen, wenn das Betriebssystem nicht zu 100 Prozent klar ist.

Hier eine kleine Übersicht der Hosts eines Zabbix Test-Servers:


Im rechten Bildschirmbereich sieht man, welche Agents bei den Hosts aktiv sind. Ist ein Host nicht erreichbar, so wird das grüne Symbol direkt rot. Es sei denn der Host hat keinerlei Interface konfiguriert. So auch mein "Kühlschrank". Hier gibt man zwar die IP beim Agent Interface an, wird aber nie ein grünes Symbol bei ZBX erhalten. Trotzdem funktioniert die Sammlung der Daten zur Erreichbarkeit und der Antwortzeiten.

Es kann durchaus eine Stunde dauern, bis alle Daten des Hosts vom Zabbix Server ausgelesen worden sind und auch für die visuelle Auswertung zur Verfügung stehen.

Das ganze Monitoring Prinzip basiert (genau, wie bei PRTG) auf vorgefertigten Templates / Vorlagen mit denen beispielsweise Linux- oder Windows-Server eine Auswahl an Sensoren verpasst bekommen, welche dann in vorgefertigten Graphen visualisiert werden. Das Erstellen von Graphen kann jedoch auch vollkommen manuell erfolgen, um beispielsweise verschiedene Sensoren zu kombinieren, Skalierung, farbliche Trennung oder Darstellung zu ändern. So gibt es Graphen, welche mehr Sinn machen in einem Kuchen-Diagramm oder manche eher in Balken.

Übersicht der verfügbaren Graphen eines Synology NAS mit dem Standard Template OS Linux SNMPv2:


Standard Graphen können auch geklont und nach eigenen Vorstellungen angepasst werden.

Eigene Templates können ebenfalls erstellt und mit Hosts verknüpft werden. Die Konfiguration und deren Syntax ist bei Zabbix recht gut dokumentiert, aber ich hatte mich bisher immer auf den Standard beschränkt und bin damit gut gefahren.

Jedes Template besteht aus mehreren Komponenten. Applications beinhalten alle dort verankerten Vorlagen. Items sind die einzelnen Sensoren, welche Daten sammeln. Trigger lösen bei Ereignissen oder Unter- und -Überschreitungen von festgelgten Werten aus. Diese Trigger können in verschiedene Schweregrade eingeteilt werden. Somit kann einerseits im Dashboard schnell erkannt werden, wo es am schlimmsten brennt. Andererseits können die sogennanten Actions an diesen Schweregraden aufgehangen werden. So können beispielsweise Informationen und Warnungen ohne Sendung einer Nachricht verbleiben und alle andere Einstufungen schlagen dann Alarm.

Trigger und einzelne Komponenten können auch deaktiviert werden, wenn beispielsweise zu viele False-Positives gemeldet werden, oder einfach diese Daten nicht aufgezeichnet werden sollen.

Bei den Benachrichtigungen stehen verschiedenste Medien zur Verfügung. Beispielsweise E-Mail, SMS, Discord oder der gute alte Pager Dienst. Diese müssen zunächst an den entsprechenden Benutzern hinterlegt werden. Anschließend kann eine Action angelegt und entsprechend einfach oder auch wirklich komplex ausgestaltet werden. So können Recovery Operationen definiert werden, welche bestimmte andere Voraussetzungen benötigen. Die Bedingungen für die Actions sind vielfältig kombinierbar.

Hier erstelle ich eine Benachrichtigung für alle Probleme, deren Trigger eine gleiche oder höhere Einstufung als "Warning" haben:


In den "Operations" muss ich nun festlegen, was passieren soll. In meinem Fall soll der Benutzer Zabbixadm per E-Mail informiert werden:


Unter "Recovery Operations" definiere ich, ob ich benachrichtigt werden soll, wenn das Problem sich erledigt hat. Auch eine erneute Benachrichtigung ist konfigurierbar.

Bestehende Templates zu ändern ist nur eingeschränkt möglich. Man muss auch schauen, dass Eigenkreationen nicht mit anderen Templates kollidieren. Es wird jedoch auch sofort gemeldet, wenn mal ein Sensor in mehreren der ausgewählten Templates vorkommt.

Eingruppierungen bzw. Klassifizierungen von Hosts sind auf verschiedene Weisen möglich. Mit Tags oder Gruppen, welche schnell und unkompliziert erstellt werden können.

So bleibt die Übersicht stets gewahrt und man kann auch schnell mal eine Wartungsperiode für eine bestimmte Gruppe einrichten.

Fazit

Es gibt auch für diverse Geräte wie NAS von QNAP oder Synology extra dafür von der Community erstellte Templates, diese funktionieren leider nicht immer zuverlässig. Die Veeam Vorlage hatte ich aber erfolgreich testen können. Snyology NAS beispeislweise funktionieren jedoch mit dem oben angesprochenen Linux SNMP Template sehr gut.

Die generelle Möglichkeit der Erweiterung ist in jedem Fall nicht verkehrt und wer XML beherrscht könnte sich auch Eigenkreationen zusammenschustern.

Ein zu überwachender Host kann mit mehreren Verfahren angesprochen werden. Also SNMP und Agent gleichzeitig. Für SNMP beispielsweise muss der Community String mit einem Makro am Host definiert werden. Dies bringt eine gewisse Redundanz-Option an der Stelle.

Für PFSense gibt es beispielsweise den Agent als Standard-Paket zum Download, was das Infrastruktur-Monitoring hier schon auf einem guten Fuß startet.

Vergleich PRTG / Zabbix

Da wir auf der Arbeit PRTG und Zabbix parallel nutzen habe ich über mehrere Dinge gute Vergleiche ziehen können. Die Einrichtung von Sensoren ist bei PRTG definitiv simpler.
Den Aufbau einer Baumstruktur in PRTG halte ich jetzt nicht für einen Vorteil, da das Suchen bei Zabbix ebenfalls sehr gut Ergebnisse liefert.

Das verschachtelte Menü bei PRTG finde ich zum Beispiel nicht so dolle, verzieht man die Maus ein wenig ist der gewünschte Menüpunkt verschwunden. Da ist Zabbix haptisch besser.

Das Webfrontend von PRTG finde ich auch insgesamt etwas zu verspielt, Zabbix ist da deutlich nüchterner gehalten. Die Einrichtung und Verteilung des Zabbix Agents per GPO ist ein absolutes Plus für Enterprise Umgebungen.

Die False-Positive Meldungen empfand ich bei Zabbix tatsächlich geringer als bei PRTG. Bei einem QNAP NAS beispielsweise wurde von PRTG ständig eine fehlerhafte Festplatte gemeldet, was am Ende dazu führte, dass diese Sensoren deaktiviert wurden.

Wie Eingangs erwähnt läuft Zabbix auch auf einem Raspberry Pi. PRTG ist etwas hungriger was die Hardware betrifft und ist auf Windows als Server OS beschränkt. Zumindest sind 100 Sensoren bei PRTG kostenlos nutzbar.

Man merkt, dass Zabbix ein Open Source Projekt ist, aber ein sehr gutes und muss sich meiner Ansicht nicht vor den Konkurrenten verstecken.

Für Fragen und Anregungen stehe ich gerne parat.

Gruß
Radiogugu