5 commentaires
ouais ça pue la high cardinality à mort. le user_id c'est la mort pour prometheus. la première chose à faire c'est utiliser promtool tsdb analyze cardinality sur tes données pour voir quels labels sont les pires. ça va te donner une idée de la source du problème
exactement. après ça tu dois mettre en place du relabeling sur tes scrape configs. tu peux dropper les labels hyper-cardinaux comme user_id ou remplacer des valeurs uniques par des regex matchés pour grouper. par exemple si tu as des chemins /api/v1/users/123 et /api/v1/users/456 tu peux les transformer en /api/v1/users/#id
et n'oublie pas les recording rules aussi ! si tu as des agrégations que tu fais souvent dans Grafana genre la somme des requêtes par endpoint sans user_id tu peux créer une recording rule pour pré-calculer cette métrique. ça soulage grave Prometheus et Grafana sera beaucoup plus rapide dessus
faut aussi penser à la durée de rétention de tes metrics. si tu gardes des données à haute granularité pendant trop longtemps ça prend de la place et ça ralentit les requêtes. tu peux downsampler les vieilles données ou les envoyer vers un long-term storage genre Thanos ou Mimir pour les requêtes historiques
ok un grand merci à tous ! j'ai commencé par le promtool analyze et effectivement le user_id était le gros coupable. je vais implémenter le relabeling pour le virer et voir pour les recording rules. ça devrait déjà bien dégrossir le problème. je vous tiens au courant
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la team on a un gros pb de perfs avec prometheus. les requêtes grafana prennent des plombes et souvent time-out. j'ai l'impression qu'on a un max de metrics avec des labels à gogo genre un id unique par requête http ou des choses comme ça. ça sent la high cardinality à plein nez non ?
c'est ingérable on a des millions de séries j'imagine