Monitoring - Anspruch und Realisierung mit Zabbix
Teil 2

Autor: Armin Krauß - K&K Software AG

Dreiteilige Serie über Monitoring, Anspruch und Realisierung mit Zabbix

bilder/monitor-1054708_1920_1.jpg © Foto: Pixabay #1054708

Wie zu Beginn angekündigt, werde ich im zweiten Teil nun die
Monitoring Software Zabbix vorstellen. Die Open Source
Software stellt eine umfassende Lösung zur Überwachung
von IT-Systemen dar und erfreut sich unter Administratoren großer Beliebtheit. Für die Erfassung von Daten bietet Zabbix mehrere Schnittstellen. Den größten Funktionsumfang bietet die Installation eines sog. Agenten auf dem zu überwachenden Gerät. Bei einem Agenten handelt es sich um einen Software-Client, der Daten an den Zabbix-Server liefert. Dies kann wahlweise passiv (per Poll-Abfrage) oder aktiv (per Push-Übertragung) erfolgen. Zabbix-Agenten gibt es für eine Vielzahl Betriebssysteme, insbesondere Linux, Windows, OSX, AIX und FreeBSD bzw. OpenBSD. Daneben existieren weitere Schnittstellen für Sensorabfragen, wie SNMP, IPMI und JMX.

Neben der freien Verfügbarkeit überzeugt Zabbix durch seine Erweiterungsmöglichkeiten und den enormen Funktionsumfang. Die Komplexität fordert ihren Preis in Form erhöhten Einarbeitungs- und Lernaufwands, der sich jedoch schnell bezahlt macht. Ein bestechendes Merkmal, mit dem sich Zabbix von anderen Open Source Monitoring-Lösungen absetzt, ist die mächtige Weboberfläche. Diese erlaubt für Alltagsaufgaben eine reine webbasierte Bedienung, ohne die Notwendigkeit der umständlichen Konfigurationspflege in Textdateien, wie man dies beispielsweise vom oben erwähnten Nagios/Icinga kennt. Die Weboberfläche bietet direkten Zugriff auf Merkmale wie anpassbare Dashboards (Screens), Topologiedarstellungen (Maps) mit integriertem Editor, Inventarisierung der Geräte (Hosts), automatische Host-Erkennung (Discovery) sowie eine spezielle Komponente zur Prüfung von Webanwendungen.

Überzeugend ist bei Zabbix die Einrichtung der Prüfungsaufgaben gelöst. Einzelne Prüfungen werden in Zabbix als Items bezeichnet. Allerdings wird man in der Praxis nur selten einzelne Überprüfungen definieren. Stattdessen findet man Items zusammengefasst nach ihrem Einsatzzweck, Anwendung oder Betriebssystembasis des jeweiligen Geräts (Zabbix-Bezeichnung: Host) in Form von Gruppen, den sog. Templates. Diese Abstraktion erlaubt es auf sehr einfache und effiziente Weise neue Geräte in die Überwachung mit aufzunehmen. Nach Definition der Grundmerkmale wie Name oder IP-Adresse eines Geräts, sucht man sich passende Templates aus dem Pool der eigenen Zabbix-Installation aus, z.B. ein Template für das entsprechende Betriebssystem sowie weitere Templates zur Prüfung bereitgestellter Dienste. Templates stellen daher das A und O für eine leistungsstarke Zabbix Installation dar. Verfügt man erst einmal über einen breiten Pool unterschiedlichster Prüfungsszenarien, wird Zabbix zum mächtigen Datensammler und erlaubt auf komfortable Weise die Erweiterung um neue Hosts aber auch die Ausrollung weiterer Prüfungen. Templates werden von offizieller Seite aber auch rege durch die Anwender-Community bereitgestellt (unter share.zabbix.com). Wer sich wirklich ernsthaft mit dem Monitoring seiner Systemlandschaft beschäftigt, wird aber wohl früher oder später beginnen, sich seine eigenen Templates zu schreiben. Ab hier wird man in der Regel doch noch Konfigurationsdateien pflegen müssen. Hat man sein individuelles Template aber erst einmal erstellt, steht es ab sofort zur bequemen Ausrollung über die Weboberfläche bereits. Das offene Template-Konzept ermöglicht es auch Zabbix für Prüfungsaufgaben außerhalb der IT-Administration einsetzen.

Als Ergänzung zu den Items, die zunächst nur zur Datenerfassung dienen, bietet Zabbix als logische Fortführung die Möglichkeit Alarmierungen z.B. bei Überschreitung eines Schwellenwerts durch ein Item festzulegen. Diese Alarmierungen werden als Trigger bezeichnet. Items und Trigger sind dadurch eng verknüpft bzw. bauen aufeinander auf. Auch bei der Definition von Triggern erlaubt Zabbix größtmögliche Freiheit. So können Items selbstverständlich in unterschiedlichen Triggern abgefragt werden und die Prüf- bzw. Vergleichsmöglichkeiten von Triggern unterstützen auch zahlreiche komplexere Funktionen, z.B. Summen- oder Mittelwertbildungen oder Vergleiche über frei definierbare Perioden. Letzteres ermöglicht es beispielsweise schleichende Veränderungen in Messwerten aufzudecken durch Vergleiche mit gemittelten Sensordaten vom Vortag oder der vorangegangenen Woche.

