Prometheus: Metriken sammeln und Alerts auslösen

Prometheus ist ein quelloffenes Monitoring-System, das 2012 bei SoundCloud entwickelt und 2016 als zweites Projekt überhaupt von der Cloud Native Computing Foundation (CNCF) aufgenommen wurde. Es sammelt kontinuierlich Metriken von Diensten und Servern, speichert sie als Zeitreihen und kann bei kritischen Werten automatisch Alarme auslösen. Zusammen mit Grafana als Dashboard ist es der De-facto-Standard im Kubernetes-Umfeld.

Pull statt Push: das Besondere an Prometheus

Die meisten klassischen Monitoring-Systeme erwarten, dass die überwachten Systeme ihre Daten aktiv einschicken (Push-Prinzip). Prometheus dreht das um: Der Prometheus-Server holt sich die Metriken selbst in regelmäßigen Abständen von den Zielsystemen (Pull-Prinzip). Jedes Ziel stellt dafür unter /metrics einen HTTP-Endpunkt bereit, der die Messwerte im Textformat ausliefert:

http_requests_total{method="get",status="200"} 54231
http_requests_total{method="post",status="500"} 7

Jede Messreihe heißt Zeitreihe und wird durch ihren Namen plus Labels (Schlüssel-Wert-Paare) eindeutig identifiziert. Die Labels sind das Herzstück: Damit lassen sich Metriken nach Server, Dienst, Endpunkt oder Fehlercode filtern und gruppieren.

Exporter: Metriken für alles

Systeme, die selbst kein /metrics anbieten, werden über kleine Helferprogramme angebunden, die Exporter heißen. Der bekannteste ist node_exporter für Linux-System-Metriken (CPU, RAM, Festplatte, Netzwerk). Für Datenbanken, Webserver und Fast jede Software gibt es fertige Exporter.

PromQL, Alertmanager und Grafana

  • PromQL ist die Abfragesprache von Prometheus. Damit starten Anfragen wie „Wie hoch war die CPU-Last der letzten 5 Minuten?" direkt aus der Weboberfläche oder aus Dashboards.
  • Der Alertmanager nimmt Warnungen entgegen, gruppiert ähnliche Alerts, unterdrückt Wiederholungen und leitet sie an E-Mail, Slack oder PagerDuty weiter.
  • Grafana ist das typische Dashboard-Frontend: Es liest die Zeitreihen per PromQL und visualisiert sie in Diagrammen — Prometheus selbst bringt nur eine einfache, für den Betrieb meist ausreichende Oberfläche mit.

Service Discovery: Ziele automatisch finden

Statt Zieladressen von Hand zu pflegen, entdeckt Prometheus seine Ziele automatisch. In Kubernetes beobachtet es die API: Startet ein neuer Pod mit passenden Labels, wird er automatisch überwacht; verschwindet er, fällt er aus dem Monitoring — ganz ohne Konfigurationsarbeit. Auch Konsul, DNS und Cloud-APIs werden als Quellen unterstützt.

Monitoring-Denken: USE und die vier goldenen Signale

Für Infrastruktur bewährt sich die USE-Methode: Utilization (Auslastung), Saturation (Überlastung), Errors (Fehler). Für Dienste gelten Googles vier goldene Signale aus der SRE-Praxis: Latenz, Traffic, Fehlerquote und Sättigung. Wer diese Werte systematisch erfasst, erkennt Engpässe und Verschlechterungen, bevor Nutzer sie spüren — das ist der Kern von Observability.

Praxis-Tipps

  • Metriken über den /metrics-Endpunkt mit klaren Namen und wenigen, sorgfältig gewählten Labels versehen — zu viele Labels erzeugen explodierende Zeitreihenmengen.
  • Alerts erst einrichten, wenn ein Schwellwert wirklich eine Aktion erfordert; jede Warnung, die niemand braucht, zermürbt im Incident Management.
  • Metrikdaten nur kurze Zeit lokal speichern und Langzeitarchive an ein separates System auslagern.
  • Prometheus überwacht die Dienste, Logging (z. B. über syslog) beantwortet die Frage nach dem „Warum" — beide ergänzen sich und ersetzen einander nicht.
  • Die mit Terraform provisionierte Infrastruktur von Anfang an an Prometheus anbinden.

Verwandte Grundlagen: Monitoring und Telemetrie.