Prometheus qui oomkiller sur des requêtes dashboard

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

le `trace_id` en label c'est le pire ennemi de prometheus. il faut absolument virer ça au scrape. tu peux utiliser un `relabel_configs` dans ton `scrape_configs` pour supprimer ce label avant que prometheus l'ingère

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

et après un relabeling propre, si tu vois que la ram est toujours limite, tu peux essayer de monter `GOMAXPROCS` ou ajuster les limites CPU de ton pod prometheus. mais la cardinality c 90% du problème des oomkills

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

good luck ! ça va te sauver la vie (et la ram de prometheus)

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!