Monitor Proxmox with Zabbix: using the official template right

Since version 6.0, Zabbix has shipped an official, vendor-maintained template for Proxmox: "Proxmox VE by HTTP". It works agentlessly via the REST API, automatically discovers nodes, storages, VMs and containers, and provides ready-made triggers for the most important failures. This guide shows the path to a production-ready setup - including the places where the template alone is not enough (as of July 2026, tested with Zabbix 7.x and PVE 8/9). For an overview of alternative tools, see the monitoring tools comparison.

Prerequisites

• A running Zabbix server (6.0 or newer; for SMART discovery via the API: 7.4)
• Network access from the Zabbix server to the PVE API: port 8006 (HTTPS)
• Admin access to Proxmox to create the user and token

Step 1: create a monitoring user and API token in Proxmox

The template needs read-only permissions - per the template documentation Sys.Audit on /, Datastore.Audit on /storage and VM.Audit on /vms. In practice, the built-in PVEAuditor role bundles exactly these privileges:

1. In the PVE interface under Datacenter → Permissions → Users, create a user, e.g. zabbix@pve.
2. Under Permissions, assign the PVEAuditor role on path / to the user.
3. Under API Tokens, generate a token for the user (e.g. zabbix@pve!monitoring). Important: with privilege separation enabled, the token itself also needs the PVEAuditor permission on /.
4. Note the token ID (zabbix@pve!monitoring) and the secret shown once.

On the command line, this is a three-liner:

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 lets the token inherit the user's PVEAuditor permissions. If you want to keep privilege separation (the default), assign the role to the token itself as well: pveum acl modify / --tokens 'zabbix@pve!monitoring' --roles PVEAuditor.

This way monitoring can read everything and change nothing - exactly as it should be.

Step 2: assign the template and set macros

Create a host for the Proxmox environment in Zabbix (for clusters one host is enough, the template discovers the other nodes) and link the "Proxmox VE by HTTP" template (official Zabbix integration). Then set the host macros:

The template fetches data via an HTTP-agent master item (including /cluster/resources) and distributes it to dependent items via preprocessing - gentle on the API, since only a few requests run.

Step 3: verify discovery

After a few minutes, low-level discovery should kick in. Expected result under Monitoring → Hosts:

• Cluster: quorum status with trigger
• Nodes: status, uptime, PVE version, CPU, RAM and swap utilization with load triggers
• Storages: usage per storage
• VMs & containers: all QEMU and LXC guests with CPU, RAM, disk and network I/O

From Zabbix 7.4, disk discovery with SMART health status via the PVE API (trigger on "SMART status fail"), certificate expiry and available APT updates are added. New VMs will appear automatically from now on - nobody has to update the monitoring when a guest is added.

Step 4: close the gaps - SMART, ZFS, backups

Three things the template does not cover (or not on every version):

• SMART on Zabbix < 7.4: install Zabbix agent 2 on the host (official Debian packages matching the PVE base) and use the built-in SMART plugin with the "SMART by Zabbix agent 2" template - requires smartmontools and a passwordless sudo entry for smartctl.
• ZFS pool health: no official Zabbix template exists; proven community templates read zpool status and capacity. Alternatively, custom UserParameters. A degraded pool must alert before the second disk dies.
• PBS backup jobs: add custom checks, such as the age of the last successful backup per guest via the PBS API. A green cluster with stalled backups is a deceptive calm - the PBS guide explains why.

Installing the agent on the node is quick (Zabbix 7.0 LTS; use debian12 in the package name for PVE 8, debian13 for PVE 9):

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

The connection to the Zabbix server should be encrypted - easiest via 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

Step 5: alerting and escalation

Monitoring without consequences is a dashboard. To finish:

• Adjust thresholds: tune the default triggers (e.g. CPU utilization) to the real load of the environment, otherwise alerts lose their edge.
• Notification channels: email for reports, messenger or webhook for acute alerts.
• Escalation chains: who reacts first, who after 15 minutes, who at night? Without defined responsibility, alerts fizzle out.
• Maintenance windows: enter planned work as maintenance periods so updates do not trigger a flood of false alarms.

How WZ-IT does it

This is exactly the stack we run for customers - on a highly available Zabbix cluster, so the monitoring itself is not a single point of failure: the official template as the base, agent-2 checks for SMART and ZFS, backup verification for PBS and escalation chains up to on-call. Included in Managed Proxmox from €179.90 per node per month, and available as Managed Zabbix for self-operated environments too - entry from €79.90 per month. We are happy to walk you through the setup in a free initial consultation.