Zabbix: Open-Source Monitoring für Unternehmen — Einrichtung und Best Practices

In modernen IT-Umgebungen ist Monitoring keine optionale Disziplin, sondern eine operative Notwendigkeit. Zabbix ist eine der meistverbreiteten Open-Source-Monitoring-Plattformen weltweit und bietet Unternehmen jeder Größe eine vollständige Überwachungslösung — von einfachen Ping-Checks bis hin zur Überwachung komplexer verteilter Systeme mit Tausenden von Hosts. Und das ohne Lizenzkosten.

Was ist Zabbix und warum setzen Unternehmen es ein?

Zabbix wurde 1998 von Alexei Vladishev entwickelt und ist seit 2001 als Open-Source-Projekt verfügbar. Die Plattform überwacht Server, virtuelle Maschinen, Netzwerkgeräte, Anwendungen und Cloud-Services in Echtzeit. Sie sammelt Metriken, bewertet diese gegen konfigurierbare Schwellenwerte und löst bei Bedarf Alarme aus.

Gegenüber kommerziellen Monitoring-Lösungen überzeugt Zabbix durch:

• Keine Lizenzkosten — auch für große Installationen mit Tausenden von Hosts
• Vollständige Datenkontrolle — alle Daten bleiben in der eigenen Infrastruktur
• Flexible Architektur — skalierbar von kleinen Umgebungen bis zum Enterprise-Betrieb
• Breite Integrationsmöglichkeiten — SNMP, IPMI, JMX, HTTP, Datenbanken und mehr
• Aktive Community und professioneller kommerzieller Support durch Zabbix LLC

Zabbix-Architektur: Server, Proxy, Agent

Zabbix besteht aus mehreren Komponenten, die je nach Umgebungsgröße unterschiedlich eingesetzt werden:

Zabbix Server ist das zentrale Element. Er verarbeitet eingehende Daten, bewertet Trigger und versendet Benachrichtigungen. In kleinen Umgebungen reicht ein einzelner Server, der alle Hosts direkt überwacht.

Zabbix Agent läuft auf jedem zu überwachenden System und liefert lokale Metriken an den Server. Es gibt zwei Generationen: den klassischen zabbix-agent (Version 1) und den moderneren zabbix-agent2 (Version 2), der in Go geschrieben ist und bessere Performance sowie erweiterte Plugin-Unterstützung bietet.

Zabbix Proxy sammelt Daten von einer Gruppe von Hosts und leitet sie an den Zabbix Server weiter. Proxies sind essenziell in verteilten Umgebungen — etwa an entfernten Standorten mit eingeschränkter WAN-Verbindung. Der Proxy puffert Daten lokal, sodass keine Metriken verloren gehen, selbst wenn die Verbindung zum Server kurzzeitig unterbrochen wird.

[Remote-Standort A]          [Remote-Standort B]
Hosts → Zabbix Proxy A  →    Hosts → Zabbix Proxy B
              ↓                             ↓
         [Zabbix Server (Zentrale)]
              ↓
         [Zabbix Frontend (Web)]
              ↓
         [Datenbank: PostgreSQL / MySQL]

Für die Datenbank empfehlen wir PostgreSQL mit TimescaleDB-Erweiterung — letztere optimiert die Speicherung von Zeitreihendaten erheblich und verbessert die Abfrageperformance bei großen Installationen spürbar.

Installation auf Debian/Ubuntu

Die offizielle Zabbix-Repository-Quelle stellt immer aktuelle Pakete bereit:

# Zabbix-Repository hinzufügen (Beispiel: Zabbix 7.0 LTS auf Ubuntu 24.04)
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_7.0-2+ubuntu24.04_all.deb
dpkg -i zabbix-release_7.0-2+ubuntu24.04_all.deb
apt update

# Zabbix Server, Frontend und Agent installieren
apt install -y zabbix-server-pgsql zabbix-frontend-php \
  zabbix-apache-conf zabbix-sql-scripts zabbix-agent2

# PostgreSQL-Datenbank anlegen
sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix

# Schema importieren
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | \
  sudo -u zabbix psql zabbix

Anschließend die Datenbankverbindung in /etc/zabbix/zabbix_server.conf konfigurieren:

DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=sicheresPasswort

Dienste starten und für den Autostart aktivieren:

systemctl enable --now zabbix-server zabbix-agent2 apache2

