PromQL systematisch einsetzen

PromQL systematisch einsetzen

0:00 Jetzt lernen wir, die Daten zu befragen. PromQL hat einen Ruf als eigenwillige Sprache, und der ist teilweise verdient — aber die wirklich wichtigen Regeln lassen sich an einer Hand abzählen. Eine davon möchte ich gleich an den Anfang stellen, weil sie der häufigste Fehler überhaupt ist: erst die Rate, dann die Summe. Umgekehrt sieht das Ergebnis nur plausibel aus.

0:21 Wir arbeiten uns von den Datentypen über die Raten bis zu den Verknüpfungen vor, und am Ende stehen drei Abfragen, die den Rest des Seminars tragen.

PromQL systematisch einsetzen

0:30 Drei Kapitel. Zuerst die Datentypen und Selektoren — vier Typen, von denen zwei im Alltag zählen. Dann Raten und Quoten, also die Verwandlung eines stumpfen Zählwerts in eine Aussage. Und zuletzt das Verknüpfen mehrerer Zeitreihen, inklusive der Frage, warum eine Abfrage leer bleibt. In der Übung bauen Sie die drei Abfragen, aus denen später Dashboard und Alarme entstehen.

Datentypen und Selektoren

0:54 Fangen wir mit dem Fundament an. PromQL kennt vier Ausdruckstypen, und wer sie unterscheiden kann, versteht die meisten Fehlermeldungen der Sprache auf Anhieb — denn fast jede lautet sinngemäß: Hier wurde der falsche Typ übergeben. Dazu kommen die Selektoren, mit denen Sie aus Tausenden Zeitreihen die wenigen herausgreifen, die Ihre Frage beantworten. Beides zusammen ist die halbe Miete.

1:17 Vier Typen: Der Instant Vector liefert je Zeitreihe einen Messwert zum selben Zeitpunkt. Der Range Vector liefert je Zeitreihe eine Reihe von Messwerten über einen Zeitraum. Ein Scalar ist eine einzelne Zahl. Und String bleibt derzeit ungenutzt, den können Sie vergessen. Die praktisch wichtige Unterscheidung ist die zwischen den ersten beiden: Funktionen wie rate brauchen einen Range Vector, weil sie eine Veränderung berechnen — dafür braucht man mindestens zwei Messpunkte.

1:44 Ein Instant Vector allein hat keine Veränderung. Vier Operatoren zum Filtern. Gleich und ungleich sind selbsterklärend. Die beiden Varianten mit regulären Ausdrücken verdienen den Hinweis in der Fußzeile: Sie sind vollständig verankert. Das heißt, der Ausdruck muss auf den ganzen Wert passen, nicht auf einen Teil davon. Wer aus anderen Sprachen kommt, erwartet oft das Gegenteil und wundert sich über leere Ergebnisse.

2:09 Wenn Sie also nach allem suchen, was mit einem Präfix beginnt, brauchen Sie ausdrücklich einen Ausdruck, der den Rest mit abdeckt. Zwei Zeilen, die den Unterschied aus der Definition greifbar machen. Oben ein Selektor: Er liefert den aktuellen Wert je Zeitreihe. Unten derselbe Selektor mit einer Zeitangabe in eckigen Klammern — und plötzlich ist es ein Range Vector mit allen Messpunkten der letzten fünf Minuten.

2:34 Mehr ist an der Syntax nicht dran. Die Zeiteinheiten reichen von Millisekunden bis Jahre und lassen sich kombinieren. Und die Fußzeile erwähnt den Zusatz für Zeitverschiebungen — damit vergleichen Sie den aktuellen Verlauf mit dem der Vorwoche, was bei wochentagsabhängigen Lasten sehr nützlich ist. Der erste Punkt ist der Typfehler, über den wir gesprochen haben — und er ist harmlos, weil Prometheus ihn meldet.

2:58 Der zweite ist gefährlicher: der reguläre Ausdruck, der als Teiltreffer gedacht war und stillschweigend nichts findet. Der dritte ist ein Klassiker mit Lücken im Diagramm — das Zeitfenster ist kürzer als zwei Abfrageintervalle, und dann hat rate zu wenig Punkte. Faustregel: mindestens das Vierfache des Abfrageintervalls. Und der vierte ist banal und häufig: Es wird auf einem Label gefiltert, das die Metrik gar nicht trägt.

3:24 Das Ergebnis ist leer, ohne Fehlermeldung.

Raten, Quoten und Vergleiche

3:27 Jetzt zum eigentlichen Handwerk. Ein Counter für sich ist wenig aussagekräftig — er sagt Ihnen, wie oft etwas seit dem Start passiert ist, und das interessiert niemanden. Interessant ist die Veränderung. Genau dafür gibt es eine kleine Familie von Funktionen, und man sollte wissen, welche wann passt. Ein Counter wächst monoton; interessant ist seine Veränderung.

3:49 Drei Funktionen liefern sie: rate berechnet die durchschnittliche Zunahme pro Sekunde über ein Zeitfenster, increase die Zunahme im gesamten Fenster, irate nur aus den beiden letzten Punkten. Für Dashboards und Alarme nehmen Sie fast immer rate — es ist geglättet und damit stabil. Aggregiert wird mit den üblichen Verdächtigen, gruppiert mit by oder without.

4:10 Der Unterschied dieser beiden ist praktisch: by sagt, was bleibt, without sagt, was wegfällt. Zwei Abfragen, und die zweite ist das Muster, das Sie in jedem Projekt wiedersehen werden: eine Quote als Division zweier Raten. Oben die Anfragerate je Dienst. Unten die Fehlerquote — Fehler geteilt durch alle, beide Male dieselbe Gruppierung. Auf dieses „beide Male dieselbe Gruppierung" kommt es an; die Fußzeile sagt es ausdrücklich.

4:37 Weichen Zähler und Nenner in der Gruppierung ab, finden die Zeitreihen nicht zusammen, und Sie bekommen ein leeres Ergebnis statt einer Fehlermeldung. Beachten Sie außerdem, dass rate in beiden Fällen innerhalb der Summe steht. Und hier ist die Begründung für diese Regel — sie ist erstaunlich elegant. Die Funktion rate erkennt, wenn ein Zähler auf null zurückspringt, weil ein Prozess neu gestartet ist, und gleicht das aus. Sie kann das, weil sie die einzelne Zeitreihe sieht.

5:06 Summieren Sie vorher über alle Instanzen, ist die einzelne Zeitreihe weg — und der Neustart einer Instanz sieht aus wie ein plötzlicher Einbruch der Gesamtsumme. Das Ergebnis bleibt plausibel und ist falsch. Deshalb gilt ausnahmslos: erst rate, dann sum. Der erste Punkt ist genau dieser Fehler in freier Wildbahn — und Sie werden ihn in fremden Dashboards finden, wenn Sie darauf achten.

5:29 Der zweite ist eine Verwechslung mit optischer Folge: irate in Dashboards liefert sprunghafte Kurven, weil es nur die letzten beiden Punkte ansieht. Der dritte ist das zu kurze Fenster von eben. Und der vierte ist ein Auswertungsfehler: Die Quote wird ohne Gruppierung berechnet und mischt alle Dienste zu einer Zahl, die keinem Dienst gehört.

Verknüpfen und prüfen

5:48 Im letzten Kapitel geht es um die Frage, die Sie in der Praxis am häufigsten beschäftigen wird: Warum ist meine Abfrage leer? Die Antwort liegt fast nie in den Daten — sie liegt in den Labels. Wer das weiß, sucht an der richtigen Stelle und ist in zwei Minuten fertig statt in einer halben Stunde. Dazu sehen wir uns an, wie PromQL zwei Zeitreihen überhaupt zueinander findet.

6:11 Werden zwei Instant Vectors verrechnet, paart PromQL sie über ihre Labelmengen. Nur Zeitreihen mit übereinstimmenden Labels finden zusammen; alles andere bleibt ohne Partner und fällt aus dem Ergebnis. Das ist wie ein Reißverschluss: Er schließt nur dort, wo auf beiden Seiten Zähne sind. Hat eine Seite ein Label mehr, passt nichts mehr zusammen.

