Monitoring Proxmox mit Prometheus und Grafana: Exporter, Dashboards und Alerts

Monitoring Proxmox mit Prometheus und Grafana ist in vielen IT-Betrieben die bevorzugte Lösung, um Hosts, virtuelle Maschinen (VMs) und Clusterzustand messbar, historisch und alarmfähig zu machen. Dieses Dossier richtet sich an Administratoren, System Engineers und Operatoren und erklärt praxisnah, welche Exporter Sie brauchen, wie Sie Prometheus skalieren, Alerts operationalisieren und welche Prüf- und Rückfallstrategien sich in echten Betriebsumgebungen bewährt haben.

Monitoring Proxmox mit Prometheus und Grafana: Kurze Voraussetzungen und Begriffscheck

Bevor Sie starten: Prometheus ist eine zeitserienbasierte Metrik-Datenbank (TSDB) mit Pull-Mechanismus; Grafana ist das Visualisierungs-Frontend; Alertmanager steuert Benachrichtigung, Gruppierung und Stummschaltungen. Exporter sind kleine Dienste, die Metriken im Prometheus-Format bereitstellen – node_exporter liefert OS-Metriken, pve_exporter spricht die Proxmox-API an. Synchronisierte Uhren (NTP/Chrony), Firewall-Regeln und sichere Token sind Pflicht.

Architektur- und Skalierungsentscheidungen

Beginnen Sie mit einer klaren Trennung zwischen Hot-Store (kurze Retention, schnelle Queries) und Long-Term-Store (historische Daten). Für kleine Umgebungen reicht ein einzelner Prometheus; bei wachsenden Cardinality-Anforderungen und vielen VMs empfiehlt sich ein Edge-/Central-Pattern: lokale Prometheus-Instanzen scrapen Knoten, remote_write stellt Daten in eine zentrale, skalierbare TSDB wie VictoriaMetrics, Thanos oder Cortex.

Warum Edge-Prometheus?

Ein Edge-Prometheus reduziert Netzwerklast, limitiert API-Calls gegen Proxmox und hält Ausfälle lokalisiert. Federation oder remote_write aggregiert nur das, was zentral benötigt. Das minimiert die Gefahr, dass eine einzelne globale Abfrage Ihre gesamte Infrastruktur belastet.

Exporter im Detail: node_exporter und pve_exporter richtig betreiben

node_exporter: Betriebshinweise

node_exporter sollte als systemd-Service laufen, mit limitierten Collectors (nicht benötigte Module abschalten) und textfile-Collector für lokale Statuschecks (z. B. Backup-Ergebnisse). Dateiberechtigungen und Benutzerkontexte (dedizierter, nicht-privilegierter User) sind wichtig, weil node_exporter Metriken aus dem System liest.

# Systemd-Unit-Auszug für node_exporter
[Service]
User=nodeusr
Group=nodeusr
ExecStart=/usr/local/bin/node_exporter 
  --no-collector.wifi 
  --no-collector.mdadm 
  --collector.textfile.directory=/var/lib/node_exporter/textfile_collector

# Verzeichnisrechte
chown -R nodeusr:nodeusr /var/lib/node_exporter
chmod 750 /var/lib/node_exporter

pve_exporter: Auth, Cache und API-Rate-Limits

pve_exporter nutzt die Proxmox-REST-API und ist damit abhängig von API-Stabilität und Token-Berechtigungen. Setzen Sie eine Cache-Dauer (z. B. 30–60s) im Exporter, um unnötige API-Last zu vermeiden; proxmox-api endpoints können bei zu vielen Anfragen langsam reagieren oder temporär sperren.

# systemd-Umgebung mit sicherer Token-Datei
[Service]
User=pveexport
EnvironmentFile=/etc/pve_exporter/env
ExecStart=/usr/local/bin/pve_exporter --listen-address=127.0.0.1:9273 --cache-duration=60s

# /etc/pve_exporter/env (richtig setzen mit 600)
PROXMOX_API_TOKEN_ID=exporter@pve!id
PROXMOX_API_TOKEN_SECRET=longsecret

Wichtig: legen Sie Token mit minimalen Rechten an und speichern Sie Secrets in einem Vault, oder zumindest in Dateien mit restriktiven Berechtigungen (chmod 600). Testen Sie API-Zugriff getrennt, bevor Sie Prometheus verbinden.

Cardinality kontrollieren: Label-Strategie und Relabeling

Cardinality bezeichnet die Anzahl einzigartiger Zeitreihen; sie explodiert schnell, wenn Sie dynamische Metadaten als Labels übernehmen (z. B. freie VM-Notizen). Das erhöht Speicherbedarf, CPU und Query-Latenz. Maßnahmen:

• Definieren Sie eine erlaubte Label-Liste pro job.
• Droppen Sie volatile Labels bereits per relabel_configs.
• Erstellen Sie service- oder role-Labels via Regex-Normalisierung statt vollständiger VM-Namen.

relabel_configs:
  - source_labels: [vm_description]
    regex: '.*'
    action: drop
  - source_labels: [vm_name]
    regex: '^(web|db|cache)-.*'
    target_label: service
    replacement: '${1}'

Prometheus-Betrieb: Retention, Compaction und Ressourcen

Prometheus speichert Daten in Blocks. Empfohlene Konfigurationen sind eine Hot-Retention von 15–30 Tagen und remote_write für langfristigen Speicher. Beobachten Sie TSDB-I/O: Disk-Latenzen führen zu erhöhten Scrape-Dauern und zu Fehlern.

# Prometheus Startflags (Beispiel)
prometheus --storage.tsdb.path=/var/lib/prometheus 
  --storage.tsdb.retention.time=30d 
  --storage.tsdb.no-lockfile

Bei hoher Belastung skalieren Sie horizontal mit Thanos oder VictoriaMetrics; prüfen Sie zudem Blockgröße und Wal-Settings, wenn Sie häufige Schreibspitzen sehen.

PromQL-Beispiele, die im Alltag helfen

Praxisnahe Queries für Diagnose und Dashboards:

# Aktive VMs pro Node
count by (instance) (pve_vm_info{state="running"})

# Storage-Usage pro Storage-Pool
sum by (storage) (pve_storage_used_bytes) / sum by (storage) (pve_storage_total_bytes)

# Disk-IO-Latenz pro VM (wenn Exporter Metrik liefert)
avg by (vm) (rate(pve_vm_disk_io_time_seconds_total[5m]))

Alerting: bewährte Patterns und Alertmanager-Integration

Nutzen Sie Alertmanager als zentrale Steuerung für Routing, Gruppierung, Inhibition (Unterdrückung) und Silences. Alerts sollten handlungsorientiert sein: eine kurze Zusammenfassung, eine präzise Ursache (sofern möglich) und ein verlinktes Runbook.

Grouping, Inhibition und Beispiel

Grouping reduziert Notification-Flut, Inhibition verhindert Doppelalarme (z. B. wenn Storage-Down einen Reihe von VM-Alerts auslöst).

# Beispiel: Inhibit-Regel in alertmanager.yml
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['instance']

Alert-Regel: Storage-Füllstand mit For-Delay

- alert: ProxmoxStorageHighUsage
  expr: (pve_storage_used_bytes / pve_storage_total_bytes) > 0.9
  for: 30m
  labels:
    severity: warning
    team: storage
  annotations:
    summary: "Storage fast voll auf {{ $labels.storage }}"
    runbook: "https://intranet/runbooks/proxmox-storage-full"

Mit einem längeren for verzögern Sie Alarme für transiente Peaks (z. B. temporäre Snapshots).

Praktische Test- und Validierungsschritte

Vor produktivem Rollout prüfen Sie standardisiert:

