Die meisten Logging- und Monitoring-Werkzeuge sendest du Daten zu. Prometheus dagegen ist um das Ziehen (Pulling) herum gebaut: Es geht nach Zeitplan auf die Dinge zu, die es überwacht, und fragt nach ihren aktuellen Zahlen. Diese eine Designentscheidung prägt fast alles Weitere daran, wie es betrieben und konfiguriert wird, und diese Anleitung behandelt die Architektur, die daraus folgt.

Scraping: ein Pull statt eines Push

Prometheus sendet periodisch eine HTTP-Anfrage an jedes System, das es überwacht, und liest einen Schnappschuss der aktuellen Metrikwerte dieses Systems zurück. Prometheus nennt das Scraping, und alles, was es abfragt, ist ein Target. Ein Scrape trägt nur die Werte dieses Moments; die Nutzlast enthält keine Historie; Prometheus ist es, das eine Folge von in Abständen genommenen Scrapes in eine Historie verwandelt.

Das Pull-Modell hat eine praktische Folge: Alles, was Prometheus überwacht, muss einen HTTP-Endpunkt bereitstellen (/metrics per Konvention), der seine aktuellen Werte in einem Format zurückgibt, das Prometheus versteht, statt dass Prometheus für jede mögliche Quelle einen eingehenden Listener braucht, die Daten an es pusht.

Targets: instrumentierte Apps und Exporter

Ein Target fällt in eine von zwei Kategorien:

• Direkt instrumentierte Anwendungen. Dein eigener Service, der mit einer der offiziellen Client-Bibliotheken von Prometheus seine eigenen Metriken nativ verfolgt und unter einem /metrics-Endpunkt bereitstellt.
• Exporter, für alles, was selbst keine Prometheus-Metriken bereitstellt (oder nicht kann): eine Datenbank, ein Linux-Host, eine Netzwerk-Appliance. Ein Exporter ist ein kleiner Prozess, der neben dem überwachten Ding läuft und dessen native Statistiken in Prometheus’ Format übersetzt. node_exporter für Host-Metriken (CPU, Speicher, Disk, Netzwerk) und cAdvisor für Metriken pro Container sind zwei der meistgenutzten.

Weil das Exposition-Format bewusst einfacher Text ist (in der nächsten Anleitung behandelt), ist es realistisch, einen Exporter zu schreiben oder sogar Metriken ganz ohne Client-Bibliothek von Hand zu bauen, selbst für etwas ohne offizielle Prometheus-Unterstützung.

Targets finden: statische Konfiguration oder Service Discovery

Prometheus braucht eine Liste von Targets zum Abfragen. Für eine Handvoll stabiler Hosts ist es in Ordnung, sie von Hand in Prometheus’ Konfigurationsdatei aufzulisten. Für alles Größere oder Dynamischere, Maschinen und Container, die kommen und gehen, wird das schnell von Hand unpraktikabel. Prometheus integriert sich stattdessen mit Service-Discovery-Mechanismen, DNS, dem Kubernetes-API-Server, Cloud-Anbieter-APIs und anderen, um seine Target-Liste automatisch aufzubauen und fortlaufend zu aktualisieren, während sich die Umgebung ändert.

Speicher: die lokale Zeitreihendatenbank

Abgefragte Samples landen in Prometheus’ eigener lokaler Zeitreihendatenbank (TSDB) auf der Platte. Standardmäßig behält Prometheus 15 Tage an Daten; das ist ein konfigurierbares Flag (--storage.tsdb.retention.time), keine harte Grenze, aber 15 Tage reichen für die überwältigende Mehrheit echter Fehlersuche, da die meisten Vorfälle mit Minuten oder Stunden zuvor verglichen werden, selten mit Monaten. Für Langzeitaufbewahrung oder einen zentralisierten Speicher über viele Prometheus-Server kann Prometheus außerdem so konfiguriert werden, dass es Samples an ein externes Speichersystem mit anderen Kompromissen als seine lokale TSDB weiterleitet (Remote Write).

Was den Kernserver umgibt

Ein paar Komponenten vervollständigen ein typisches Setup:

• Alertmanager ist eine separate Komponente, an die Prometheus auslösende Alerts übergibt. Er dedupliziert, gruppiert und routet sie an E-Mail, Slack, PagerDuty oder was auch immer du konfigurierst und entkoppelt so „ein Problem erkennen“ von „entscheiden, wer wie benachrichtigt wird“.
• Grafana (oder Prometheus’ eigene mitgelieferte Web-UI oder andere Werkzeuge) ist, womit du die Daten typischerweise erkundest und visualisierst; Prometheus selbst konzentriert sich darauf, Metriken zuverlässig zu sammeln und zu speichern, nicht darauf, die Dashboard-Schicht zu sein.
• PromQL, Prometheus’ Abfragesprache, ist das, worauf sowohl Grafanas Dashboards als auch Prometheus’ eigene Alerting-Regeln gebaut sind. Alerting und Dashboarding sind nicht zwei verschiedene zusammengeschraubte Systeme; sie sind zwei Konsumenten derselben Abfragesprache gegen dieselben Daten. Spätere Anleitungen dieser Reihe behandeln das Datenmodell und PromQL direkt.

Die Teile zusammensetzen

   ┌──────────────┐        fragt per HTTP ab        ┌──────────────┐
   │  Prometheus  │ ───────────────────────────────▶ │    Target    │
   │    Server    │                                    │ (/metrics)   │
   └──────┬───────┘                                    └──────────────┘
          │ speichert Samples in
          ▼
   lokaler TSDB (Standard-Aufbewahrung 15d)
          │
   ┌──────┴───────────────┬───────────────────────┐
   ▼                       ▼                       ▼
auslösende Alerting-    PromQL-Abfragen         Remote Write
Regeln                  (Grafana, ad hoc)       (optional, externer Speicher)
   │
   ▼
Alertmanager → E-Mail / Slack / PagerDuty / ...

Alles Nachgelagerte, Alerts, Dashboards, Ad-hoc-Debugging, liest aus derselben TSDB, die das Scraping füllt. Der Rest dieser Reihe beginnt mit dem, was tatsächlich darin gespeichert wird.