Zabbix Monitoring im Homelab: Guide für Einsteiger

Warum Monitoring im Homelab?

Dein Homelab läuft. Proxmox schnurrt, Docker-Container erledigen ihren Job, die Self-Hosted Dienste laufen. Alles gut — bis du am Montagmorgen merkst, dass die Nextcloud seit Freitag offline war, die Festplatte zu 98% voll ist, und ein Container in einer Crash-Loop hängt. Freitag hätte ein guter Zeitpunkt gewesen, das zu wissen.

Monitoring löst genau das. Du siehst auf einen Blick, was läuft und was nicht. Und wenn etwas schief geht, bekommst du eine Nachricht — nicht erst wenn sich jemand beschwert.

Uptime Kuma vs. Zabbix: Was brauchst du?

In meinem Selfhosting-Guide habe ich Uptime Kuma empfohlen. Gutes Tool, in 2 Minuten aufgesetzt, macht genau eine Sache gut: prüfen ob Services erreichbar sind. Ja/Nein. Fertig.

Aber irgendwann willst du mehr wissen:

• Warum ist der Service langsam? CPU bei 95%? RAM voll? Disk I/O am Limit?
• Wie war die Performance letzte Woche vs. heute?
• Welcher Container frisst plötzlich 4 GB RAM obwohl er sonst mit 500 MB auskommt?
• Wann wird die Festplatte voll, wenn sie jeden Tag 2 GB mehr belegt?

Hier kommt Zabbix ins Spiel. Zabbix ist Enterprise-Monitoring — das gleiche Tool, mit dem Rechenzentren tausende Server überwachen. Und ja, es ist kostenlos und Open Source. Kein Haken, kein “Enterprise Tier” mit den eigentlich wichtigen Features hinter einer Paywall.

Was Zabbix konkret überwacht

Klingt nach Overkill fürs Homelab? Vielleicht. Aber sobald du es hast, willst du nie wieder ohne. Es ist wie eine Rückfahrkamera am Auto — brauchst du nicht, willst du aber nie wieder hergeben.

Zabbix-Architektur: Was du brauchst

Bevor wir loslegen, ein kurzer Blick auf die Komponenten. Zabbix besteht aus drei Teilen:

┌──────────────────────────────────────────┐
│           Zabbix Frontend (Web)          │
│        ───────────────────────           │
│   Dashboard, Graphs, Trigger, Config     │
└──────────────────┬───────────────────────┘
                   │
┌──────────────────┴───────────────────────┐
│           Zabbix Server (Backend)        │
│        ───────────────────────           │
│   Datensammlung, Trigger-Auswertung,     │
│   Alerting, Housekeeping                 │
└──────────────────┬───────────────────────┘
                   │
┌──────────────────┴───────────────────────┐
│           Zabbix Agents (auf den Hosts)  │
│        ───────────────────────           │
│   Sammeln lokale Metriken, senden an     │
│   Server. Leichtgewichtig (~10 MB RAM)   │
└──────────────────────────────────────────┘

• Zabbix Server: Das Gehirn. Sammelt Daten, wertet Trigger aus, schickt Alarme. Braucht eine Datenbank (MySQL/PostgreSQL).
• Zabbix Frontend: Die Web-Oberfläche. PHP-basiert, zeigt dir Dashboards, Graphen und die Konfiguration.
• Zabbix Agent: Läuft auf jedem Host, den du überwachen willst. Sammelt lokale Metriken und schickt sie an den Server. Extrem leichtgewichtig — 5-15 MB RAM.

Für ein Homelab mit 3-15 Hosts reicht ein einziger Docker-Stack für Server + Frontend + Datenbank. Die Agents installierst du auf jedem zu überwachenden System separat.

Zabbix mit Docker installieren

Die sauberste Methode für’s Homelab. Alles in einem Compose-Stack, Updates per docker compose pull, Backup per Volume-Sicherung.

Voraussetzungen