1. Exporter-Endpoint:
   ShellCode kopieren

   curl -s http://pve-node1:9273/metrics | head

2. Prometheus /targets: alle relevanten Targets zeigen UP und geringe Scrape-Dauer.
3. Grafana-Panels: Kernauswertungen (CPU, Memory, Storage) validieren.
4. Alert-Tests: Testregel mit niedriger Schwelle aktivieren, Alertmanager-Route prüfen.
5. Playbook-Drill: Empfänger führen definierte Schritte durch und melden Rücksetzpunkt.

Integration in Incident-Management-Tools

Alertmanager unterstützt viele Integrationen (Webhook, PagerDuty, Opsgenie, Microsoft Teams, Slack). Für Slack/Webhook definieren Sie einen Receiver mit der entsprechenden URL und strukturieren Labels für Routing (team, severity).

receivers:
- name: 'slack-main'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/XXXXX/XXXXX/XXXXX'
    channel: '#infra-alerts'
    title: '{{ template "slack.title" . }}'

Vermeiden Sie, sensible URLs in Klartext-Repos zu speichern; nutzen Sie Secrets-Management.

Security- und Betriebsrisiken

Unzureichend geschützte Exporter-Endpunkte sind eine Angriffsfläche. Schützen Sie folgende Ebenen:

• Netzwerk: Firewall nur zwischen Prometheus und Exportern zulassen.
• Transport: TLS oder mTLS über Reverse-Proxy, wenn Netzsegmente unsicher sind.
• API-Zugriffe: Tokens mit minimalen Rechten, Rotation und Vault-Einsatz.

Upgrade- und Migrationshinweise

Exporter- und API-Versionen können inkompatibel werden. Vorgehen:

• Versions-Pinning: testen Sie neue Exporter-Versionen in Staging.
• Smoke-Tests: nach Upgrade Exporter-Endpunkte, Prometheus-Targets und Grafana-Dashboards prüfen.
• Rollback: Versionsverwaltung für Konfigurationen (Git) und Revert-Skripte für systemd-Units vorhalten.

Rückfallstrategie bei Alarmflut oder Systemausfall

Wenn Alerts unkontrolliert auslösen oder Prometheus selbst Probleme verursacht, gibt es schnelle Maßnahmen:

1. Silence per Alertmanager-API für betroffene Alert-Gruppen setzen.
2. Prometheus-Queries auf teuerste Ausdrücke identifizieren und temporär deaktivieren (Config-Revert).
3. Edge-Prometheus wieder aktivieren oder Last von zentraler Instanz trennen.

# Silence per API anlegen (Beispiel)
curl -XPOST -H "Content-Type: application/json" http://alertmanager.example.local/api/v2/silences -d '{
  "matchers": [{"name":"team","value":"storage"}],
  "startsAt":"2026-07-28T10:00:00Z",
  "endsAt":"2026-07-28T10:30:00Z",
  "createdBy":"ops",
  "comment":"Emergency mute while investigating"
}'

Grafana: Dashboards, Struktur und Reproduzierbarkeit

Guter Dashboardbau ist mehr als schöne Charts: verwenden Sie Variablen für Umgebung/Node, speichern Sie Dashboards als JSON in Git (Export/Import) und verlinken Sie Runbooks direkt in Panel-Anmerkungen. Richten Sie Ordner-Rechte ein, damit Editing auf ein kleines Team beschränkt ist.

Praktische Checkliste für Rollout

• Token, Firewall, Zeit-Synchronisation prüfen.
• Node- und PVE-Exporter als Dienste, Secrets sicher ablegen.
• Prometheus-Relabeling definieren, Cardinality-Report aktivieren.
• Alertmanager-Routing, Silences und Inhibition-Regeln testen.
• Grafana-Dashboards mit Variablen, Runbook-Links und Versionierung bereitstellen.

Fazit

