Was die Proxmox-Oberfläche nicht zeigt

/01Was die Oberfläche zeigt — und was sie verschweigt

Die Weboberfläche von Proxmox VE zeigt für jeden Knoten und jeden Gast eine Kachel mit CPU-, RAM- und Speicherauslastung, dazu RRD-Grafiken für Tag, Woche, Monat und Jahr. Für den schnellen Blick reicht das: Ist der Knoten grün, läuft er. Für den Betrieb reicht es nicht, weil drei Dinge fehlen, die den eigentlichen Unterschied machen. Erstens eine Schwelle — die Oberfläche zeigt einen Wert, aber sie sagt nicht, ab wann er ein Problem ist. Zweitens eine Adresse — sie zeigt den Zustand demjenigen, der gerade hineinschaut, nicht demjenigen, der informiert werden müsste. Drittens eine Historie über den Cluster hinweg — ein einzelner Graph pro Knoten beantwortet nicht, ob ein Trend systemweit ist oder lokal.

Dieser Artikel behandelt ausschließlich die Proxmox-spezifische Instrumentierung: Kennzahlen, die es nur im Zusammenhang mit Ceph, Quorum, Cluster-Kommunikation und Proxmox-eigenen Diensten gibt. Wie ein allgemeiner Prometheus- und Grafana-Stack grundsätzlich aufgesetzt wird — Docker-Compose, Node-Exporter, erste Dashboards, PromQL-Grundlagen — steht bereits im Beitrag „Grafana & Prometheus: Monitoring-Stack aufbauen". Was dort fehlt und hier den Schwerpunkt bildet, ist die Ebene darunter: die Signale, die nur ein Proxmox-Cluster liefert und die eine generische Server-Überwachung nicht abgreift, weil sie sie nicht kennt.

Wichtig ist außerdem, was in diesem Beitrag nicht vorkommt: die Installation von Grafana selbst, der Aufbau von Dashboards oder PromQL als Sprache. Auch Logs bleiben außen vor — eine Sammlung etwa über Loki ist ein verwandtes, aber eigenes Thema und würde den Rahmen sprengen. Es geht um sechs Kennzahlen, drei Wege, sie abzugreifen, und die Entscheidung, welcher Alarm einen Menschen aus dem Schlaf holen darf.

/02Sechs Kennzahlen, die über der Grafik stehen

Diese sechs Werte entscheiden im laufenden Cluster-Betrieb — nicht, weil sie exotisch wären, sondern weil die Proxmox-Oberfläche sie entweder gar nicht zeigt oder ohne die Einordnung zeigt, die einen Alarm erst sinnvoll macht.

• Speicherfüllgrad mit Wiederherstellungsreserve. Nicht der reine Füllstand zählt, sondern der Füllstand abzüglich der Kapazität, die ein Cluster braucht, um den Ausfall eines ganzen Hosts aufzufangen.
• IO-Wartezeit. Die Zeit, die eine CPU auf Antwort vom Storage wartet — in der CPU-Grafik der Oberfläche unsichtbar, weil „Last" dort nicht zwischen Rechnen und Warten unterscheidet.
• Corosync-Laufzeit und Link-Status. Die Cluster-Kommunikation, über die Quorum überhaupt erst zustande kommt — sichtbar in der Oberfläche erst dann, wenn sie schon fehlt.
• Backup-Erfolg. Die Oberfläche zeigt den letzten Lauf je Job, nicht den Trend über alle Datastores und Wochen hinweg.
• Zertifikatslaufzeit. Das Zertifikat, über das GUI, API und Cluster-Beitritt laufen, läuft ab, ohne dass irgendwo eine Kachel rot wird, bevor es zu spät ist.
• Abonnementstatus. Steuert den Zugriff auf das Enterprise-Repository und den Support — ein abgelaufenes Abo fällt sonst erst auf, wenn ein Sicherheitsupdate fehlt.

Die folgenden Abschnitte gehen drei dieser sechs Kennzahlen vertieft durch — Speicherfüllgrad, Corosync/Quorum und die drei „leisen" Ausfälle Backup, Zertifikat, Abonnement. IO-Wartezeit lässt sich mit denselben Exportern erfassen, die auch im allgemeinen Monitoring-Stack zum Einsatz kommen; die Proxmox-spezifische Pointe liegt in den anderen fünf.

/03PDM, Ausleitung, Exporter — drei Wege, keine Konkurrenz

Für Proxmox-Metriken gibt es nicht einen Weg, sondern vier Ebenen, die unterschiedliche Aufgaben lösen und sich im Betrieb ergänzen statt gegenseitig zu ersetzen.