• Ein funktionierender Docker-Host (VM oder Bare-Metal)
• Mindestens 2 GB RAM frei (Zabbix Server + PostgreSQL + Frontend)
• 10 GB Festplatte für die Datenbank (wächst mit der Anzahl überwachter Hosts und der History-Retention)

Docker Compose Stack

mkdir -p /opt/docker/zabbix
cat > /opt/docker/zabbix/docker-compose.yml << 'COMPOSEEOF'
services:
  zabbix-postgres:
    image: postgres:16-alpine
    container_name: zabbix-postgres
    restart: unless-stopped
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: zabbix
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U zabbix"]
      interval: 10s
      timeout: 5s
      retries: 5

  zabbix-server:
    image: zabbix/zabbix-server-pgsql:ubuntu-7.0-latest
    container_name: zabbix-server
    restart: unless-stopped
    ports:
      - "10051:10051"
    volumes:
      - ./alertscripts:/usr/lib/zabbix/alertscripts
      - ./externalscripts:/usr/lib/zabbix/externalscripts
    environment:
      DB_SERVER_HOST: zabbix-postgres
      POSTGRES_DB: zabbix
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      ZBX_STARTPOLLERS: 10
      ZBX_CACHESIZE: 64M
      ZBX_HISTORYCACHESIZE: 32M
      ZBX_TRENDCACHESIZE: 16M
    depends_on:
      zabbix-postgres:
        condition: service_healthy

  zabbix-web:
    image: zabbix/zabbix-web-nginx-pgsql:ubuntu-7.0-latest
    container_name: zabbix-web
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      DB_SERVER_HOST: zabbix-postgres
      POSTGRES_DB: zabbix
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      ZBX_SERVER_HOST: zabbix-server
      PHP_TZ: Europe/Berlin
    depends_on:
      - zabbix-server
COMPOSEEOF

Environment-Datei anlegen

Passwörter gehören nicht in die Compose-Datei. Stattdessen eine .env Datei:

cat > /opt/docker/zabbix/.env << 'EOF'
DB_PASSWORD=HierEinSicheresPasswort42!
EOF

chmod 600 /opt/docker/zabbix/.env

Bitte nimm nicht HierEinSicheresPasswort42! als Passwort. Auch wenn es besser ist als admin123.

Stack starten

cd /opt/docker/zabbix
docker compose up -d

Der erste Start braucht 1-2 Minuten — Zabbix initialisiert die Datenbank mit dem Schema und den Default-Templates. Danach:

http://DEINE-IP:8080

Standard-Login: Admin / zabbix (Groß-A bei Admin, ja wirklich). Direkt nach dem Login ändern — in den User-Einstellungen unter Administration → Users.

Erste Schritte im Zabbix-Frontend

Nach dem Login siehst du das Default-Dashboard. Noch leer, weil kein Host überwacht wird. Das ändern wir jetzt.

Zabbix Agent 2 installieren

Der Zabbix Agent läuft auf jedem System, das du überwachen willst. Agent 2 ist die moderne Go-Version — schneller, weniger Abhängigkeiten, native Docker- und Plugin-Unterstützung.

Auf Debian/Ubuntu:

# Zabbix Repository hinzufügen (für Debian 12/Bookworm)
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
dpkg -i zabbix-release_latest_7.0+debian12_all.deb
apt update

# Agent 2 installieren
apt install -y zabbix-agent2 zabbix-agent2-plugin-*

# Konfiguration anpassen
nano /etc/zabbix/zabbix_agent2.conf

Die wichtigsten Einstellungen in /etc/zabbix/zabbix_agent2.conf:

# IP deines Zabbix-Servers (der Docker-Host, auf dem Zabbix läuft)
Server=192.168.1.100
ServerActive=192.168.1.100

# Eindeutiger Hostname — muss später im Zabbix-Frontend identisch sein!
Hostname=proxmox-node1

# Optional: verschlüsselte Verbindung via PSK
# TLSConnect=psk
# TLSAccept=psk
# TLSPSKIdentity=PSK_proxmox-node1
# TLSPSKFile=/etc/zabbix/zabbix_agent2.psk

Agent starten:

