prometheus perf degradée trop de cardinalité

Posté par jules41 le 05/12/2024
RÉSOLU

jules41

Membre depuis le 24/09/2024

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

Commentaires

gbuisson

Membre depuis le 31/05/2024

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

Membre depuis le 24/09/2024

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

Membre depuis le 15/02/2020

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

Membre depuis le 31/05/2024

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

Membre depuis le 24/09/2024

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

Membre depuis le 13/11/2024

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

Membre depuis le 15/02/2020

et n'oublie pas le

shard
de prometheus si vraiment tu as trop de cibles à scraper. mais ça complexifie l'infra

jules41

Membre depuis le 24/09/2024

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

Membre depuis le 31/05/2024

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

Membre depuis le 24/09/2024

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

Membre depuis le 13/11/2024

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

Membre depuis le 24/09/2024

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

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire