6 commentaires
hello t'as checké la cardinalité de tes métriques ? c'est souvent la cause des OOMs. si tu as des labels avec des valeurs très dynamiques et uniques (genre request ID, pod name sans sélecteur intelligent) ça explose la mémoire car Prometheus doit stocker toutes les séries temporelles
ouais la cardinalité c'est le grand classique. tu peux utiliser PromQL pour identifier les métriques les plus gourmandes. genre regarde topk(10, count by (__name__)({__name__=~".+"})) pour avoir une idée des noms de métriques et topk(10, count by (job, instance, ...) ({__name__=~".+"})) pour voir la cardinalité par job/instance
aussi la rétention des données. si tu gardes trop de données sur une longue période ça va bouffer ta RAM et ton disque. quelle est ta config de rétention ?
la rétention est à 15 jours par défaut. je vais regarder la cardinalité. j'ai effectivement des services qui balancent pas mal de labels dynamiques. je vais essayer de les nettoyer avec un relabel_config
n'oublie pas non plus que Prometheus est un peu gourmand en CPU pour le TSDB. assure-toi que tes cpus sont pas throttlés par K8s si les requests/limits sont trop bas par rapport à l'activité réelle
j'ai bien trouvé des labels à la con avec des IDs uniques sur une de mes apps. j'ai mis en place un relabel_config pour les virer et après redémarrage la mémoire est stable et Prometheus tient le coup. Ouf ! merci pour les pistes
Laisser une réponse
Vous devez être connecté pour poster un message !
salut les sres ! j'ai un Prometheus qui tourne sur un K8s worker et il se fait OOMKilled régulièrement. J'ai alloué 8Go de RAM et 4 cpus, ce qui est censé être suffisant pour mon infra. Les métriques indiquent une utilisation mémoire d'environ 6-7Go avant le crash. Je scrappe pas des milliers de cibles non plus. Des idées sur ce qui bouffe la RAM ?