Prometheus

Prometheus "pullt" (zieht) Daten. Deine App stellt eine Seite /metrics bereit. Dort steht: cpu_usage 45% requests_total 1024 Prometheus besucht diese Seite regelmäßig und speichert die Werte. Wenn ein Wert kritisch wird (CPU > 90%), kann es Alarm schlagen (Alertmanager).

Praxisroutine

In der Praxis lernst du Prometheus, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. TSDB (Time Series Database)

Prometheus ist keine normale Datenbank (SQL). Es ist spezialisiert auf Zeitreihen. Es speichert nicht "Wer ist User X?", sondern "Wie war Wert Y um 12:00, 12:01, 12:02?". Das ist extrem effizient komprimiert.

2. PromQL

Die Abfragesprache. rate(http_requests_total[5m]) "Zeige mir die Rate der Anfragen pro Sekunde im Durchschnitt der letzten 5 Minuten." Mächtig, aber man muss Mathe mögen.

Technische Einordnung im System

Technisch ist Prometheus nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

1. Architektur (Borgmon Heritage)

Prometheus kopiert massiv das Design von Googles internem "Borgmon" Tacho. Die Kernphilosophie ist das strikte Vermeiden von Single-Points of Failure durch Clustering-Abhängigkeiten. Ein Prometheus-Server ist 100% autark. Er benötigt keine externe Datenbank, kein Kafka, kein Zookeeper. Er läuft als monolithischer Binärprozess und schreibt seine Time-Series Daten in lokale Flat-Files in Chunks. Das bedeutet: Bricht dein kompletter Kubernetes-Cluster durch einen Netzwerk-Ausfall weg, läuft der kleine Prometheus-Knoten auf der Eck-Hardware munter weiter und sendet verlässlich PagerDuty-SMS, weil er sich nicht auf abstrakte Service-Meshes verlässt.

2. Labels und Cardinality (Der Tod durch Tags)

Metriken in Prometheus sind nicht nur Namen (http_requests), sondern n-dimensionale Arrays via Labels: http_requests{status="500", path="/login", method="POST"}. Jede einzigartige Kombination der Labels erzeugt in der Engine eine brandneue Time-Series (Cardinality). Der tödlichste Anfängerfehler: Man nutzt User-IDs als Label (http_requests{status="200", user_id="84192"}). Bei 1 Million Usern explodiert die Kardinalität. Prometheus versucht 1 Million Time-Series im RAM zu halten und crasht gnadenlos mit "Out of Memory". Metrik-Labels dürfen niemals hoch-dynamische unbounded Daten (IPs, UUIDs, Tokens) enthalten, sondern nur Kategorien (HTTP-Status, Environment, Pod-Name).

3. Compaction und Storage Retention

Um Speicher vollgepackt mit Millisekunden-Daten effizient zu handhaben, schreibt Prometheus zunächst nur in einen Write-Ahead-Log (WAL) und hält 2 Stunden rohe Daten im RAM (Head Block). Danach schneidet es den RAM-Block ab und schreibt einen persistenten Disk-Block. Später wendetet die Engine Compaction an: Sie nimmt mehrere alte kleine 2-Stunden-Blöcke und "kompiliert" sie zu großen, stark zippierten Delta-Encodings zusammen. Prometheus ist historisch nicht für Langzeit-Speicherung gedacht (Default Retention: 15 Tage). Will man 5 Jahre an Metriken aufheben (für ML / Capacity Planning), konfiguriert man das Remote Write API. Prometheus feuert die Datenpakete an Thanos oder Cortex weiter, die diese ewig-persistierten Brocken geballt in billige Amazon S3 Object Stores werfen.