Monitoring - Anspruch und Realisierung mit Zabbix
Teil 3

Autor: Armin Krauß - K&K Software AG

Dreiteilige Serie über Monitoring, Anspruch und Realisierung mit Zabbix

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

Nach der Theorie möchte ich nun, wie eingangs angekündigt, anhand von 3 ausgewählten Beispielen die Einsatzmöglichkeiten von Zabbix demonstrieren. Da dieser Beitrag einen Überblick zu den Möglichkeiten von Monitoring und Zabbix geben soll, kann er keine Einführung in die Bedienung und Grundkonfiguration der Überwachungssoftware geben. Hier sei auf die Vielzahl an Artikeln, Tutorials und die umfangreiche Zabbix-Dokumentation verwiesen.

 

Beispiel 1: Screens und Maps

Mit Screens bietet Zabbix die Möglichkeit individuelle Dashboards zu erstellen. Die nachstehend verlinkte Ansicht zeigt ein einfaches Screen zu einem ausgewählten Host (hier: ein Proxmox-Node aus unserem Testcluster). Die 6 zusammengestellten Graphen lassen sich bei Bedarf über den integrierten Editor in der Zabbix-Weboberfläche anpassen oder erweitern.

Eine grafische Darstellung mit freieren Gestaltungsmöglichkeiten bieten Maps. Diese können beispielsweise zur Erstellung von Topologieansichten genutzt werden, wie im nachfolgenden Screenshot zu sehen ist. Die Map wurde einfach über den Web-Editor zusammengeklickt und zeigt das Vernetzungsschema unseres Proxmox Testclusters. Die unter den Geräten kleinen, grünen OK-Symbole spiegeln übrigens den aktuellen Zustand der Monitoring-Überwachung wider. Im Fall einer Störung würde das entsprechende Gerät optisch hervorgehoben. Map-Elemente können darüber hinaus angeklickt werden, wodurch sich Informationen zum jeweiligen Gerät oder Dashboard-Ansichten aufrufen lassen.

Screens in Zabbix erlauben es andererseits Maps als Gestaltungselemente einzubinden. Die nachstehend verlinkte Ansicht zeigt eine Zweckentfremdung von Zabbix zur Visualisierung von Temperaturen und deren Verläufen. Auf der linken Seite zeigen die Map-Darstellungen die aktuellen Temperaturen im symbolisierten Gebäude an und rechts daneben die Temperaturverläufe in Form von Graphen für den ausgewählten Zeitraum.

Wem die durchaus mächtige Weboberfläche von Zabbix mit ihrer Darstellung zu altbacken erscheint, möchte ich auf die oben erwähnte, optionale Grafana-Einbindung vertrösten. Als kleinen Vorgeschmack zeigen die beiden nachstehenden Abbildungen Auszüge eines Grafana-Dashboards. Das Dashboard visualisiert eine Menge Detailwerte unseres Proxmox Testclusters – direkt abgefragt aus Zabbix über die vorhandene Schnittstelle und optisch schön aufbereitet sowie interaktiv bedienbar, wie man es von Grafana gewohnt ist.

 

Beispiel 2: Auslesen von Festplattentemperaturen

In diesem Beispiel möchte ich den oben zitierten Fall für die Ermittlung von Festplatten-Temperaturen aufgreifen. In Zabbix lässt sich dies ideal durch Erstellung eines passenden Templates lösen. Das Template soll universell für Linux-Server einsetzbar sein und die Temperatur aller im Gerät vorhandenen Festplatten automatisch erfassen. Da die Anzahl der Festplatten abhängig vom jeweiligen Gerät ist, muss man im Template eine Erkennungsroutine vorsehen – in Zabbix als „Discovery rule“ bezeichnet. Die nachstehenden Screenshots zeigt die Definition dieser Regel über die Zabbix-Weboberfläche.

