If you've made the switch from VMware to Proxmox VE - or you're seriously considering it - you already know that monitoring can't be an afterthought. The Broadcom acquisition changed the economics of VMware practically overnight, and for many organizations, Proxmox VE became the obvious answer: open source, proven in production, no licensing surprises. But switching hypervisors is one thing. Making sure your new environment is properly monitored is another.
The good news? PRTG now covers all of it - four dedicated sensors for proxmox monitoring, one for each layer of your environment. Virtual machines, LXC containers, individual proxmox nodes, and the proxmox cluster as a whole. It's not a perfect fit for every situation, but for most environments it covers exactly what you actually need to know. Here's what each sensor does in practice.
Think of your Proxmox VE environment as a stack. At the top, you have your workloads - the virtual machines and LXC containers running your applications. Below that, the Proxmox host and individual nodes doing the heavy lifting. And at the bottom, the cluster mechanics keeping everything coordinated in a high-availability setup.
Most monitoring tools - whether that's Zabbix, Checkmk, Prometheus with Grafana, or a self-hosted InfluxDB stack - require significant config effort to cover all these layers properly. Some teams piece together solutions from GitHub scripts and community templates. It works, but it's another system to maintain. PRTG takes a different approach: four purpose-built sensors, all accessible from the same dashboard you already use for the rest of your infrastructure.
Start your free 30-day PRTG trial today - no credit card required.
Your KVM-based virtual machines are usually where the critical workloads live. The Proxmox VE Virtual Machine Status sensor gives you real-time visibility into exactly what's happening inside each VM - CPU usage, RAM, memory consumption, I/O performance, and overall VM status. The sensor is deliberately kept to a maximum of 10 channels so your dashboard stays readable and actionable.
In practice, this means: when someone reports that the ERP system feels sluggish, you don't need to open an SSH session or dig through the Proxmox web UI. The answer is right there in PRTG. CPU maxed out? Memory pressure? Disk I/O bottleneck? You see it immediately, and your existing alert workflows take care of the rest.
LXC containers are a different beast compared to full VMs. They share the host kernel, spin up faster, and let you run more workloads on the same hardware - which is one reason they're popular in everything from home lab setups to production datacenters. But lighter doesn't mean invisible.
The Proxmox VE Container Status sensor covers the same core metrics - CPU, RAM, memory, I/O, and container status - but tuned for the LXC environment. And honestly, that distinction matters more than it sounds. Five containers behave differently than fifty spread across multiple proxmox nodes, and having each one show up individually in PRTG means you're not staring at aggregate numbers trying to figure out which one is actually causing trouble.
Here's where things get interesting. Your cluster might look healthy overall, but one node quietly running at 95% CPU while the others sit at 30% - that imbalance will cause problems eventually. The Proxmox VE Node Performance sensor zooms in on individual Proxmox nodes and exposes exactly that kind of data.
The metrics it tracks include load average (primary channel), CPU usage, memory usage and available memory, disk space and disk usage, and uptime. That uptime channel alone is worth having - it tells you immediately if a node has been unexpectedly restarted, which is often the first sign that something is wrong at the hardware or OS level.
One thing that caught a few people off guard during testing: the available disk space number looks slightly lower than what you'd expect from the OS level on Debian or Ubuntu. That's not a bug - it's just how the PVE API reports it. The value reflects space available to non-root users and excludes system-reserved blocks. Worth keeping in mind before you start setting alert thresholds and wonder why the numbers don't quite match.
Oh, and if you're managing more than just a handful of nodes - the sensor works with PRTG's meta-scan feature for auto-discovery. PRTG finds your Proxmox nodes automatically and pre-fills the sensor config for you. It's one of those small things that saves a surprising amount of time when you're rolling this out across a larger environment.
If you're running Proxmox VE in a high-availability setup, this is arguably the most important sensor of the four. The Proxmox VE Cluster Health sensor monitors the overall state of your proxmox-ve-cluster - not just "is it up", but whether the cluster is actually in a functional, decision-capable state.
The key channel here is quorum. Losing quorum means your cluster can no longer collectively decide where to restart a VM after a node failure. It's the kind of failure that can quietly take down services without an obvious error message in the web UI. Having an alert fire the moment quorum is lost is genuinely valuable - not just for uptime, but for understanding the blast radius of a node failure.
Beyond quorum, the sensor tracks active nodes, online nodes as a percentage (with sensible default thresholds: warning at 95%, error at 20%), total nodes, and - if you're using it - Ceph status. The Ceph channel only appears when Ceph is configured on your cluster. No unnecessary clutter in your dashboard if it's not relevant to your setup.
Here's the real argument for handling proxmox monitoring inside PRTG rather than building a separate stack: consolidation. Your network devices, servers, applications, and now your entire Proxmox virtual environment all visible in one place. Same dashboards, same alert workflows, same reporting.
When something goes wrong at an inconvenient hour - and it will - you're not jumping between Grafana graphs, a Zabbix interface, and terminal windows trying to piece together what happened. You have one place to start, with visibility from the cluster level down to individual resource usage on every VM and container.
Honestly, the setup is less work than you might expect. Add your Proxmox host as a device in PRTG, hand it an API token with the right permissions, and you're basically done. The sensors start pulling in metrics through the Proxmox API on their own - no agents to install anywhere, no config files to wrestle with. All four sensors run on the multi-platform probe and support IPv6, so you're covered regardless of how your network is set up.
Please note: All four Proxmox sensors are currently in beta. To use them, enable the Beta Sensors experimental feature in PRTG. For details, see the Knowledge Base: 👉 What are beta sensors and how can I use them?
Tried them already? Head over to Paessler UserVoice and share your feedback - that's exactly how these sensors came to exist in the first place.
Download the free trial - 30 days, full functionality, no credit card needed.
KVM-based virtual machines run a full OS with their own kernel, ideal for workloads that need complete isolation or run non-Linux operating systems. LXC containers share the Linux host kernel and are far more resource-efficient - you can run significantly more of them on the same Proxmox host compared to full VMs. PRTG monitors both: the VM Status sensor covers your KVM workloads, and the Container Status sensor handles your LXC environments. Both track the same core metrics - CPU, RAM, I/O, and uptime - with each sensor optimized for its respective workload type.
Setup is agentless and straightforward. You create an API token on the Proxmox side with the appropriate permissions, add your Proxmox host as a device in PRTG, and the sensors start pulling in metrics via the Proxmox API automatically - no agents, no complex config files, nothing to install on your VMs or containers. For node discovery specifically, the Proxmox VE Node Performance sensor supports PRTG's meta-scan feature, which automatically detects Proxmox nodes across your datacenter and pre-fills the sensor configuration. Especially useful if you're managing a larger Proxmox VE Cluster with many nodes.
Look, tools like Prometheus, InfluxDB, or Grafana are genuinely good - nobody's arguing otherwise. But getting them to work properly with Proxmox means finding exporters, building your graphs and visualization from scratch, and then maintaining that whole stack on top of everything else you're already managing. Zabbix and Checkmk are similar: capable, but they come with a real config overhead. If you've ever spent an afternoon debugging a Grafana datasource connection or tweaking a Zabbix template, you know exactly what that looks like. PRTG gives you purpose-built sensors with sensible defaults, integrated alerting, and no additional infrastructure. As for scope: the current four sensors focus on the Proxmox Virtual Environment itself. For topics like ZFS storage monitoring or Proxmox Backup Server, it's worth checking the Paessler Sensor Hub for community-contributed scripts and templates - including contributions shared via GitHub - and keeping an eye on upcoming sensor releases via Paessler User Voice.