Der Proxmox Datacenter Manager ist laut eigener Dokumentation als „centralized management platform designed to oversee Proxmox Virtual Environment and Proxmox Backup Server instances across disjointed locations" gedacht — ausdrücklich als lose gekoppeltes System, bei dem der zentrale Verwalter nicht selbst zum Engpass werden soll. Er liefert ein aggregiertes Dashboard über Zustand, Gesundheit und Last aller angebundenen Cluster und Einzelknoten sowie zentrale Task-Protokolle. Was er nicht liefert: eine Alarmregel, die um drei Uhr nachts einen Menschen erreicht. Das ist keine Kritik am Werkzeug — es ist schlicht nicht sein Zweck.

Die eingebaute Metrik-Ausleitung von Proxmox VE spricht drei Formate: Graphite, InfluxDB und seit einer der jüngeren Versionen auch OpenTelemetry. Konfiguriert wird sie ausschließlich über die Oberfläche unter Rechenzentrum → Metric Server; die Werte landen in /etc/pve/status.cfg. Der Proxmox Backup Server bietet dasselbe Prinzip für seine eigenen Werte an, dort beschränkt auf InfluxDB per HTTP oder UDP, konfiguriert in /etc/proxmox-backup/metricserver.cfg. Beide Wege senden periodisch — push statt pull —, ohne dass ein zusätzlicher Dienst auf dem Host laufen muss. Wer schon eine InfluxDB oder Grafana-Instanz betreibt, kommt damit am schnellsten zu einer ersten Grafik.

Der dritte Weg, der prometheus-pve-exporter, kehrt das Prinzip um: Er wartet auf Abfragen, statt selbst zu senden, und fügt sich damit in eine bestehende Prometheus-Landschaft ein, statt eine eigene zu verlangen. Genau das macht ihn zur naheliegenden Wahl, wenn Alertmanager, Grafana und ein bestehendes Retention-Konzept ohnehin schon für andere Systeme laufen — dann kommt Proxmox als ein weiteres Target dazu, statt eine zweite Infrastruktur zu benötigen.

/04Den Prometheus-Exporter aufsetzen

Der prometheus-pve-exporter ist ein eigenständiges Projekt, nicht Teil der Proxmox-Distribution. Zwei Installationswege stehen zur Wahl: per pip direkt auf einem Rechner mit Netzzugriff auf die Proxmox-API, oder als Container. Für den produktiven Betrieb bei mehreren Clustern ist ein zentraler Exporter außerhalb der Proxmox-Hosts selbst die sauberere Lösung — er überlebt dann auch einen Neustart des Knotens, den er überwacht.

Vor der Installation braucht es einen Nur-Lese-Zugang. Ein eigener Proxmox-Benutzer mit der Rolle PVEAuditor und einem API-Token ist dafür der richtige Zuschnitt — dieser Zugang kann lesen, aber nichts verändern, was das Risiko eines kompromittierten Exporters von vornherein begrenzt.

# Nur-Lese-Benutzer und Token anlegen
pveum user add prometheus@pve
pveum aclmod / -user prometheus@pve -role PVEAuditor
pveum user token add prometheus@pve monitoring -privsep 0

# Exporter installieren
python3 -m pip install prometheus-pve-exporter
# alternativ als Container:
# docker pull prompve/prometheus-pve-exporter

# /etc/prometheus/pve.yml
default:
    user: prometheus@pve
    token_name: monitoring
    token_value: "<token-wert-aus-der-vorherigen-ausgabe>"
    verify_ssl: true

pve_exporter --config.file /etc/prometheus/pve.yml

# Testabfrage gegen einen konkreten Node
hostspezial@pve01:~$ curl -s localhost:9221/pve?target=pve01

Der Exporter läuft standardmäßig auf Port 9221 und liefert unter dem Pfad /pve Metriken für den per target-Parameter benannten Knoten — Cluster- und Node-Status, CPU-, Speicher- und Netzwerkwerte je VM und Container, deren Uptime, Storage-Größe und -Nutzung sowie den Abonnementstatus je Node. In der prometheus.yml wird der Exporter als eigenständiges Scrape-Target mit dem Zielparameter eingetragen, damit Prometheus für jeden Node im Cluster eine eigene Abfrage absetzt, statt sich auf eine einzelne Sammelantwort zu verlassen:

# prometheus.yml — ein Scrape-Job je Proxmox-Node
scrape_configs:
  - job_name: 'pve'
    static_configs:
      - targets:
          - pve01
          - pve02
          - pve03
    metrics_path: /pve
    params:
      module: [default]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: localhost:9221

Damit übernimmt Prometheus die Abfrage jedes Knotens einzeln, während der Exporter selbst zentral an einer Stelle läuft und sich nicht auf jedem Cluster-Mitglied wiederholen muss.

/05Speicherfüllgrad mit Wiederherstellungsreserve

Ein Ceph-Cluster kennt drei eingebaute Schwellen für die Belegung eines einzelnen OSD, dokumentiert in der Ceph-Konfigurationsreferenz: mon_osd_nearfull_ratio mit Standardwert 0,85 löst eine erste Warnung aus. mon_osd_backfillfull_ratio mit Standardwert 0,90 verhindert, dass Daten auf ein OSD zurückgeschrieben werden, das sich gerade füllt — Wiederherstellung nach einem Ausfall wird ab dieser Marke also blockiert. mon_osd_full_ratio mit Standardwert 0,95 stoppt Schreibzugriffe auf dem gesamten Cluster, sobald ein einzelnes OSD diese Marke erreicht.

Diese drei Werte sind Ceph-eigene Notbremsen, keine Empfehlung dafür, wann ein Mensch informiert werden sollte. Der Unterschied ist entscheidend: Wer erst bei 90 oder 95 Prozent alarmiert, alarmiert an dem Punkt, an dem Ceph selbst schon blockiert — die Zeit, in Ruhe zu reagieren, ist dann bereits verbraucht. Die Wiederherstellungsreserve ist der Puffer, der übrig bleiben muss, damit der Cluster den Ausfall des größten Fehlerbereichs — in der Regel eines ganzen Hosts — auffangen kann, ohne dass die verbleibenden OSDs in die Nähe der eigenen Schwellen rutschen. Bei einem Drei-Knoten-Cluster mit annähernd gleicher Datenverteilung bedeutet der Ausfall eines Hosts grob ein Drittel zusätzlicher Belegung auf den verbleibenden zwei — eine Reserve, die kleiner ist, wird im Ernstfall selbst zum Problem.

Für ZFS-Storage gilt ein anderer Mechanismus mit ähnlicher Konsequenz. ZFS ist ein Copy-on-Write-Dateisystem: Jede Änderung schreibt neue Blöcke, statt vorhandene zu überschreiben, und braucht dafür zusammenhängenden freien Platz. Je voller ein Pool wird, desto schwerer findet der Allocator diesen Platz, die Fragmentierung steigt — sichtbar in der FRAG-Spalte von zpool list — und Schreibvorgänge werden spürbar langsamer, lange bevor der Pool im eigentlichen Sinn „voll" ist. Eine feste Prozentzahl, ab der das spürbar wird, ist herstellerseitig nicht als harte Grenze dokumentiert; als Erfahrungswert hat sich eine Warnung ab rund 80 Prozent Belegung bewährt, weil Copy-on-Write ab diesem Punkt in aller Regel schon Headroom braucht, den es nicht mehr findet.

/06Corosync und Quorum im Blick behalten

Ein Proxmox-Cluster funktioniert nur, solange die Mehrheit seiner Knoten sich über Quorum einig ist, wer noch dazugehört. Diese Verständigung läuft über Corosync, und Corosync selbst lässt sich mit einem einzigen Befehl abfragen — corosync-cfgtool -s zeigt für jeden konfigurierten Link, ob er aktiv ist und mit welchen anderen Knoten er verbunden ist:

hostspezial@pve01:~$ corosync-cfgtool -s
LINK ID 0
        addr    = 192.168.100.81
        status:
                nodeid  1:      localhost
                nodeid  2:      connected
                nodeid  3:      connected

Das Entscheidende an dieser Ausgabe ist, dass sie einen Zustand zeigt, keinen Messwert — ein Link ist verbunden oder nicht. Genau deshalb passt hier keine graduelle Warnstufe: Ein Link, der nicht mehr connected meldet, gehört sofort in die höchste Alarmstufe, nicht in eine Grafik, die man am nächsten Morgen durchsieht. Bei einem Cluster mit mehreren Corosync-Links — sinnvoll, um genau diesen Einzelpunkt-Ausfall abzufangen — ist ein einzelner unterbrochener Link noch kein Notfall, aber ein klares Signal, dass die Redundanz gerade weg ist.

