12 commentaires
hello ! oomkill sur prometheus avec grafana ça sent la cardinality explosive. tu scrapes des métriques avec des labels qui changent trop souvent? genre des IDs de requêtes, des UUIDs? si oui, faut relabel au scrape avec un labeldrop ou label_replace pour réduire le nombre de séries uniques
et regarde la durée de tes requêtes. si tes dashboards interrogent sur des périodes trop longues (plusieurs jours ou semaines) avec des agrégations complexes (rate, sum by, histogram_quantile), ça demande bcp de ram. essaye de réduire les plages de temps pour voir si ça tient mieux
t'as check le storage.tsdb.retention.time dans ta config prometheus? si c'est trop long et que ton volume est trop grand ça peut aussi être une raison. et le query.max-concurrent et query.timeout peuvent aider un peu mais c'est pas une solution miracle
regarde aussi les métriques internes de prometheus lui-même. prometheus_tsdb_head_series et prometheus_tsdb_head_chunks c'est clé pour la cardinality. le endpoint /api/v1/status/tsdb te donne une bonne vue de l'état de la base et des séries à forte cardinality
ouais j'ai pas mal de métriques applicatives qui ont des tags dynamiques. par exemple on tag les requêtes http avec un trace_id. ça crée plein de séries uniques c'est clair. les dashboards interrogent sur 24h à 7j selon le dashboard
pour les plages longues, si tu as besoin d'historique, pense à un setup avec Thanos ou Cortex pour le long-term storage, et utilise le query frontend pour faire de la downsampling ou des requêtes distribuées. ton prometheus local sera moins sollicité
fais gaffe aussi si tu fais des group_left ou group_right avec beaucoup de séries. ça peut aussi faire des gros pics de ram. privilégie les on() si tu peux
ok je vais mettre en place un relabel_configs pour supprimer le trace_id et d'autres labels à haute cardinality. j'ai regardé le tsdb stats et j'ai une métrique qui a plus de 10 millions de séries actives à cause de ça. c'est bien le souci. thx les gars je vous tiens au jus
j'ai déployé la nouvelle config de scrape avec le relabeling. prometheus est stable depuis quelques heures et les dashboards s'ouvrent sans souci. merci à tous pour les pistes c'était bien la cardinality le problème!
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la team sre. notre prometheus (un seul pod sur k8s) se fait oomkiller régulièrement quand on ouvre certains dashboards grafana. y'a des requêtes promql qui sont un peu lourdes je pense mais je vois pas trop comment optimiser sans casser les dashboards. la limite de ram est à 16g mais ça suffit pas parfois