Was ist hohe Kardinalität in einem Metriksystem, und wie hältst du sie unter Kontrolle?

Kardinalität ist die Anzahl eindeutiger Label-Kombinationen einer Metrik, und jede Kombination ist eine eigene Zeitreihe im Speicher. User-IDs, Request-IDs, E-Mail-Adressen oder rohe URL-Pfade als Labels können Millionen Reihen erzeugen und eine Prometheus-Instanz umlegen. Halt Labels begrenzt und niedrig kardinal, templatisiere dynamische Pfadsegmente, schieb Details pro Request in Logs oder Traces und erzwing Grenzen über Relabeling und Sample-Limits.

Jede eindeutige Kombination von Label-Werten ist eine eigene Zeitreihe mit eigenem Speicherbedarf und eigenem Chunk auf der Platte. In dem Moment, in dem jemand user_id oder einen rohen Pfad als Label ergänzt, gehst du also von ein paar hundert Reihen auf Millionen. Uns ist eine Prometheus-Instanz wiederholt ins OOM gelaufen, und es stellte sich heraus, dass ein Team die volle URL inklusive Query String als Label auf ihrem Request-Counter hatte. Meine Regel ist, dass ein Label-Wert aus einer kleinen, geschlossenen Menge stammen muss, die du auf ein Whiteboard schreiben könntest: Methode, Statusklasse, Endpoint-Template, Region. Alles Unbegrenzte geht in eine Logzeile oder ein Attribut eines Trace-Spans, denn dort ist das Speichermodell dafür gebaut. Praktisch setze ich es mit metric_relabel_configs durch, um bekannte schlechte Labels beim Scrape zu droppen, mit einem Sample-Limit pro Target, damit ein Service nicht die ganze Instanz reißt, und mit einem kurzen Review, sobald eine neue Metrik in einem Pull Request auftaucht.