Monitoring Proxmox VE
A Proxmox VE node is recognised by its daemon and read through the API the node already
runs, using pvesh in read-only fashion. Guests, storage, the cluster view from this
node's side, HA state and the outcome of every backup and migration arrive within a minute
of installing the agent. Each node runs its own agent; there is nothing to configure on the
cluster.
How Proxmox VE is recognised
The signed Proxmox definition matches a host that runs the pvedaemon process. Every
minute it runs pveversion for the version, pvesm status for the storage summary, and the
compiled probe, which calls pvesh get on /cluster/resources, /cluster/status,
/cluster/ha/status and /cluster/tasks with a 30-second budget. A node counts as a
cluster member when /cluster/status reports a cluster or /etc/pve/corosync.conf exists;
a standalone node never produces cluster metrics, so it can never raise a cluster alert.
What is collected
Guests on this node. Every VM and container is a guest in the inventory with its name, type and state. Running guests report CPU, memory (bytes and percentage), disk usage where the guest reports it, and uptime. Guests that live on other cluster members are left to the agents on those nodes.
Storage. Usage per storage as this node sees it, plus how many storages are active out of the total.
Cluster view. Whether this node sees quorum, members total and online, each member's liveness, and whether the cluster membership daemon is active. On clusters with HA, the HA master and the number of HA resources in error or fenced state.
Tasks as events. Finished migrations and backups become events on the host, with the task type, guest, duration, user, and for migrations the target node. Any other task that ends in a failure becomes an event too, and so does the next clean run of the same task type for the same guest, which is what closes the incident described below. Tasks that finished before the agent started are not replayed.
Facts shown on the host page: the Proxmox VE version.
| Signal | Metric |
|---|---|
| VMs and containers, total and running | svc.proxmox.vms, svc.proxmox.vms_running, svc.proxmox.cts, svc.proxmox.cts_running |
| Per-guest state and usage | svc.proxmox.guest.running, .guest.cpu_pct, .guest.mem_pct, .guest.mem_bytes, .guest.disk_pct, .guest.uptime tagged by vmid, name, type |
| Storage usage | svc.proxmox.storage.used_pct tagged by storage; svc.proxmox.storages_active, svc.proxmox.storages_total |
| Cluster quorum and members | svc.proxmox.cluster.quorate, .cluster.nodes, .cluster.nodes_online, .cluster.node.online tagged by node |
| Membership daemon | svc.proxmox.cluster.corosync_active |
| HA resources in error | svc.proxmox.ha.errors |
Names, tags and units are in the metrics reference.
Logs. The logs-proxmox definition ships the journal of pvedaemon, pveproxy,
pvestatd, pmxcfs, pve-firewall and qmeventd at notice level and above by default.
See Logs.
Alerts out of the box
| Rule | Fires when | Severity | Ships |
|---|---|---|---|
| Proxmox node lost quorum | this node reports no quorum for 2 minutes | warning | on |
| Proxmox HA resource in error | at least one HA resource in error or fenced for 5 minutes | warning | on |
| Proxmox storage is filling up | a storage is 90% or more used for 15 minutes | warning | on |
| Proxmox task failed | a task ends with a status other than OK | warning | on |
| Corosync is not running | the membership daemon is inactive on a cluster member for 2 minutes | warning | on |
| Proxmox guest is not running | a guest is not running for 5 minutes | warning | off |
The task rule is event-born: it has no threshold, opens one incident per task type and guest, and closes when the same task type completes cleanly for that guest. A quorum loss is judged from this node's own view, so during a network split each side reports honestly. Storage closes only under 85% and waits 15 minutes, which lets a backup finish and clean up before anyone is paged. The guest rule ships off because a stopped guest is routine on a hypervisor (templates, standbys, machines shut down on purpose); enable it per workspace where every guest must stay up. The corosync rule reads the cluster-plane metric, so a standalone node with an inactive corosync never fires it. Thresholds and hysteresis are in the rules catalog.
Limitations
- Guest metrics cover the guests on this node. A full cluster picture needs an agent on every node, and each node reports the cluster as it sees it.
- Disk usage is reported only for guests where Proxmox itself provides it.
- HA metrics exist only when HA resources are defined; the membership metric exists only on cluster members.
- Task events start with the first probe cycle; history before that is not imported.
- Services running inside LXC guests are not matched as services of the node; their processes are filtered out of host discovery on purpose.
- Ceph and ZFS pool health are not read; storage is judged by usage percentage only.
Related
- Monitoring DRBD and LINSTOR for replicated guest storage
- Monitoring corosync for the membership daemon on its own
- Monitoring KVM and libvirt for hosts outside Proxmox
- Proxmox monitoring on the main site