High cardinality dans Prometheus et alertmanager fou

yo. ah la high cardinality c'est le cancer de prometheus. la première chose à faire c'est un bon nettoyage via relabel_configs. tu dois virer tous les labels qui ont une cardinalité trop élevée, genre user_id, session_id, request_id... ces trucs là sont à logger, pas à scraper dans prometheus.

exactement. utiliser le prometheus TSDB status page pour voir les series par target et les labels qui génèrent le plus de series. tu peux aussi query l'api prometheus pour ça :

/api/v1/status/tsdb

et alertmanager qui spamme c'est typique si t'as des alerts basées sur des requêtes avec ces labels à haute cardinalité. l'évaluation prend trop de temps, ou alors les labels changent tellement vite que ça crée des instances d'alertes à la volée.

ok les relabel_configs c'est chaud à faire sans tout péter. et le tsdb status j'ai regardé c'est un peu un bordel avec tous les labels mais je vois bien que c'est nos métriques custom qui pèsent. je dois virer complètement user_id etc ? même si on en a besoin pour debug ?

oui carrément virer ces labels si c'est pour du debug. prometheus n'est pas un système de log ou de tracing. si tu veux ces infos pour debug, mets les dans les logs de ton app ou un outil de tracing type jaeger/opentelemetry. prometheus c'est pour l'état global et les agrégats.

un bon pattern c de garder des labels d'identification stables genre pod name, service name, namespace. et tous les trucs volatiles c dehors. tu peux faire des relabel_configs avec action: drop sur des regex qui matchent tes labels problématiques.

aussi check tes exporter configs. y'a des exporters qui par défaut sont trop verbeux. le kube-state-metrics par exemple peut être configuré pour ne pas exposer certains labels inutiles pour ton contexte.

ça me fait chier de jeter user_id mais je vois le point. ok je vais tenter de virer ces labels sur nos métriques custom avec un relabel_config global. et je vais regarder le kube-state-metrics si on peut l'alléger.

fais gaffe avec le relabel_config global si t'as beaucoup de jobs, c'est mieux de le faire par job ou par scrape_config. ouais et pour kube-state-metrics c'est --metric-labels-allowlist et --metric-annotations-allowlist

et une fois que t'as cleané, regarde le cardinality_limit dans prometheus.yml pour éviter que ça reparte en vrille. ça met une limite sur les series actives. --tsdb.max-series= au démarrage aussi.

ok la liste est longue. je vais commencer par les relabel_configs sur les métriques user_id/session_id. on verra après pour kube-state-metrics et les limites. énorme merci pour toutes les infos, ça va bien m'aider à remettre cette usine à gaz en état.