Monitoring Proxmox mit Prometheus und Grafana bietet tiefgehende Einblicke, wenn Sie das System iterativ einführen: ein schlanker Exporter-Satz (node_exporter, pve_exporter), eine restriktive Label-Strategie zur Begrenzung der Cardinality, testbare Alerts mit Runbooks und eine skalierbare Persistenz-Strategie sind die Kernbausteine. Sichern Sie API-Zugänge, automatisieren Sie Tests und halten Sie klare Rückfallpfade bereit — so betreiben Sie Ihren Proxmox-Cluster stabil, nachvollziehbar und skalierbar.

Weiterführende Prüfpunkte (Kurz)

• Automatisierte Token-Rotation prüfen.
• TSDB-Backups und Restore-Prozesse dokumentieren.
• Alert-Drills und Postmortem-Prozesse regelmäßig durchführen.

Betriebssicherheit, Disaster Recovery und „Monitoring, das überwacht“

Neben der Basisfunktionalität ist entscheidend, dass Ihr Monitoring selbst robust, testbar und wiederherstellbar ist. Betrachten Sie Prometheus, Alertmanager und Grafana nicht als beliebige Tools, sondern als betriebskritische Services: sie benötigen eigene SLOs, Backup-Verfahren, Kapazitätsplanung und eine Beobachtung, die Ausfälle der Monitoring-Pipeline frühzeitig erkennt.

Metriken, mit denen Sie das Monitoring überwachen

Erfassen Sie gezielt interne Metriken Ihrer Monitoring-Instanzen, etwa Scrape-Dauer (scrape_duration_seconds), fehlgeschlagene Scrapes (scrape_samples_post_metric_relabeling), WAL-Lag und Speicherauslastung der TSDB. Definieren Sie Alerts, wenn diese Indikatoren Grenzwerte überschreiten — ein hoher WAL-Lag signalisiert oft I/O-Engpässe, ein schneller Anstieg fehlender Scrapes weist auf Netzwerk- oder API-Probleme hin.

Recording Rules und Aggregationen zur Performance-Optimierung

Recording Rules speichern voraggregierte Zeitreihen als neue Metriken und entlasten wiederkehrende, teure PromQL-Abfragen. Legen Sie Regeln für häufig genutzte Kennzahlen (z. B. durchschnittliche Speicherbelegung pro Node über 5m) an, statt die Rohdaten bei jeder Dashboard-Abfrage neu zu berechnen.

groups:
- name: recording_rules
  rules:
  - record: job:node_memory_used_bytes:avg5m
    expr: avg_over_time(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes[5m])

Warum das wirkt: Queries gegen bereits berechnete Series sind deutlich schneller und reduzieren CPU-Last auf der zentralen Prometheus-Instanz. Wann es scheitert: bei sehr hoher Cardinality müssen auch Recording Rules limitiert und gezielt gestaltet werden.

TSDB-Backup und Wiederherstellung

Prometheus bietet eine Snapshot-API, die einen konsistenten Block erzeugt. Erstellen Sie regelmäßige Snapshots und archivieren Sie diese außerhalb des Primärspeichers (z. B. Object-Storage). Beispiel: Erzeugen Sie einen Snapshot vor Änderungen an Retention- oder Compaction-Parametern und testen Sie die Wiederherstellung in einer Staging-Umgebung.

# Snapshot per API auslösen und anschließend sichern
curl -s -XPOST http://prometheus.local:9090/api/v1/admin/tsdb/snapshot 
  | jq -r '.data.name' 
  | xargs -I{} tar -C /var/lib/prometheus/snapshots -czf /backup/prom_snap_{}.tar.gz {}

Dokumentieren Sie Restore-Schritte explizit (Welche Version, welche Config-Dateien) und testen Sie Wiederherstellungen mindestens vierteljährlich.

Canary-Scrapes und synthetische Checks

Setzen Sie einen kleinen Satz „Canary“-VMs oder Services, die synthetisch geprüft werden (Blackbox- oder HTTP-Exporter). Diese liefern frühzeitig Signale, wenn API-Änderungen, Netzwerksegmente oder Authentifizierungsprobleme ganze Gruppen von Targets betreffen.