Das Zabbix-Frontend ist danach unter http://<server-ip>/zabbix erreichbar. Der Einrichtungsassistent führt durch die initiale Konfiguration.

Hosts überwachen mit dem Zabbix Agent

Auf jedem zu überwachenden Linux-Host wird der Agent installiert:

# Zabbix-Repository hinzufügen (gleicher Weg wie oben)
apt install -y zabbix-agent2

Konfiguration in /etc/zabbix/zabbix_agent2.conf:

Server=192.168.1.10          # IP des Zabbix Servers (passiver Check)
ServerActive=192.168.1.10    # IP für aktive Checks
Hostname=webserver-prod-01   # Muss mit dem Hostnamen in Zabbix übereinstimmen

systemctl enable --now zabbix-agent2

Im Zabbix-Frontend wird der Host anschließend unter Configuration > Hosts > Create host angelegt und dem passenden Template zugewiesen.

Wichtige Metriken im Unternehmensmonitoring

Zabbix erfasst standardmäßig eine umfangreiche Palette an Systemmetriken. Die wichtigsten für den täglichen Betrieb:

Kategorie	Metriken	Empfohlene Schwellenwerte
CPU	Auslastung, Load Average, iowait	Warning >70 %, Critical >90 %
RAM	Verfügbar, genutzt, Swap-Nutzung	Warning <20 % frei, Critical <10 % frei
Disk	Auslastung, I/O-Warte, freier Inodes	Warning >80 %, Critical >90 %
Netzwerk	Durchsatz, Fehlerrate, Kollisionen	Kontextabhängig
Dienste	Prozess läuft, Port erreichbar	Sofortalarm bei Ausfall
Log-Dateien	Fehlermuster in Systemlogs	Regex-basiert konfigurierbar

Mit dem Zabbix-Agent lassen sich auch benutzerdefinierte Metriken erfassen. Ein Beispiel für einen UserParameter, der die Anzahl aktiver Datenbankverbindungen überwacht:

# In /etc/zabbix/zabbix_agent2.d/custom.conf
UserParameter=db.connections,psql -U monitor -c "SELECT count(*) FROM pg_stat_activity;" -t | tr -d ' '

Templates und Auto-Discovery

Einer der größten Stärken von Zabbix sind die Templates — vorkonfigurierte Sammlungen von Items, Triggern, Graphen und Dashboards für bestimmte Systeme oder Dienste. Zabbix liefert von Haus aus Hunderte offizieller Templates mit, darunter:

• Linux by Zabbix agent (CPU, Memory, Disk, Network)
• Apache by HTTP, Nginx by HTTP
• PostgreSQL by Zabbix agent, MySQL by Zabbix agent
• VMware, Docker, Kubernetes
• Cisco, Juniper, MikroTik (via SNMP)

Templates werden einem Host oder einer Hostgruppe zugewiesen und greifen sofort — ohne manuelle Konfiguration einzelner Items.

Auto-Discovery geht noch einen Schritt weiter: Zabbix scannt regelmäßig definierte IP-Bereiche oder fragt SNMP-Geräte ab und legt neu gefundene Hosts automatisch an. Über Discovery Actions werden diesen Hosts automatisch Templates, Hostgruppen und Trigger-Aktionen zugewiesen:

Administration > Discovery > Discovery rules > Create discovery rule
→ IP-Range: 192.168.1.1-192.168.1.254
→ Checks: Zabbix Agent, ICMP Ping
→ Update interval: 1h

In größeren Umgebungen kombiniert man Auto-Discovery mit Low-Level Discovery (LLD), das z. B. automatisch alle Netzwerkschnittstellen, Festplatten oder Datenbankinstanzen auf einem Host als einzelne Items anlegt.

Alerting und Eskalationen

Zabbix-Alarme basieren auf Triggern — logischen Ausdrücken, die auf den erfassten Item-Werten operieren. Ein einfaches Beispiel:

{webserver-prod-01:system.cpu.util.avg(5m)} > 90

Dieser Trigger löst aus, wenn die durchschnittliche CPU-Auslastung der letzten 5 Minuten 90 % übersteigt.

Eskalationen ermöglichen mehrstufige Benachrichtigungsabläufe: Zunächst wird der zuständige Administrator per E-Mail informiert. Bleibt das Problem nach 30 Minuten offen, eskaliert Zabbix an den Teamleiter. Nach einer weiteren Stunde ohne Reaktion geht ein Alert an die Notfallbereitschaft. Diese Logik wird unter Configuration > Actions konfiguriert.

