3 commentaires
C'est probablement une explosion de cardinalité sur certaines metrics. Tu peux interroger l'API de Prometheus pour voir quels labels ou noms de metrics sont les plus lourds dans ton TSDB.
promtool tsdb analyze /prometheusRegarde aussi si t'as pas des devs qui ont push des metrics avec des ID d'utilisateurs ou des timestamps en labels. Ça tue le scheduler et sature la mémoire direct. Tu peux aussi limiter le nombre de samples par target dans ta config.
scrape_configs:
- job_name: 'my-app'
sample_limit: 10000Le promtool tsdb analyze a sauvé ma journée. C'était une metric custom qui enregistrait l'email des clients en label... J'ai viré ça et la RAM est redevenue stable. Merci !
Je vais aussi ajouter le sample limit pour éviter que ça recommence.
Laisser une réponse
Vous devez être connecté pour poster un message !
Mon instance Prometheus explose en RAM depuis ce matin et finit en OOMKilled toutes les heures. J'ai pourtant pas ajouté tant de targets que ça.
Vous avez une astuce pour identifier quel job bouffe tout avant que le container crash ?