Betrieb & Monitoring
Zabbix
Zabbix ist eine quelloffene All-in-one-Monitoring-Lösung für Netzwerke, Server, Dienste und Cloud, die Metriken, Verfügbarkeit, Alerting und Visualisierung vereint.
- All-in-one (Metriken + Alerting + Visualisierung)
- SNMP, IPMI, JMX nativ im Kern
- Templates und Auto-Discovery (LLD)
- Proxies und Server-HA
- AGPLv3 (ab Version 7.0)
Zabbix ist eine quelloffene Monitoring-Lösung der Enterprise-Klasse aus Lettland, die anders als ein Baukasten aus mehreren Werkzeugen alles in einer Software vereint: Metriken, Verfügbarkeit, Alerting und Visualisierung. Seine Stärke liegt in der breiten, oft agentlosen Erfassung heterogener Infrastruktur und in einem Template-System, das den Konfigurationsaufwand bei vielen gleichartigen Geräten stark senkt.
Dieser Artikel erklärt die Architektur (Server, Datenbank, Frontend, Proxy, Agent), das Erfassungsmodell mit Items und Keys, Templates und Low-Level Discovery, Trigger und Eskalationen, verteiltes Monitoring und Hochverfügbarkeit, die Datenhaltung mit History und Trends sowie die Lizenzlage seit Version 7.0. Eine sachliche Abgrenzung zu Prometheus rundet das Bild ab.
1. Architektur und Komponenten
Ein Zabbix-Aufbau besteht aus fünf Bausteinen: dem Server (zentrale Verarbeitung, in C), einer Datenbank (MySQL/MariaDB oder PostgreSQL, optional mit der Erweiterung TimescaleDB), dem Web-Frontend (PHP), optionalen Proxies für verteilte Erfassung und dem Agent auf den Zielen. Daneben ist vollständig agentloses Monitoring möglich, etwa über SNMP für Netzwerkgeräte.
- Agent passiv der Server holt die Werte beim Agent ab (Pull).
- Agent aktiv der Agent meldet sich beim Server und sendet selbst (entlastet den Server, gut hinter Firewalls).
- Agentlos SNMP (v1/v2c/v3), IPMI, JMX, SSH, HTTP oder einfache ICMP-Checks ganz ohne Agent.
2. Items, Templates und automatische Erkennung
Die kleinste Einheit ist das Item: eine einzelne Metrik mit einem eindeutigen Key auf einem Host. Templates bündeln Items, Trigger, Graphen und Discovery-Regeln; eine Verknüpfung mit einem Host überträgt alles automatisch, und Änderungen am Template wirken sofort auf alle verknüpften Hosts. Low-Level Discovery (LLD) legt Items automatisch für dynamisch erkannte Objekte an, etwa für jedes Dateisystem oder Netzwerkinterface.
Der eigentliche Hebel bei Zabbix sind Templates und Low-Level Discovery. Wer jeden Host von Hand konfiguriert, hat das System nicht verstanden; wer sauber templatisiert, überwacht hunderte gleichartige Geräte mit minimalem Pflegeaufwand.
3. Trigger, Aktionen und Eskalation
Trigger sind logische Ausdrücke über Item-Werte und bestimmen den Status (OK / Problem). Sie können Zeitfenster-Funktionen nutzen (etwa Durchschnitt über fünf Minuten) und über eine separate Recovery-Bedingung mit Hysterese gegen Flattern abgesichert werden. Actions reagieren darauf: Sie versenden Benachrichtigungen über Media Types (E-Mail, SMS, Webhook, eigene Skripte) oder führen Remote-Kommandos aus, mit zeitlich gestaffelten Eskalationsstufen.
4. Verteiltes Monitoring und Hochverfügbarkeit
Ein Zabbix Proxy sammelt Daten im Auftrag des Servers (gleiche Methoden), berechnet aber selbst keine Trigger und versendet keine Alarme: Das bleibt dem Server vorbehalten. Proxies eignen sich für Außenstandorte, instabile WAN-Strecken und zur Entlastung bei vielen Hosts. Mit Version 7.0 kamen Proxy-Gruppen mit automatischer Lastverteilung hinzu. Server-Hochverfügbarkeit ist seit 6.0 nativ eingebaut (Active/Standby über eine gemeinsame Datenbank), ohne externe Cluster-Software.
5. Datenhaltung: History, Trends und Housekeeping
Zabbix speichert History (jeden Rohwert) und Trends (stündliche Aggregate aus Min/Max/Durchschnitt). History wird typischerweise kurz aufbewahrt, Trends lange, weil sie wenig Platz brauchen. Das Housekeeping löscht veraltete Daten regelmäßig; ohne sauberes Housekeeping wächst die Datenbank unbegrenzt und die Performance leidet. Bei hohem Durchsatz hilft TimescaleDB, weil es ganze Partitionen statt einzelner Zeilen löscht.
Zabbix vs. Prometheus, sachlich
Zabbix ist all-in-one, template- und geräteorientiert (SNMP/IPMI/JMX im Kern) und speichert in einer relationalen Datenbank. Prometheus ist auf Metriken und cloud-native Umgebungen ausgelegt, arbeitet primär per Pull mit PromQL und eigener Zeitreihen-Datenbank. Kein Entweder-oder, sondern eine Frage der Umgebung; oft ergänzen sie sich.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| All-in-one: kein separater Alertmanager, keine Extra-Visualisierung nötig | Relationale Datenhaltung skaliert anders als reine Zeitreihen-DBs |
| SNMP, IPMI, JMX nativ im Kern, ohne Exporter-Umweg | Housekeeping muss aktiv konfiguriert und überwacht werden |
| Templates und LLD senken den Pflegeaufwand deutlich | Trigger-Tuning erfordert Erfahrung (Flattern, Recovery) |
| Natives Server-HA und verteilte Proxies | Großer Konfigurationsumfang, spürbare Einarbeitung |
| Lange LTS-Zyklen für stabile Planung | AGPLv3 (ab 7.0) bei Weitergabe als Dienst prüfen |
Häufige Fragen zu Zabbix
Die Software ist quelloffen und kostenlos (seit Version 7.0 unter AGPLv3). Geld kostet optional kommerzieller Support, Schulung und Beratung durch Zabbix LLC oder Partner. Für die reine Nutzung fallen keine Lizenzgebühren an.
Nein. Der Agent liefert detaillierte Systemmetriken, aber Zabbix überwacht auch vollständig agentlos über SNMP, IPMI, JMX, SSH oder HTTP. Gerade Netzwerkgeräte werden in der Regel per SNMP ohne Agent eingebunden.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Zabbix im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.