# Prometheus: Das Herzstück moderner Cloud-Native Observability

TL;DR / Management Summary Prometheus ist das führende Open-Source Monitoring-System für zeitbasierte Metriken (Time-Series). Im Gegensatz zu klassischen Systemen arbeitet Prometheus nach dem Pull-Prinzip: Er holt sich die Daten aktiv von den Zielsystemen. Ein Senior Admin nutzt Prometheus in Kombination mit spezialisierten Exportern, um hunderte Server, Container und Netzwerkgeräte (Artikel 757) lückenlos zu überwachen. Die mächtige Abfragesprache PromQL erlaubt es, komplexe Anomalien in Millisekunden zu finden.

# 1. Das Prometheus-Modell

Pull statt Push.

1. Scraping: Prometheus fragt in festen Intervallen (z.B. alle 15 Sek.) einen HTTP-Endpunkt (meist /metrics) auf dem Zielsystem ab.
2. Storage: Die Daten landen in einer hochoptimierten lokalen Datenbank (TSDB).
3. PromQL: Eine funktionale Abfragesprache zur Analyse der Daten.

# 2. Exporter: Die Datenlieferanten

Alles ist messbar.

Da viele Programme keine nativen Prometheus-Metriken liefern, nutzen wir Exporter:

• Node Exporter: Der Standard für Linux (CPU, RAM, Disk, Load).
• Windows Exporter: Das Pendant für Windows-Server.
• Blackbox Exporter: Prüft die Erreichbarkeit von außen (Ping, HTTP, SSL-Ablauf).
• Proxmox Exporter: Holt Cluster-Daten via API (Artikel 699).

# 3. Deep Dive: PromQL Grundlagen

Sinn aus den Zahlen machen.

Lernen Sie die wichtigsten Operatoren:

• Rate: rate(node_network_receive_bytes_total[5m]) (Berechnet den aktuellen Durchsatz der letzten 5 Min).
• Sum: sum(container_memory_usage_bytes) by (namespace) (Aggregiert Speicherverbrauch pro K8s-Namespace).
• Topk: topk(5, node_cpu_seconds_total) (Zeigt die Top 5 CPU-Fresser).

# 4. Day-2 Operations: Service Discovery

Automatisisches Finden von Zielen.

In dynamischen Umgebungen (Kubernetes/Proxmox) wollen wir keine IP-Listen pflegen.

• Aktion: Konfigurieren Sie die Relabeling Rules.
• Vorteil: Prometheus fragt die API ab: “Welche VMs laufen gerade?”. Er fügt neue VMs automatisch zum Scraping hinzu, sobald sie online gehen.

# 5. Troubleshooting & “War Stories”

Wenn die Graphen ‘löchrig’ werden.

# Top 3 Fehlerbilder

1. Symptom: “Scrape Target Down” (Status 404).

   • Ursache: Der Exporter läuft nicht oder die Firewall (OPNsense) blockiert Port 9100.
   • Lösung: curl <target>:9100/metrics manuell testen.

2. Symptom: Hoher RAM-Verbrauch des Prometheus-Servers.

   • Ursache: Zu viele Labels (High Cardinality). Wenn jedes Paket eine eigene ID im Label hat, explodiert die Datenbank.
   • Fix: Labels bereinigen und nur Aggregate speichern.

3. Symptom: Datenverlust nach Neustart.

   • Fix: Nutzen Sie Persistent Volumes (Artikel 815) für das Prometheus-Datenverzeichnis.

# “War Story”: Der “Metrics-Loop” des Grauens

Ein Admin konfigurierte den Prometheus-Server so, dass er seine eigenen Metriken alle 1 Sekunde abfragte und diese wiederum als neue Metriken exportierte. Das Ereignis: Innerhalb von 2 Stunden wuchs die Datenbank um 50 GB. Das Ergebnis: Der Server fror ein, da der RAM für die Indexierung der Millionen von redundanten Zeitreihen nicht ausreichte. Lehre: Nutzen Sie Federation und Scrape-Intervalle mit Bedacht. Nicht alles, was gemessen werden kann, muss im Sekundentakt gespeichert werden.

# 6. Monitoring & Reporting

Selbstüberwachung.

# Prometheus Meta-Monitoring

Überwachen Sie den Wächter selbst:

• prometheus_tsdb_head_series: Wie viele Metriken verwalten wir?
• prometheus_target_interval_length_seconds: Halten wir die Scrape-Intervalle ein?

# 7. Fazit & Empfehlung

Prometheus ist das Gehirn Ihres Monitoring-Stacks.

• Empfehlung: Nutzen Sie den kube-prometheus-stack für Kubernetes-Umgebungen. Er konfiguriert alles (Prometheus, Grafana, Alertmanager) in einem Rutsch.
• Wichtig: Trennen Sie das Monitoring-Netzwerk (Artikel 728) von der Produktion, um “Heisenberg-Effekte” (Monitoring beeinflusst die Performance) zu vermeiden.

# Anhang: Cheatsheet (Wichtige Exporter Ports)

# Referenzen

• Prometheus Official Documentation
• PromQL Cheat Sheet
• Awesome Prometheus (Curated List)