Proxmox mit Zabbix überwachen: das offizielle Template richtig einsetzen

Zabbix bringt seit Version 6.0 ein offizielles, vom Hersteller gepflegtes Template für Proxmox mit: „Proxmox VE by HTTP". Es arbeitet agentenlos über die REST-API, entdeckt Nodes, Storages, VMs und Container automatisch und liefert fertige Trigger für die wichtigsten Ausfälle. Diese Anleitung zeigt den Weg zum produktionsreifen Setup - inklusive der Stellen, an denen das Template allein nicht reicht (Stand Juli 2026, getestet mit Zabbix 7.x und PVE 8/9). Einen Überblick über alternative Werkzeuge gibt der Monitoring-Tool-Vergleich.

Voraussetzungen

• Ein laufender Zabbix-Server (6.0 oder neuer; für SMART-Discovery über die API: 7.4)
• Netzwerk-Zugriff vom Zabbix-Server auf die PVE-API: Port 8006 (HTTPS)
• Admin-Zugriff auf Proxmox, um User und Token anzulegen

Schritt 1: Monitoring-User und API-Token in Proxmox anlegen

Das Template braucht ausschließlich Lese-Rechte - laut Template-Dokumentation Sys.Audit auf /, Datastore.Audit auf /storage und VM.Audit auf /vms. In der Praxis bündelt die eingebaute PVEAuditor-Rolle genau diese Rechte:

1. In der PVE-Oberfläche unter Datacenter → Permissions → Users einen User anlegen, z. B. zabbix@pve.
2. Unter Permissions dem User die Rolle PVEAuditor auf dem Pfad / zuweisen.
3. Unter API Tokens einen Token für den User erzeugen (z. B. zabbix@pve!monitoring). Wichtig: Bei aktivierter Privilege Separation braucht auch der Token selbst die PVEAuditor-Berechtigung auf /.
4. Die Token-ID (zabbix@pve!monitoring) und das einmalig angezeigte Secret notieren.

Auf der Kommandozeile ist das ein Dreizeiler:

pveum user add zabbix@pve --comment "Zabbix Monitoring"
pveum acl modify / --users zabbix@pve --roles PVEAuditor
pveum user token add zabbix@pve monitoring --privsep 0

--privsep 0 lässt den Token die PVEAuditor-Rechte des Users erben. Wer die Privilege Separation (Default) behalten will, vergibt die Rolle zusätzlich an den Token selbst: pveum acl modify / --tokens 'zabbix@pve!monitoring' --roles PVEAuditor.

Damit kann das Monitoring alles lesen und nichts verändern - genau so soll es sein.

Schritt 2: Template zuweisen und Makros setzen

In Zabbix einen Host für die Proxmox-Umgebung anlegen (bei Clustern genügt ein Host, das Template entdeckt die übrigen Nodes) und das Template „Proxmox VE by HTTP" (offizielle Zabbix-Integration) verknüpfen. Anschließend die Host-Makros setzen:

Das Template holt die Daten über ein HTTP-Agent-Master-Item (u. a. /cluster/resources) und verteilt sie per Preprocessing auf abhängige Items - schonend für die API, da nur wenige Requests laufen.

Schritt 3: Discovery prüfen

Nach wenigen Minuten sollte die Low-Level-Discovery greifen. Erwartetes Ergebnis in Monitoring → Hosts:

• Cluster: Quorum-Status samt Trigger
• Nodes: Status, Uptime, PVE-Version, CPU-, RAM- und Swap-Auslastung mit Auslastungs-Triggern
• Storages: Füllstände je Storage
• VMs & Container: alle QEMU- und LXC-Gäste mit CPU, RAM, Disk- und Netzwerk-I/O

Ab Zabbix 7.4 kommen zusätzlich Disk-Discovery mit SMART-Health-Status über die PVE-API (Trigger bei „SMART status fail"), Zertifikats-Ablauf und verfügbare APT-Updates hinzu. Neue VMs tauchen künftig automatisch auf - niemand muss das Monitoring nachpflegen, wenn ein Gast dazukommt.

Schritt 4: Lücken schließen - SMART, ZFS, Backups

Drei Dinge deckt das Template nicht (oder nicht auf jeder Version) ab:

• SMART auf Zabbix < 7.4: den Zabbix Agent 2 auf dem Host installieren (offizielle Debian-Pakete passend zur PVE-Basis) und das eingebaute SMART-Plugin mit dem Template „SMART by Zabbix agent 2" nutzen - benötigt smartmontools und einen passwortlosen sudo-Eintrag für smartctl.
• ZFS-Pool-Health: kein offizielles Zabbix-Template vorhanden; bewährte Community-Templates lesen zpool-Status und Kapazität aus. Alternativ eigene UserParameter. Ein degradeter Pool muss alarmieren, bevor die zweite Platte stirbt.
• PBS-Backup-Jobs: eigene Checks ergänzen, etwa das Alter des letzten erfolgreichen Backups je Gast über die PBS-API. Ein grüner Cluster mit stillstehenden Backups ist eine trügerische Ruhe - warum, zeigt der PBS-Guide.

Die Agent-Installation auf dem Node ist schnell erledigt (Zabbix 7.0 LTS; für PVE 8 debian12, für PVE 9 debian13 im Paketnamen):

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 zabbix-agent2

Die Verbindung zum Zabbix-Server gehört verschlüsselt - am einfachsten per PSK:

openssl rand -hex 32 > /etc/zabbix/zabbix_agent2.psk
chown zabbix:zabbix /etc/zabbix/zabbix_agent2.psk && chmod 600 /etc/zabbix/zabbix_agent2.psk

# /etc/zabbix/zabbix_agent2.conf
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=PSK-PVE-NODE01
TLSPSKFile=/etc/zabbix/zabbix_agent2.psk

Schritt 5: Alarmierung und Eskalation

Monitoring ohne Konsequenz ist ein Dashboard. Zum Abschluss gehören:

• Schwellwerte anpassen: die Default-Trigger (z. B. CPU-Auslastung) an die reale Last der Umgebung anpassen, sonst stumpfen Alarme ab.
• Benachrichtigungswege: E-Mail für Reports, Messenger oder Webhook für akute Alarme.
• Eskalationsketten: Wer reagiert zuerst, wer nach 15 Minuten, wer nachts? Ohne definierte Zuständigkeit versanden Alarme.
• Wartungsfenster: geplante Arbeiten als Maintenance-Period eintragen, damit Updates keine Fehlalarm-Flut auslösen.

Betrieb durch WZ-IT

Wenn Sie Zabbix ausdrücklich als eigene Monitoring-Plattform einsetzen möchten, übernehmen wir Einrichtung, Pflege und Betrieb als Managed Zabbix. Managed Proxmox enthält unabhängig vom eingesetzten Werkzeug 24/7 proaktives Monitoring, Backup-Management und die vereinbarte Reaktion ab 179,90 Euro pro Node und Monat. Gern ordnen wir Ihr Setup in einem kostenlosen Erstgespräch ein.