Das Problem
Die Nextcloud-Platte auf meinem Docker-Host war bei 100% — 817 MB frei von 373 GB. Zabbix? Stille. Kein Alert, kein Trigger, nicht mal ein Item. Null Filesystem-Monitoring auf einem Host mit 50+ Containern.
Das war nicht ein Bug, sondern vier verschiedene Fallen die zusammenspielten.
Falle 1: Container-Agent klaut den Port
Mein Zabbix-Stack lief als Docker Compose — Server, Web, Datenbank, und ein containerisierter Agent 2. Gleichzeitig hatte ich einen dpkg-installierten Host-Agent (die bessere Wahl fuer Docker-Hosts).
Das Problem: Beide wollen Port 10050.
# docker-compose.yml — der Uebeltaeter
zabbix-agent2:
image: zabbix/zabbix-agent2:alpine-7.0-latest
ports:
- 10050:10050/tcp # <-- blockiert den Host-Agent!
Der Container-Agent gewann das Port-Rennen. Der Host-Agent lief zwar (systemctl is-active = active), konnte aber nicht auf Port 10050 lauschen. Keine Fehlermeldung, kein Log-Eintrag.
Der Container-Agent sieht nur Container-Mounts (overlay, tmpfs, devpts). Die Host-Filesysteme (/, /mnt/data) existieren fuer ihn nicht. Ergebnis: Die LLD Filesystem Discovery liefert Daten, aber alles wird vom Filter rausgeworfen — null Items.
Diagnose
# Wer hat Port 10050?
ss -tlnp | grep 10050
# LISTEN 0 4096 0.0.0.0:10050 users:(("docker-proxy",...))
# ^^^^^^^^^ Container hat den Port!
# Was entdeckt der Agent?
docker exec zabbix-server zabbix_get -s <DEIN-HOST> -p 10050 -k vfs.fs.discovery
# Nur overlay, tmpfs, devpts — keine echten Filesysteme
Fix
# Container-Agent stoppen
docker compose stop zabbix-agent2
docker compose rm -f zabbix-agent2
# In docker-compose.yml dauerhaft deaktivieren
# Unter dem zabbix-agent2 Service hinzufuegen:
# profiles: ["disabled"]
# Host-Agent neustarten — bindet jetzt Port 10050
systemctl restart zabbix-agent2
ss -tlnp | grep 10050
# LISTEN 0 4096 *:10050 users:(("zabbix_agent2",...)) ✓
Falle 2: Plugin-Config crasht Agent silent
Nach dem Port-Fix startete der Host-Agent — aber lauschte immer noch nicht auf Port 10050. Kein Log-Output, kein Error, der Prozess lief einfach still vor sich hin.
Die Ursache: Eine einzelne Plugin-Config in /etc/zabbix/zabbix_agent2.d/plugins.d/ liess den Agent beim Start haengen. In meinem Fall war es mongodb.conf.
Diagnose
# Agent laeuft aber kein Port?
systemctl is-active zabbix-agent2 # active
ss -tlnp | grep 10050 # leer!
# Minimal-Config testen
cat > /tmp/zabbix_minimal.conf << 'EOF'
LogType=console
Server=127.0.0.1
ListenPort=10050
Hostname=test
EOF
timeout 8 /usr/sbin/zabbix_agent2 -c /tmp/zabbix_minimal.conf -f
# Startet normal → Problem liegt in den Includes
# Plugin-Configs einzeln testen
cd /etc/zabbix/zabbix_agent2.d/plugins.d
for f in *.conf; do
for g in *.conf; do mv "$g" "${g}.off"; done
mv "${f}.off" "$f"
RESULT=$(timeout 5 /usr/sbin/zabbix_agent2 -c /etc/zabbix/zabbix_agent2.conf -f 2>&1 | grep -c 'Press Ctrl')
[ "$RESULT" = "1" ] && echo "OK: $f" || echo "FAIL: $f"
done
for g in *.off; do mv "$g" "${g%.off}"; done
Fix
# Schuldige Config deaktivieren
mv /etc/zabbix/zabbix_agent2.d/plugins.d/mongodb.conf \
/etc/zabbix/zabbix_agent2.d/plugins.d/mongodb.conf.disabled
systemctl restart zabbix-agent2
Falle 3: /run/zabbix/ fehlt nach LXC-Reboot
Auf einem anderen LXC-Container war der Agent in einer Crash-Loop — 49.553 Restart-Versuche seit dem letzten Boot.
ERROR: Failed to run agent: cannot initialize PID file:
cannot open PID file [/run/zabbix/zabbix_agent2.pid]:
no such file or directory
/run ist ein tmpfs — alles darin verschwindet bei einem Reboot. Das Zabbix-Paket legt /run/zabbix/ beim Install an, aber nicht beim Boot.
Fix
# Sofort
mkdir -p /run/zabbix && chown zabbix:zabbix /run/zabbix
systemctl restart zabbix-agent2
# Permanent (ueberlebt Reboots)
echo 'd /run/zabbix 0755 zabbix zabbix -' > /etc/tmpfiles.d/zabbix-agent2.conf
Falle 4: Phantom-Trigger durch SNMP-Index-Drift
Auf meiner pfSense feuerten seit Wochen zwei identische Alerts fuer das gleiche WireGuard-Interface. Ursache: SNMP-Interface-Indizes aendern sich nach einem Tunnel-Neustart. Die LLD Discovery erstellt neue Items, aber die alten Trigger bleiben offen.
# Drei Discoveries fuer dasselbe Interface tun_wg1:
net.if.out.errors[9] = 0 last=2026-04-06 ← aktuell, funktioniert
net.if.out.errors[14] = 0 last=1970-01-01 ← Phantom, nie gepollt
net.if.out.errors[18] = 0 last=1970-01-01 ← Phantom, nie gepollt
Die Phantom-Items haben lastclock=1970 — sie wurden nie erfolgreich abgefragt. Aber der Trigger min(5m) > 2 wertet nodata als Problem.
Fix
Phantom-Trigger ueber die Zabbix API disablen:
curl -s -X POST -H "Content-Type: application/json-rpc" \
-d '{
"jsonrpc": "2.0",
"method": "trigger.update",
"params": {"triggerid": "<PHANTOM_TRIGGER_ID>", "status": 1},
"auth": "<TOKEN>",
"id": 1
}' https://<DEIN-ZABBIX>/api_jsonrpc.php
Checkliste: Zabbix Agent 2 auf Docker/LXC-Hosts
- Port 10050: Gehoert dem Host-Agent, nicht einem Container
- Plugin-Configs: Nach Agent-Start
ss -tlnp | grep 10050pruefen - LXC tmpfiles.d:
/etc/tmpfiles.d/zabbix-agent2.confvorhanden? - LLD Phantom-Items:
lastclock=0Items nach Interface-Aenderungen pruefen - Filesystem Discovery: Mindestens
/und relevante Mounts als Items sichtbar?
Lessons Learned
systemctl is-activeluegt — der Agent kann laufen ohne zu funktionieren. Immerss -tlnp | grep 10050als Beweis.- Plugin-Configs testen — ein kaputtes Plugin crasht den gesamten Agent ohne Fehlermeldung. Binary Bisect ist der einzige Weg.
- Container-Agent auf Docker-Hosts ist sinnlos fuer Host-Monitoring. Der sieht nur seine eigenen Mounts. dpkg-Install ist die richtige Wahl.
- SNMP-Index-Drift auf pfSense ist normal. LLD-Lifetime auf 7d setzen statt 30d um Phantome schneller loszuwerden.