Für die Quorum-Frage selbst liefert pvecm status die unmittelbare Antwort — wie viele Stimmen aktuell vorhanden sind und ob der Cluster als „Quorate: Yes" geführt wird. Beides, Link-Status und Quorum-Status, lässt sich über einen einfachen Cronjob und den Textfile-Collector des Node-Exporters in Prometheus einspeisen: ein kleines Skript parst die Ausgabe der beiden Befehle und schreibt das Ergebnis als Metrikdatei, die der Node-Exporter periodisch einliest. Einen eigenen Prometheus-Exporter für Corosync gibt es nicht — dieser Weg über den Textfile-Collector ist der pragmatische Ersatz.

Die Alarmlogik dafür bleibt bewusst einfach: Fehlt das Quorum, ist der betroffene Teil des Clusters handlungsunfähig — HA-Dienste stoppen dort, bis die Mehrheit wiederhergestellt ist. Das ist ein Anruf, kein Ticket. Ein einzelner geflippter Link bei sonst intaktem Quorum ist dagegen eine Warnung, die bis zum nächsten Werktag warten kann, solange sie nicht anhält.

/07Backup, Zertifikat, Abonnement — die leisen Ausfälle

Drei Dinge fallen im Betrieb typischerweise nicht durch einen roten Balken auf, sondern dadurch, dass niemand hinschaut, bis es zu spät ist.

Backup-Erfolg

Der Proxmox Backup Server bringt ein eigenes Benachrichtigungssystem mit, das deutlich weiter geht als eine E-Mail pro Job: Ereignisse für Prune-, Garbage-Collection-, Verify-, Sync- und Tape-Jobs lassen sich einzeln nach Erfolg und Fehlschlag auslösen und über Sendmail, SMTP, Gotify oder Webhook zustellen. Über sogenannte Matcher filtert PBS diese Ereignisse nach Kalenderfenster, nach Feldern wie Datastore oder Job-ID und nach Schweregrad — eine Regel ohne Filter benachrichtigt schlicht immer. Der Webhook-Kanal ist der naheliegende Weg, PBS-Ereignisse in dieselbe Alarmkette einzuspeisen, die auch Prometheus-Alerts zustellt, statt zwei getrennte Benachrichtigungswege im Betrieb zu pflegen. Für den schnellen Blick auf der Kommandozeile liefert proxmox-backup-manager den aktuellen Status von Datastores und Jobs, ohne die Oberfläche zu öffnen.

Zertifikatslaufzeit

Das TLS-Zertifikat, über das Proxmox-Weboberfläche, API und Cluster-Kommunikation laufen, erneuert sich bei ACME-Konfiguration in der Regel automatisch — bis die Erneuerung aus einem Grund scheitert, den niemand vorhergesehen hat: ein abgelaufenes DNS-Token, ein erreichtes Rate-Limit, eine geänderte Domain. Ein einfacher Cronjob mit openssl x509 -noout -enddate gegen das aktive Zertifikat, wieder über den Textfile-Collector an Prometheus gemeldet, deckt genau diesen Fall ab. Als Erfahrungswert hat sich eine Warnung ab 30 Tagen Restlaufzeit und eine kritische Eskalation ab 14 Tagen bewährt — ausreichend Vorlauf, um eine gescheiterte automatische Erneuerung noch von Hand zu beheben, ohne dass die Oberfläche zwischenzeitlich unerreichbar wird.

Abonnementstatus

Der Prometheus-Exporter liefert den Abonnementstatus je Node mit aus. Das klingt nach einer Verwaltungsfrage, ist aber eine betriebliche: Ohne gültiges Abonnement fehlt der Zugriff auf das Enterprise-Repository, und sicherheitsrelevante Updates laufen dann über den No-Subscription-Kanal oder gar nicht mehr automatisiert ein. Ein wöchentlicher Check reicht hier aus — im Gegensatz zu Speicherfüllgrad oder Quorum ist das kein Wert, der sich innerhalb von Minuten ändert.

/08Wo es hakt

Vier Fallstricke, die den Aufbau erschweren, wenn sie erst im laufenden Betrieb auffallen statt vorher.

Kardinalität wächst mit jeder VM

Jede virtuelle Maschine, jeder Container und jeder Storage-Pool bringt eigene Zeitreihen mit eigenen Labels mit. Bei einem Cluster mit wenigen Dutzend Gästen ist das unproblematisch; bei mehreren Hundert VMs über mehrere Cluster summiert sich das spürbar und treibt Speicherbedarf und Abfragezeit von Prometheus nach oben. Wer viele Gäste betreibt, sollte das beim Scrape-Intervall und bei der Auswahl der erfassten Metriken von Anfang an einplanen, statt es nachträglich zu bemerken.

