Prometheus Architektur

Lernziele

Nach dieser Lektion kannst du die Prometheus-Architektur an einem Whiteboard skizzieren: Server mit Scraper, TSDB und PromQL-Engine, dazu Exporters, Service Discovery und Alertmanager. Du kannst den Weg einer Metrik vom Target bis zur Alert-Benachrichtigung beschreiben und erklären, warum Prometheus bewusst als Single-Node-System mit lokalem Storage entworfen wurde — inklusive der Konsequenzen für Skalierung und Hochverfügbarkeit.

Das Problem: Monitoring darf nicht mit dem System sterben

Ein Monitoring-System hat eine unangenehme Anforderung: Es muss ausgerechnet dann funktionieren, wenn alles andere brennt. Wenn dein Monitoring von der Datenbank abhängt, die gerade ausgefallen ist, oder von einem verteilten Cluster, der gerade eine Netzwerkpartition erlebt, bist du im Incident blind.

Prometheus zieht daraus eine radikale Konsequenz: Ein Prometheus-Server ist ein einzelner Prozess mit lokalem Storage und ohne externe Abhängigkeiten. Kein Cluster-Konsens, keine externe Datenbank, kein Message Broker. Ein Binary, eine Konfigurationsdatei, eine lokale Disk. Das macht ihn extrem robust und einfach zu betreiben — und erklärt gleichzeitig, warum Themen wie Langzeit-Speicherung und globale Sicht außerhalb des Servers gelöst werden (dazu Lektion 13).

Die Komponenten und der Weg einer Metrik

Das Gesamtbild lässt sich als Pipeline lesen:

Targets (/metrics) ──scrape──▶ Prometheus Server ──▶ TSDB (lokal)
       ▲                       │        │
  Service Discovery            │        └──▶ PromQL Engine ◀── Grafana, API-Clients
  (woher kommen die Targets?)  │
                               └──▶ Rule Evaluation ──▶ Alertmanager ──▶ Slack, PagerDuty, …

Der Prometheus Server vereint drei Aufgaben in einem Prozess. Der Scraper ruft in konfigurierten Intervallen (typisch 15–60 s) die /metrics-Endpoints aller Targets ab. Die TSDB (Time Series Database) persistiert die Samples lokal. Die PromQL-Engine beantwortet Abfragen — für Dashboards, Ad-hoc-Queries und die Auswertung von Alert-Regeln.

Exporters sind Übersetzer für Systeme, die kein Prometheus-Format sprechen: Der node_exporter exponiert Host-Metriken, der postgres_exporter Datenbank-Interna. Eigene Anwendungen instrumentierst du direkt mit Client Libraries — beides vertieft Lektion 4.

Service Discovery beantwortet die Frage, woher Prometheus seine Targets kennt. Statische Listen funktionieren für eine Handvoll Server; in dynamischen Umgebungen wie Kubernetes, EC2 oder Consul fragt Prometheus die jeweilige API ab und aktualisiert seine Target-Liste laufend selbst. Wie das in Kubernetes konkret aussieht, ist Thema von Lektion 5.

Der Alertmanager ist ein separater Prozess mit klarer Arbeitsteilung: Prometheus wertet Alert-Regeln aus und erzeugt Alerts; der Alertmanager übernimmt Deduplizierung, Gruppierung, Routing und Zustellung an Slack, PagerDuty oder E-Mail. Diese Trennung erlaubt, dass mehrere Prometheus-Server denselben Alertmanager-Cluster beliefern — Duplikate werden dort zusammengeführt. Details in Lektion 9.

Die TSDB: warum lokaler Storage so schnell ist

Die TSDB schreibt eingehende Samples zunächst in einen In-Memory-Puffer und parallel in ein WAL (Write-Ahead Log) auf Disk — stürzt der Prozess ab, wird der Zustand beim Neustart aus dem WAL rekonstruiert. Alle zwei Stunden wird der Puffer als unveränderlicher Block auf die Disk geschrieben; ältere Blöcke werden im Hintergrund zu größeren kompaktiert. Jeder Block bringt seinen eigenen Index mit, der Label-Kombinationen auf Zeitreihen abbildet.

Zwei Konsequenzen solltest du erklären können. Erstens: Die Kompression ist exzellent — durch Delta-Kodierung von Zeitstempeln und Werten landet ein Sample im Schnitt bei wenigen Bytes, weshalb ein einzelner Server problemlos Millionen aktiver Zeitreihen halten kann. Zweitens: Der teuerste Faktor ist nicht die Anzahl der Samples, sondern die Anzahl unterschiedlicher Zeitreihen — jede neue Label-Kombination erzeugt eine neue Serie samt Index-Eintrag. Dieses Kardinalitätsproblem zieht sich durch den ganzen Lernpfad und bekommt in Lektion 14 einen eigenen Schwerpunkt.

Standardmäßig behält Prometheus Daten 15 Tage (--storage.tsdb.retention.time). Das ist kein Versehen, sondern Designentscheidung: Der lokale Storage ist als operatives Kurzzeitgedächtnis gedacht, nicht als Archiv.

Skalierung und HA: was der Single-Node-Ansatz bedeutet

Im Interview kommt fast immer die Frage: „Prometheus ist ein einzelner Prozess — wie skalierst du das, und was ist mit Hochverfügbarkeit?”

Hochverfügbarkeit löst Prometheus pragmatisch: Du betreibst zwei identisch konfigurierte Server, die unabhängig dieselben Targets scrapen. Beide werten dieselben Alert-Regeln aus und schicken Alerts an den Alertmanager, der Duplikate dedupliziert. Die Daten beider Server sind dabei nie exakt identisch (Scrapes erfolgen zu leicht unterschiedlichen Zeitpunkten) — für Alerting ist das egal, für lückenlose Dashboards braucht es Werkzeuge wie Thanos.

Horizontale Skalierung funktioniert über funktionales Sharding: mehrere Prometheus-Instanzen, jede zuständig für einen Teil der Targets (pro Team, pro Cluster, pro Region). Für die globale Sicht über Shards hinweg gibt es zwei Mechanismen: Federation, bei der ein übergeordneter Prometheus ausgewählte (aggregierte) Zeitreihen von anderen scraped, und Remote Write, bei dem jeder Server seine Samples zusätzlich an ein zentrales Backend wie Thanos, Mimir oder Cortex streamt. Remote Write ist heute der üblichere Weg; Federation eignet sich nur für kleine, aggregierte Teilmengen — alles zu federaten wäre ein Anti-Pattern.

Praxis

Erweitere das Setup aus Lektion 1 um einen node_exporter und sieh dir die Architektur live an:

docker network create monitoring

docker run -d --name node-exporter --network monitoring \
  prom/node-exporter

docker run -d --name prom --network monitoring -p 9090:9090 \
  -v "$PWD/prometheus.yml:/etc/prometheus/prometheus.yml" \
  prom/prometheus

# prometheus.yml
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["localhost:9090"]
  - job_name: node
    static_configs:
      - targets: ["node-exporter:9100"]

Prüfe unter Status → Targets, dass beide Jobs UP sind, und stelle dann Fragen an die TSDB:

# Wie viele Zeitreihen hält der Server gerade im Kopf?
prometheus_tsdb_head_series

# Scrape-Dauer pro Target — die Pipeline beobachtet sich selbst
scrape_duration_seconds

Wirf zum Schluss einen Blick in das Datenverzeichnis (docker exec prom ls /prometheus): Du siehst das wal/-Verzeichnis und nach zwei Stunden Laufzeit die ersten Block-Verzeichnisse — die Storage-Architektur zum Anfassen.

Typische Stolperfallen

„Alertmanager wertet Alerts aus”: Nein — die Regel-Auswertung passiert in Prometheus. Der Alertmanager routet, gruppiert und stellt zu. Wer das verwechselt, sucht Alert-Probleme am falschen Ort.

Prometheus als Langzeit-Archiv behandeln: Die Retention einfach auf zwei Jahre zu stellen macht die lokale Disk zum Risiko und Queries über lange Zeiträume quälend langsam. Langzeit-Storage ist ein Remote-Write-Thema (Lektion 13).

Federation als Daten-Replikation missverstehen: Federation ist für ausgewählte, aggregierte Serien gedacht. Komplette Datenbestände zwischen Servern zu federaten erzeugt enorme Last und löst kein HA-Problem.

HA-Paar hinter einem Load Balancer für Queries: Da beide Server leicht unterschiedliche Daten haben, springen Dashboard-Werte beim Wechsel der Instanz. Für Alerting ist das Paar gedacht; konsistente Query-Sicht liefert erst eine Schicht wie Thanos Query.

Interview-Vorbereitung

Auf „Beschreibe die Prometheus-Architektur” antwortest du am stärksten entlang des Datenflusses: Service Discovery liefert Targets → der Server scraped deren /metrics-Endpoints → Samples landen in der lokalen TSDB (WAL, 2h-Blöcke, Kompaktierung) → die PromQL-Engine bedient Dashboards und wertet Alert-Regeln aus → ausgelöste Alerts gehen an den Alertmanager, der gruppiert, routet und zustellt. Dann ein Satz zur Designphilosophie: Single Node, lokaler Storage, keine externen Abhängigkeiten — Robustheit im Incident vor eingebauter Skalierung.

Typische Follow-ups:

• „Wie machst du Prometheus hochverfügbar?” — Zwei identische Instanzen scrapen unabhängig; Alertmanager dedupliziert. Kein Konsens, keine geteilten Daten.
• „Was passiert bei einem Crash mit den Daten der letzten Minuten?” — Sie stehen im WAL und werden beim Neustart wiederhergestellt.
• „Federation oder Remote Write?” — Federation für kleine aggregierte Teilmengen (Pull), Remote Write als kontinuierlicher Stream an zentrale Backends (Push) — heute der Standardweg für globale Sicht und Langzeit-Storage.
• „Was limitiert einen Prometheus-Server zuerst?” — Aktive Zeitreihen (Memory/Index), also Kardinalität — nicht die reine Sample-Rate.

Zusammenfassung

Prometheus ist bewusst ein Single-Node-System: Ein Server scraped Targets, die er per Service Discovery findet, speichert Samples in einer lokalen TSDB (WAL, 2h-Blöcke, starke Kompression) und wertet mit der PromQL-Engine Queries und Alert-Regeln aus. Der Alertmanager übernimmt als separater Prozess Deduplizierung, Gruppierung und Zustellung. HA entsteht durch zwei unabhängige Instanzen, Skalierung durch Sharding plus Remote Write oder selektive Federation.

Als Nächstes geht es eine Ebene tiefer in die Daten selbst: die vier Metrik-Typen Counter, Gauge, Histogram und Summary — und warum die Wahl des falschen Typs ganze Dashboards unbrauchbar macht.