Zabbix Dashboard bauen: Von der Standardansicht zum Lagebild für vier Standorte

Das Standard-Dashboard von Zabbix heißt „Global view“ und zeigt: eine Uhr, die Systeminformationen des Servers, eine Problemliste und eine Weltkarte mit einem Punkt in Riga. Das ist nicht das, was man morgens sehen will. Was man sehen will: Ist alles grün? Wenn nicht, was und wo? Und zwar ohne zu scrollen.

In diesem Teil zeige ich das Dashboard, das bei mir heute läuft. Es hat acht Seiten, deckt 62 Hosts an vier Standorten ab und ist in einem Nachmittag entstanden. Dazu die Widget-Fallen, über die ich gestolpert bin, und wie man das Ganze per API baut, statt zu klicken.

Das Prinzip: Eine Frage pro Seite

Ein Dashboard mit allem auf einer Seite wird unlesbar. Ich habe es nach Fragen gegliedert:

Bei mir läuft das Dashboard dauerhaft auf einem eigenen Bildschirm. In meinem Office habe ich vier Displays: zwei Full-HD-Monitore, einen 4K-Monitor und einen Ultrawide. Die obere Reihe, für die man den Kopf heben muss, ist für Status und Überwachung reserviert: Dort laufen das Zabbix-Dashboard und die Überwachungskameras. Die Seiten lassen sich als Slideshow durchschalten, wer gezielt sucht, klickt den Reiter.

Seite 1: Das Lagebild

Oben links die Verteilung offener Meldungen nach Schweregrad, oben rechts, wie viele Hosts Daten liefern. Zwei Zahlen, die auf einen Blick sagen, ob man weiterlesen muss.

Darunter die Problemliste ab Warnung, nach Schweregrad sortiert, mit den Operational Data. Das ist das Feld, in dem der Trigger den aktuellen Wert mitliefert, etwa „Load averages: 18.6 14.9 11.9″. Man sieht also nicht nur „Load zu hoch“, sondern wie hoch.

Die dritte Reihe ist der Teil, der sich am meisten gelohnt hat: drei Tabellen nebeneinander: Standort A, Standort B, Server. Jede zeigt pro Gerät Ping-Status und einen Kennwert, bei Access Points die WLAN-Clients, bei Servern den RAM als Balken. Rot und grün, fertig. Ein Blick reicht, um zu sehen, dass pve1 mit 95 Prozent RAM am Limit ist.

Ganz unten: Web-Checks als Zähler, die nächsten Zertifikatsabläufe, und die Mail-Ports eines Mailservers von außen als Einsen und Nullen.

Widgets: Problems by severity, Host availability, Problems, dreimal Top hosts, Web monitoring, Top hosts (Zertifikate), Top items.

Seite 2 und 3: Ein Standort, ein Netz

Pro Standort dieselbe Struktur. Oben Kacheln mit den Werten, die am häufigsten gebraucht werden: Ping-Zeit zum Gateway, Paketverlust, CPU des Gateways. Dann die Probleme dieses Standorts, dann alle Geräte als Tabelle mit CPU, RAM, Load, Ping, Uptime und Firmware.

Die untere Hälfte zeigt WLAN: Waben mit der Client-Anzahl pro Access Point, ein Verlauf der Clients über 24 Stunden, und eine Liste der Radios mit der stärksten Kanalauslastung. Letzteres ist der Wert, den man bei WLAN-Problemen zuerst braucht. Wenn ein 2,4-GHz-Radio auf 60 Prozent Kanalauslastung steht, hilft kein besserer Access Point, sondern ein anderer Kanal.

Die beiden Standorte sind bewusst getrennt. Standort A und Standort B haben eigene Hostgruppen, eigene Discovery-Regeln und eigene Proxys. Vermischt man das, sucht man ewig, welches „AP-Flur“ gemeint ist.

Die Daten dahinter kommen per SNMPv3 aus der UniFi-MIB. Das Standard-SNMP-Template von Zabbix kennt nur Interfaces und Ping, deshalb habe ich eigene Templates gebaut. Dazu kommt ein eigener Artikel.

