Die meisten Fehler in PromQL melden sich sofort: falscher Typ, unbekannte Funktion, ein Label, das die Metrik nicht trägt. Einer meldet sich nie — und steht deshalb in vielen Dashboards.
Zwei Funktionen, zwei Reihenfolgen
Du willst die Anfragerate über alle Instanzen eines Dienstes: rate rechnet aus
einem Range Vector die Änderung pro Sekunde, sum addiert die Zeitreihen.
Beide Reihenfolgen sind syntaktisch gültig, nur eine ist richtig — rate muss
innen stehen. Der Grund ist unspektakulär: Ein Counter wird bei
jedem Neustart des Prozesses auf null gesetzt, und rate erkennt diesen Sprung
und gleicht ihn aus. Wer vorher summiert, wirft alle Instanzen in eine Kurve —
und der Neustart einer einzigen sieht darin aus wie ein Einbruch der Last.
Warum niemand es bemerkt
Das Ergebnis ist nicht kaputt: richtige Größenordnung, richtige Form, das Panel zeigt etwas an. Der Unterschied wird erst sichtbar, wenn ein Pod neu startet — also genau dann, wenn ohnehin etwas los ist und man der Kurve glaubt.
Zwei Verwandte desselben Musters:
- Die Quote ohne
bymischt alle Dienste in einen Wert. - Zähler und Nenner mit unterschiedlicher Gruppierung ergeben ein leeres Ergebnis — und die Ursache wird dann in den Daten gesucht statt in den Labels.
Abfragen schreiben statt klicken
Abfragen, auf die du dich verlässt, gehören geschrieben und versioniert, nicht zusammengeklickt. Eine Recording Rule rechnet sie einmal je Intervall — und sorgt nebenbei dafür, dass Alarm und Dashboard dieselbe Zahl meinen.
Mehr dazu im Seminar
Wie du PromQL systematisch aufbaust — von den vier Datentypen über Label Matcher bis zu den Abfragen, die man wirklich braucht — zeigt das Modul PromQL systematisch einsetzen aus dem Seminar Observability mit OpenTelemetry, Prometheus und Grafana — mit Video und Kapitelübersicht. Kompakt zum Nachschlagen: das Cheat Sheet.