OpenStack vs. Proxmox

OpenStack und Proxmox VE werden ständig verglichen und sind fast nie tatsächlich Alternativen. OpenStack ist eine mandantenfähige IaaS-Control-Plane für Organisationen, die Self-Service-Cloud-Semantik im grossen Massstab brauchen. Proxmox ist ein Hypervisor-Cluster für Teams, die VMs und Container gut betreiben wollen, ohne Cloud-API. Die Bestände, die beides betreiben — und davon gibt es viele —, haben sich nicht für eines gegen das andere entschieden; sie haben eine Private Cloud im Telco-Massstab und eine Abteilungs-Virtualisierungsplattform, und ein Ops-Team, das auf beides schaut.

Das ist also kein „Welches sollten Sie wählen”-Beitrag. Er handelt davon, was ihre Observability gemeinsam hat (weniger, als man hofft), wo sie sich unterscheidet (mehr, als man vermutet) und was es braucht, eine Erfassungsschicht über beide zu betreiben. Jede Plattform hat ihren eigenen Tiefgang — OpenStack-Monitoring vs. Observability und Proxmox-Monitoring; dies ist die Gegenüberstellung.

Der Vergleich

	OpenStack	Proxmox VE
Was Sie beobachten	Eine verteilte Control Plane — sechs und mehr Dienste, RabbitMQ, Galera — und das Compute, das sie einplant	Einen Cluster aus Hypervisor-Nodes und die Guests darauf
Charakteristischer Ausfall	Jeder Dienst grün, ein Request langsam — eine verteilte Transaktion, die über Dienste hinweg kriecht	Quorum-Verlust, Storage-Latenz, ein Backup, das still aufgehört hat
Metrikquelle	openstack-exporter (Community) gegen die APIs; RabbitMQ- und Galera-Exporter; Node-Metriken	PVE-API über prometheus-pve-exporter (Community) oder der eingebaute Metric Server, der InfluxDB-Line-Protocol pusht; Node-Metriken
Nativer Prometheus-Endpunkt	Nein (Exporter)	Nein (Exporter oder Line-Protocol-Push)
Logs	oslo.log pro Dienst, mit einer Request-ID, die durch jeden Hop gestempelt wird	journald plus Task-Logs unter /var/log/pve/tasks/
Request-Korrelation	Eingebaut: X-Openstack-Request-Id verhält sich für die Rekonstruktion wie eine Trace-ID	Nicht nötig — Operationen sind node-lokal; Task-Logs tragen die Ergebnisse
Tracing	OSProfiler existiert; selektiv, eigenes Subsystem, kein OTLP	Nicht anwendbar
Storage	Ceph (mgr-Prometheus-Modul) oder Anbieter-Backends	Ceph oder ZFS; ZFS-ARC und Replikationsverzögerung zählen
Mandantenfähigkeit	Fundamental — Projekte sind Tenants; die Identität muss auf der Telemetrie mitreisen	Optional — Pools und Berechtigungen existieren, aber die meisten Cluster sind einmandantig
Sicht in den Guest	Agent im Guest; die Plattform sieht nur die Ressourcenform der VM	Ebenso — Host-Metriken schlüsseln jenseits der API-Sicht nicht nach Guest auf

Zwei Dinge fallen auf. Erstens ist das schwierige Problem verschieden: Auf OpenStack ist es, einem Request über Dienste hinweg zu folgen; auf Proxmox ist es, die langsamen, stillen Verschlechterungen zu fangen — ARC-Druck, IO-Wait, ein Backup, das aufgehört hat. Zweitens: Keine der beiden Plattformen gibt Ihnen einen Prometheus-Endpunkt, und beide stützen sich auf Community-Exporter — beide haben also im Monitoring-Pfad eine Abhängigkeit, die nicht vom Plattformanbieter stammt.

Wo sie gleich sind

