prometheus trop lent avec beaucoup de targets

anne67 26/09/2025
RÉSOLU
anne67
Auteur Actif
Avatar de anne67
anne67
Auteur Actif

yo la team ! on a une infra k8s qui grossit vite. on a des milliers de pods et prometheus commence à ramer pour scraper tout ça. genre il met des dizaines de secondes à faire un cycle complet les scrapes ratent on a des missing metrics. n'importe quoi. on est en HA avec deux prom server mais ça change rien.

26/09/2025 à 22:19

10 commentaires

fhebert
Membre Secouriste
Avatar de fhebert
fhebert
Membre Secouriste

hello ! c'est classique le scale de prom. déjà est-ce que tu fais du relabeling efficace ? virer les labels super volatiles ou à haute cardinalité dès le début du scrape sinon ta base tsmdb explose.

27/09/2025 à 19:44
fhubert
Membre
Avatar de fhubert
fhubert
Membre

ouais le relabeling c'est clé. regarde aussi tes

scrape_interval
et
evaluation_interval
. si c'est trop agressif pour des milliers de targets ça explose. et la taille de tes exporters. certains exportent 10k métriques par pod. faut trier.

28/09/2025 à 16:45
anne67
Auteur Actif
Avatar de anne67
anne67
Auteur Actif

on a déjà fait un peu de relabeling mais on peut optimiser.

scrape_interval
est à 30s.
evaluation_interval
à 30s aussi. les exporters c'est du node-exporter et cadvisor principalement. les autres sont custom mais on les a monitorés ils sont pas trop verbeux.

29/09/2025 à 10:56
fhebert
Membre Secouriste
Avatar de fhebert
fhebert
Membre Secouriste

ok. alors next step c'est la storage. si t'es sur du disque lent ça va freiner. prom est très io-bound. un bon ssd rapide c'est vital. et t'as combien de cores et de ram sur tes prom instances ?

30/09/2025 à 09:37
nmarques
Membre
Avatar de nmarques
nmarques
Membre

si t'as vraiment beaucoup de targets et de métriques uniques, faut passer au "sharding" ou "federation". soit tu uses thanos/cortex pour ça soit tu run plusieurs prometheus qui scrapent chacun une partie de ton cluster k8s. par exemple par namespace ou par node.

01/10/2025 à 05:56
fhubert
Membre
Avatar de fhubert
fhubert
Membre

précisément. pour le sharding tu peux jouer avec le

__meta_kubernetes_pod_uid
ou d'autres meta labels pour distribuer les targets sur différents prometheus. ça demande une config plus complexe mais ça scale beaucoup mieux. prometheus seul c'est pas fait pour gérer des dizaines de milliers de targets d'un coup.

02/10/2025 à 02:43
anne67
Auteur Actif
Avatar de anne67
anne67
Auteur Actif

nos disques sont des gp3 sur aws pas de soucis de perf là. instances sont des m5.xlarge (4 cores 16gb) pour les deux prom. le sharding on y pense mais ça rajoute une complexité de dingue. c'est vraiment la seule solution ?

03/10/2025 à 01:58
fhebert
Membre Secouriste
Avatar de fhebert
fhebert
Membre Secouriste

pour du k8s à cette échelle oui le sharding est quasi obligatoire si tu veux de la perf stable. les 4 cores et 16gb c'est ptete un peu light si t'as beaucoup de séries et de churn. monitoring des metrics internes de prometheus lui-même est crucial.

prometheus_tsdb_head_samples_appended_total
prometheus_target_scrapes_missed_total

03/10/2025 à 23:44
nmarques
Membre
Avatar de nmarques
nmarques
Membre

regarde

prometheus_engine_query_duration_seconds_count
et
prometheus_engine_query_duration_seconds_sum
pour voir si les requêtes sont le bottleneck. aussi les rules evaluation.
prometheus_rule_evaluation_duration_seconds

04/10/2025 à 19:27
anne67
Auteur Actif
Avatar de anne67
anne67
Auteur Actif

bon je crois que je vais devoir me faire à l'idée du sharding alors. je vais commencer par les metrics internes de prom pour voir où ça tape le plus. merci pour les pistes c'est beaucoup plus clair maintenant.

05/10/2025 à 18:05

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire