prometheus trop lent avec beaucoup de targets

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.

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

scrape_interval

evaluation_interval

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

scrape_interval

evaluation_interval

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 ?

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.

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

__meta_kubernetes_pod_uid

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 ?

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

regarde

prometheus_engine_query_duration_seconds_count

prometheus_engine_query_duration_seconds_sum

prometheus_rule_evaluation_duration_seconds

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.