systemctl enable --now zabbix-agent2
systemctl status zabbix-agent2

Auf Proxmox direkt:

Proxmox basiert auf Debian, also gleiches Vorgehen. Das Zabbix-Repository für Debian 12 passt.

# Auf dem Proxmox-Host:
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.0+debian12_all.deb
dpkg -i zabbix-release_latest_7.0+debian12_all.deb
apt update && apt install -y zabbix-agent2

Anpassen, starten, fertig. Proxmox selbst bietet kein Monitoring-Dashboard, das in Sachen Tiefe mit Zabbix mithalten könnte — mit dem Agent holst du dir CPU-Temperatur, ZFS-Pool-Status, I/O-Werte und alles andere raus.

Host im Zabbix-Frontend anlegen

1. Monitoring → Hosts → “Create host”
2. Host name: proxmox-node1 (muss exakt mit der Agent-Konfiguration übereinstimmen!)
3. Visible name: Freitext, z.B. “Proxmox Hauptserver”
4. Host groups: “Linux servers” (oder eine eigene Gruppe erstellen, z.B. “Homelab”)
5. Interfaces → Add → Agent:
   • IP: 192.168.1.50 (die IP des überwachten Hosts)
   • Port: 10050 (Standard-Agent-Port)
6. Templates Tab → Link new templates:
   • Suche nach Linux by Zabbix agent und auswählen
   • Das Template bringt 200+ vorkonfigurierte Items, Trigger und Graphen mit

“Add” klicken. Nach 1-2 Minuten siehst du unter Monitoring → Hosts einen grünen “ZBX”-Badge — der Agent kommuniziert. Falls nicht: Firewall prüfen (Port 10050 TCP muss offen sein).

Templates: Das Herz von Zabbix

Templates sind der Grund, warum Zabbix bei 5 oder 500 Hosts gleich wenig Aufwand macht. Ein Template definiert was überwacht wird und wann Alarm geschlagen wird. Du weist es einem Host zu, und alles funktioniert automatisch.

Mitgelieferte Templates (die Wichtigsten)

Zabbix 7.0 bringt hunderte Templates mit. Hier die, die du im Homelab sofort nutzen wirst:

Docker-Container überwachen

Besonders im Homelab spannend: Zabbix kann deine Docker-Container direkt überwachen. So richtest du es ein:

Auf dem Docker-Host den Agent zur docker-Gruppe hinzufügen:

usermod -aG docker zabbix
systemctl restart zabbix-agent2

Dann im Zabbix-Frontend das Template “Docker by Zabbix agent 2” dem Host zuweisen. Zabbix entdeckt automatisch alle Container und überwacht:

• Container-Status (running, stopped, restarting)
• CPU-Nutzung pro Container
• RAM-Verbrauch pro Container
• Netzwerk-I/O pro Container
• Restart-Count

Du siehst dann auf einen Blick, welcher Container gerade Ressourcen frisst. Und wenn einer in einer Restart-Loop hängt, bekommst du sofort Bescheid.

Trigger: Wann soll Alarm geschlagen werden?

Trigger sind die Regeln, die festlegen, ab wann ein Zustand zum Problem wird. Die Templates bringen bereits sinnvolle Trigger mit. Hier die wichtigsten, die out-of-the-box funktionieren:

Standard-Trigger aus dem Linux-Template

Eigene Trigger erstellen

Nehmen wir an, du willst wissen, wenn die CPU-Temperatur über 80°C steigt (bei Mini-PCs im Sommer durchaus relevant):

1. Data collection → Hosts → Dein Host → Items → Create item
2. Name: CPU Temperature
3. Key: system.hw.sensors[temp, coretemp-isa-0000, temp1] (variiert je nach Hardware — mit zabbix_agent2 -t system.hw.sensors.list auf dem Host auslesen)
4. Type of information: Numeric (float)
5. Units: °C
6. Update interval: 60s

Jetzt den Trigger dazu:

