# Proxmox Performance Monitoring: Metriken, Trends & Observability

TL;DR / Management Summary Ein stabiler Cluster erfordert eine kontinuierliche Überwachung der Leistungsdaten. Proxmox bietet hierfür den Metrics Server, der Daten in Echtzeit an externe Zeitreihen-Datenbanken (z.B. InfluxDB) sendet. Ein Senior Admin nutzt diese Metriken, um IO-Wait Engpässe (Artikel 703) zu identifizieren, das RAM-Management zu optimieren und Langzeit-Trends zu visualisieren. Ziel ist die proaktive Erkennung von Lastspitzen, bevor sie die Benutzererfahrung beeinträchtigen.

# 1. Das Monitoring-Konzept

Push vs. Pull.

In Proxmox nutzen wir primär das Push-Modell:

Metrics Server: Die Proxmox-Dienste sammeln Daten und “pushen” diese aktiv an ein Ziel.
Vorteil: Keine zusätzliche Last durch sekündliche API-Abfragen von außen.
Ziele: Unterstützt werden InfluxDB (modern, schnell) und Graphite (etabliert).

# 2. Einrichtung des Metrics-Exports

Datenfluss aktivieren.

Datacenter -> Metric Server -> Add -> InfluxDB.

Server: IP Ihrer InfluxDB-Instanz (z.B. im Docker-Container, Artikel 678).
Port: 8086 (HTTP) oder 8089 (UDP).
Protocol: HTTP (für InfluxDB v2 mit Token) oder UDP (für v1 - schnellster Transfer).
Aktion: Wählen Sie die Detailtiefe der Metriken (Standard: Alles).

# 3. Deep Dive: Wichtige Metriken (KPIs)

Was die Graphen uns sagen.

# 1. CPU IO-Wait (`cpu_iowait`)

Der wichtigste Wert im Datacenter.

Bedeutung: Zeit, die die CPU untätig verbringt, weil sie auf Daten von der Festplatte wartet.
Alarm: Wenn dieser Wert dauerhaft > 10% liegt, ist Ihr Storage (ZFS/Ceph) der Flaschenhals.

# 2. Memory Ballooning (`mem_balloon`)

Bedeutung: Wie viel RAM der Host von der VM zurückgefordert hat (Artikel 704).
Nutzen: Hilft bei der Identifizierung von VMs, die mit zu wenig RAM “kämpfen”.

# 3. Network PPS (Packets Per Second)

Bedeutung: Nicht die Bandbreite (MB/s), sondern die Anzahl der Pakete.
Nutzen: Erkennt DDoS-Angriffe oder ineffiziente Applikations-Protokolle.

# 4. Day-2 Operations: Visualisierung mit Grafana

Vom Wert zum Tacho.

Verknüpfen Sie Ihre InfluxDB mit Grafana (Artikel 698).

Vordefinierte Dashboards: Laden Sie das “Proxmox All-in-One” Dashboard (ID 15366) herunter.
Custom Panels: Erstellen Sie Graphen für ZFS ARC Hit Ratio, um die Effizienz Ihres Lese-Caches zu prüfen.

# 5. Troubleshooting & “War Stories”

Wenn das Monitoring blind ist.

# Top 3 Fehlerbilder

Symptom: Graphen sind lückenhaft.
- Ursache: Netzwerk-Jitter im Management-LAN oder InfluxDB-Server ist überlastet.
- Lösung: UDP-Transfer auf HTTP (TCP) umstellen für garantierten Transport.
Symptom: “No Data” in der InfluxDB.
- Ursache: Firewall blockiert den ausgehenden Traffic vom Proxmox-Host auf Port 8086.
- Lösung: Regel in der OPNsense prüfen (Artikel 553).
Symptom: InfluxDB Festplatte ist nach 2 Wochen voll.
- Fix: Retention Policies setzen! Löschen Sie Rohdaten nach 30 Tagen und behalten Sie nur aggregierte Stunden-Mittelwerte.

# “War Story”: Der “Zufalls-Gau” durch Monitoring

Ein Admin stellte das Sende-Intervall des Metrics Servers auf 1 Sekunde für 200 VMs ein. Das Ereignis: Jedes Mal, wenn der Metrics-Dienst die Daten sammelte, verursachte er einen kleinen CPU-Spike auf dem Proxmox-Host. Das Ergebnis: Bei 200 VMs summierten sich diese Spikes zu einer permanenten 20% Grundlast auf dem Hypervisor, was die Latenz für die VMs spürbar verschlechterte. Lehre: Monitoring ist kein Selbstzweck. Ein Intervall von 10-30 Sekunden reicht für Kapazitätsplanung völlig aus. Weniger ist oft mehr Performance.

# 6. Monitoring & Reporting

Status-Reports.

# Der wöchentliche Health-Report

Nutzen Sie die Reporting-Funktion von Grafana:

Durchschnittliche Uptime.
Speicherwachstums-Rate.
Top 5 Ressourcen-Fresser (VMs).

# 7. Fazit & Empfehlung

Performance Monitoring ist die Grundlage für jede Hardware-Investition.

Empfehlung: Nutzen Sie den Metrics Server ab dem ersten Knoten.
Wichtig: Trennen Sie das Monitoring physisch von den zu überwachenden Systemen, um auch bei einem Cluster-Ausfall noch sehen zu können, was passiert ist.

# Anhang: Cheatsheet (InfluxDB v2 CLI)

Aufgabe	Befehl
Buckets listen	`influx bucket list`
Letzte Daten sehen	`influx query 'from(bucket:“pve”)
Token erstellen	`influx auth create --all-access`
Speicherplatz prüfen	`du -sh /var/lib/influxdb2/engine`