7.6 Alerting

Inhalt

Intro

Im vorherigen Kapitel haben wir einige PromQL Queries zusammengestellt. Nun möchten wir, dass einige dieser Queries von Prometheus in regelmässigen Abständen automatisch ausgeführt werden. Ziel ist es, Alarme auszulösen, wenn bestimmte Metriken einen definierten Grenzwert überschreiten.

Prometheus Konfiguration

Um dieses Verhalten zu erreichen, passen wir unsere Prometheus-Konfiguration folgendermassen an:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "prometheus"
    metrics_path: "/metrics"
    static_configs:
      - targets: ["localhost:9090"]

rule_files:
  - "rules.yml"

Zusätzlich erstellen wir im gleichen Verzeichnis wie die prometheus.yml Konfiguration die Datei rules.yml mit folgendem Inhalt:

1
2
3
4
5

groups:
  - name: example_rules
    rules:
      - alert: DemoAlert
        expr: sum(increase(prometheus_http_requests_total[30m])) > 30

Die Konfiguration der Alert Rules besteht aus zwei Teilen. Im ersten Teil definieren wir mit der Anweisung rule_files, in welchen Dateien wir die Rules definieren. Zusätzlich definieren wir in diesem Schritt die Option evaluation_interval. Diese bestimmt, in welchem Intervall Prometheus die Regeln auswertet. Anschliessend erstellen wir die Datei rules.yml und fügen eine Rule mit dem Namen DemoAlert und dem Query sum(increase(prometheus_http_requests_total[30m])) > 30 hinzu. Die Regeln werden gruppiert, wobei thematisch zusammengehörige Regeln in der Regel in derselben Gruppe definiert werden (z. B. alle Alerts einer bestimmten Applikation).

Speichere die Änderungen und starte Prometheus anschliessend neu, um die Änderungen anzuwenden.

Navigiere nun auf die Seite http://localhost:9090/alerts . In der Übersicht sollte die Regel für den Demoalert auftauchen. Der Alert sollte zu diesem Zeitpunkt noch in grün (Status Inactive) dargestellt werden.

Überlege dir, was genau wir mit diesem PromQL Ausdruck überwachen und wie du Prometheus dazu bringst, den Grenzwert zu überschreiten (ohne das Query anzupassen).

Alert rules

Wie du im Beispiel oben erkennen kannst, bestehen die Rules hauptsächlich aus einem PromQL Query. Sobald dieses Query ein Ergebnis zurückliefert, wird ein Alert ausgelöst. In den allermeisten Fällen ist es daher wichtig, einen Vergleichsoperator zu benutzen. In unserem Fall lautet dieser > 30. Ein Alert wird also nur ausgelöst, wenn der Teil vor dem Vergleichsoperator sum(increase(prometheus_http_requests_total[30m])) einen Wert von mehr als 30 ergibt.

for duration

Manchmal ist es wünschenswert, dass ein bestimmter Fehlerzustand über eine gewisse Zeit bestehen muss, bevor ein Alert ausgelöst wird. Nehmen wir als Beispiel folgendes Query:

sum by(status_code) (
  rate(prometheus_http_requests_total{status_code="500"}[5m])
) > 5

Wir berechnen damit, wie viele Requests pro Sekunde mit einem HTTP Status Code 500 beantwortet wurden. Wenn diese Rate mehr als 5 ist, lösen wir einen Alert aus. In der Alert Rule können wir mit dem for Keyword definieren, dass dieser Zustand über min. 10 Minuten bestehen muss, bevor ein Alert ausgelöst wird. Die entsprechende Alertrule sieht folgendermassen aus:

1
2
3
4
5
6

groups:
  - name: prometheus
    rules:
      - alert: HTTP500
        expr: sum by(status_code) (rate(prometheus_http_requests_total{status_code="500"}[5m])) > 5
        for: 10m

Alert states

Alerts besitzen in Prometheus immer einen der folgenden drei Zustände:

  • Inactive: Der PromQL Ausdruck dieser Rule liefert kein Ergebnis, es wurde somit kein Fehlerzustand erkannt.
  • Pending: Der PromQL Ausdruck dieser Rule liefert ein oder mehrere Ergebnisse, die definierte for duration ist aber noch nicht abgelaufen.
  • Firing: Der PromQL Ausdruck dieser Rule liefert ein oder mehrere Ergebnisse, die for duration ist abgelaufen oder es ist keine for duration definiert.

