prometheus perf degradée trop de cardinalité

Question

salut les sres
on a un cluster prometheus qui commence à pisser du sang, cpu à fond, mémoire qui explose, et les scrapes se mettent à ramer voire timed out. en gros notre infra a grossi mais prometheus a du mal à suivre.
je pense que c'est un problème de cardinalité avec trop de labels dynamiques générés par nos apps. on a des métriques avec des labels qui incluent des uuid, des ips éphémères, des user_ids etc. ce qui fait des millions de séries temporelles
comment vous gérez ce genre de trucs ? on peut pas juste virer ces labels parce qu'on en a besoin pour debugger

gbuisson · Answer

oui la cardinalité c'est le mal pour prometheus. la première chose à faire c'est de bien configurer le

relabel_configs

dans ta config prometheus. tu peux dropper les labels à forte cardinalité avant qu'ils n'arrivent dans prometheus

jules41 · Answer

mais si je les droppe comment je fais pour le debug ? genre si je veux filtrer par user_id quand y a un souci sur une req spécifique ?

smoulin · Answer

tu droppes les labels hyper-cardinaux de prometheus mais tu les envoies à un autre système pour le debug. par exemple un log-aggregator comme loki ou splunk. prometheus c'est pour les métriques agrégées pour l'alerting et le monitoring pas pour le tracing fin

gbuisson · Answer

exactement. prometheus n'est pas fait pour le "diagnostic event level". tu gardes des labels importants mais moins dynamiques (app_name, host, env) et tu uses loki/tempo/elastic pour les détails spécifiques à une requête

jules41 · Answer

ok je vois le point. donc je devrais ptete plutôt revoir ma stratégie de logging/tracing. c'est un gros changement dans notre stack mais ça fait sens pour la perf prometheus

matthieu-louis · Answer

en attendant de refaire ta stack de logs/traces tu peux aussi jouer sur le

storage.tsdb.retention.time

pour réduire la durée de rétention. si tu réduis la rétention ça réduit la taille du tsdb et ça soulage un peu

smoulin · Answer

et n'oublie pas le shard de prometheus si vraiment tu as trop de cibles à scraper. mais ça complexifie l'infra

jules41 · Answer

la rétention est déjà à 15 jours c'est le minimum syndical pour nous. le sharding on y a pensé mais on voulait éviter pour l'instant

gbuisson · Answer

si le relabeling ne suffit pas regarde tes exporters. c'est souvent eux qui génèrent ces labels. vois si tu peux les configurer pour qu'ils ne remontent pas ces labels ou si tu peux les agréger avant l'exposition

jules41 · Answer

c'est surtout nos applications custom avec le client prometheus qui exportent tout et n'importe quoi. on va devoir faire un effort de discipline sur le code pour limiter les labels

matthieu-louis · Answer

tu peux aussi utiliser des remote_write vers un long-term storage comme thanos ou cortex pour décharger le prometheus local si tu as besoin de rétention longue sur ces métriques

jules41 · Answer

merci à tous pour les idées ! on va commencer par un gros nettoyage des

relabel_configs

pour droper les labels inutiles et essayer de basculer la logique de debug sur loki pour les détails. ensuite on attaquera la modification du code des apps. ça va être un chantier mais au moins on a une direction claire

prometheus perf degradée trop de cardinalité

12 commentaires

Laisser une réponse

Les pointeurs dans le langage de programmation Go

Déploiement et Backup automatique d'une application Symfony 4

C'est quoi exactement un conteneur ?

Introduction du cours pour apprendre l'orchestrateur Kubernetes (k8s)

Sécurisez vos déploiements : Ne laissez plus vos clés API dans le state

Rejoindre la communauté