OMNI52
Prometheus Cheatsheet OMNI52™ GmbH

Prometheus
auf einem Blatt.

Dichte Referenz für Senior Platform Engineers und SREs zum CNCF-Monitoring-Standard. Datenmodell und Cardinality, PromQL-Kern, Scrape-Config und Relabeling, Recording/Alerting Rules, Alertmanager, Remote-Write vs Federation, Thanos/Mimir, Prometheus Operator und Anti-Patterns. Keine Einsteiger-Folien.

Vorschau (2 Seiten A4 quer + Brand-Rückseite)

Prometheus Cheatsheet Seite 1: Datenmodell, PromQL, Scrape-Config, Rules
Prometheus Cheatsheet Seite 2: Alertmanager, Remote-Write, Thanos/Mimir, Operator, Anti-Patterns

PDF herunterladen

Direkter Download, keine Mail-Adresse nötig. CC BY-SA 4.0 , kopieren, drucken, weiterverteilen ist ausdrücklich erlaubt, solange die Quellenangabe sichtbar bleibt.

Prometheus Cheatsheet (PDF, ~100 KB)

Was drin steht

Datenmodell

Counter, Gauge, Histogram, Summary. Labels, Serien und Cardinality als Kostengröße. Native Histograms (stabil seit 3.8), Prometheus-3.x-Stand.

PromQL

rate vs irate, Aggregationen mit by/without, histogram_quantile für klassische und Native Histograms. Fehlerquote und p99 als Copy-Paste-Queries.

Scrape & Discovery

scrape_configs, kubernetes_sd_configs-Rollen, relabel_configs vs metric_relabel_configs, Relabel-Actions.

Rules & Alertmanager

Recording Rules (level:metric:operations), Alerting mit for/labels/annotations. Routing-Tree, Grouping-Timing, Inhibition, Silences.

Langzeit & HA

Remote-Write 2.0 vs Federation. Thanos (Sidecar, Query, Compactor) und Grafana Mimir eingeordnet. HA-Grundmuster mit Dedup downstream.

Operator & Anti-Patterns

ServiceMonitor, PodMonitor, PrometheusRule, ScrapeConfig. Cardinality-Anti-Patterns und PromQL-Fallen aus der Praxis.

Cheatsheet im Volltext

Derselbe Inhalt wie im PDF, zum Mitlesen, Durchsuchen und direkten Kopieren der YAML-Snippets. Stand: Prometheus v3.13 (Edition 2026.07).

Datenmodell

Metriktypen

Counter: monoton steigend, nur mit rate()/increase() auswerten. Gauge: frei beweglicher Momentanwert (Queue-Länge, Memory).

Histogram: kumulative le-Buckets + _sum/_count, serverseitig aggregierbar. Summary: client-seitig berechnete Quantile, nicht über Instanzen aggregierbar.

Labels, Serien, Cardinality

Jede eindeutige Label-Kombination erzeugt eine eigene Zeitserie. Serienzahl wächst multiplikativ mit den Wertemengen der Labels, Cardinality ist die zentrale Kostengröße für RAM, Ingest und Query-Latenz. Labels nur für Dimensionen mit kleiner, stabiler Wertemenge.

Native Histograms (stabil seit 3.8)

Exponentielle Buckets mit hoher Auflösung in einer Serie statt Dutzender le-Serien. Scraping explizit aktivieren: scrape_native_histograms: true (global oder pro Job, Protobuf-Scrape-Format). Das alte Feature-Flag native-histograms ist seit 3.9 wirkungslos.

Prometheus 3.x

UTF-8 in Metrik-/Label-Namen (Rückfall: metric_name_validation_scheme: legacy). OTLP-Receiver: --web.enable-otlp-receiver.

Agent-Mode: --agent, nur Scrape + WAL + Remote-Write, kein Querying/Alerting/lokale TSDB. Defaults: scrape_interval 1m, scrape_timeout 10s, TSDB-Retention 15d.

# Cardinality inspizieren
curl -s localhost:9090/api/v1/status/tsdb | jq .
# Top-10 Metriken nach Serienzahl (PromQL)
topk(10, count by (__name__)({__name__=~".+"}))

PromQL-Kern

rate vs irate

rate(v[5m]): per-second-Durchschnitt übers Fenster, extrapoliert an die Fensterränder, Counter-Resets werden korrigiert, Standard für Alerts und Dashboards.

irate(v[5m]): Momentanrate aus den letzten zwei Samples, reagiert schnell, verschluckt alles dazwischen. Nie für Alerts. Fenster immer groß genug für mehrere Samples wählen.

Aggregationen

sum, avg, min, max, count, topk, quantile, Dimensionen steuern mit by (labels) (behalten) oder without (labels) (entfernen). Regel: erst rate() pro Serie, dann sum(), nie umgekehrt.