6:31 Subqueries sind der zweite Begriff hier — sie werten einen Instant-Ausdruck über einen Zeitraum aus und sind mächtig und teuer in etwa gleichem Maß. Zwei Zeilen, die dasselbe zu tun scheinen und es nicht tun. Oben die richtige Variante: rate innerhalb, sum außen. Unten die falsche, die erst summiert und dann über eine Subquery eine Rate bildet. Die Fußzeile enthält den eigentlichen Punkt: Die falsche Variante ist syntaktisch gültig.

6:57 Prometheus beschwert sich nicht, das Diagramm sieht aus wie erwartet, und erst beim nächsten Neustart einer Instanz erscheint ein Einbruch, den niemand erklären kann. Genau deshalb überlebt dieser Fehler so lange in Dashboards. Vier typische Ursachen, und die ersten beiden decken die meisten Fälle ab: Eine Seite trägt ein Label, das die andere nicht kennt, oder die Gruppierungen unterscheiden sich.

7:21 Der dritte Punkt ist speziell und begegnet Ihnen in OpenTelemetry-Umgebungen — ein Join über die Metrik mit den Zielinformationen aus Modul elf braucht ausdrückliches Vektor-Matching. Und der vierte ist ein Betriebsthema: Abfragen über sehr viele Zeitreihen werden langsam und belasten den Server. Dafür gibt es Recording Rules, die wir in Modul siebzehn behandeln.

7:42 Der erste Punkt kostet die meiste Zeit: Das Ergebnis ist leer, und man sucht die Ursache in den Daten statt in den Labels. Sehen Sie sich beide Seiten einzeln an, dann sehen Sie den Unterschied sofort. Der zweite ist ein Betriebsrisiko — eine Subquery mit feiner Auflösung über mehrere Tage kann einen Prometheus-Server blockieren.

8:01 Der dritte ist verwandt: Abfragen im Dashboard ohne Begrenzung über alle Instanzen. Und der vierte ist der Vorgriff auf Modul siebzehn — regelmäßig gebrauchte teure Abfragen gehören vorberechnet.

Übung

8:13 In der Übung schreiben Sie drei Abfragen, die uns bis zum Ende des Seminars begleiten — sie werden in Modul sechzehn zu Panels und in Modul siebzehn zu Alarmregeln. Und Sie führen ein kleines Experiment durch, das den Unterschied zwischen richtig und bloß plausibel sichtbar macht. Genau dieser Unterschied ist der Grund, warum dieses Modul mehr ist als eine Syntaxeinführung.

8:34 Drei Abfragen: Anfragerate je Dienst, Fehlerquote in Prozent, Dauer nach Filiale gruppiert. Und zusätzlich die Erklärung, worin sich die beiden Fehlerquoten-Varianten unterscheiden. Der Hinweis erklärt, warum sich Sorgfalt lohnt: Diese Abfragen werden in Modul sechzehn zum Dashboard und in Modul siebzehn zur Alarmregel. Eine schludrige Abfrage vervielfältigt sich also — sie landet in einem Panel, in einer Recording Rule und in einem Alarm, und dann korrigieren Sie an drei Stellen.

9:03 Der rote Faden führt von der einfachen zur zusammengesetzten Abfrage und endet bei einem Experiment. Erst die Rate, dann die Quote mit gleicher Gruppierung, dann die Gruppierung nach Filiale. Im vierten Schritt bauen Sie bewusst die falsche Variante — ja, absichtlich. Und im fünften starten Sie einen Dienst neu und vergleichen beide Ergebnisse.

9:23 Die Fußzeile sagt, warum das der eigentliche Kern ist: Der Neustart macht den Unterschied sichtbar, den die Theorie nur behauptet. Was man einmal gesehen hat, vergisst man nicht mehr. Der erste Punkt ist genau der Grund für den Neustart im Vorgehen: Im Ruhezustand sehen beide Varianten gleich aus. Der zweite ist eine Kleinigkeit mit Verwirrungspotenzial — die Quote wird in Prozent erwartet, liefert aber einen Anteil zwischen null und eins; entweder multiplizieren Sie, oder Sie stellen die Einheit im Panel entsprechend ein.

9:54 Der dritte ist ein Datenproblem: Nach Filiale wird gruppiert, obwohl das Label nicht an der Metrik hängt — dann fehlt etwas in Modul sechs oder elf. Und der vierte ist ein Arbeitsweise-Thema: Geklickte Abfragen sind später nicht auffindbar. Schreiben Sie sie auf.