1. Hosts → Dein Host → Triggers → Create trigger
2. Name: CPU Temperatur über 80°C auf {HOST.NAME}
3. Expression: last(/proxmox-node1/system.hw.sensors[temp,coretemp-isa-0000,temp1])>80
4. Severity: High

Fertig. Sobald der Sensor 80°C meldet, wird das Problem sichtbar und (wenn Benachrichtigungen konfiguriert sind) eine Meldung verschickt.

Predictive Trigger — die Zukunft vorhersagen

Das ist mein Lieblings-Feature in Zabbix, und ich kenne kein anderes Monitoring-Tool in dieser Preisklasse (kostenlos), das das kann: Trend-Vorhersagen.

Beispiel: Du willst wissen, ob die Festplatte in den nächsten 30 Tagen voll wird — nicht erst wenn sie es ist:

timeleft(/proxmox-node1/vfs.fs.size[/,pfree],30d,0)<30d

Das analysiert den Trend der letzten 30 Tage und rechnet hoch, wann 0% frei sein werden. Wenn das in weniger als 30 Tagen passiert → Alarm. Du hast dann einen Monat Zeit zu reagieren, statt nachts um 3 festzustellen, dass die Platte voll ist und alle Container crashed sind.

Benachrichtigungen: Telegram, Email & Co.

Ein Monitoring, das niemand sieht, ist nutzlos. Zabbix muss dich aktiv informieren wenn etwas schief geht.

Telegram-Bot einrichten (empfohlen für Homelab)

Telegram ist der beste Kanal fürs Homelab-Monitoring: Push auf’s Handy, keine Email-Flut, und Bots sind in 5 Minuten eingerichtet.

Schritt 1: Bot erstellen

1. In Telegram: @BotFather anschreiben
2. /newbot → Namen vergeben → Token kopieren (sieht aus wie 6123456789:ABCdefGHIjklMNOpqrSTUVwxyz)
3. Eine Nachricht an deinen neuen Bot schicken (damit der Chat existiert)
4. Chat-ID herausfinden: https://api.telegram.org/bot<DEIN-TOKEN>/getUpdates aufrufen, chat.id notieren

Schritt 2: In Zabbix konfigurieren

1. Alerts → Media types → Telegram (existiert bereits als Default)
2. Token eintragen: Dein Bot-Token
3. Users → Admin → Media → Add:
   • Type: Telegram
   • Send to: Deine Chat-ID
   • Severity: Mindestens Warning und höher

Schritt 3: Action erstellen

1. Alerts → Actions → Trigger actions → Create action
2. Name: Homelab Telegram Alerts
3. Conditions: Severity >= Warning
4. Operations: Send to: Admin via Telegram

Ab jetzt bekommst du eine Telegram-Nachricht, sobald ein Trigger feuert. Getestet habe ich das, indem ich stress-ng --cpu 4 --timeout 60 auf einem Host lief — nach 5 Minuten kam die Meldung. Und als die CPU wieder runter war, die Recovery-Meldung direkt hinterher.

Email-Benachrichtigungen (Alternative)

Falls du lieber Email willst — Zabbix hat einen eingebauten SMTP-Client:

1. Alerts → Media types → Email
2. SMTP-Server, Port, Absender konfigurieren
3. Tipp: Für Gmail oder andere Provider mit 2FA brauchst du ein App-Passwort

Ich empfehle trotzdem Telegram. Emails gehen unter, Push-Notifications nicht.

Dashboards: Dein Homelab auf einen Blick

Das Standard-Dashboard ist ein guter Ausgangspunkt, aber du willst ein eigenes bauen. Hier ist ein Setup, das sich bei mir bewährt hat:

Dashboard erstellen

Monitoring → Dashboards → Create dashboard

Sinnvolle Widgets für ein Homelab-Dashboard:

Graphen die sich lohnen

Einige Graphen die ich in jedem Homelab-Dashboard habe:

• CPU-Auslastung aller Hosts (stacked): Zeigt sofort, wer gerade Last erzeugt
• RAM-Verbrauch über 7 Tage: Erkennt Memory Leaks in Containern (langsam steigender Verbrauch)
• Disk I/O: Wenn die VM langsam ist, liegt es oft an der Platte — nicht an der CPU
• Netzwerk-Durchsatz: Wer schiebt gerade Daten? Backup? Jellyfin-Stream?

Praxis-Beispiel: Komplettes Homelab überwachen

Angenommen du hast dieses Setup (ein typisches Anfänger-Homelab):

Host-Gruppen sinnvoll organisieren

Statt alles in “Linux servers” zu werfen:

• Homelab/Hypervisors → Proxmox-Nodes
• Homelab/Docker → Docker-Hosts
• Homelab/Infrastructure → DNS, Router, NAS
• Homelab/Services → Einzelne VMs/Container

Das hilft bei Dashboards (Filter nach Gruppe) und Alerting (verschiedene Regeln pro Gruppe — z.B. nachts keine Alerts für nicht-kritische Services).

Maintenance Windows — Wenn Updates anstehen

Bevor du apt upgrade auf dem Proxmox-Host machst:

1. Configuration → Maintenance → Create maintenance period
2. Hosts auswählen, Zeitraum setzen
3. Während der Maintenance werden Trigger nicht als Probleme gezählt → keine Spam-Alerts während du rebooten musst

Housekeeping: Datenbank schlank halten

Zabbix sammelt Daten. Viele Daten. Ohne Housekeeping wächst die Datenbank unkontrolliert:

Empfohlene Retention-Zeiten für Homelab

In der Zabbix-Admin-Oberfläche unter Administration → Housekeeping:

• History storage period: 14d
• Trend storage period: 365d

Für ein Homelab mit 10 Hosts und ~500 Items pro Host bei 60s Intervall:

• History: ~3 GB nach 14 Tagen
• Trends: ~500 MB nach einem Jahr

Also absolut handlebar. Aber wenn du es nicht konfigurierst und die Default-Werte (90 Tage History) lässt, wunderst du dich nach 3 Monaten über eine 20 GB Datenbank.

Zabbix vs. Prometheus+Grafana: Die ehrliche Gegenüberstellung

“Warum nicht Prometheus und Grafana?” wird oft gefragt. Beides hat seine Berechtigung:

Mein Fazit: Für ein Homelab mit Proxmox, ein paar VMs, Docker-Containern, einem NAS und einem Router: Zabbix. Weil du eine Plattform hast die alles kann, statt 5 Tools zusammenzustöpseln. Templates draufklicken, Agent installieren, läuft. Kein PromQL lernen, keine Exporter-Konfiguration, kein Alertmanager-YAML.

Wenn du aber primär Kubernetes oder Cloud-Infrastruktur fährst und PromQL sowieso schon kannst: Prometheus + Grafana ist dort besser integriert.

Performance-Tipps für Zabbix im Homelab

Polling-Intervalle anpassen

Nicht jedes Item muss jede Minute geprüft werden:

• CPU/RAM: 60s (Standard, passt)
• Festplattenplatz: 300s (ändert sich langsam)
• SMART-Werte: 3600s (einmal pro Stunde reicht)
• Uptime: 600s (wenn der Host da ist, ist er da)
• Log-Items: 30s (wenn du schnelle Erkennung willst)

Je seltener gepollt wird, desto weniger Last auf Zabbix-Server und Agent. Bei 10 Hosts ist das egal, aber gute Gewohnheiten schaden nie.

PostgreSQL tunen

Für die Zabbix-Datenbank in Docker ein paar PostgreSQL-Parameter in der Compose-Datei anpassen:

  zabbix-postgres:
    image: postgres:16-alpine
    command: >
      postgres
      -c shared_buffers=256MB
      -c effective_cache_size=512MB
      -c work_mem=8MB
      -c maintenance_work_mem=128MB
      -c max_connections=100

Für ein Homelab reichen diese Werte locker. Mehr RAM heißt: mehr Cache, weniger Disk-I/O, schnellere Dashboards.

Zabbix Monitoring Kit: Fertige Templates & Dashboards

