How to Monitor Proxmox VE with InfluxDB and Grafana (External Metric Server Setup)

Introduction

Proxmox VE's own web interface gives you graphs for every node, VM, and container — CPU, memory, disk, network, all right there under the Summary tab. For a single box, that's plenty. The moment you're running more than a couple of nodes, though, those graphs stop being enough. You can't see all your hosts on one screen, the retention is limited by RRD's fixed resolution buckets, and there's no way to get an alert texted to you when a node's memory creeps past 90% at 2 AM.

That's what an external metric server is for. Proxmox VE can push its internal statistics — the same numbers behind those built-in graphs — out to InfluxDB every ten seconds, where Grafana can turn them into dashboards that cover your whole fleet, keep history for as long as you want, and alert on whatever thresholds you care about.

This guide walks through the whole chain: standing up InfluxDB 2.x, pointing Proxmox VE at it, wiring up Grafana, and building a first dashboard you'll actually use. We're using Proxmox VE 9.x for the menus and commands below; the metric server feature has been stable since well before 8.x, so the concepts carry over cleanly to older releases too.

What You Will Learn

What Proxmox VE's external metric server actually sends, and how often
How to run InfluxDB 2.x and create an organization, bucket, and API token
How to register InfluxDB as a metric server in Proxmox VE, from the GUI and via pvesh
How to confirm data is actually arriving before you waste time debugging Grafana
How to connect Grafana to InfluxDB and build a real cluster-wide dashboard
How to keep the metrics stack from silently filling your disk
The errors you're most likely to hit, and how to fix them

What Is This Feature?

Under Datacenter → Metric Server, Proxmox VE lets you register one or more external targets that its pvestatd daemon will push time-series data to at a fixed interval — every 10 seconds by default. This isn't a new bolt-on; it's the same data source feeding the RRD graphs you already see in the GUI, just exported somewhere with no built-in retention limit.

Three target types are supported: Graphite (the original, UDP or TCP), InfluxDB (either the legacy UDP line-protocol format or the modern HTTP/HTTPS API used by InfluxDB 2.x), and, on more recent Proxmox VE releases, an OpenTelemetry export option for shops already standardized on an OTel collector. This guide focuses on InfluxDB 2.x over HTTP, since it's the most common pairing with Grafana and doesn't require opening a UDP port between your nodes and your monitoring host.

What actually gets sent: per-node CPU, memory, swap, network, and root-disk usage; per-guest (VM and LXC) CPU, memory, disk I/O, and network throughput; and per-storage usage and I/O. All of it tagged with node name, guest ID, and guest name, so you can slice dashboards by any of those in Grafana.

Why Would You Use It?

A few concrete reasons this is worth the half hour of setup:

