Prometheus: Wie wir den Speicherverbrauch drastisch gesenkt und entdeckt haben, dass unsere Dashboards das eigentliche Problem waren

Prometheus wacht nicht eines Morgens auf und beschließt, Ihren RAM aufzufressen. Es springt auch nicht zufällig von „gesund" zu „warum fordert dieser Pod 64 GB an?". Wenn der Speicherverbrauch in die Höhe schießt, hat das fast immer einen Grund, den man sich selbst eingebrockt hat.

In der Geschichte hinter „Prometheus: Wie wir den Speicherverbrauch drastisch gesenkt haben" lag es weder am Traffic noch an der Skalierung oder an einem exotischen Bug in der TSDB. Schuld waren die Dashboards, genauer gesagt Metriken und Labels mit hoher Kardinalität, die Grafana-Panels speisten, die schon lange niemand mehr ernsthaft auditiert hatte.

Retention-Flags oder obskure Storage-Einstellungen spielten dabei kaum eine Rolle. Die Arbeit glich eher einer forensischen Untersuchung dessen, was tatsächlich im Head Block saß, und warum es dort war.

Der Moment, in dem klar wird: Das ist nicht „nur Wachstum"

Jeder Prometheus-Betreiber kennt das Gefühl. Der Speicherverbrauch kriecht langsam nach oben, und man hält das für organisches Wachstum: mehr Services, mehr Pods, mehr Metriken, eben der Preis des Skalierens. Steigt der Verbrauch aber stärker als der Workload, stimmt etwas nicht.

An diesem Punkt beginnt die Geschichte. Statt das Problem mit Hardware zu erschlagen, grub sich das Team in die Kardinalität ein und behandelte den Speicherverbrauch als Symptom. Die Ursache, die sie fanden, kommt einem schmerzhaft bekannt vor.

Hohe Kardinalität: Der unauffällige Multiplikator

Der Speicherverbrauch von Prometheus hängt stark von der Anzahl aktiver Zeitreihen ab. Mehr eindeutige Label-Kombinationen bedeuten mehr Zeitreihen, und mehr Zeitreihen bedeuten mehr Speicher. Der Zusammenhang ist gnadenlos linear.

Das Team konzentrierte sich darauf, Metriken und Labels mit hoher Kardinalität zu finden, besonders jene, die Grafana-Dashboards nutzten. Dieses Detail ist entscheidend, denn Dashboards rechtfertigen schlechtes Metrik-Design gern, ohne dass es jemand merkt.

Jemand fügt ein Panel hinzu, das nach user_id oder request_path aufschlüsselt. Es sieht cool aus und beantwortet eine Debugging-Frage, und niemand fragt, ob das in eine Produktionsmetrik gehört. Wochen vergehen, Deployments vervielfachen sich, Pods kommen und gehen. Irgendwann ist dieses „vorübergehende" Label zu Zehntausenden eigenständiger Series explodiert, und Prometheus speichert brav jede einzelne davon.

Grafana ist nicht der Bösewicht, begünstigt aber schlechte Gewohnheiten

Grafana hat das Problem nicht verursacht. Dashboards setzen aber Anreize. Braucht ein Panel ein bestimmtes Label, zögern Engineers, dieses Label zu entfernen, selbst wenn es die Kardinalität aufbläht.

Der Artikel beschreibt, wie das Team analysierte, welche Metriken und Labels tatsächlich von Dashboards genutzt wurden. Das ist ein subtiler, aber wirkungsvoller Schachzug. Die Frage lautete weder „Welche Metriken gibt es?" noch „Welche Labels sind groß?", sondern „Welche Labels sind durch echte Nutzung gerechtfertigt?" Wenn ein Label keine Dashboards oder Alerts nennenswert speist, hat es im Speicher nichts zu suchen.

PromQL als Skalpell

Der Artikel verspricht hilfreiche PromQL-Queries, um Metriken mit hoher Kardinalität zu finden, und genau diesen Teil überspringen die meisten Teams. Sie spüren den Schmerz, glauben die Ursache zu kennen und fangen an, Exporter zu löschen oder Scrape-Intervalle anzupassen.

PromQL zeigt Ihnen dagegen:

• Welche Metriken die meisten Series haben.
• Welche Labels die höchste Anzahl eindeutiger Werte haben.
• Welche Kombinationen explodieren.

Sobald Sie Ihr Prometheus über sich selbst befragen, müssen Sie nicht mehr raten. Sie messen, was jedes Label kostet, und damit beginnt Disziplin.

Der eigentliche Wandel: Von „alles sammeln" zu „gezielt sammeln"

Viele Kubernetes-basierte Setups starten mit breiten Standardeinstellungen:

• kube-state-metrics
• cAdvisor
• Node Exporter
• Ingress-Controller
• Service Meshes

Alle scrapen und exportieren mit reichhaltigen Labels, und das funktioniert, bis es irgendwann nicht mehr funktioniert.

Prometheus-Features wurden in dieser Geschichte nicht gestrichen. Das Team stutzte Metriken, die technisch verfügbar, aber praktisch unnötig waren, und das erfordert ein anderes Denken. Die Observability-Kultur drängt oft zu „jetzt sammeln, später analysieren", und genau diese Haltung bestraft Prometheus. Ihre Unentschlossenheit wird nicht komprimiert, jede Series liegt heiß im Speicher.

Dashboards als technische Schulden

Unbequem wird es an dieser Stelle: Dashboards häufen sich an wie Code. Jemand erstellt eins für einen Incident, ein anderes Team klont es, ein drittes fügt ein neues Label hinzu, um die Granularität zu verbessern. Bald haben Sie Dutzende Panels, die an subtilen Label-Kombinationen hängen, und niemand erinnert sich mehr, warum.

Ein Label zu entfernen fühlt sich dann riskant an. „Was, wenn dieses Dashboard kaputtgeht?" „Was, wenn jemand diese Aufschlüsselung während eines Ausfalls braucht?" Also bleibt das Label, und der Speicherverbrauch steigt.

Indem dieses Team die Kardinalität bis zur Dashboard-Nutzung zurückverfolgte, stellte es die Frage anders. Statt „Können wir es uns leisten, dieses Label zu entfernen?" fragte es „Verdient sich dieses Label seine Kosten?", und damit verschiebt sich die ganze Diskussion.

Beim Speicher-Sparen helfen Flags wenig

Wird Prometheus schwerfällig, liegt es nahe, nach Runtime-Anpassungen zu suchen:

• Retention anpassen.
• Compaction tunen.
• Scrape-Intervall erhöhen.
• Kompressions-Flags aktivieren.

Das kann helfen, behebt aber die Kardinalität nicht. Hohe Kardinalität ist ein strukturelles Problem, und aus schlechtem Metrik-Design kommt man nicht per GC heraus.

In dieser Geschichte ging es darum, die Series-Anzahl zu senken, indem unnötige Labels mit hoher Kardinalität verschwanden. Das ist eine Frage der Architektur und keine Konfigurationsänderung.

Die versteckten Kosten von „nur noch ein Label"

Engineers lieben Labels. Sie machen Metriken flexibel, das Aufschlüsseln einfach und Dashboards mächtig. Jede neue Label-Dimension vervielfacht aber die möglichen Series.

Eine Metrik mit 10 Services, 5 Statuscodes und 3 Regionen ergibt 150 mögliche Series. Kommt user_id mit 10.000 möglichen Werten dazu, sind Sie bei 1,5 Millionen. Das ist keine Theorie, so verschwindet Speicher.

Am ärgerlichsten ist, dass die meisten Dashboards diese Aufschlüsselung gar nicht brauchen. Sie existiert, weil sie vielleicht einmal nützlich sein könnte. Prometheus optimiert aber nicht für „vielleicht", sondern für „du hast danach gefragt".

Was diese Geschichte lehrt

Der Artikel erzählt von einer drastischen Senkung des Speicherverbrauchs. Die Lehre dahinter ist, dass Observability-Systeme Governance brauchen. Ohne sie wuchern Metriken genauso wie Logs, Dashboards wachsen unkontrolliert, Labels vervielfachen sich, und der Speicherverbrauch zieht mit.

Exotisches Tooling brauchen Sie dafür nicht. Sie brauchen:

• Sichtbarkeit in Series-Zahlen.
• Bereitschaft, Dashboard-Annahmen zu hinterfragen.
• Die Disziplin, Labels zu entfernen, die ihr Gewicht nicht wert sind.

Prometheus skaliert, wenn Sie es respektieren

In diesen Speicher-Geschichten wiederholt sich ein Muster. Prometheus versagt selten, weil es etwas nicht kann. Es versagt, weil es zu viel zulässt: Es speichert bereitwillig Millionen von Series, wenn Sie es verlangen, indiziert jedes dynamische Label und hält Sie dabei nicht auf. Darin liegt die Falle.

In diesem Fall schaute das Team nach innen und auditierte seine eigene Metrik-Hygiene. Es gab weder der TSDB die Schuld, noch griff es sofort zu einer anderen Zeitreihendatenbank. Stattdessen fragte es: „Was speichern wir, und warum?" Allein diese Frage bringt schon viel.

Wenn Ihr Prometheus schwerfällig wird

Fragen Sie sich:

• Welche Metriken haben die höchste Series-Anzahl?
• Welche Labels explodieren in der Wertkardinalität?
• Werden diese Labels tatsächlich von Dashboards oder Alerts benötigt?
• Bestimmen Dashboards das Metrik-Design, statt umgekehrt?
• Exportieren Sie Labels, die sich bei jedem Deploy ändern?

Wenn Sie die Antworten nicht kennen, kennt sie wahrscheinlich Ihr Speicher-Graph, und der zeigt nach oben.

Den Speicherverbrauch drastisch zu senken hat nichts mit Magie zu tun, es ist Subtraktion. Oft macht man Prometheus am schnellsten leichter, indem man sich eingesteht, dass man mehr misst, als man braucht.