histogram_quantile

histogram_quantile(0.99, ...) berechnet das φ-Quantil aus klassischen le-Buckets (vorher rate() auf _bucket, by (le) behalten!) oder direkt aus Native Histograms. Ergebnis ist eine Schätzung (Interpolation innerhalb des Buckets).

# Fehlerquote pro Service (5m-Fenster)
sum by (service)
  (rate(http_requests_total{code=~"5.."}[5m]))
/ sum by (service)
  (rate(http_requests_total[5m]))

# p99 aus klassischem Histogram
histogram_quantile(0.99, sum by (le)
  (rate(http_request_duration_seconds_bucket[5m])))

# p99 aus Native Histogram (keine _bucket-Serien)
histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds[5m])))

Scrape-Config & Service Discovery

scrape_configs

Pro job_name entweder static_configs oder eine *_sd_configs-Discovery. Kubernetes-Rollen (kubernetes_sd_configs): endpoints, endpointslice, service, pod, node, ingress. Discovery liefert __meta_*-Labels als Rohmaterial fürs Relabeling.

relabel vs metric_relabel

relabel_configs: vor dem Scrape, auf Target-Ebene, Targets filtern (keep/drop), Adresse/Pfad setzen, __meta_* in echte Labels überführen.

metric_relabel_configs: nach dem Scrape, auf jede Serie, letzte Verteidigungslinie gegen Cardinality. Actions: replace, keep, drop, labelmap, hashmod, labeldrop, labelkeep.

scrape_configs:
- job_name: kubernetes-pods
  kubernetes_sd_configs:
  - role: pod
  relabel_configs:
  - source_labels:
    - __meta_kubernetes_pod_annotation_prometheus_io_scrape
    action: keep
    regex: "true"
  - source_labels: [__meta_kubernetes_pod_name]
    action: replace
    target_label: pod
  metric_relabel_configs:
  - source_labels: [__name__]
    action: drop
    regex: go_gc_.*

Recording & Alerting Rules

Recording Rules

Teure Ausdrücke vorberechnen, Dashboards/Alerts lesen die fertige Serie. Naming-Konvention: level:metric:operations, z.B. job:http_requests:rate5m. Auswertung pro Rule-Group sequenziell, Takt evaluation_interval (Default 1m).

Alerting Rules

expr + for: Alert ist erst pending, nach Ablauf von for firing , entprellt Flapping. labels (z.B. severity) steuern das Routing im Alertmanager, annotations sind für Menschen (summary, Runbook-Link).

groups:
- name: api.rules
  rules:
  - record: job:http_requests:rate5m
    expr: sum by (job) (rate(http_requests_total[5m]))
  - alert: HighErrorRate
    expr: |
      sum by (job)
        (rate(http_requests_total{code=~"5.."}[5m]))
      / sum by (job)
        (rate(http_requests_total[5m])) > 0.05
    for: 10m
    labels: {severity: page}
    annotations:
      summary: >-
        Fehlerquote ueber 5% in {{ $labels.job }}

Alertmanager

Routing-Tree

Ein Wurzel-route-Block, Kinder matchen per matchers. Erster Match gewinnt (ausser continue: true). Die Root-Route muss alles matchen (keine Matchers), sie ist der Default-Receiver.

Grouping, Timing

group_by bündelt Alerts zu einer Notification. group_wait (Default 30s): Wartezeit vor der ersten Notification einer neuen Gruppe. group_interval (5m): Takt für Updates der Gruppe. repeat_interval (4h): Wiederholung unveränderter Alerts, als Vielfaches von group_interval wählen.

Inhibition & Silences

inhibit_rules: unterdrücken abhängige Alerts (z.B. warning, solange dasselbe critical feuert), equal: verhindert Querschüsse zwischen Clustern.

Silences: ad hoc via UI/amtool, immer mit Ablaufzeit. Geplante Wartungsfenster: mute_time_intervals.

route:
  receiver: default
  group_by: [alertname, cluster]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
  - matchers: [severity="page"]
    receiver: oncall
inhibit_rules:
- source_matchers: [severity="critical"]
  target_matchers: [severity="warning"]
  equal: [alertname, cluster]

Remote-Write vs Federation

Remote-Write

Streamt Samples (via write_relabel_configs gefiltert) an ein Langzeit-Backend. Remote-Write 2.0: protobuf_message: io.prometheus.write.v2.Request (Default bleibt prometheus.WriteRequest); Metadata-Versand braucht --enable-feature=metadata-wal-records. Receiver-Seite: --web.enable-remote-write-receiver.

Federation

/federate-Endpoint, Auswahl per match[]-Selektoren. Gedacht für aggregierte Serien (hierarchisch) oder gezielte Cross-Service-Metriken, kein Voll-Replikat und kein Langzeit-Backup. Für Langzeit/HA: Remote-Write.