Widgets: Host availability, dreimal Item value, Problems, Top hosts, Honeycomb, Graph, Top items, Graph.

Seite 4: Server und Proxmox

Alle Server in einer Tabelle, sortiert nach Problemen: Ping, Agent, RAM, Platte. Darunter CPU- und RAM-Verlauf aller Server in je einem Graphen, so sieht man Ausreißer sofort. Die untere Hälfte kommt aus dem Proxmox-Template: jede VM mit Status und RAM, und daneben die Datenträger mit der höchsten Belegung zuerst.

Widgets: Problems, Top hosts, zwei Graphs, zwei Top items.

Seite 5: Mail und Datenbanken

Sechs Kacheln oben: SMTP 25, Submission 587, SMTPS 465, IMAPS 993, POP3S 995, LDAPS 636. Jede zeigt eine 1 oder eine 0. Das sind einfache TCP-Checks vom Zabbix-Server aus, also die Sicht eines externen Mailclients. Darunter PostgreSQL und MariaDB mit Status und Verbindungen, dann die Dienste des Mailservers und die SMTP-Antwortzeit über den Tag.

Widgets: sechsmal Item value, Problems, zwei Top hosts, Top items, drei Graphs.

Seite 6: Dienste und Container

Hier leben die Anwendungen: die systemd-Dienste pro Host als Top-items-Liste, der Container-Bestand, und die Healthchecks aller Container. Ein Container, der unhealthy ist, steht hier rot, lange bevor jemand merkt, dass eine App nicht mehr antwortet.

Seite 7: Web und Zertifikate

Links alle 30 Websites mit HTTP-Code und Antwortzeit, rechts alle Zertifikate nach Restlaufzeit sortiert, die kürzeste oben. Unten die Antwortzeiten als Verlauf. Wer Kunden-Websites hostet, hat hier seine wichtigste Seite.

Seite 8: Inventar und Meldungen

Links der Host-Navigator mit allen 62 Hosts, gruppiert, mit Problemzähler. Rechts alle Meldungen inklusive Information, die Systeminformation des Zabbix-Servers und drei Kacheln: Queue-Länge, und wann die beiden Proxys zuletzt Kontakt hatten. Das ist die Seite für den Zabbix-Betrieb selbst.

Die Widgets, die sich lohnen

Zabbix 7.x hat rund 25 Widget-Typen. Die, die ich wirklich nutze:

• Problems: die Liste. Mit „Show operational data“ und Sortierung nach Schweregrad.
• Problems by severity: die farbige Zahlenleiste oben. Mit „Show totals“ als eine Zeile.
• Host availability: wie viele Hosts liefern. Mit „Only totals“.
• Top hosts: die Tabelle mit Balken. Das vielseitigste Widget. Spalten frei wählbar, jede Spalte ein Item, als Zahl, Balken oder Farbindikator.
• Top items: wie Top hosts, aber ein Host mit vielen Items, etwa alle Container eines Docker-Hosts.
• Item value: eine große Zahl in einer Kachel. Für die fünf Werte, die man immer sieht.
• Honeycomb: Waben, pro Host eine, gefärbt nach Wert. Perfekt für „WLAN-Clients je AP“ oder „alle Hosts nach Ping“.
• Graph (SVG): Verlauf. Mit Host- und Item-Mustern, so dass neue Hosts automatisch mit drin sind.
• Web monitoring: Zähler ok/fehlgeschlagen für Web-Szenarien.
• Host navigator: Baum aller Hosts mit Problemen.

Nicht gebraucht: Geomap, Clock, URL, Gauge (die Kachel ist besser), Map (zu viel Pflege).

Die Fallen

Ich habe das Dashboard per API gebaut und dabei mehr Zeit mit Widget-Eigenheiten verbracht als mit allem anderen. Damit es anderen erspart bleibt:

Top hosts matcht Item-Namen exakt. Eine Spalte „CPU“ mit Item-Muster CPU* zeigt nichts. Das Feld heißt zwar „Item pattern“, aber es ist kein Muster. Der Name muss auf jedem Host identisch sein. Bei Templates ist das der Fall. Bei per Discovery erzeugten Items, die den Hostnamen enthalten, wie [example.com]: Expires on, geht es nicht. Lösung: ein berechnetes Item mit festem Namen anlegen, bei mir „Zertifikat: Tage bis Ablauf“, und darauf die Spalte bauen. Das ist auch gleich der bessere Wert.

Graph-Widgets matchen den sichtbaren Hostnamen, nicht den technischen. Ein Host mit technischem Namen appserver und sichtbarem Namen „App-Server (Hetzner)“ wird von appserver nicht gefunden, von App-Server* schon.

Honeycomb braucht den Wert-Typ. primary_label_type ist 0 für Text und 1 für Wert. Steht dort etwas anderes, zeigt das Widget „not fully configured“, ohne zu sagen, welches Feld.

Felder nie doppelt setzen. Wer per API dasselbe Feld zweimal schickt, macht daraus ein Array, und das Dashboard antwortet mit HTTP 500. Die Fehlermeldung steht nur im nginx-Log.

Zeitraum. Graphen folgen dem Dashboard-Zeitraum, standardmäßig eine Stunde. Für Verläufe wie „Clients über den Tag“ im Widget „Override time period“ auf 24 Stunden setzen, sonst sieht man je nach Tageszeit nichts.

Per API bauen

Für ein Dashboard mit 60 Widgets ist Klicken keine Option. Die API-Methode dashboard.create nimmt alle Seiten und Widgets in einem Aufruf. Ein Widget ist ein JSON-Objekt mit Typ, Position, Größe und einer Feldliste:

{
  "type": "tophosts",
  "name": "Server · RAM",
  "x": 48, "y": 6, "width": 24, "height": 6,
  "fields": [
    {"type": 2, "name": "groupids.0", "value": "2"},
    {"type": 1, "name": "columns.0.name", "value": "Server"},
    {"type": 0, "name": "columns.0.data", "value": "2"},
    {"type": 1, "name": "columns.1.name", "value": "RAM"},
    {"type": 0, "name": "columns.1.data", "value": "1"},
    {"type": 1, "name": "columns.1.item", "value": "Memory utilization"},
    {"type": 0, "name": "columns.1.display", "value": "2"},
    {"type": 1, "name": "columns.1.min", "value": "0"},
    {"type": 1, "name": "columns.1.max", "value": "100"}
  ]
}

Das Raster ist 72 Einheiten breit. Der Feldtyp 0 ist Integer, 1 String, 2 Hostgruppe, 3 Host, 4 Item. Welche Felder ein Widget kennt, steht nicht in der Dokumentation, sondern im Frontend-Code unter /usr/share/zabbix/ui/widgets/<typ>/includes/WidgetForm.php. Der schnellste Weg: Ein Widget im Frontend von Hand anlegen, dann per dashboard.get die Felder auslesen und als Vorlage nehmen.

Der Vorteil: Das Dashboard liegt als JSON-Datei im Git. Ein neuer Standort ist eine kopierte Seite mit anderer Gruppen-ID.

Grafana?

Die Frage kommt immer. Ja, man kann Grafana an Zabbix hängen, das Plugin ist offiziell und die Graphen sind hübscher. Ich habe es nicht gemacht, weil die Zabbix-Widgets seit Version 7 gut genug sind und ich ein Werkzeug weniger pflegen muss. Wer schon Grafana für andere Quellen betreibt, nimmt es dazu. Wer nur Zabbix hat, braucht es nicht.

Wie es weitergeht

Damit steht die Grundausstattung: Server, Agents, Benachrichtigung, Dashboard. Die nächsten Teile gehen in die Tiefe: UniFi-Geräte per SNMP mit automatischer Discovery, ein Zabbix-Proxy für den zweiten Standort, Proxmox über die API und das Monitoring von 30 Websites mit Zertifikaten.