# Proxmox Monitoring: Dashboards & Alerts mit Grafana & InfluxDB

TL;DR / Management Summary Ein Administrator darf niemals vom Ausfall eines Dienstes überrascht werden. Während die Proxmox-GUI den Status-Quo zeigt, ermöglicht die Grafana-Integration die Analyse von Langzeit-Trends und die Korrelation von Fehlern. Wir nutzen die InfluxDB als Speicher für Performance-Metriken und bauen Grafana-Dashboards, die uns bei Anomalien (z.B. plötzlicher IO-Wait Anstieg) via Teams oder Email alarmieren. Ein Senior Admin nutzt diese Observability, um Hardware-Limits frühzeitig zu erkennen.

# 1. Die Architektur der Überwachung

Vom Host zum Dashboard.

Die Kette besteht aus drei Gliedern:

Collector: Der Proxmox Metrics Server (Artikel 697).
Storage: InfluxDB (Zeitreihen-Datenbank).
Frontend: Grafana (Visualisierung & Alerting).

# 2. Grafana Dashboard Design

Was wir wirklich sehen müssen.

Importieren Sie bewährte Dashboards (z.B. ID 15366) und passen Sie diese an:

Cluster Overview: Quorum-Status, Gesamt-CPU/RAM Last.
Top Guests: Welche VMs verbrauchen am meisten I/O? (Suche nach dem “Noisy Neighbor”).
Storage Health: Freier Platz auf ZFS/Ceph und Latenz-Graphen.

# 3. Deep Dive: Proaktives Alerting

Die Alarm-Logik.

In Grafana können wir komplexe Schwellenwerte definieren, die über die Proxmox-Bordmittel hinausgehen.

# Beispiel: Speicher-Warnung

Regel: IF (Disk_Usage_Rate > 1GB/h) AND (Free_Space < 10%)
Aktion: Sende “Warnung: Disk wird in ca. 10 Stunden voll sein!” an den IT-Support.
Vorteil: Sie agieren, bevor der Server abstürzt.

# 4. Day-2 Operations: Log-Aggregation (Loki)

Text und Graphen vereinen.

Integrieren Sie Grafana Loki, um System-Logs (Artikel 701) direkt unter den Performance-Graphen anzuzeigen.

Szenario: Die CPU-Last einer VM steigt sprunghaft an.
Vorteil: Sie sehen im gleichen Fenster die Log-Einträge der VM (“OOM Killer aktiv”), ohne die Konsole öffnen zu müssen.

# 5. Troubleshooting & “War Stories”

Wenn die Metriken schweigen.

# Top 3 Fehlerbilder

Symptom: Graphen zeigen keine Daten mehr (“No Data”).
- Ursache: Der pvedaemon am Proxmox-Host hat die Verbindung zur InfluxDB verloren oder das Token ist abgelaufen.
- Lösung: journalctl -u pvedaemon prüfen.
Symptom: Dashboards laden extrem langsam.
- Ursache: Zu hohe Auflösung (z.B. 1s Sampling) über einen langen Zeitraum (z.B. 30 Tage).
- Fix: Nutzen Sie InfluxDB Continuous Queries, um alte Daten zu aggregieren (Downsampling).
Symptom: Fehlalarmierung bei Backup-Läufen.
- Lösung: Konfigurieren Sie “Alert Silencing” für die nächtlichen Backup-Stunden.

# “War Story”: Der “Zufalls-Gau” durch falsche Alarme

Ein Admin setzte den Alarm für “CPU Last > 90%” ohne zeitliche Verzögerung (For: 0m). Das Ereignis: Jedes Mal, wenn eine VM startete oder ein Programm kompilierte, schickte Grafana 50 SMS-Alarme gleichzeitig raus. Das Ergebnis: Das Team ignorierte die Alarme schließlich komplett (“Ist ja nur wieder ein Fehlalarm”). Als ein echter DDoS-Angriff die Server lahmlegte, reagierte niemand. Lehre: Gute Alarme brauchen eine Hysterese. Nutzen Sie FOR 5m, damit kurze Spitzen keinen Alarm auslösen. Alarme müssen wertvoll sein, nicht nervig.

# 6. Monitoring & Reporting

Management-Reports.

# Capacity Planning Report

Generieren Sie monatliche Berichte aus Grafana:

VM Count Growth.
Peak Load vs. Average Load.
KPI: Effizienz des Clusters. (Nutzen wir die Hardware, die wir bezahlt haben?).

# 7. Fazit & Empfehlung

Monitoring ist das visuelle Gewissen Ihres RZs.

Empfehlung: Betreiben Sie Grafana und InfluxDB auf separater Hardware (nicht im gleichen Proxmox-Cluster), damit die Überwachung auch im Falle eines Cluster-Crashs online bleibt.
Wichtig: Versionieren Sie Ihre Dashboards (JSON Export) im Git-Repository Ihres Teams.

# Anhang: Die “Top 5” Panels für Admins

Cluster Quorum (Gauge).
Host CPU Load vs. IO-Wait (Graph).
Storage Free Space (Bar Gauge).
VM Network PPS (Table).
Corosync RTT Latency (Heatmap).