Prometheus-Counter sind nicht kaputt - aber sie brechen Teams das Genick, die sie wie Datadog behandeln
Es gibt eine ganz bestimmte Art von Frustration, die erst nach einer Migration auftaucht.
Sie wechseln von etwas wie Datadog zu Prometheus. Dashboards werden neu gebaut. Alerts werden neu geschrieben. Alles fühlt sich schlanker an, „offener", stärker unter Ihrer Kontrolle.
Und dann fangen die Counter an, Sie zu belügen.
Zumindest fühlt es sich so an.
Niederfrequente Counter verpassen Increments. Kurzlebige Series verschwinden aus den Summen. Erfolgsraten gehen über 30 Tage nicht ganz auf. Alerts feuern nicht, wenn sie sollten. Oder schlimmer – sie feuern zu spät.
Ein Team beschrieb es unverblümt: Counter waren seit dem Wechsel der größte Schmerzpunkt. Dinge, die vorher „einfach funktionierten", erfordern jetzt sorgfältiges Nachdenken. Und selbst wenn man glaubt, es richtig gemacht zu haben, bleibt ein ungutes Gefühl.
Ist Prometheus unzuverlässig?
Oder verlangen wir von ihm, sich wie etwas zu verhalten, das es nie sein sollte?
Schauen wir genauer hin.
Die Kernbeschwerde: Langsame Counter + dynamische Labels = Angst
Der eigentliche Schmerz zeigt sich an ein paar vorhersehbaren Stellen:
- Alerting auf einen Counter-Anstieg, wenn der Counter nicht bei null beginnt.
- Berechnen der Gesamt-Increments über einen Zeitraum, besonders wenn kurzlebige Series existieren.
- Betrachten der Increment-Häufigkeit als Zeitreihe ohne seltsame Artefakte.
- Berechnen langfristiger Erfolgsraten mit
sum(rate(success_total[30d])) / sum(rate(overall_total[30d]))und die Erkenntnis, dass kurzlebige Series die Ergebnisse verzerren.
Es gibt auch eine Meta-Frustration: Die Rohdaten sind da. Wenn Sie den Graphen manuell überfliegen, sehen Sie oft, was „eigentlich" gezählt werden sollte. Aber rate() oder increase() scheint die Dinge zu unterschätzen.
Und das ist kein Bug.
Es ist Absicht.
Prometheus bevorzugt Unter- gegenüber Überzählung, wenn es Randfälle wie Resets oder verpasste Scrapes erkennt. Für SREs kann sich diese Sicherheitsverzerrung falsch herum anfühlen. Ein False-Negative-Alert ist in vielen realen Setups schlimmer als ein False-Positive.
Wenn Ihr Monitoring-System also Sicherheit über Sensitivität stellt, kann sich das anfühlen, als würde es Sie verraten.
Die erste harte Wahrheit: Sehr langsame Counter sind unangenehm
Eine erfahrene Stimme brachte es direkt auf den Punkt: Sehr langsam laufende Counter sind ein schwieriges Thema bei Prometheus.
Wenn Sie alle 30 Sekunden scrapen und etwas sich nur alle 20 Minuten erhöht, arbeiten Sie mit spärlichen Daten. Jetzt kommt noch hinzu:
- Dynamische Labels
- Kurzlebige Pods
- Neustarts durch Deployments
- Autoscaling-Ereignisse
Plötzlich messen Sie keine saubere monotone Series mehr. Sie messen Fragmente von Countern über mehrere Instanzen hinweg.
Prometheus behandelt Counter-Resets.
Es rekonstruiert nicht auf magische Weise fehlende Historie von Pods, die verschwunden sind.
Das ist keine Inkompetenz. Das ist Physik.
Die Kardinalitätsfalle
Eine der durchgängigsten Empfehlungen: Kardinalität für wichtige SLO-Metriken reduzieren.
Zu viele Teams fügen Fehler-Countern direkt Labels auf Debugging-Ebene hinzu:
- user_id
- request_id
- feature_flag
- shard
- deployment hash
Es fühlt sich mächtig an.
Es ist auch ein Rezept für Sparsity.
Spärliche Series machen rate() unzuverlässiger, weil das Zeitfenster Series enthalten kann, die nur für einen kleinen Teil dieses Fensters existierten. Ihre 30-Tage-Erfolgsraten-Query enthält jetzt Dutzende Mikro-Series, die kurz auf- und wieder verschwunden sind.
Metriken sollen Folgendes beantworten:
„Gibt es zum Zeitpunkt X ein Problem?"
Sie sollen nicht Ihre Logs ersetzen.
Wenn Sie Counter mit forensischer Labeling-Tiefe überladen, dehnen Sie Prometheus über sein eigentliches Designzentrum hinaus.
Kurzlebige Worker: Der stille Saboteur
Ein weiterer pointierter Kommentar: Kurzlebige Metriken sind ein Antipattern.
Wenn Sie über Queues verteilte, ephemere Worker oder FaaS-artiges Compute nutzen, können Ihre Counter:
- starten.
- sich einmal erhöhen.
- verschwinden.
Jetzt muss Ihre increase()-Berechnung Series abgleichen, die nur für ein paar Scrapes existierten. Genau da taucht die seltsame Unterzählung auf.
Eine erwähnte Lösung: Accumulator-Exporter.
Statt dass jeder kurzlebige Worker seinen eigenen Counter exponiert, pushen Sie Increments zu einem zentralen Accumulator (im StatsD-Stil), und lassen Sie Prometheus diese stabile Quelle scrapen.
In modernen Stacks nutzen Sie vielleicht kumulative OpenTelemetry-Deltas, die in einen einzigen Aggregations-Collector fließen.
Das Thema zieht sich durch: Stabilisieren Sie den Counter, bevor Prometheus ihn sieht.
Prometheus mag langlebige Zeitreihen.
Flackernde mag es nicht.
„Created Timestamp Injection" ist keine Magie
Für Counter, die nicht bei null beginnen, unterstützt Prometheus jetzt die Zero-Injection des Created-Timestamps über OpenMetrics.
Das hilft bei manchen Startup-Unklarheiten.
Aber es beseitigt nicht alle Randfälle.
Wenn ein Pod neu startet und Ihr Scrape-Intervall einen Teil des Lebenszyklus verpasst, sehen Sie trotzdem unvollständige Daten. Prometheus versucht, Resets intelligent zu handhaben, tendiert dabei aber zur Unterschätzung.
Das ist so gewollt.
Wenn Sie „perfekte Delta-Rekonstruktion" erwartet haben, erwarten Sie etwas, das Prometheus nicht verspricht.
Recording Rules: Langweilig, mächtig, unterschätzt
Der Ansatz des Grafana-SLO-Features – geschichtete Recording Rules wie:
Codesum(sum_over_time((grafana_slo_success_rate_5m{})[28d:5m])) / sum(sum_over_time((grafana_slo_total_rate_5m{})[28d:5m]))
Fühlt sich kompliziert an.
Aber das ist kein willkürliches Zeremoniell.
Die Vorab-Aggregation in stabile 5-Minuten-Deltas über Recording Rules macht langfristige SLO-Berechnungen deutlich zuverlässiger.
Ein zentraler Vorschlag: Testen Sie Ihre Recording Rules.
Nutzen Sie promtool test rules.
Fügen Sie Alerts hinzu, falls Recording Rules aufhören auszuwerten.
Wenn Sie sie nicht testen, vertrauen Sie unsichtbarer Verrohrung. Wenn Sie sie testen, sind sie überraschend solide.
Die Ironie ist, dass viele Teams rohem PromQL mehr vertrauen als Recording Rules – obwohl Recording Rules, wenn getestet, oft sicherer sind.
Das Float-Problem (ja, es ist real)
Prometheus verwendet Floats.
Das bedeutet, Counter verlieren bei sehr hohen Größenordnungen (um 2^53) an +1-Präzision.
Bei den meisten Web-Workloads erreichen Sie das nie.
Bei Hochgeschwindigkeits-Interfaces oder massiven Aggregationen kann es passieren.
Ein cleverer erwähnter Workaround: uint64-Counter vor dem Export modulo 2^53 wrappen.
Das ist Nische.
Aber es erinnert daran, dass Prometheus früh Kompromisse eingegangen ist – und diese Entscheidungen wirken bis heute nach.
Metriken vs. Logs: Die Vertrauenskrise
Unter den technischen Beschwerden liegt ein tieferes Problem.
Wenn Teams anfangen zu sagen:
„Vielleicht sollten wir dafür einfach Logs nutzen."
Dabei geht es nicht um Mathematik. Es geht um Vertrauen.
Metriken wirken weniger glaubwürdig, wenn sie Randfälle verpassen. Wenn sich eine 30-Tage-Erfolgsraten-Query je nach Fenstergröße anders verhält, bröckelt das Vertrauen.
Aber hier ist die unbequeme Wahrheit:
Metriken waren nie als perfekte forensische Buchhaltungssysteme gedacht.
Sie sind grobe, aggregierte Signale.
Logs sind präzise.
Metriken sind skalierbar.
Wenn Sie von Countern Log-Level-Genauigkeit verlangen, werden Sie immer enttäuscht sein.
Die interessanteste Idee: „Materialized Metrics"
Ein langfristiger Vorschlag, der in der Diskussion aufkam: eine neue Pipeline innerhalb von Prometheus, die Scrapes zurück in Deltas umwandelt und sie nach Label-Reduktion zu projizierten Countern re-materialisiert.
instance fallen lassen.
Ephemere Dimensionen fallen lassen.
Zuerst Deltas aggregieren.
Stabile Counter neu aufbauen.
Das ist ambitioniert.
Es erkennt einen zentralen Schmerzpunkt an: Viele Nutzer denken in Deltas, nicht in kumulativen Countern. Sie wollen event-artige Semantik mit der Performance von Metriken.
Wenn so etwas released wird, könnte es völlig verändern, wie Menschen über Counter denken.
Sind Counter also „sehr unzuverlässig"?
Nein.
Aber sie verzeihen nichts.
Prometheus-Counter sind extrem zuverlässig, wenn:
- Series langlebig sind.
- Kardinalität kontrolliert ist.
- Scrape-Intervalle zur Ereignishäufigkeit passen.
- Recording Rules für langfristige Berechnungen genutzt werden.
- Sie Systemzustand messen, nicht Transaktionen auditieren.
Sie werden unangenehm, wenn:
- Sie Debugging-Labels in SLO-Metriken mischen.
- Sie sich auf kurzlebige Worker verlassen.
- Sie perfekte Rekonstruktion über Neustarts hinweg erwarten.
- Sie
rate()über 30 Tage fragmentierter Series dehnen.
Der Titel, der sie als „sehr unzuverlässig" bezeichnete, war eingestandene Übertreibung.
Aber die Frustration ist real.
Es ist nicht so, dass Prometheus kaputt ist.
Es ist, dass sich Datadog-artige mentale Modelle nicht sauber übertragen lassen.
Prometheus zwingt Sie, nachzudenken über:
- Scrape-Intervalle.
- Series-Lebensdauer.
- Label-Ökonomie.
- Aggregationsstrategie.
Diese kognitive Last fühlt sich anfangs wie ein Rückschritt an.
Bis man merkt, dass es einfach ein anderer Vertrag ist.
Und wie bei den meisten Verträgen in verteilten Systemen zählt das Kleingedruckte.