Lokale Historie ist keine Langzeit-Aufbewahrung

Prometheus speichert seine Zeitreihen standardmäßig lokal und für einen begrenzten Zeitraum. Für einen Kapazitätstrend über mehrere Quartale reicht das allein nicht — dafür braucht es ein Remote-Storage-Konzept oder eine bewusst konfigurierte, längere Retention, nicht die Werkseinstellung.

Der Exporter-Port ist kein geschützter Bereich

Der prometheus-pve-exporter selbst prüft auf seinem Metrik-Port keine Zugangsdaten — wer den Port erreicht, sieht die Metriken. Das Sicherheitsmodell verlagert sich damit auf das Netzwerk: Der Port gehört ins Monitoring-Segment, nicht ins offene Netz, unabhängig davon, dass der Zugriff auf die Proxmox-API selbst über ein Nur-Lese-Token abgesichert ist.

Zwei parallele Ausleitungen verdoppeln die Last

Eingebaute Ausleitung und Prometheus-Exporter lassen sich gleichzeitig betreiben — beide fragen dieselbe Proxmox-API ab, nur mit unterschiedlichem Intervall und Ziel. Bei einem knapp dimensionierten Cluster mit sehr kurzem Scrape-Intervall auf beiden Wegen summiert sich das zu spürbarer Zusatzlast auf pveproxy und pvestatd. In der Praxis reicht ein Weg fast immer aus; zwei parallele lohnen sich nur in der Übergangsphase, wenn ein Ziel-System abgelöst wird.

/09Wer weckt wen nachts — und wann sich der Aufbau lohnt

Eine Alarmkette, die nachts weckt, verkürzt im Ernstfall die MTTR — aber nur, wenn sie tatsächlich nur dann weckt, wenn es nötig ist, und wenn der Angerufene ein Runbook vorfindet, das den nächsten Schritt vorgibt, statt ihn zum Improvisieren um drei Uhr nachts zu zwingen. Nicht jede Kennzahl aus diesem Beitrag verdient dieselbe Reaktion. Eine einfache Zweiteilung hat sich bewährt:

Das darf nachts wecken

• Verlorenes Quorum — der betroffene Cluster-Teil ist handlungsunfähig, HA-Dienste stehen.
• Ceph erreicht die Backfillfull- oder Full-Schwelle — der Cluster blockiert bereits Wiederherstellung oder Schreibzugriffe.
• Ein Corosync-Link fällt bei bereits reduzierter Redundanz aus — die letzte verbleibende Verbindung wackelt.
• Backup einer Tier-1-VM schlägt wiederholt fehl — ein einzelner Fehlschlag mit erfolgreichem Retry ist kein Grund, mehrere hintereinander schon.

Das ist ein Ticket für den nächsten Morgen

• Ceph oder ZFS erreichen die eigene Warnschwelle, aber nicht die kritische — Zeit für Kapazitätsplanung, kein Notfall.
• Einzelner Knoten mit erhöhter IO-Wartezeit ohne Auswirkung auf andere Knoten.
• Zertifikat läuft in 30, aber nicht in 14 Tagen ab.
• Abonnement läuft in den nächsten Wochen aus.

Die zweite Entscheidung ist grundsätzlicher: Lohnt sich der ganze Aufbau — eigener Exporter, Prometheus, Alertmanager — überhaupt, oder reichen Proxmox Datacenter Manager und eingebaute Ausleitung? Für einen einzelnen kleinen Cluster ohne Ceph, mit wenigen VMs und einem überschaubaren Team, das ohnehin regelmäßig in die Oberfläche schaut, ist der zusätzliche Betriebsaufwand eines eigenen Prometheus-Stacks oft größer als der Gewinn — PDM-Dashboard, PBS-Benachrichtigungen und ein manueller Blick auf den Speicherfüllgrad decken den größten Teil des Risikos ab. Der Aufbau lohnt sich, sobald mindestens eine dieser Bedingungen zutrifft: mehrere Cluster oder Standorte, Ceph im Einsatz, Hochverfügbarkeit für geschäftskritische Systeme, oder ein bestehender Prometheus-Alertmanager, in den sich Proxmox einfach als weiteres Target einreiht. Dann trägt die Investition in eine Alarmregel mehr als jede zusätzliche Grafik. Wo genau die Grenze zwischen Anruf und Ticket verläuft, sollte sich am eigenen SLA gegenüber den eigenen Nutzern orientieren, nicht an Bauchgefühl.

/10Häufige Fragen