Zabbix unterstützt zahlreiche Benachrichtigungskanäle:

• E-Mail (SMTP)
• Slack, Microsoft Teams, Telegram (via Webhooks)
• PagerDuty, OpsGenie
• SMS über externe Gateways
• Eigene Skripte für individuelle Integrationen

Dashboard und Visualisierung

Das Zabbix-Frontend bietet flexible Dashboards, die sich pro Benutzer oder als globale Ansicht konfigurieren lassen. Verfügbare Widgets umfassen Graphen, Karten (Network Maps), Problem-Listen, Heatmaps und Datentabellen.

Für erweiterte Visualisierungen lässt sich Zabbix mit Grafana integrieren — das Zabbix-Plugin für Grafana greift direkt auf die Zabbix-API zu und erlaubt die Erstellung professioneller Dashboards mit allen Zabbix-Metriken als Datenquelle.

Zabbix im Vergleich

Kriterium	Zabbix	Prometheus + Grafana	Nagios	DATAZONE Control
Lizenzkosten	Kostenlos	Kostenlos	Nagios XI kostenpflichtig	Managed Service
Einstiegshürde	Mittel	Hoch	Mittel	Sehr niedrig
Skalierbarkeit	Sehr hoch	Sehr hoch	Begrenzt	Hoch
Agent erforderlich	Optional	Optional	Ja	Ja
Alerting	Integriert	Via Alertmanager	Integriert	Integriert
Auto-Discovery	Ja	Begrenzt	Nein	Ja
Managed/Hosted	Selbst betrieben	Selbst betrieben	Selbst betrieben	Vollständig gemanagt
DSGVO-Konformität	Selbst sicherstellen	Selbst sicherstellen	Selbst sicherstellen	Inkludiert

Integration mit DATAZONE Control

Zabbix und DATAZONE Control schließen sich nicht aus — sie ergänzen sich sinnvoll. Zabbix liefert tiefe technische Metriken auf System- und Anwendungsebene, während DATAZONE Control das übergeordnete IT-Management abdeckt: Patch-Management, Compliance-Prüfungen, Inventarisierung und automatisierte Remediation.

In der Praxis empfiehlt sich folgendes Setup: Zabbix übernimmt die granulare Metriken-Erhebung und leitet kritische Alerts per Webhook an DATAZONE Control weiter. DATAZONE Control korreliert diese Alerts mit dem aktuellen Patch-Status, offenen Compliance-Verstößen und bekannten Wartungsfenstern — und kann bei bestimmten Problemmuster automatisch Gegenmaßnahmen einleiten, etwa das Neustart eines Dienstes oder die Eskalation an das DATAZONE-Support-Team.

Best Practices für große Umgebungen

Wer Zabbix für mehr als 500 Hosts betreibt, sollte folgende Punkte beachten:

Datenbankoptimierung ist der kritischste Faktor. TimescaleDB als PostgreSQL-Erweiterung reduziert den Speicherbedarf und beschleunigt Abfragen über lange Zeiträume erheblich. Regelmäßiges Housekeeping (History, Trends) muss aktiv konfiguriert werden:

# Housekeeping-Parameter in zabbix_server.conf
HousekeepingFrequency=1
MaxHousekeeperDelete=5000

Zabbix-Proxies an entfernten Standorten oder für logische Segmente (z. B. DMZ, Produktionsnetz) reduzieren die Last auf dem zentralen Server und erhöhen die Ausfallsicherheit.

Active Checks statt passiver Checks bevorzugen — bei aktiven Checks verbinden sich die Agenten selbst zum Server, was Firewall-Regeln vereinfacht und die Skalierbarkeit verbessert.

Housekeeping-Zeiten für History und Trends sorgfältig wählen: Für operative Dashboards reichen 7–30 Tage History; Trend-Daten (stündliche Durchschnitte) können deutlich länger aufbewahrt werden.

---

Sie möchten Zabbix professionell in Ihrer Unternehmensinfrastruktur einsetzen oder suchen eine vollständig gemanagte Monitoring-Lösung? Unser Team berät Sie gerne — sprechen Sie uns über unsere Linux-Infrastrukturleistungen an oder kontaktieren Sie uns direkt.