Als herausragendes Merkmal kann man die Erstellung dynamischer Items und Trigger durch Zabbix-Templates bezeichnen. Nehmen wir als Beispiel ein Template zur Erfassung der Festplattentemperatur. Die meisten Zielgeräte werden über mehr als 1 Festplatte verfügen. Mit statischen Items und Trigger könnte man Prüfungen für eine bestimmte Zahl von Festplatten vorsehen, z.B. 4 Stück. Bei Geräten mit weniger als 4 Festplatten würde dies zu leeren bzw. unerfüllten Items und Trigger führen. Auf anderen Geräten, die über mehr als 4 Festplatten verfügen, blieben hingegen Komponenten unberücksichtigt. Man könnte nun separate Templates für unterschiedliche Festplattenbestückungen erstellen. Das ist in Zabbix aber gar nicht erforderlich, da Templates von Haus aus dynamische Items und Trigger unterstützen – abhängig von der tatsächlich vorgefundenen Zahl an Einzelkomponenten. Die Ermittlung dieser Komponenten (in unserem Beispiel: die Anzahl der Festplatten im Host) bezeichnet man in Zabbix als Discovery. Dahinter verbirgt sich eine relativ einfach zu implementieren Erkennungsroutine, die dem Zabbix-Template die tatsächlich vorhandenen Einzelkomponenten in Form eines JSON-Array zurückliefert. Für alle Einträge im JSON-Array lassen sich dann dynamisch Items und Trigger vordefinieren. So reicht ein einzelnes, wohlüberlegtes Template in Zabbix aus, um einen ganzen Anwendungsfall universell abzudecken.

Eine konsequente Fortführung der Alarmierung durch Trigger bietet Zabbix durch die Möglichkeit automatische Aktionen (Actions) zu erstellen. Erkennt z.B. ein Trigger den Ausfall eines Dienstes auf einem Host (z.B. der DNS-Server antwortet nicht mehr), kann durch eine zuvor festgelegte Aktion automatisch der Service neu gestartet werden. Im Alltag lassen sich so Routinefälle ohne menschlichen Eingriff beheben. Benachrichtigungen über Probleme und deren Lösung, wie man sie von einer Monitoring-Software erwartet, sind in Zabbix ebenfalls als Aktionen ausgeführt. Dies bietet den Vorteil mehrstufige Prozesse definieren zu können, bei denen zunächst eine automatische Fehlerbehebung ausgelöst wird, bevor eine E-Mail-Benachrichtigung an das Support-Team erfolgt und – bei Fortbestand der Störung – weitere Eskalationen erfolgen, z.B. E-Mails an die Team-Leitung oder SMS-Benachrichtigungen. Da auch Aktionen Optionen zur freien Erweiterbarkeit mitbringen, ist es z.B. relativ einfach möglich externe Systeme anzubinden (z.B. ein Ticket-System) oder weitere Kommunikationsmedien (z.B. Benachrichtigungen via Telegram) einzubinden.

Beim Schlagwort der freien Erweiterbarkeit sollte auch die Skripting-Schnittstelle von Zabbix nicht unerwähnt bleiben. Eine besonders effektive Lösung zur Bedienung der Zabbix-API stellt hier das Python-Skript Zabbix-CLI dar, mit dem sich beispielsweise vollautomatisiert Hosts in Zabbix erstellen lassen – mit vordefinierten Konfigurationseigenschaften aus XML-Dateien. Wer sich die Zeit nimmt, Routine-Tätigkeiten wie die Einbindung neuer Hosts (von bekanntem Typ) durch Automatismen zu bedienen, dem bietet Zabbix spätestens an dieser Stelle größtmögliche Effizienz und Einsparpotenziale.

Als letztes bestechendes Merkmal eines Monitoring-Systems mit Zabbix sei noch auf die Schnittstellenintegration in Grafana hingewiesen. Bei Grafana handelt es sich um eine mächtige Open Source Software zur Datenvisualisierung, mit der sich wunderschöne, intuitiv bedienbare Dashboards und Auswertungen erstellen lassen. Eine Vorstellung von Grafana ist in einem eigenen, späteren Beitrag geplant. Ergänzt man die Monitoring-Funktionalität von Zabbix mit den Visualisierungsmöglichkeiten von Grafana, erhält man ein Gesamtsystem, das sowohl auf Überwachungsseite wie auch im Bereich der optischen Darstellung seinesgleichen sucht.

 

Lesen Sie hier: Teil 1 und Teil 3

 

Die Namensnennung von Firmen oder Markennamen dient lediglich der redaktionellen Verwendung, zur Abgrenzung und zur Kenntlichmachung der Kompatibilität im Rahmen des jeweiligen Geschäftsumfanges. Die Zeichen, Begriffe und Namen sind gegebenenfalls geschützte Marken- und Warenzeichen der jeweiligen Rechteinhaber. Die angebotene Ware ist zu vielen Produkten namhafter Marken kompatibel, es handelt sich aber keinesfalls um Produkte der betreffenden Firmen und Marken!
 
Autor: Armin Krauß - K&K Software AG - eine Serie in 3 Teilen
 
 

Beitrag vom 23.08.2018

Kommentar abgeben: