Alerting und Recording Rules

Alerting und Recording Rules

0:00 Alarmierung ist der Punkt, an dem Observability die Menschen erreicht — meistens nachts. Und genau deshalb ist sie der Bereich, in dem Schaden am leichtesten entsteht. Ein Alarm, der niemanden zum Handeln bringt, ist kein Alarm. Er ist eine Gewohnheit, und Gewohnheiten werden irgendwann ignoriert. Wir schauen uns deshalb nicht nur an, wie man Regeln schreibt, sondern vor allem, worauf man alarmieren sollte und worauf besser nicht.

0:25 Die Antwort der Prometheus-Leute ist dabei angenehm klar.

Alerting und Recording Rules

0:29 Drei Kapitel. Zuerst die Regeln selbst — Recording Rules zum Vorberechnen und Alerting Rules zum Auslösen, beide in derselben Syntax. Dann die Zustellung: Wer bekommt wann welche Meldung, und wie verhindert man Lawinen? Und drittens die inhaltliche Frage, die über die Qualität entscheidet: Symptom oder Ursache? In der Übung bauen Sie einen Alarm und lösen ihn tatsächlich aus.

Regeln definieren

0:54 Fangen wir mit den beiden Regelarten an. Sie sehen fast gleich aus und tun sehr verschiedene Dinge: Die eine speichert ein Ergebnis für später, die andere schlägt Alarm. Beide leben in derselben Datei und in derselben Syntax, und beide haben denselben unterschätzten Vorteil — sie sind Text und damit prüfbar, versionierbar und im Fehlerfall nachvollziehbar.

1:14 Eine Recording Rule berechnet einen Ausdruck regelmäßig vor und speichert das Ergebnis unter einem neuen Metriknamen. Eine Alerting Rule wertet einen Ausdruck aus und löst aus, sobald er Ergebnisse liefert. Dieser letzte Halbsatz ist eine Feinheit, die man verstehen muss: Ein Alarm feuert nicht, wenn eine Bedingung wahr ist — er feuert, wenn die Abfrage Zeitreihen zurückgibt.

1:36 Ein Vergleich, der nichts trifft, liefert ein leeres Ergebnis, und das heißt: alles ruhig. Beide Regelarten stehen in Gruppen mit Namen und Auswertungsintervall. Zwei Regeln, die aufeinander aufbauen, und das ist das eigentliche Muster. Oben wird die Fehlerquote aus Modul dreizehn unter einem neuen Namen vorberechnet. Unten greift der Alarm auf genau diese vorberechnete Reihe zu — nicht auf die ursprüngliche Abfrage. Damit rechnen Dashboard und Alarm garantiert dasselbe.

2:05 Beachten Sie außerdem den Namen der Recording Rule: Das Schema aus Ebene, Metrik und Operation ist Konvention und hilft enorm beim Lesen fremder Regelwerke — man sieht dem Namen an, dass es sich um eine vorberechnete Größe handelt. Der erste Punkt ist der offensichtliche: Teure Abfragen laufen einmal je Intervall statt bei jedem Dashboard-Aufruf.

2:25 Der zweite ist der eigentlich wichtige — Alarm und Dashboard rechnen garantiert dasselbe, weil beide dieselbe Reihe lesen. Widersprüche zwischen Alarm und Dashboard sind sonst ein häufiger und sehr zermürbender Zustand. Der dritte folgt daraus: Eine Änderung an der Definition wirkt an einer Stelle. Und der vierte ist ein Lesbarkeitsgewinn — ein guter Name macht die Absicht der Abfrage sichtbar, auch für Leute, die PromQL nicht fließend lesen.

2:51 Der erste Punkt ist genau der Widerspruch von eben, und er untergräbt das Vertrauen in beide Systeme. Der zweite ist ein Auflösungsproblem: Die Recording Rule läuft seltener, als das Dashboard aktualisiert — dann sehen Sie eine Treppe statt einer Kurve. Der dritte ist Benennung: Der Name verrät nicht, was vorberechnet wurde, und niemand traut sich, die Regel zu ändern.

3:13 Und der vierte ist der Zeitpunkt — teure Abfragen bleiben unberechnet, bis der Server unter ihnen zusammenbricht. Dann ist die Einführung hektisch statt geplant.

Zustellung steuern

