Proxmox-Monitoring

Teams, die von VMware zu Proxmox VE kommen, tun das meist aus zwei Gründen: Die Lizenzkosten haben sich verändert, und sie wollten einen Hypervisor, den sie tatsächlich kontrollieren. (Was auf dem Weg dorthin aus jeder vCenter- und Aria-Fähigkeit wird, steht in Von VMware zu Proxmox: Was wird aus dem Monitoring?.) Dann stellen sie fest, dass auch das Monitoring kein Drop-in-Ersatz ist. Es gibt kein vCenter, kein vRealize und — das Detail, über das die meisten stolpern — keinen nativen Prometheus-Endpunkt.

Was Proxmox hat, reicht für ein sauberes Observability-Bild, sofern Sie wissen, welche vier Quellen zu kombinieren sind. Dieser Leitfaden behandelt diese Quellen, die Collector-Konfiguration, die sie vereinheitlicht, und die Signale, die eine schlechte Nacht auf einem Proxmox-Cluster tatsächlich vorhersagen.

Woher Proxmox-Metriken tatsächlich kommen

Es gibt keinen einzelnen Endpunkt. Ein vollständiges Bild braucht vier Quellen, jede mit einem anderen Mechanismus:

• Das Node-Betriebssystem. Proxmox VE ist Debian — CPU, Arbeitsspeicher, Disk, Dateisystem und Netzwerk des Hosts selbst kommen also aus dem hostmetrics-Receiver des OpenTelemetry Collectors. Kein zusätzlicher Exporter nötig; es ist dieselbe Erfassung, die Sie auf jedem Linux-Host betreiben würden.
• Die PVE-API — Cluster, Guests, Storage. Guest-Zustand, CPU und Arbeitsspeicher pro VM, Belegung der Storage-Pools, HA-Zustand und Node-Mitgliedschaft leben in der Proxmox-API. Die übliche Brücke ist der Community-Exporter prometheus-pve-exporter, gescrapt vom prometheus-Receiver des Collectors. Er ist keine offizielle Proxmox-Komponente; behandeln Sie ihn als Abhängigkeit, die Ihnen gehört.
• Der eingebaute Metric Server. Proxmox kann seine eigenen Metriken nativ ausliefern, spricht dabei aber InfluxDB- oder Graphite-Line-Protocol, nicht Prometheus. Das wird meist als Sackgasse gelesen. Ist es nicht: Der influxdb-Receiver des Collectors nimmt InfluxDB-Line-Protocol entgegen, Sie können Datacenter → Metric Server also direkt auf einen Collector richten und die eigenen Metriken von PVE ganz ohne Exporter im Pfad bekommen.
• Logs. journald auf jedem Node deckt System und Proxmox-Daemons ab. Die Task-Logs unter /var/log/pve/tasks/ sind der Ort, an dem Backup-, Migrations- und Replikationsergebnisse tatsächlich landen — eine filelog-Quelle.

Daraus folgen zwei tragfähige Entwürfe: Entweder scrapen Sie die PVE-API mit dem Exporter, oder Proxmox pusht Line Protocol in den Collector. Der Push-Pfad hat weniger bewegliche Teile; der Scrape-Pfad liefert mehr Detail pro Guest. Die meisten Cluster betreiben am Ende beides.

Ein Collector auf jedem Node, dazu ein kleines Gateway

Die Form, die funktioniert, ist die übliche zweistufige: ein Agent-Collector auf jedem Proxmox-Node für die lokale Erfassung, der an ein kleines Gateway weiterleitet, das Egress und Routing übernimmt.

receivers:
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
      load:
      disk:
      filesystem:
      network:
      paging:
  # Proxmox' eingebauter Metric Server, der Line Protocol zu uns pusht.
  influxdb:
    endpoint: 0.0.0.0:8086
  # Der Community-PVE-Exporter und Cephs eigenes mgr-Modul.
  prometheus:
    config:
      scrape_configs:
        - job_name: pve
          scrape_interval: 30s
          static_configs:
            - targets: ['127.0.0.1:9221']
        - job_name: ceph
          scrape_interval: 30s
          static_configs:
            - targets: ['127.0.0.1:9283']
  journald:
    units: [pvedaemon, pveproxy, pvestatd, corosync, ceph-mon, ceph-osd]

processors:
  resourcedetection:
    detectors: [system]
  batch:

exporters:
  otlp/gateway:
    endpoint: otel-gateway.internal:4317

Richten Sie Datacenter → Metric Server auf http://<node>:8086 mit ausgewähltem InfluxDB, aktivieren Sie bei hyperkonvergentem Storage das Prometheus-Modul des Ceph-Managers (ceph mgr module enable prometheus) — und der Node emittiert einen zusammenhängenden Stream statt vier unverbundener.

Die Signale, die Ärger tatsächlich vorhersagen

Proxmox-Cluster fallen auf wenige charakteristische Arten aus, und generisches Host-Monitoring verpasst die meisten davon:

• Quorum und Corosync-Link-Health. Ein Cluster, der das Quorum verliert, lässt keine Änderungen mehr zu, und HA hört auf zu funktionieren. Corosync-Link-Status und Ring-Fehler sind der Frühindikator; wenn ein Node im UI als offline erscheint, stecken Sie bereits im Vorfall.
• Storage-Latenz, nicht Storage-Kapazität. Ein voller Pool ist offensichtlich. Der Ausfall, der wirklich wehtut, ist steigendes IO-Wait auf einem ZFS-Pool oder eine Ceph-OSD nahe der Sättigung — spürbar als träge Guests, lange bevor irgendetwas alarmiert. Latenz und Auslastung schlagen einen Kapazitätsschwellwert; dasselbe Argument wie in Storage-Metriken, die zählen.
• ZFS-ARC-Druck. Proxmox-Nodes betreiben häufig ZFS mit einem ARC, der mit dem Guest-Arbeitsspeicher konkurriert. Ein unter Speicherdruck schrumpfender ARC ist eine langsame, stille Performance-Regression.
• CPU-Steal in den Guests. Die Host-CPU kann gut aussehen, während Guests hungern. Steal-Time wird im Guest gemessen — es braucht also einen Agenten im Guest; die Host-Sicht allein sieht das nicht.
• Ergebnisse der Backup-Jobs. Ein Backup, das still aufgehört hat zu laufen, ist der Ausfall, den niemand bemerkt — bis zur Wiederherstellung. Die Task-Ergebnisse des Proxmox Backup Servers sind das Signal; behandeln Sie einen fehlenden Erfolg als Alarm, nicht nur einen Fehlschlag.
• Replikationsverzögerung bei ZFS-Replikationsjobs, die still driftet, wenn ein Ziel volläuft.

Was das nicht leistet

Ehrlich zu den Lücken, weil sie den Entwurf verändern:

• Es gibt keinen offiziellen OpenTelemetry-Receiver für Proxmox. Der Exporter ist ein Community-Projekt. Er ist verbreitet und er funktioniert, aber er ist eine Abhängigkeit mit eigenem Release-Rhythmus und sitzt in Ihrem Monitoring-Pfad.
• Einblick in den Guest braucht einen Guest-Agenten. Host-seitige Metriken sagen Ihnen, was der Hypervisor sieht. Dateisystembelegung innerhalb einer VM, Anwendungslogs und CPU-Steal verlangen alle Erfassung im Guest — meist derselbe Collector, deployt als gewöhnlicher Host-Agent.
• Kardinalität pro Guest summiert sich schnell. Ein paar hundert Guests mit Serien pro VM über CPU, Arbeitsspeicher, Disk und Netzwerk sind eine grosse Menge an Metriken. Entscheiden Sie früh, auf welche Pro-Guest-Serien Sie tatsächlich alarmieren, und aggregieren Sie den Rest — sonst wird die Speicherrechnung zu dem Problem, das Sie mit der Migration vermeiden wollten.
• hostmetrics auf dem Hypervisor zählt den Hypervisor. Es schlüsselt die Nutzung nicht nach Guest auf; das kommt aus der PVE-API.

Auf der eigenen Infrastruktur bleiben

Wenn Proxmox auch wegen der Kontrolle gewählt wurde, lohnt es sich, das in der Monitoring-Schicht nicht wieder aufzugeben. Zwei Dinge sichern diese Position:

• Die Pipeline dort terminieren, wo Sie wollen. Die Collector-Flotte exportiert an das, was Sie betreiben — Prometheus/Mimir und Loki on-prem, oder ein Cloud-Backend für die Teile ohne sensible Daten. Das ist eine Routing-Entscheidung pro Datensatz, keine Plattformbindung.
• Die Flotte ohne Dritte im Datenpfad verwalten. Eine Control Plane muss Konfiguration und Health sehen, nicht Telemetrie — siehe wie Daten verarbeitet werden für das, was diese Trennung praktisch bedeutet.

Wo anfangen

1. Ein Node, nur hostmetrics. Bringen Sie Collector, Gateway und Backend zum Laufen, bevor Sie Proxmox-spezifische Quellen ergänzen.
2. Den eingebauten Metric Server ergänzen, gerichtet auf den influxdb-Receiver — die aufwandsärmste Quelle für genuin Proxmox-spezifische Daten.
3. Den PVE-Exporter ergänzen, falls Sie Detail pro Guest brauchen, das der Push-Pfad nicht trägt.
4. journald und die Task-Log-filelog-Quelle ergänzen, dann auf Backup-Erfolg alarmieren, bevor Sie auf irgendetwas anderes alarmieren.
5. Dieselbe Config von einer Stelle aus auf jeden Node ausrollen, damit Node sechs sich nicht subtil von Node eins unterscheidet — Flottenmanagement.

Betreiben Sie daneben OpenStack? Die Telemetrie der beiden Plattformen ist am Node identisch und darüber verschieden — OpenStack vs. Proxmox: Observability im Vergleich behandelt eine Collector-Flotte über beide.