Labels und Annotations

Alertrules können optional mit zusätzlichen Labels und/oder Annotations versehen werden. Diese helfen dabei, die Alerts später an die richtigen Kanäle (E-Mail, Chat usw.) zu senden oder mit zusätzlichen Informationen (z. B. Links zu möglichen Lösungswegen) anzureichern. Labels und Annotations werden direkt in der Definition der Regeln ergänzt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

groups:
  - name: prometheus
    rules:
      - alert: HTTP500
        expr: sum by(status_code) (rate(prometheus_http_requests_total{status_code="500"}[5m])) > 5
        for: 10m
        labels:
          severity: critical
        annotations:
          runbook_url: https://letmegooglethat.com/?q=prometheus+alertrule+label+and+annotation

Es gibt keine strikte Regel, welche Informationen in Labels oder Annotations gehören. Grundsätzlich gilt:

  • Maschinell auswertbare Informationen gehören in Labels.
  • Informationen für den Benutzer (z. B. Hinweise oder Anleitungen) gehören in Annotations.

Zusätzlich zu den manuell definierten Labels werden alle Labels aus dem Ergebnis des PromQL Ausdrucks ebenfalls als Labels auf dem Alert übernommen. In unserem Query erhalten wir durch by(status_code) das Label status_code, das ebenfalls als Label im Alert gespeichert wird.

Templating

Sowohl Labels als auch Annotations können mit Templates versehen werden. Mit Templates können Labels aus der PromQL Expression oder auch das Resultat der Expression als Variablen innerhalb von Labels und Annotations verwendet werden:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

groups:
  - name: prometheus
    rules:
      - alert: HTTP500
        expr: sum by(status_code) (rate(prometheus_http_requests_total{status_code="500"}[5m])) > 5
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: high HTTP error rate
          description: |
            Prometheus error rate (http status {{ $labels.status_code }} )
            is at {{ $value }} requests per second            
          runbook_url: https://letmegooglethat.com/?q=prometheus+alertrule+label+and+annotation

Wie bereits erwähnt, sind Labels und Annotations optional. Die meisten Rules besitzen aber immer min. die Annotations summary und description. In der summary Annotation wird dabei eine kurze und prägnante Beschreibung des Fehlers hinterlegt (der Value von dieser Annotation enthält in der Regel keine Templatevariablen), während die description Details (z.B. welcher Threshold überschritten wurde oder welcher HTTP Statuscode oder welche Instanz betroffen ist) enthält.

Alertmanager

Es reicht meist nicht aus, den Zustand einer Alert Rule nur im Prometheus UI anzuzeigen. In der Regel müssen Alerts über geeignete Kommunikationskanäle (E-Mail, Chat usw.) weitergeleitet werden. Dafür gibt es im Prometheus-Ökosystem eine separate Komponente: den Alertmanager. Auf diesen werden wir im Rahmen dieser Labs jedoch nicht weiter eingehen.

Fazit

In diesem Lab haben wir gelernt, wie man Alerts in Prometheus definiert und konfiguriert. Wichtige Erkenntnisse sind:

  • Alerts werden mit PromQL Queries definiert und in Regeldateien gespeichert.
  • Die PromQL Queries in den Alert Rules enthalten meist Vergleichsoperatoren, um Grenzwerte zu definieren.
  • Alerts können mit einer for duration versehen werden.
  • Labels und Annotations helfen bei der Verwaltung und Weiterleitung von Alerts.
  • Alerts durchlaufen die Zustände Inactive, Pending und Firing.
  • Der Alertmanager ermöglicht die Weiterleitung von Alerts an verschiedene Kanäle.

Damit schliessen wir den Hauptteil dieser Labs ab. Im letzten Kapitel werden wir einige spezifische Eigenschaften und Verhaltensweisen von Prometheus genauer betrachten. Dabei tauchen wir tief in bestimmte Themen ein, die möglicherweise nicht sofort verständlich sind. Falls einige Inhalte unklar bleiben, kannst du dieses letzte Kapitel später erneut durchgehen – mit mehr Prometheus-Erfahrung werden diese Details oft leichter verständlich.

Zuletzt geändert March 11, 2025: fiy tpos (b06157f)