OpenStack vs. Proxmox

OpenStack and Proxmox VE get compared constantly and are almost never actually alternatives. OpenStack is a multi-tenant IaaS control plane for organisations that need self-service cloud semantics at scale. Proxmox is a hypervisor cluster for teams that want to run VMs and containers well without a cloud API. The estates that run both — and there are many — did not choose one over the other; they have a telco-scale private cloud and a departmental virtualisation platform, and one ops team looking at both.

So this is not a “which should you pick” post. It is about what their observability has in common (less than you would hope), where it differs (more than you would guess), and what it takes to run one collection layer across both. Each platform has its own deep dive — OpenStack monitoring vs observability and Proxmox monitoring; this is the side-by-side.

The comparison

	OpenStack	Proxmox VE
What you are observing	A distributed control plane — six-plus services, RabbitMQ, Galera — and the compute it schedules	A cluster of hypervisor nodes and the guests on them
Characteristic failure	Every service green, a request slow — a distributed transaction crawling across services	Quorum loss, storage latency, a backup that silently stopped
Metrics source	openstack-exporter (community) against the APIs; RabbitMQ and Galera exporters; node metrics	PVE API via prometheus-pve-exporter (community) or the built-in metric server pushing InfluxDB line protocol; node metrics
Native Prometheus endpoint	No (exporters)	No (exporter or line-protocol push)
Logs	oslo.log per service, with a request ID stamped through every hop	journald plus task logs under /var/log/pve/tasks/
Request correlation	Built in: X-Openstack-Request-Id behaves like a trace ID for reconstruction	None needed — operations are node-local; task logs carry outcomes
Tracing	OSProfiler exists; selective, own subsystem, not OTLP	Not applicable
Storage	Ceph (mgr Prometheus module) or vendor backends	Ceph or ZFS; ZFS ARC and replication lag matter
Tenancy	Fundamental — projects are tenants; identity must ride on telemetry	Optional — pools and permissions exist but most clusters are single-tenant
Guest visibility	Agent in the guest; the platform sees only the VM’s resource shape	Same — host metrics do not decompose by guest beyond the API view

Two things stand out. First, the hard problem is different: on OpenStack it is following a request across services; on Proxmox it is catching the slow, quiet degradations — ARC pressure, IO wait, a backup that stopped. Second, neither platform gives you a Prometheus endpoint, and both lean on community exporters — which means both have a dependency in the monitoring path that is not the platform vendor’s.

Where they are the same

• Node-level collection is identical. Both are Linux hosts; hostmetrics and journald on an OpenTelemetry Collector cover CPU, memory, disk, network and system logs the same way on a Nova compute node and a Proxmox node.
• Ceph is Ceph. If both platforms sit on Ceph, the mgr Prometheus module is one source feeding one set of storage dashboards.
• Both need a collector in the guest for anything inside the VM. The platform view stops at the VM boundary on either.
• Both are chosen for control, and both are undermined by a monitoring layer that ships everything to a foreign SaaS by default — the point of digital sovereignty for observability data.

One collector fleet across both

The practical goal is one collection model, not one dashboard. Concretely:

• One agent config per role, not per platform. A “linux-node” role (hostmetrics, journald) is shared. On top of it, an “openstack-controller” role adds the service exporters and oslo log parsing with request-ID extraction; a “proxmox-node” role adds the PVE source and the task-log filelog. Roles compose; they do not fork.
• Tenancy stamped where it exists. OpenStack telemetry carries project.id as a resource attribute from the first hop; Proxmox telemetry usually does not need it. The routing layer handles the difference — multi-tenant architecture for the OpenStack half, nothing special for the Proxmox half.
• Shared gateway, shared destinations. Both fleets export to the same gateway tier and the same backends. The Ceph dashboards, the node dashboards and the alerting on “collector went quiet” are written once.
• Managed from one place. Two platforms’ worth of collectors is exactly the fleet size at which hand-managed YAML drifts. One control plane, one inventory, one answer to “what version is on that node” — fleet management.

Honest differences that stay different

• The OpenStack control plane needs the correlated-logs work and Proxmox does not. Parsing request IDs into attributes is the single highest-value step on OpenStack and has no Proxmox equivalent. Do not try to make the two roles symmetrical.
• Alerting priorities are opposite. On OpenStack, alert on control-plane latency and queue depth first. On Proxmox, alert on backup-job absence and storage latency first. Shared infrastructure, different runbooks.
• Exporter risk is shared but not identical. Both community exporters are dependencies you own. Pin them, and treat their upgrades as part of the fleet’s release discipline rather than as an afterthought.

The summary

Compare the platforms and you get an architecture debate that rarely changes a decision. Compare their telemetry and you get something useful: identical at the node, divergent at the platform layer, and — with roles that compose rather than fork — entirely manageable as one fleet. That is the design worth arguing for.