Prometheus: Wie wir den Speicherverbrauch drastisch gesenkt haben - und entdeckten, dass unsere Dashboards das eigentliche Problem waren
Prometheus wacht nicht eines Morgens auf und beschließt, Ihren RAM aufzufressen.
Es springt nicht zufällig von „gesund" zu „warum fordert dieser Pod 64 GB an?".
Wenn der Speicherverbrauch in die Höhe schießt, ist das fast immer verdient.
Und in der Geschichte hinter „Prometheus: Wie wir den Speicherverbrauch drastisch gesenkt haben" war der Bösewicht nicht der Traffic, nicht die Skalierung und auch kein exotischer Bug in der TSDB.
Es waren die Dashboards.
Genauer gesagt: Metriken und Labels mit hoher Kardinalität, die Grafana-Panels antrieben, die schon lange niemand mehr ernsthaft auditiert hatte.
Das war keine Geschichte über das Justieren von Retention-Flags oder das Umlegen obskurer Storage-Einstellungen. Es war eine forensische Untersuchung dessen, was tatsächlich im Head Block saß – und warum.
Der Moment, in dem klar wird: Das ist nicht „nur Wachstum"
Jeder Prometheus-Betreiber kennt das Gefühl.
Der Speicherverbrauch kriecht langsam nach oben. Man geht von organischem Wachstum aus. Mehr Services. Mehr Pods. Mehr Metriken. Das ist eben der Preis des Skalierens.
Aber wenn der Verbrauch unverhältnismäßig zum Workload-Wachstum steigt, stimmt etwas nicht.
Genau da beginnt diese Geschichte.
Statt das Problem mit Hardware zu erschlagen, grub sich das Team in die Kardinalität ein. Sie behandelten den Speicherverbrauch als Symptom, nicht als Grundursache.
Und was sie fanden, ist schmerzhaft vertraut.
Hohe Kardinalität: Der stille Multiplikator
Der Speicherverbrauch von Prometheus wird stark von der Anzahl aktiver Zeitreihen beeinflusst.
Mehr eindeutige Label-Kombinationen = mehr Zeitreihen.
Mehr Zeitreihen = mehr Speicher.
Das ist brutal linear.
Das Team konzentrierte sich darauf, Metriken und Labels mit hoher Kardinalität zu identifizieren, besonders die, die von Grafana-Dashboards genutzt wurden.
Dieses Detail ist entscheidend.
Denn Dashboards haben die Angewohnheit, schlechtes Metrik-Design still und leise zu rechtfertigen.
Jemand fügt ein Panel hinzu, das nach user_id oder request_path aufschlüsselt.
Es sieht cool aus.
Es beantwortet eine Debugging-Frage.
Niemand fragt, ob das in eine Produktionsmetrik gehört.
Wochen vergehen.
Deployments vervielfachen sich.
Pods kommen und gehen.
Jetzt ist dieses „vorübergehende" Label zu Zehntausenden eigenständiger Series explodiert.
Und Prometheus speichert brav alle davon.
Grafana ist nicht der Bösewicht – aber es begünstigt schlechte Gewohnheiten
Um das klarzustellen: Grafana hat das Problem nicht verursacht.
Aber Dashboards schaffen Anreize.
Wenn ein Panel ein bestimmtes Label braucht, um zu funktionieren, zögern Engineers, dieses Label zu entfernen – selbst wenn es die Kardinalität aufbläht.
Der Artikel beschreibt, wie analysiert wurde, welche Metriken und Labels tatsächlich von Dashboards genutzt wurden.
Das ist ein subtiler, aber wirkungsvoller Schachzug.
Nicht „welche Metriken gibt es?".
Nicht „welche Labels sind groß?".
Sondern:
„Welche Labels sind durch echte Nutzung gerechtfertigt?"
Wenn ein Label keine Dashboards oder Alerts nennenswert antreibt, warum steckt es dann im Speicher?
PromQL als Skalpell
Der Artikel verspricht hilfreiche PromQL-Queries, um Metriken mit hoher Kardinalität zu finden.
Das ist der Teil, den die meisten Teams überspringen.
Sie spüren den Schmerz.
Sie nehmen an, die Ursache zu kennen.
Sie fangen an, Exporter zu löschen oder Scrape-Intervalle anzupassen.
Aber PromQL zeigt Ihnen:
- Welche Metriken die meisten Series haben.
- Welche Labels die höchste Anzahl eindeutiger Werte haben.
- Welche Kombinationen explodieren.
Wenn Sie Ihr eigenes Prometheus über sich selbst befragen, hören Sie auf zu raten.
Sie fangen an, die Kosten jedes Labels zu messen.
Und genau da 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. Alle exportieren. Alle mit reichhaltigen Labels.
Und es funktioniert – bis es das nicht mehr tut.
Bei dieser Geschichte geht es nicht darum, Prometheus-Features zu streichen.
Es geht darum, Metriken zu stutzen, die technisch verfügbar, aber praktisch unnötig waren.
Das ist ein Mentalitätswechsel.
Die Observability-Kultur drängt oft zu „jetzt sammeln, später analysieren".
Aber Prometheus bestraft diese Mentalität.
Es komprimiert Ihre Unentschlossenheit nicht.
Es hält jede Series heiß im Speicher.
Dashboards als technische Schulden
Hier ist der unbequeme Blickwinkel.
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 von subtilen Label-Kombinationen abhängen, deren Rechtfertigung sich niemand mehr erinnert.
Ein Label zu entfernen fühlt sich plötzlich 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 auf die Dashboard-Nutzung zurückverfolgte, stellte es die Frage neu.
Statt zu fragen:
„Können wir es uns leisten, dieses Label zu entfernen?"
fragten sie:
„Verdient sich dieses Label seine Kosten?"
Das ist eine andere Energie.
Beim Speicher-Sparen geht es nicht um Flags
Wenn Prometheus schwerfällig wird, liegt die Versuchung nahe, nach Runtime-Anpassungen zu suchen:
- Retention anpassen.
- Compaction tunen.
- Scrape-Intervall erhöhen.
- Kompressions-Flags aktivieren.
Das kann helfen.
Aber es behebt nicht die Kardinalität.
Hohe Kardinalität ist strukturell.
Aus schlechtem Metrik-Design kommt man nicht per GC heraus.
In dieser Geschichte dreht sich alles darum, die Series-Anzahl zu reduzieren, indem unnötige Labels mit hoher Kardinalität eliminiert werden.
Das ist keine Konfigurationsänderung.
Das ist Architektur.
Die versteckten Kosten von „nur noch ein Label"
Engineers lieben Labels.
Sie machen Metriken flexibel.
Sie machen das Aufschlüsseln einfach.
Sie machen Dashboards mächtig.
Aber jede neue Label-Dimension vervielfacht die potenziellen Series.
Eine Metrik mit:
- 10 Services
- 5 Statuscodes
- 3 Regionen
Das sind 150 mögliche Series.
Fügen Sie user_id mit 10.000 möglichen Werten hinzu?
Jetzt sind Sie bei 1,5 Millionen.
Das ist nicht theoretisch.
So verschwindet Speicher.
Und das Schlimmste?
Die meisten Dashboards brauchen diese Aufschlüsselung gar nicht.
Sie ist da, weil sie vielleicht nützlich sein könnte.
Prometheus optimiert nicht für „vielleicht".
Es optimiert für „du hast danach gefragt".
Was diese Geschichte wirklich lehrt
Der Artikel stellt es als drastische Senkung des Speicherverbrauchs dar.
Aber die tiefere Lektion ist diese:
Observability-Systeme brauchen Governance.
Ohne sie wuchern Metriken genauso wie Logs.
Dashboards wachsen unkontrolliert.
Labels vervielfachen sich.
Der Speicherverbrauch folgt.
Sie brauchen kein exotisches Tooling, um das zu beheben.
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
Es gibt ein wiederkehrendes Muster über diese Speicher-Geschichten hinweg.
Prometheus versagt selten, weil es unfähig ist.
Es versagt, weil es zu freizügig ist.
Es speichert bereitwillig Millionen von Series, wenn Sie es dazu auffordern.
Es indiziert bereitwillig jedes dynamische Label.
Es wird Sie nicht aufhalten.
Und das ist die Falle.
In diesem Fall wandte sich das Team nach innen und auditierte seine eigene Metrik-Hygiene.
Sie gaben nicht der TSDB die Schuld.
Sie griffen nicht sofort zu einer anderen Zeitreihendatenbank.
Sie fragten:
„Was speichern wir – und warum?"
Allein diese Frage ist wirkungsvoll.
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 Ihr Speicher-Graph wahrscheinlich.
Und er steigt.
Den Speicherverbrauch drastisch zu senken ist keine Magie.
Es ist Subtraktion.
Und manchmal ist der schnellste Weg, Prometheus leichter zu machen, einzugestehen, dass Sie mehr messen, als Sie brauchen.