prometheus qui rame, trop de séries

Salut ! le classique c'est la haute cardinalité. t'as des labels qui changent trop souvent ou qui ont trop de valeurs uniques ? genre des IDs de requêtes, des noms de pods éphémères générés avec des UUIDs, des IPs qui sont pas agrégées ? ça, ça peut faire exploser le nombre de séries et donc la conso de ressources de prometheus.

Ah oui, bingo. J'ai un service en dev qui expose l'ID unique de chaque transaction en métrique. Et nos pods k8s ont des noms générés avec des UUIDs que je n'ai pas filtrés. Je sens que c'est ça.

Clairement. Il faut virer ça. Utilise des `relabel_configs` dans ton scrape config pour supprimer ou réécrire ces labels à haute cardinalité avant qu'elles n'arrivent dans prometheus. Une regex pour remplacer les UUIDs ou virer les IDs transactionnels fera des miracles.

Mieux encore si possible : fais-le à la source. Si tes exporters peuvent déjà agréger ou simplifier ces labels avant de les exposer, c'est encore plus efficient. Moins de charge réseau et moins de travail pour prometheus.

Regarde la page `/tsdb-status` de ton prometheus (typiquement sur le port 9090). Elle te donnera une idée des labels et métriques qui génèrent le plus de séries. C'est un outil super utile pour cibler les coupables.

Et si t'as VRAIMENT besoin de ces infos transactionnelles, un système de log agrégé (genre loki, grafana tempo, ou un ELK) est ptete plus adapté que prometheus qui est fait pour des métriques agrégées et pas du détail unitaire.

t'as des "target limits" ou des "series limits" configurés dans prometheus ? des fois, ce n'est pas le nombre de séries lui-même qui explose mais la limite par défaut qui est trop basse pour la taille de ton infra et il passe son temps à recharger ou à purger.

vérifie aussi la fréquence de scrape. si tu scrapes toutes les 5s et que t'as 1000 targets, ça fait 200 scrapes/sec. multiplie ça par le nombre moyen de métriques par target. ça peut vite devenir énorme en terme de nombre d'échantillons ingérés.

pense à désactiver les metrics inutiles si tu peux. beaucoup d'exporters exposent tout par défaut, mais tu n'as pas toujours besoin de tout. `metric_relabel_configs` peut t'aider à filtrer les métriques dont tu n'as absolument pas besoin avant l'ingestion.

vous avez tapé dans le mille ! c'est clairement les ids de transaction et les noms de pods qui étaient la source du problème. je viens de mettre en place des `relabel_configs` pour virer les ids transactionnels et regrouper les pods par `app` label. le cpu a déjà baissé un peu. je vais regarder `/tsdb-status` pour affiner. super tips, thx la team !