remote_write:
- url: https://metrics.example.com/api/v1/push
  protobuf_message: io.prometheus.write.v2.Request
  write_relabel_configs:
  - source_labels: [__name__]
    action: drop
    regex: go_.*

Langzeit & HA: Thanos / Mimir

Thanos (CNCF Incubating)

Sidecar neben jedem Prometheus lädt TSDB-Blöcke in Object Storage; Query liefert die globale Sicht und dedupliziert HA-Paare; Store Gateway liest alte Blöcke, Compactor verdichtet und downsampled, Receive nimmt Remote-Write an. Prometheus bleibt die Scrape-Quelle.

Grafana Mimir (AGPLv3)

Horizontal skalierbarer, nativ multi-tenanter Langzeit-Store; Ingest ausschließlich via Remote-Write, Ablage in Object Storage (S3/GCS/Azure). Projektangabe: bis zu 1 Mrd. aktive Serien. Wahl: Thanos hält Prometheus im Zentrum, Mimir zentralisiert.

HA-Grundmuster

Zwei identische Prometheus-Replicas scrapen dieselben Targets; Deduplizierung passiert downstream (Thanos Query, Mimir-HA-Dedup). Beide Replicas melden an denselben Alertmanager-Cluster, der dedupliziert Notifications.

Prometheus Operator

CRDs statt Config-Files

ServiceMonitor (Services), PodMonitor (Pods), Probe (Blackbox/Ingress), ScrapeConfig (Targets ausserhalb des Clusters), PrometheusRule (Recording/Alerting), AlertmanagerConfig (Routing-Teilbäume). Der Operator generiert daraus die laufende Prometheus-Konfiguration; die Prometheus-CR wählt CRs per Label-Selektor aus.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api
  labels: {team: platform}
spec:
  selector:
    matchLabels: {app: api}
  endpoints:
  - port: http-metrics
    interval: 30s
    path: /metrics

Stolperfallen

port im ServiceMonitor ist der Port-Name des Service, nicht die Nummer. CR wird nicht gescraped? Label-Selektor der Prometheus-CR prüfen , nicht selektierte CRs werden still ignoriert.

Anti-Patterns

Was du nicht tun solltest

Unbounded Labels: user_id, request_id, volle URLs als Label-Wert, Cardinality-Explosion bis zum OOM. IDs gehören in Logs/Traces, nicht in Labels.

irate() in Alerts: sieht nur die letzten zwei Samples, kurze Spikes und Lücken kippen den Alert. rate() nehmen.

sum() vor rate(): Counter-Resets einzelner Targets gehen als Sprünge in die Summe ein, immer erst rate(), dann sum().

Summary-Quantile mitteln: avg() über client-seitige Quantile ist statistisch bedeutungslos , Histogram + histogram_quantile.

Federation als Backup: /federate repliziert keine Historie und skaliert nicht für alles , Langzeit via Remote-Write.

Ein globaler Mega-Prometheus: pro Cluster/Zone scrapen, globale Sicht über Thanos/Mimir, nicht über ein einzelnes, vertikal gemästetes Prometheus.

Aus der OMNI52 Cheatsheet-Fabrik

Verwandte Sheets in dichter Senior-Qualität:
kubernetes-cheatsheet.de, Kubernetes Core
istio-cheatsheet.de, Istio (Mesh-Telemetrie)
cilium-cheatsheet.de, Cilium/Hubble
rke2-cheatsheet.de, RKE2 (rancher-monitoring)

Lizenz & Weiterverteilung

CC BY-SA 4.0. Du darfst dieses Cheatsheet kopieren, weiterverteilen, ausdrucken und in eigenen Materialien zitieren. Bedingung: Quellenangabe „Prometheus Cheatsheet, OMNI52 GmbH, prometheus-cheatsheet.de“ bleibt sichtbar, und abgeleitete Werke stehen unter der gleichen Lizenz (Share-Alike).

Nicht erlaubt: Logo, Marken oder den Eindruck zu vermitteln, dass der Inhalt von dir/euch stammt oder dass OMNI52 GmbH die Weiterverwendung sponsort.

Volltext der Lizenz: creativecommons.org/licenses/by-sa/4.0/deed.de.

Prometheus is a trademark of The Linux Foundation. Kubernetes is a registered trademark of The Linux Foundation. Other names (Thanos, Grafana Mimir) are trademarks of their respective owners and are used in a nominative / descriptive sense. OMNI52™ is a trademark of OMNI52 GmbH (filed, not yet registered). This website is operated by OMNI52 GmbH and is not affiliated with, endorsed by, or sponsored by The Linux Foundation, the CNCF, or the Prometheus project. “Prometheus” is used in a nominative / descriptive sense to indicate the technology this cheatsheet documents.