Betrieb & Monitoring
Prometheus
Prometheus ist ein quelloffenes Monitoring- und Alerting-System für Metriken, das Zeitreihen per Pull-Modell einsammelt und mit der Abfragesprache PromQL auswertet.
- Zeitreihen-Datenbank für Metriken
- Pull-Modell (HTTP-Scrape)
- PromQL als Abfragesprache
- CNCF graduated, Apache 2.0
- Alertmanager (Routing/Silencing)
Prometheus ist ein quelloffenes Monitoring-System, das auf Metriken spezialisiert ist: numerische Messwerte über die Zeit (Zeitreihen). Es entstand bei SoundCloud und war nach Kubernetes das zweite Projekt, das bei der CNCF den Graduated-Status erreichte. Sein Markenzeichen ist das Pull-Modell: Prometheus holt die Daten aktiv von den Zielen ab, statt sie entgegenzunehmen.
Dieser Artikel erklärt das Pull-Prinzip und die Service Discovery, das Datenmodell mit Labels, die Metrik-Typen, die Abfragesprache PromQL, Exporter und Instrumentierung, Recording- und Alerting-Regeln samt Alertmanager, das Thema Langzeitspeicherung und das in der Praxis wichtigste Betriebsrisiko: die Kardinalität. Die Visualisierung übernimmt typischerweise Grafana.
1. Pull-Modell und Service Discovery
Prometheus fragt die Ziele aktiv ab (Scrape): In regelmäßigen Abständen ruft es deren HTTP-Endpunkt /metrics auf und liest die dort exponierten Werte. Welche Ziele es gibt, erfährt es entweder aus statischer Konfiguration oder über Service Discovery (Kubernetes, Consul, EC2, Azure, DNS oder Dateien).
Das Pull-Modell hat einen praktischen Nebeneffekt: Schlägt ein Scrape fehl, ist das Ziel sofort als nicht erreichbar erkennbar (die interne Metrik up wird 0). Die Überwachung des Sammelpunkts ist also eingebaut. Die Kehrseite: Prometheus muss seine Ziele über das Netz erreichen können. Für kurzlebige Batch-Jobs gibt es als Ausnahme das Pushgateway, das aber bewusst sparsam einzusetzen ist.
2. Datenmodell und Metrik-Typen
Jede Zeitreihe ist eindeutig über ihren Metriknamen und ein Set von Labels (Schlüssel-Wert-Paaren) bestimmt. http_requests_total{method="POST", handler="/api"} ist eine andere Reihe als dieselbe Metrik mit method="GET". Vier Metrik-Typen decken die Fälle ab:
- Counter monoton steigender Zähler (z. B. Anzahl Requests); ausgewertet meist über rate().
- Gauge Momentanwert, der steigt und fällt (z. B. Speicherbelegung, Warteschlangenlänge).
- Histogram verteilt Beobachtungen auf Buckets; Quantile werden serverseitig per PromQL berechnet.
- Summary berechnet Quantile bereits auf dem Client; über mehrere Instanzen nicht nachträglich aggregierbar.
Kardinalität ist der häufigste Betriebsfehler
Labels mit vielen möglichen Werten (User-IDs, Request-IDs, IP-Adressen) erzeugen sehr viele Zeitreihen. Da jede aktive Reihe Arbeitsspeicher belegt, kann hohe Kardinalität Prometheus bis zum Speicherüberlauf treiben. Faustregel: Labels nur für Werte mit überschaubarer, stabiler Wertemenge verwenden.
3. PromQL: Abfragen und Regeln
PromQL ist die Abfragesprache für die mehrdimensionalen Zeitreihen. Sie kennt Selektoren mit Label-Matchern (auch regulär, RE2), Aggregationen über by/without und Funktionen wie rate() (durchschnittliche Counter-Rate pro Sekunde) oder histogram_quantile().
Zwei Regeltypen bauen darauf auf: Recording Rules berechnen teure Ausdrücke vorab und speichern sie als neue Zeitreihe (Performance). Alerting Rules prüfen eine Bedingung und melden bei anhaltender Erfüllung (for) einen Alarm an den Alertmanager.
PromQL: Fehleranteil (5xx) je Service über 5 Minuten
sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))
/ sum by (job) (rate(http_requests_total[5m]))4. Exporter und Instrumentierung
Systeme, die nicht selbst Prometheus-Metriken liefern, werden über Exporter angebunden: kleine Dienste, die Werte ins Prometheus-Format übersetzen. Verbreitet sind der node_exporter (Linux/Unix-Systemmetriken), der windows_exporter, der blackbox_exporter (externe HTTP/TCP/ICMP-Checks) und der snmp_exporter für Netzwerk-Equipment. Eigener Anwendungscode wird über Client-Bibliotheken (Go, Java, Python, Ruby und weitere) direkt instrumentiert.
5. Alertmanager
Prometheus erkennt Alarme, versendet sie aber nicht selbst. Das übernimmt der separate Alertmanager. Er fasst zusammengehörige Alarme zu einer Meldung zusammen (Grouping), leitet sie anhand von Labels an die richtigen Empfänger (Routing), unterdrückt sie für Wartungsfenster (Silencing) und verhindert Folgealarme, wenn bereits ein übergeordneter Alarm feuert (Inhibition). Versandwege sind E-Mail, Webhook, Slack, PagerDuty und weitere.
Ein Monitoring-System ist nur so gut wie sein Alerting. Ohne durchdachtes Grouping, Routing und Silencing ertrinkt das Team bei einem größeren Ausfall in hunderten Einzelalarmen, und genau dann werden die wichtigen übersehen.
6. Langzeitspeicher und Hochverfügbarkeit
Die lokale Zeitreihen-Datenbank von Prometheus ist bewusst einfach gehalten: Standard-Aufbewahrung etwa 15 Tage, kein eingebautes Clustering, keine native Langzeit- oder HA-Funktion. Für längere Aufbewahrung und Ausfallsicherheit schreibt Prometheus per Remote Write an dafür ausgelegte Speicher: Thanos, Grafana Mimir oder Cortex nutzen Objektspeicher (S3/GCS) und bieten eine globale, hochverfügbare Sicht. Für ressourcenarme Außenstandorte gibt es zusätzlich einen Agent-Modus, der nur sammelt und weiterleitet.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| De-facto-Standard für Metriken im Cloud-native-Umfeld | Nur Metriken: keine Logs, kein Tracing |
| Pull-Modell liefert Erreichbarkeitsprüfung gratis mit | Lokale TSDB ohne native Langzeit-/HA-Funktion |
| Mächtiges Label-Datenmodell und PromQL | Hohe Label-Kardinalität kann den Speicher sprengen |
| Großes Exporter-Ökosystem (node, SNMP, Blackbox) | Pull setzt Netz-Erreichbarkeit der Ziele voraus |
| Apache 2.0, CNCF graduated, aktive Community | Langzeit/HA erst über Zusatzbausteine (Thanos/Mimir) |
Häufige Fragen zu Prometheus
Nicht zwingend, aber fast immer. Prometheus bringt eine einfache Ausdrucks-Oberfläche mit; für Dashboards, Drilldown und ansprechende Visualisierung ist Grafana der Standard und liest Prometheus als native Datenquelle.
Es zielt auf einen anderen Schwerpunkt. Prometheus ist auf Metriken und dynamische, cloud-native Umgebungen ausgelegt; Zabbix ist eine All-in-one-Lösung mit starkem SNMP-/Geräte-Fokus. Beide haben ihre Berechtigung, oft je nach Umgebung.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Prometheus im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.