Prometheus-Counter sind nicht kaputt, aber sie brechen Teams das Genick, die sie wie Datadog behandeln

Manche Frustration taucht erst nach einer Migration auf. Sie wechseln von etwas wie Datadog zu Prometheus, bauen Dashboards neu und schreiben Alerts neu. Alles fühlt sich schlanker an, „offener", mehr unter Ihrer Kontrolle. Und dann fangen die Counter an, Sie zu belügen, oder zumindest fühlt es sich so an.

Niederfrequente Counter verpassen Increments, kurzlebige Series verschwinden aus den Summen, und Erfolgsraten gehen über 30 Tage nicht ganz auf. Alerts feuern nicht, wenn sie sollten, oder, noch schlimmer, zu spät.

Ein Team beschrieb es unverblümt: Seit dem Wechsel seien Counter der größte Schmerzpunkt. Was vorher „einfach funktionierte", verlangt jetzt sorgfältiges Nachdenken, und selbst wenn man glaubt, alles richtig gemacht zu haben, bleibt ein ungutes Gefühl.

Ist Prometheus also unzuverlässig, oder verlangen wir, dass es sich wie etwas verhält, das es nie sein sollte? Ein genauerer Blick lohnt sich.

Die Kernbeschwerde: Langsame Counter + dynamische Labels = Angst

Der 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.

Dazu kommt eine Meta-Frustration. Die Rohdaten sind da, und wer den Graphen von Hand überfliegt, sieht oft, was „eigentlich" gezählt werden sollte. Trotzdem scheinen rate() und increase() zu wenig zu zählen.

Ein Bug ist das nicht, sondern Absicht. Erkennt Prometheus Randfälle wie Resets oder verpasste Scrapes, zählt es lieber zu wenig als zu viel. Für SREs kann sich diese Vorsicht falsch herum anfühlen, denn in vielen realen Setups ist ein ausbleibender Alert schlimmer als ein Fehlalarm. Wenn Ihr Monitoring-System Sicherheit über Sensitivität stellt, kann sich das wie Verrat anfühlen.

Sehr langsame Counter sind unangenehm

Eine erfahrene Stimme sagte es direkt: Sehr langsam laufende Counter sind bei Prometheus ein schwieriges Thema.

Wenn Sie alle 30 Sekunden scrapen und sich etwas nur alle 20 Minuten erhöht, arbeiten Sie mit spärlichen Daten. Kommen dann noch dynamische Labels, kurzlebige Pods, Neustarts durch Deployments und Autoscaling-Ereignisse hinzu, messen Sie keine saubere monotone Series mehr, sondern Bruchstücke von Countern über mehrere Instanzen.

Prometheus kommt mit Counter-Resets zurecht. Die fehlende Historie von Pods, die verschwunden sind, kann es aber nicht herbeizaubern. Mit Inkompetenz hat das nichts zu tun, das ist schlicht Physik.

Die Kardinalitätsfalle

Eine Empfehlung kam immer wieder: Halten Sie die Kardinalität wichtiger SLO-Metriken niedrig.

Zu viele Teams hängen Fehler-Countern direkt Labels auf Debugging-Ebene an:

• user_id
• request_id
• feature_flag
• shard
• deployment hash

Das fühlt sich mächtig an und führt geradewegs zu spärlichen Daten. Spärliche Series machen rate() unzuverlässiger, weil das Zeitfenster Series enthalten kann, die nur einen kleinen Teil davon existiert haben. Ihre Query für die 30-Tage-Erfolgsrate enthält dann Dutzende Mikro-Series, die kurz auftauchten und wieder verschwanden.

Metriken sollen beantworten, ob es zum Zeitpunkt X ein Problem gibt. Ihre Logs sollen sie nicht ersetzen. Wer Counter mit forensischer Label-Tiefe überlädt, zwingt Prometheus zu etwas, wofür es nicht gebaut wurde.

Kurzlebige Worker: Der unauffällige Saboteur

Ein weiterer pointierter Kommentar nannte kurzlebige Metriken ein Antipattern. Wenn Sie über Queues verteilte, ephemere Worker oder FaaS-artiges Compute nutzen, können Ihre Counter:

1. starten.
2. sich einmal erhöhen.
3. verschwinden.

Ihre increase()-Berechnung muss dann Series abgleichen, die nur ein paar Scrapes lang existiert haben, und genau dort taucht die seltsame Unterzählung auf.

Als Lösung wurden Accumulator-Exporter genannt. Statt dass jeder kurzlebige Worker seinen eigenen Counter bereitstellt, pushen Sie die Increments an einen zentralen Accumulator (im StatsD-Stil) und lassen Prometheus diese stabile Quelle scrapen. In modernen Stacks können das auch kumulative OpenTelemetry-Deltas sein, die in einen einzigen Aggregations-Collector fließen.