Multi-Tenancy, Zugriffsteuerung und Compliance

Wenn mehrere Teams Grafana nutzen oder Sie Proxmox-Metriken als Service für Dritte bereitstellen, achten Sie auf feingranulares RBAC. Verwenden Sie Grafana-Organisationen, Folder-Permissions und variablenbasierte Queries, um Datenisolierung zu erreichen. Prüfen Sie zusätzlich, ob Metriken personenbezogene Daten enthalten (z. B. Benutzernamen in VM-Meta) und entfernen/anononymisieren Sie diese, um Compliance-Risiken zu vermeiden.

Kostenplanung und Betriebskosten reduzieren

Langfristige Speicherung von hoher Cardinality ist teuer. Legen Sie eine Daten-Retention-Policy fest, die zwischen operativer Notwendigkeit und Kosten abwägt: kurze Retention in Hot-Store, langsame Aggregation in Long-Term-Store (VictoriaMetrics, Thanos). Nutzen Sie Sampling und Downsampling für historische Daten.

Automatisierung: Provisioning und Config-as-Code

Versionieren Sie Prometheus-, Alertmanager- und Grafana-Provisioning (Dashboards, Alerts, Datasources) in Git. Automatisieren Sie Rollouts per CI/CD, testen Sie Konfigurationsänderungen gegen eine Test-Prometheus-Instanz (promtool check rules) und stellen Sie sicher, dass Rollbacks per Git-Revert reproduzierbar sind.

Schnelle Rückfall- und Eskalationspfade

Definieren Sie klare Eskalationsstufen in Alertmanager (z. B. Team → On-call → Management) und halten Sie dokumentierte Runbooks bereit. Wenn Monitoring selbst ausfällt: setzen Sie temporäre Silences, deaktivieren Sie teure Queries und schalten Sie auf Edge-Prometheus-Instanzen um, um Wiederherstellungszeit zu verkürzen.

Kurzcheck (operativ): Monitor-Metriken aktivieren, Recording Rules anlegen, Snapshot-Backups automatisieren, Canary-Scrapes einrichten, RBAC und Datenanonymisierung prüfen, Dashboards und Alerts Git-versionieren. Mit diesen zusätzlichen Maßnahmen betreiben Sie Ihr Proxmox-Monitoring belastbar, prüfbar und rechtssicher — Voraussetzungen für eine nachhaltige Betriebsführung und für Integrationen in individuelle Unternehmenssoftware und zentrale Betriebsprozesse.

Service Discovery, Laufzeitisolierung und mTLS-Härtung

Praktisch wichtig sind zwei ergänzende Aspekte: automatische Service Discovery für dynamische Proxmox-Pools und saubere Laufzeitisolation von Prometheus. Erzeugen Sie Targets per file_sd aus Ihrem Inventar-Tool (Ansible/CMDB), statt statisch zu pflegen – das reduziert Fehlkonfigurationen bei Skalierung.

# file_sd example
- targets: ['pve1:9273','pve2:9273']
  labels:
    cluster: 'prod'
    role: 'hypervisor'

Betreiben Sie Prometheus bevorzugt in einem dedizierten Laufzeitkontext (Container oder VM) mit direktem, performanten Block-Storage; prüfen Sie cgroup- und I/O-QoS, um WAL- und Compaction-Ausfälle zu vermeiden. Für Exporte­r-Endpunkte empfiehlt sich mTLS via Reverse-Proxy (Envoy/Nginx) und eine interne CA zur einfachen Zertifikatsrotation. So schützen Sie Datenintegrität, reduzieren Angriffsfläche und erleichtern Integration in individuelle Unternehmenssoftware über gesicherte Webhooks.

Für dieses Thema sind auch Proxmox Monitoring und Prometheus Alerting wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.