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
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 ?
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
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
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
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
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
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
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
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
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
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
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
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