3:23 Jetzt zur Frage, wie aus einer ausgelösten Regel eine sinnvolle Meldung bei einem Menschen wird. Zwischen beidem liegt mehr, als man vermutet. Hier sitzen nämlich die Stellschrauben gegen die beiden großen Übel der Alarmierung: das Flattern, bei dem ein Alarm im Minutentakt kommt und geht, und die Lawine, bei der ein einziges Problem vierzig Meldungen erzeugt.

3:43 Zwei Zeitangaben und zwei Werkzeuge. Die Angabe für die Haltedauer verlangt, dass die Bedingung eine Zeit lang anhält, bevor ausgelöst wird — das filtert Ausreißer. Die zweite hält den Alarm noch eine Weile aktiv, nachdem die Bedingung entfallen ist; das verhindert Flattern, wenn ein Wert um den Schwellwert pendelt. Labels tragen die Einordnung, Annotations den erklärenden Text. Und der Alertmanager gruppiert, leitet weiter und unterdrückt — er ist die Poststelle zwischen Regel und Mensch.

4:14 Die Logik dieser Tabelle ist: Jede Stellschraube wirkt gegen ein bestimmtes Übel. Die Haltedauer gegen kurze Ausschläge. Die Gruppierung gegen Lawinen — bei Pfandwerk heißt das, vierzig betroffene Filialen erzeugen eine Meldung und nicht vierzig. Die Unterdrückung gegen Folgealarme: Wenn das Netz ausgefallen ist, braucht niemand zusätzlich die Meldungen aller davon abhängigen Dienste.

4:36 Und die Wiederholung gegen das Vergessen — ein Alarm, der einmal zugestellt und dann übersehen wurde, meldet sich wieder. Hier steht eine Architekturentscheidung, die man bewusst treffen sollte. Regeln in Prometheus laufen auch dann, wenn Grafana nicht erreichbar ist — das ist ein gewichtiges Argument, denn im Störfall fällt gern mehr aus als geplant.

4:57 Regeln in Grafana können dafür mehrere Datenquellen in einer Bedingung verbinden, etwa eine Metrik und ein Log. Der dritte Punkt ist die Warnung: Zwei parallele Wege führen zu doppelter Zustellung und widersprüchlichen Ständen. Entscheiden Sie sich, und schreiben Sie die Entscheidung auf. Der erste Punkt ist die Regel ohne Haltedauer, die bei jedem einzelnen Ausreißer auslöst — der schnellste Weg zur Alarmmüdigkeit.

5:21 Der zweite ist die doppelte Bedingung in beiden Systemen. Der dritte ist die fehlende Gruppierung mit dem Vierzig-Meldungen-Effekt. Und der vierte ist eine Gefahr, die aus einer guten Absicht entsteht: Die Unterdrückung wird so weit gefasst, dass echte Alarme verschwinden. Unterdrückungsregeln gehören deshalb genauso überprüft wie Alarmregeln — nur denkt kaum jemand daran.

Alarme, die handlungsfähig machen

5:44 Und jetzt zum inhaltlichen Kern dieses Moduls: Worauf alarmiert man eigentlich? Die Prometheus-Dokumentation hat dazu eine klare Haltung, die sich in zwei Worten zusammenfassen lässt — auf Symptome. Das klingt banal und widerspricht dem, was klassische Überwachungssysteme historisch getan haben, nämlich jede erdenkliche Ursache einzeln abzufangen.

6:04 Die Empfehlung lautet, auf Symptome zu alarmieren, die mit spürbarem Nachteil für Endnutzer verbunden sind, statt jede mögliche Ursache abzufangen. Ursachenbezogene Alarme bleiben die Ausnahme — für Fälle, die nach außen nicht sichtbar, aber schwerwiegend genug für einen Eingriff sind. Der Gedanke dahinter ist bestechend: Es gibt unendlich viele Ursachen und wenige Symptome. Wer alle Ursachen abdecken will, kommt nie an ein Ende.

6:30 Wer die Symptome abdeckt, merkt jeden Ausfall — auch den, an den niemand gedacht hat. Diese Gegenüberstellung macht es konkret. Links, alarmwürdig: Rücknahmen scheitern seit zehn Minuten. Auszahlung dauert über fünf Sekunden. Eine Filiale meldet nichts mehr. Rechts, nur fürs Dashboard: Heap-Auslastung bei achtzig Prozent. Verbindungspool zu siebzig Prozent belegt. Ein Pod-Neustart.