Der gemeinsame Nenner: Stabilisieren Sie den Counter, bevor Prometheus ihn sieht. Prometheus mag langlebige Zeitreihen und kommt mit flackernden schlecht zurecht.

„Created Timestamp Injection" ist keine Magie

Für Counter, die nicht bei null beginnen, unterstützt Prometheus inzwischen die Zero-Injection des Created-Timestamps über OpenMetrics. Das hilft bei manchen Unklarheiten beim Start, beseitigt aber nicht alle Randfälle.

Startet ein Pod neu und verpasst Ihr Scrape-Intervall einen Teil seines Lebenszyklus, sehen Sie weiterhin unvollständige Daten. Prometheus versucht, Resets intelligent zu behandeln, schätzt dabei aber eher zu niedrig, und das ist gewollt. Wer eine perfekte Rekonstruktion der Deltas erwartet, erwartet etwas, das Prometheus nie versprochen hat.

Recording Rules: Langweilig, mächtig, unterschätzt

Der Ansatz des Grafana-SLO-Features arbeitet mit geschichteten Recording Rules wie dieser:

Codesum(sum_over_time((grafana_slo_success_rate_5m{})[28d:5m])) / sum(sum_over_time((grafana_slo_total_rate_5m{})[28d:5m]))

Das wirkt kompliziert, ist aber kein willkürliches Ritual. Wer über Recording Rules vorab in stabile 5-Minuten-Deltas aggregiert, bekommt deutlich zuverlässigere langfristige SLO-Berechnungen.

Ein wichtiger Rat dazu: Testen Sie Ihre Recording Rules mit promtool test rules und legen Sie Alerts an, falls die Rules nicht mehr ausgewertet werden. Ungetestet vertrauen Sie unsichtbaren Rohrleitungen, getestet sind sie erstaunlich solide.

Ironischerweise trauen viele Teams rohem PromQL mehr als Recording Rules, obwohl getestete Recording Rules oft die sicherere Wahl sind.

Das Float-Problem (ja, es ist real)

Prometheus arbeitet mit Floats. Bei sehr großen Werten (um 2^53) verlieren Counter deshalb die Präzision für +1.

Die meisten Web-Workloads kommen da nie hin, bei Hochgeschwindigkeits-Interfaces oder massiven Aggregationen kann es aber passieren. Ein cleverer Workaround aus der Diskussion: uint64-Counter vor dem Export modulo 2^53 umbrechen.

Das ist ein Nischenthema, erinnert aber daran, dass Prometheus früh Kompromisse eingegangen ist, die bis heute nachwirken.

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", dann geht es kaum noch um Mathematik, sondern um Vertrauen.

Metriken wirken weniger glaubwürdig, sobald sie Randfälle verpassen. Verhält sich eine Query für die 30-Tage-Erfolgsrate je nach Fenstergröße anders, bröckelt das Vertrauen.

Metriken waren nie als perfekte forensische Buchhaltung gedacht. Sie sind grobe, aggregierte Signale. Logs sind präzise, Metriken skalieren. Wer von Countern die Genauigkeit von Logs verlangt, wird immer enttäuscht sein.

Die interessanteste Idee: „Materialized Metrics"

In der Diskussion kam auch ein langfristiger Vorschlag auf: eine neue Pipeline innerhalb von Prometheus, die Scrapes zurück in Deltas umwandelt und sie nach einer Label-Reduktion wieder zu projizierten Countern materialisiert. Dabei würde man instance und andere ephemere Dimensionen fallen lassen, zuerst die Deltas aggregieren und daraus stabile Counter neu aufbauen.

Das ist ehrgeizig, trifft aber einen echten Schmerzpunkt. Viele Nutzer denken in Deltas und nicht in kumulativen Countern, sie wollen die Semantik von Events mit der Performance von Metriken. Sollte so etwas erscheinen, könnte es grundlegend verändern, wie Menschen über Counter denken.

Sind Counter also „sehr unzuverlässig"?

Nein, aber sie verzeihen nichts. Prometheus-Counter sind sehr 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, statt Transaktionen zu auditieren.

Unangenehm werden sie, 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 „sehr unzuverlässig" nannte, war zugegebenermaßen übertrieben. Die Frustration dahinter ist trotzdem echt. Prometheus ist nicht kaputt, nur lassen sich Denkmodelle aus der Datadog-Welt nicht sauber übertragen.

Prometheus zwingt Sie, über Scrape-Intervalle, die Lebensdauer von Series, sparsamen Umgang mit Labels und die Aggregationsstrategie nachzudenken. Diese kognitive Last fühlt sich anfangs wie ein Rückschritt an, bis man merkt, dass man schlicht einen anderen Vertrag unterschrieben hat. Und wie bei den meisten Verträgen in verteilten Systemen kommt es auf das Kleingedruckte an.