Real history. Proxmox VE's built-in RRD graphs downsample aggressively — fine-grained data only sticks around for a day or two before it's averaged down. InfluxDB keeps whatever resolution and retention you configure.
One dashboard, every node. If you're running a cluster, or even just a few standalone hosts, Grafana can show all of them on a single screen instead of clicking through nodes one at a time.
Alerting. Grafana (or InfluxDB's own alerting) can page you when a disk crosses a threshold, a VM's memory spikes, or a node's load average goes sideways — none of which the Proxmox GUI does on its own.
Correlation. Once your Proxmox metrics live next to your app or network metrics in the same Grafana instance, you can actually line up "why did the app get slow" with "what was the host doing at that exact minute."

If you're running one lone homelab box and already glance at the Summary tab often enough, none of this is mandatory — the built-in graphs cover that case fine. It starts paying for itself once you have multiple nodes, guests you'd notice going down, or you just like knowing about a problem before a service does.

Prerequisites

A working Proxmox VE install, 8.x or 9.x, standalone or clustered — root or an account with Sys.Modify on / to configure the metric server
A place to run InfluxDB and Grafana — a small dedicated VM or LXC container works well; avoid running the monitoring stack on the same Proxmox host you're trying to monitor, since you lose visibility exactly when that host has a problem
Network connectivity from every Proxmox node to the InfluxDB host on TCP port 8086
Basic comfort with Docker, or willingness to install InfluxDB and Grafana as native packages instead — this guide uses Docker for simplicity
A rough idea of how much history you want to keep; InfluxDB will happily grow forever if you don't set a retention period

Step-by-Step Tutorial

Step 1: Run InfluxDB 2.x

On your monitoring VM or container, the fastest path is Docker:

docker run -d --name influxdb \
  -p 8086:8086 \
  -v influxdb-data:/var/lib/influxdb2 \
  influxdb:2

Open http://<monitoring-host>:8086 in a browser and walk through the first-run setup: pick a username and password, an initial Organization name (for example homelab), and an initial Bucket name (for example proxmox). Write both down — you'll type them again in the Proxmox VE config.

Step 2: Create an API token for Proxmox VE to write with

Inside the InfluxDB UI, go to Load Data → API Tokens → Generate API Token → Custom API Token. Give it write-only access to the proxmox bucket rather than an all-access token — Proxmox VE never needs to read anything back, and a write-scoped token limits the blast radius if it ever leaks. Copy the generated token immediately; InfluxDB only shows it once.

Step 3: Register InfluxDB as a metric server in Proxmox VE

In the Proxmox web UI, go to Datacenter → Metric Server → Add → InfluxDB and fill in:

ID — any short name, e.g. homelab-influx
Server — the IP or hostname of your InfluxDB host
Port — 8086
Protocol — HTTP (or HTTPS if you've put TLS in front of InfluxDB)
Organization — the org name from Step 1 (e.g. homelab)
Bucket — the bucket name from Step 1 (e.g. proxmox)
Token — the API token from Step 2

Leave Enable checked and click Add. If you're on a cluster, this config is stored cluster-wide in /etc/pve/status.cfg, so every node starts reporting immediately — you only add it once.

To do the exact same thing from the command line instead of the GUI:

pvesh create /cluster/metrics/server/homelab-influx \
  --type influxdb \
  --server 10.0.0.20 \
  --port 8086 \
  --influxdbproto http \
  --organization homelab \
  --bucket proxmox \
  --token "<YOUR_API_TOKEN>" \
  --enable 1

Step 4: Confirm data is actually flowing

Don't skip this and jump straight to Grafana — if nothing's arriving, you want to know that before you start debugging dashboards for the wrong reason. In the InfluxDB UI, go to Data Explorer, pick your proxmox bucket, and look for a measurement named pve. If you see recent points, the pipeline works.

If nothing shows up after a couple of minutes, tail the stats daemon on a Proxmox node:

journalctl -u pvestatd -f

Any HTTP or connection errors related to your metric server ID will show up here as they happen, roughly every 10 seconds.

Step 5: Install Grafana and connect it to InfluxDB

Same pattern as before — Docker is the quickest way to get Grafana running:

docker run -d --name grafana \
  -p 3000:3000 \
  -v grafana-data:/var/lib/grafana \
  grafana/grafana:latest

Log into http://<monitoring-host>:3000 (default credentials are admin / admin, and it'll immediately ask you to change the password). Go to Connections → Data sources → Add data source → InfluxDB, and set it up as follows:

Query Language — Flux (this matters — InfluxDB 2.x's native query language is Flux, not the older InfluxQL, and using the wrong one is the single most common reason people get "no data" in Grafana)
URL — http://<influxdb-host>:8086
Organization — same org as before
Token — you can reuse the same token, or generate a separate read-only one scoped to the bucket specifically for Grafana
Default Bucket — proxmox

Click Save & Test. A green confirmation means Grafana can query InfluxDB successfully.

Step 6: Build a first dashboard

Create a new dashboard, add a panel, and use a Flux query like this to graph CPU usage per node over the last 6 hours:

from(bucket: "proxmox")
  |> range(start: -6h)
  |> filter(fn: (r) => r._measurement == "pve")
  |> filter(fn: (r) => r._field == "cpu")
  |> filter(fn: (r) => r.object == "node")

Duplicate the panel and swap the field filter to mem, netin, netout, or disk to build out CPU, memory, network, and disk panels. Set the panel's legend to use the id or host tag so each node gets its own labeled line instead of one blurred-together series.

If you'd rather not build every panel by hand, search grafana.com's dashboard library for community-built Proxmox VE + InfluxDB2 dashboards and import one by ID as a starting point, then adjust the queries to match your bucket and tag names.

Step 7: Set a retention policy before you forget

By default, an InfluxDB 2.x bucket keeps data forever. At one data point roughly every 10 seconds per node, per guest, and per storage, that adds up faster than people expect. In the InfluxDB UI, go to Load Data → Buckets, edit your proxmox bucket, and set a retention period — 90 days is a reasonable default for a homelab; drop it lower if disk space is tight.

Commands Explained

Command	What it does
`pvesh create /cluster/metrics/server/<id>`	Registers a new external metric server with the given ID, using the flags that follow to set its type and connection details.
`pvesh set /cluster/metrics/server/<id>`	Updates an existing metric server's configuration, e.g. rotating its token without deleting and recreating it.
`pvesh get /cluster/metrics/server`	Lists every metric server currently configured cluster-wide, useful for confirming what's actually enabled.
`pvesh delete /cluster/metrics/server/<id>`	Removes a metric server definition; Proxmox VE stops pushing to it immediately.
`journalctl -u pvestatd -f`	Follows the stats daemon's log in real time — the first place to look when metrics stop arriving.

Common Errors

No data in InfluxDB at all — almost always a network path problem. Confirm TCP port 8086 is reachable from every Proxmox node with a quick curl -v http://<influxdb-host>:8086/health run directly on a node.
"unauthorized" or 401 errors in pvestatd logs — the token is wrong, expired, or doesn't have write access to the specific bucket you configured. Regenerate a token scoped correctly and update it with pvesh set.
"bucket not found" or 404 errors — the organization or bucket name in the Proxmox metric server config doesn't exactly match what exists in InfluxDB. Names are case-sensitive; double-check both sides.
Grafana panel shows "No Data" even though InfluxDB has data — nine times out of ten this is the query language mismatch: the data source is set to InfluxQL instead of Flux, or a Flux query references the wrong bucket name.
Self-signed HTTPS certificate errors when using https as the protocol — either import a proper certificate on the InfluxDB side, or switch the metric server's protocol back to plain http if it's staying on a trusted internal network.

Troubleshooting

Start at the source: pvestatd is what actually pushes metrics out, and it logs every push attempt. If journalctl -u pvestatd -f shows no errors and no mention of your metric server ID at all, double check that the server entry is actually enabled — it's easy to leave the Enable checkbox unticked when adding it through the GUI.

If pvestatd looks healthy but InfluxDB's Data Explorer still shows nothing, test the write path independently of Proxmox entirely. Run a manual write against the InfluxDB API from the Proxmox node using curl, with the same token, org, and bucket — if that fails too, the problem is InfluxDB-side (permissions, bucket name, or network), not Proxmox.

If data is in InfluxDB but Grafana panels are empty, open the panel's query inspector (the small bug icon in panel edit mode) and check the raw Flux query and response. It's the fastest way to see whether Grafana is even sending the query you think it's sending, versus silently failing to reach the data source.

Best Practices

Run InfluxDB and Grafana somewhere other than the Proxmox host they're monitoring — a dedicated LXC container is plenty for a homelab scale, and it means you can still see what happened right before that host itself had a problem.
Scope tokens narrowly: a write-only token for Proxmox VE, a separate read-only token for Grafana. Neither needs the other's permissions.
Set bucket retention deliberately instead of letting it default to forever — decide how much history you actually want before disk usage decides for you.
Use Grafana's alerting on the metrics that actually matter to you — disk usage crossing 85%, a guest's memory pinned near its limit — rather than trying to watch dashboards manually.
If you add more Proxmox clusters or standalone nodes later, point them at the same InfluxDB bucket with distinct node tags rather than standing up a separate stack per cluster; it keeps everything on one Grafana dashboard.

Frequently Asked Questions

Does this replace the built-in Proxmox VE graphs?

No, and it doesn't need to. The Summary tab graphs stay exactly as they are — this just adds a second, external copy of the same data with your own retention and dashboards on top.

Do I have to use InfluxDB, or can I use Prometheus instead?

Proxmox VE's built-in metric server only speaks Graphite, InfluxDB, and OpenTelemetry natively — there's no direct Prometheus exporter format. If you're committed to a Prometheus stack, InfluxDB with its Prometheus-compatible query endpoint, or a separate community exporter, are the usual workarounds.

Will this slow down my Proxmox nodes?

No — the push happens on a background thread every 10 seconds and sends a small payload. It's negligible next to normal VM and container workloads.

Can I send metrics from a cluster to more than one destination?

Yes. You can register multiple metric servers at once — for example, both InfluxDB and Graphite — and Proxmox VE will push to all enabled ones simultaneously.

What happens if the InfluxDB host is down?

Proxmox VE just fails to push and logs it; nothing about your VMs, containers, or cluster operation is affected. Metrics resume automatically once the target is reachable again — there's no backfill for the gap, though, so you'll see a hole in the graph for that period.

Conclusion

The metric server feature is one of those things that's already built into Proxmox VE and just sitting there unused on most installs. Wiring it up to InfluxDB and Grafana is a genuinely short afternoon project, and the payoff — real history, one dashboard for every node, and alerts that reach you instead of a graph you forgot to check — is disproportionate to the setup effort.

Start small: get one node reporting, confirm the data lands, then build out panels as you find yourself wanting them. The dashboard doesn't need to be complete on day one to already be more useful than clicking through Summary tabs one host at a time.

Vormox is an independent virtualization management platform built on Proxmox VE. Proxmox® and Proxmox VE® are trademarks of Proxmox Server Solutions GmbH. Vormox is not affiliated with, endorsed by, or sponsored by Proxmox.