6:54 Der Unterschied ist nicht die Wichtigkeit — die rechten Werte sind für die Ursachensuche wertvoll. Der Unterschied ist, dass niemand nachts geweckt werden muss, weil ein Pool zu siebzig Prozent belegt ist, solange die Nutzer nichts merken. Die Dokumentation empfiehlt ausdrücklich so wenige Alarme wie möglich. Und sie gibt ein schönes Beispiel: Ist die Gesamtlatenz in Ordnung, ist ein langsamer Teil kein Grund zur Meldung.

7:21 Alarme sollen stattdessen auf die Konsolen verweisen, an denen sich die Ursache eingrenzen lässt — genau die Dashboards aus Modul sechzehn. Und der letzte Punkt ist der, der die Sache dringlich macht: Jeder Alarm ohne Handlung senkt die Aufmerksamkeit für die übrigen. Alarmmüdigkeit ist kein Charakterfehler der Bereitschaft, sondern eine vorhersehbare Reaktion.

7:42 Sie formulieren jetzt einen Alarm so, dass die Empfangenden ohne Rückfrage handeln können: betroffener Dienst, Ausmaß, Zeitpunkt, Runbook-Verweis, Zuständigkeit. Der Hinweis nennt einen Test, den ich Ihnen wirklich ans Herz lege — zeigen Sie den Alarmtext jemandem, der das System nicht kennt. Genau in dieser Lage ist nämlich die Person, die um drei Uhr nachts geweckt wird: müde, ohne Kontext, mit dem Handy in der Hand. Wenn der Text dann nicht trägt, trägt er nie.

8:10 Der erste Punkt ist der nichtssagende Alarm — eine Zahl ohne Einheit und ohne Dienst. Der zweite ist die Ursachenflut, in der die Symptome untergehen. Der dritte ist Pflege: Der Runbook-Verweis zeigt auf eine Seite, die es nicht mehr gibt; prüfen Sie solche Verweise automatisiert, das ist eine Zeile in Ihrer Bereitstellungskette.

8:29 Und der vierte ist der schleichendste — Alarme werden nie überprüft und lösen seit Monaten grundlos aus. Ab diesem Zeitpunkt filtert sie jeder, und das gilt dann auch für den einen, der wichtig gewesen wäre.

Übung

8:42 In der Übung bauen Sie die Kette einmal komplett: von der geprüften Abfrage über die Vorberechnung zum Alarm — und dann lösen Sie ihn tatsächlich aus. Dieser letzte Schritt ist der, der in der Praxis am häufigsten unterbleibt, weil er unbequem ist. Und er ist genau der, der die stillen Fehler aufdeckt: einen Tippfehler im Label, einen falschen Empfänger, eine nie erreichte Bedingung.

9:04 Vier Kriterien: Die Recording Rule liefert die Fehlerquote je Dienst, der Alarm löst erst nach anhaltender Störung aus, er trägt Runbook und Zuständigkeit, und die Zustellung ist einmal ausgelöst und geprüft worden. Der Hinweis ergänzt den Teil, an den kaum jemand denkt: Prüfen Sie auch den Weg zurück. Löst sich der Alarm auf, wenn die Störung endet?

9:24 Ein Alarm, der hängen bleibt, ist fast so schädlich wie einer, der nie kommt — beim nächsten Mal glaubt ihm niemand. Der rote Faden: erst die Vorberechnung, dann der Alarm auf die vorberechnete Reihe, dann die Begleitinformationen — Labels, Annotations, Runbook, Zuständigkeit. Und dann zweimal Praxis: Störung erzeugen und Zustellung prüfen, Störung beenden und Auflösung prüfen.

9:48 Die Fußzeile sagt es in einem Satz: Ein Alarm, der nie ausgelöst wurde, ist ungeprüft — unabhängig davon, wie richtig er aussieht. Ich habe schon Alarmregeln gesehen, die jahrelang standen und wegen eines Tippfehlers im Label nie jemanden erreicht hätten. Der erste Punkt ist genau dieser ungeprüfte Zustellweg. Der zweite ist eine Fehlkalibrierung der Haltedauer: So lang gewählt, dass die Störung vorbei ist, bevor gemeldet wird.

10:15 Der dritte ist ein Textproblem mit praktischer Folge — die Annotation beschreibt die Abfrage statt der Auswirkung. „Fehlerquote über Schwellwert" hilft niemandem; „Jede zwanzigste Rücknahme scheitert seit zehn Minuten" schon. Und der vierte ist die zu großzügige Nachhaltezeit, die den Alarm aktiv lässt, obwohl längst alles wieder läuft.