Die PromQL-Abfrage, die plausibel aussieht und falsch ist

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 by mischt 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.

← Alle Beiträge