Der im zweiten Screenshot referenzierte reguläre Ausdruck ermöglicht es die eingelesenen Werte bei Bedarf zu parsen. In unserem Fall ist dies nicht erforderlich, so dass wir nur sicherstellen möchten, dass die Festplattenerkennung echte Devices liefert und Nullstrings herausgefiltert werden. Die nachstehende Abbildung zeigt die Definition des zugehörigen regulären Ausdrucks, der global in den Administrationseinstellungen hinterlegt wird.

Nun muss man noch dafür sorgen, dass Zabbix den im ersten Screenshot referenzierten Key (namens custom.hdd.disks) auslesen kann. Wie die Benennung des Keys suggeriert, handelt es sich hierbei um einen selbst erstellten Eingabewert, der uns die tatsächlichen Festplatten in einem Linux-Server zurückliefern soll. Der Key muss vom jeweiligen Linux-Server zurückgeliefert werden, der unser Festplatten-Template bedienen soll. Als Schnittstelle dient auf dem Client ein installierter Zabbix-Agent (mit Einbindung im Zabbix-Server).

Zabbix-Agenten bieten die Möglichkeit eigene Keys zu definieren. In Linux-Installationen erfolgt dies in Konfigurationsdateien üblicherweise unter /etc/zabbix (meist /etc/zabbix/zabbix_agentd.conf.d oder /etc/zabbix/zabbix_agentd.d abhängig von der Include-Definition in zabbix_agentd.conf). Die Definition eigener Keys ist sehr simpel und beschränkt sich auf eine Zuordnung von Schlüsselwert zu einem Skript oder Kommadozeilenbefehl, womit der Datenwert bestimmt werden kann. In unserem Fall legen wir die Konfigurationsdatei hdd.conf an mit nachstehend abgebildetem Inhalt.

Die Konfigurationsdatei enthält neben dem bereits genannten Key (custom.hdd.disks) in Zeile 2 eine weitere Schlüsselkonfiguration (custom.hdd.temperature[*]), über die im späteren Schritt die Festplattentemperaturen ausgelesen werden. Da dies für eine beliebige Anzahl Festplatten möglich sein soll, ist der zweite Schlüssel als Array definiert, der als Übergabeparameter die Festplattenbezeichnung (z.B. sda, sdb, …) übergeben bekommt. Die Ermittlung genau der im System vorhandenen Festplattenbezeichnung wiederum ist die Aufgabe unseres ersten Keys, den wir oben definiert haben.

An dieser Stelle möchte ich nicht in Linux-spezifische Internas abdriften, mit denen man vorhandene Geräte und Festplattentemperaturen per Kommandozeilenutility ermittelt. Entscheidend im zuletzt dargestellten Screenshot ist das Mapping von selbst erstellten Keys zu einem Kommandozeilenbefehl (hier dem Skript /usr/share/zabbix-agent/scripts/hdd), das uns die gewünschten Werte zurückliefert. Interessant ist noch die Ausgabe des ersten Schlüssels (custom.hdd.disks), der den Discovery-Mechanismus unseres oben definierten Templates bedient. Das Template erwartet hier eine Rückgabe in Form eines JSON-Arrays. Wie dies aussehen kann, zeigt die folgende Abbildung am Beispiel eines unserer Proxmox-Nodes.