• Die Erfassung auf Node-Ebene ist identisch. Beide sind Linux-Hosts; hostmetrics und journald auf einem OpenTelemetry Collector decken CPU, Arbeitsspeicher, Disk, Netzwerk und Systemlogs auf einem Nova-Compute-Node genauso ab wie auf einem Proxmox-Node.
• Ceph ist Ceph. Sitzen beide Plattformen auf Ceph, ist das mgr-Prometheus-Modul eine Quelle, die einen Satz Storage-Dashboards speist.
• Beide brauchen einen Collector im Guest für alles innerhalb der VM. Die Plattformsicht endet bei beiden an der VM-Grenze.
• Beide werden wegen der Kontrolle gewählt, und beide werden von einer Monitoring-Schicht untergraben, die standardmässig alles an ein ausländisches SaaS schickt — der Punkt aus digitaler Souveränität für Observability-Daten.

Eine Collector-Flotte über beide

Das praktische Ziel ist ein Erfassungsmodell, nicht ein Dashboard. Konkret:

• Eine Agent-Config pro Rolle, nicht pro Plattform. Eine Rolle „linux-node” (hostmetrics, journald) ist geteilt. Darauf ergänzt eine Rolle „openstack-controller” die Dienst-Exporter und das oslo-Log-Parsing mit Request-ID-Extraktion; eine Rolle „proxmox-node” ergänzt die PVE-Quelle und das Task-Log-filelog. Rollen setzen sich zusammen; sie verzweigen nicht.
• Mandantenidentität gestempelt, wo sie existiert. OpenStack-Telemetrie trägt project.id vom ersten Hop an als Resource-Attribut; Proxmox-Telemetrie braucht das meist nicht. Die Routing-Schicht handhabt den Unterschied — Multi-Tenant-Architektur für die OpenStack-Hälfte, nichts Besonderes für die Proxmox-Hälfte.
• Geteiltes Gateway, geteilte Ziele. Beide Flotten exportieren an dieselbe Gateway-Ebene und dieselben Backends. Die Ceph-Dashboards, die Node-Dashboards und das Alerting auf „Collector ist verstummt” werden einmal geschrieben.
• Von einer Stelle verwaltet. Collectors im Umfang zweier Plattformen sind genau die Flottengrösse, bei der handgepflegtes YAML driftet. Eine Control Plane, ein Inventar, eine Antwort auf „welche Version läuft auf diesem Node” — Flottenmanagement.

Ehrliche Unterschiede, die Unterschiede bleiben

• Die OpenStack-Control-Plane braucht die Arbeit an korrelierten Logs, Proxmox nicht. Request-IDs in Attribute zu parsen ist der wertvollste einzelne Schritt auf OpenStack und hat kein Proxmox-Gegenstück. Versuchen Sie nicht, die beiden Rollen symmetrisch zu machen.
• Die Alerting-Prioritäten sind gegensätzlich. Auf OpenStack zuerst auf Control-Plane-Latenz und Queue-Tiefe alarmieren. Auf Proxmox zuerst auf das Ausbleiben von Backup-Jobs und auf Storage-Latenz. Geteilte Infrastruktur, verschiedene Runbooks.
• Das Exporter-Risiko ist geteilt, aber nicht identisch. Beide Community-Exporter sind Abhängigkeiten, die Ihnen gehören. Pinnen Sie sie und behandeln Sie ihre Upgrades als Teil der Release-Disziplin der Flotte, nicht als Nachgedanken.

Die Zusammenfassung

Vergleicht man die Plattformen, bekommt man eine Architekturdebatte, die selten eine Entscheidung verändert. Vergleicht man ihre Telemetrie, bekommt man etwas Nützliches: identisch am Node, auseinanderlaufend auf der Plattformebene und — mit Rollen, die sich zusammensetzen statt zu verzweigen — vollständig als eine Flotte beherrschbar. Das ist der Entwurf, für den es sich zu argumentieren lohnt.