Wenn du nicht alles von Null aufbauen willst — ich hab ein Zabbix Monitoring Kit zusammengestellt mit:

• Fertige Dashboards für typische Homelab-Setups
• Optimierte Templates für Proxmox, Docker und gängige Self-Hosted Services
• Alerting-Konfiguration für Telegram und Email
• Housekeeping-Best-Practices

Spart dir ein paar Stunden Konfiguration. Aber selbst ohne Kit — mit diesem Guide hast du alles was du brauchst, um Zabbix von Grund auf einzurichten.

Häufige Fehler und Lösungen

Agent verbindet sich nicht

Symptom: Host in Zabbix zeigt roten “ZBX”-Badge.

Checkliste:

1. Agent läuft? → systemctl status zabbix-agent2
2. Firewall? → Port 10050 TCP offen? (ss -tlnp | grep 10050)
3. Server-IP korrekt in der Agent-Config?
4. Hostname in Agent-Config identisch mit Zabbix-Frontend?
5. Zabbix-Server kann den Agent erreichen? → zabbix_get -s HOST-IP -k agent.version

In 90% der Fälle ist es die Firewall oder ein Hostname-Mismatch. Wirklich, ich meine das: jedes Mal wenn ich denke “das kann es nicht sein”, ist es die Firewall.

“Not enough data” in Graphen

Zabbix braucht Zeit, um Daten zu sammeln. Neue Items zeigen erst nach 2-3 Polling-Intervallen Werte. Bei 60s-Intervall: 3 Minuten warten, dann nochmal schauen. Wirklich.

Datenbank wächst unkontrolliert

Housekeeping nicht konfiguriert (siehe oben). Plus: Kontrolliere die Anzahl der Items pro Host. 500 Items sind normal, 5000 pro Host deuten auf ein übereifrig konfiguriertes Template hin. In der Administration → Queue siehst du, ob der Server hinterherkommt.

Zabbix-Frontend langsam

Meistens die Datenbank. Entweder fehlt RAM für den PostgreSQL-Cache, oder die History-Tabelle ist zu groß. Lösung: Housekeeping konfigurieren und PostgreSQL mit den oben genannten Parametern tunen.

Nächste Schritte

Dein Monitoring steht. Von hier aus geht’s weiter:

1. SNMP einrichten für NAS, Switch und Router — die meisten Netzwerkgeräte sprechen SNMP. Zabbix hat Templates für Synology, QNAP, Ubiquiti, Mikrotik und dutzende andere.
2. Auto-Discovery konfigurieren — Zabbix kann dein Netzwerk scannen und neue Hosts automatisch hinzufügen. Praktisch wenn du oft neue VMs oder Container erstellst.
3. Grafana als Frontend — Ja, du kannst Grafana mit Zabbix als Datenquelle nutzen. Zabbix-Plugin für Grafana installieren, und du hast die beste Visualisierung mit der besten Datensammlung. Das Beste aus beiden Welten.
4. Reverse Proxy einrichten — Zabbix über eine Domain statt IP:Port erreichbar machen, mit SSL.

Fazit

Zabbix ist mächtig. Kein Zweifel. Die Lernkurve ist steiler als bei Uptime Kuma — aber dafür kannst du damit buchstäblich alles überwachen: Server, Container, Netzwerk, IoT, Cloud-APIs. Und das kostenlos, ohne “Enterprise Edition” die die eigentlich wichtigen Features sperrt.

Für ein Homelab reicht ein einzelner Docker-Stack. Agent auf jeden Host, Template zuweisen, Telegram-Alerts einrichten — das ist ein Nachmittag Arbeit. Danach hast du ein Monitoring-Setup, das in vielen Firmen besser wäre als das, was dort tatsächlich läuft.

Fang mit 2-3 Hosts an. Wenn du das Dashboard morgens zum ersten Mal öffnest und siehst, dass alles grün ist — oder eben nicht — verstehst du, warum Monitoring süchtig macht.

Zuletzt aktualisiert: Februar 2026 | Zabbix 7.0 LTS | PostgreSQL 16