In diesem Fall erkennt das Template 13 Festplatten mit den Linux-typischen Device-Bezeichnungen sda, sdb, …, sdm. Passend zur oben abgebildeten Discovery rule erfolgt die Zuordnung zum Makro-Bezeichner {#DISK} (vgl. mit Abbildung 2 im Beispiel).

Nun kann im nächsten Schritt unterhalb der Discovery rule ein dynamisches Item erstellt werden, das die tatsächlichen Temperaturwerte der Festplatten erfasst. Die entsprechende Item-Definition zeigt die nachfolgende Abbildung. Relevant ist hier v.a. die Festlegung des Keys, dessen Definition bereits oben als zweiter Schlüssel in unserer Konfigurationsdatei zu sehen war. Die dargestellte Festlegung als custom.hdd.temperature[{#DISK}] sorgt dafür, dass das Item pro vorgefundenem Festplatten-Device erstellt wird.

Auf den ersten Blick mag dieses Beispiel etwas komplex erscheinen. Wer jedoch einmal die Template-Erstellung in Zabbix nachvollzogen hat, kann die benötigten Schritte anschließend schnell anwenden und verfügt damit über ein mächtiges Werkzeug, mit dem sich beliebige Messdaten im Monitoring erfassen lassen. Durch die dynamische Definition von Items lässt sich die Datenerhebung darüber hinaus flexibel und elegant für unterschiedliche Umgebungen anwenden.

 

Beispiel 3: Monitoring der virtuellen Maschinen in einem Proxmox-Cluster

Im letzten Beispiel möchte ich einen komplexen Anwendungsfall vorstellen und die Möglichkeiten demonstrieren, diesen durch Monitoring mit Zabbix zu erfassen.

Ausgangspunkt ist der zuvor schon mehrfach genannte Proxmox-Cluster. Proxmox VE ist eine Open Source Virtualisierungslösung auf Basis von Linux, die insbesondere Virtualisierung mittels QEMU/KVM unterstützt. Damit lassen sich virtuelle Maschinen mit unterschiedlichen Gastsystemen betreiben. Im Clusterverbund können diese VMs jeder Zeit per Live-Migration zwischen den Cluster-Nodes verschoben werden. Darüber hinaus unterstützt Proxmox VE von Haus aus Hochverfügbarkeit und die Replikation von virtuellen Maschinen. Neben anderen Anwendungsfällen setzen wir für unsere eigene, interne Serverlandschaft mehrere Proxmox-Cluster ein. Dieser Praxiserfahrung verdanken wir etliche Kenntnisse sowie Konfrontationen mit Problemen, wie sie im Alltag auftreten. Letztere sind dabei zum Teil allgemeiner Natur wie man sie auch in anderen Virtualisierungsumgebungen mit ähnlichem Systemaufbau vorfindet.

Ein ordentlich dimensionierter Virtualisierungscluster ist ein feines Werkzeug für den Betrieb einer Serverlandschaft. Da Hardware nur noch auf Seite der Virtualisierungsplattform vorgehalten wird, ist die Bereitstellung von Anwendungsservern im Idealfall mit wenigen Mausklicks bewerkstelligt. Problematisch wird es hingegen, wenn die Virtualisierungsumgebung an ihre Grenzen stößt und die Performance der gehosteten VMs spürbar in die Knie geht. Unzufriedene Anwender einerseits und fieberhafte Ursachensuche andererseits werden dann schnell zur Herausforderung für die IT-Administration. Falls keine offensichtlichen Defekte Auslöser für den plötzlichen Performance-Einbruch sind, kann die Ursachenforschung zur Nadelsuche im Heuhaufen werden. Aussagekräftige Daten aus dem Monitoring können jetzt den entscheidenden Vorteil bringen. Ohne Fehler auf Seite der Virtualisierungsplattform gilt es die gehosteten VMs unter die Lupe zu nehmen und darunter Perfomance-Fresser zu identifizieren. Ideal wäre es eine Darstellung der ressourcenintensivsten VMs zu bekommen, die als wahrscheinliche Verursacher für den Performance-Engpass in Frage kommen. Ausschlaggebend sind in erster Linie beanspruchte Ressourcen wie CPU-Leistung, RAM-Anforderung, v.a. aber Storage-Beanspruchung (Festplatten Lese-/Schreibraten und IOPS) und Netzwerktransfers.

Mit einem ordentlichen Monitoring lassen sich die Daten fortlaufend ermitteln, müssen jedoch für jede gehostete VM erhoben werden. Einen Zusatzaufwand machen in der Regel heterogene Umgebungen mit unterschiedlichen Gastsystemen. Auch gilt es das Monitoring ständig an die im Wechsel begriffenen Serverlandschaft anzupassen, also neu hinzugekommene VMs aufzunehmen und nicht mehr existente VMs zu entfernen. Ideal wäre es diesen Prozess zu automatisieren, so dass die Datenerhebung im Monitoring komplett ohne menschlichen Eingriff auskommt. Für eine Realisierung müssen daher 2 Anforderungen umgesetzt werden:

  1. Die automatische Aufnahme und Pflege der virtuellen Maschinen in das Monitoring
  2. Die Erfassung der Ressourcen-Nutzung (CPU-Auslastung, RAM-Belegung, Festplatten-Operationen und Netzwerk-Bandbreite) je VM

Bei Punkt b) gilt es zu beachten, dass VMs mit unterschiedlichen Gastsystemen zum Einsatz kommen. Bei einer Ermittlung der Ressourcen-Nutzung innerhalb der VMs würden daher Monitoring-Clients für unterschiedliche Betriebssysteme benötigt. Für „exotische“ VMs wie gehärtete Software-Appliances (z.B. Firewalls, Netzwerkmanagement oder WLAN-Controller) wird dies zudem unmöglich sein. Sehr viel eleganter und universell nutzbar ist es daher die Ressourcen-Nutzung der einzelnen VMs am Virtualisierungs-Host zu erfassen. Proxmox VE ermöglicht dies über das Kommandozeilen-Utility qm.

Für die in Punkt a) geforderte automatisierte Aufnahme der VMs in Monitoring ist ein Skripting der Zabbix-API erforderlich. Sehr gut eignet sich hierfür das zuvor genannte Python-Skript Zabbix-CLI. Die aktuell vorhandenen VMs im Cluster kann man bei Proxmox VE einfach anhand ihrer Konfigurationsdateien (im Verzeichnis /etc/pve/qemu-server) ermitteln. Für die Aufnahme der VMs in das Zabbix-Monitoring erwartet Zabbix-CLI pro VM eine XML-Datei mit der Host-Konfiguration. Die nachstehende Abbildung zeigt eine entsprechende Vorlage, bei der die rot eingefärbten Variablen durch die Merkmale der jeweiligen VM auszufüllen sind.

Nach erfolgreichem Import aller vorhandenen VMs stehen diese im Zabbix-Monitoring zur Verfügung wie im folgenden Screenshot zu erkennen ist. Zur fortlaufenden Pflege des Host-Bestands im Monitoring sollte der automatische Import neben der Aufnahme neuer VMs auch das Entfernen nicht mehr existenter VMs berücksichtigen.

Nach der Aufnahme in das Monitoring beginnt Zabbix sofort mit der fortlaufenden Erfassung der Ressourcen-Nutzung durch jede VM. Die nachstehende Abbildung zeigt für eine ausgewählte VM beispielhaft die Trigger (Alarmierungen), die bei Überschreitung der festgelegten Grenzen (z.B. Anzahl von IOPS) zu Warnungen durch das Monitoring führen.

Für das eingangs beschriebene Szenario von Performance-Engpässen im Virtualisierungs-Cluster liefert das Monitoring damit wertvolle Daten und identifiziert VMs mit hohem Ressourcenverbrauch. Mit dem abschließend abgebildeten Dashboard in Grafana lassen sich beispielsweise die 5 ressourcenintensivsten VMs in jeder Kategorie aufdecken. Dies gibt dem Administrator die Möglichkeit ausufernde VMs einzuschränken und schleichende Fehlentwicklungen aufzudecken.

Ich hoffe mit den im Beitrag vorgestellten Beispielen einen Einblick in die vielfältigen Möglichkeiten zur Datenüberwachung mit Zabbix gegeben zu haben.

Die nachstehende Tabellte listet abschließend einige Links zur vertieftem Lektüre.

Link

URL

Zabbix Homepage

https://www.zabbix.com/

Zabbix Dokumentation

https://www.zabbix.com/documentation/3.4/start

Zabbix Wiki

https://www.zabbix.org/wiki/Main_Page

Zabbix Templates

https://share.zabbix.com/

 

 

Zabbix-CLI

https://github.com/usit-gd/zabbix-cli/blob/master/docs/manual.rst

 

 

Grafana

https://grafana.com/

Zabbix-Plugin

https://grafana.com/plugins/alexanderzobnin-zabbix-app

 

Lesen Sie hier : Teil 1 und Teil 2

 

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 27.08.2018

Kommentar abgeben: