5 commentaires
salut ! ouais la high cardinality c'est le cancer de prometheus. souvent faut utiliser des relabel_configs sur tes jobs pour virer ou transformer les labels qui changent tout le temps. par exemple virer container_id ou remplacer pod_name par un nom de déploiement plus générique
# exemple de relabel_config
- source_labels: [__meta_kubernetes_pod_name]
regex: "(.*)-[a-z0-9]{5}$"
target_label: deployment_name
replacement: "$1"
- source_labels: [__meta_kubernetes_container_id]
action: drop
exacte ! et faut aussi checker tes metric_relabel_configs. ça c'est pour agir directement sur le nom ou les labels de la métrique après le scraping. des fois certaines métriques sont juste pas utiles et tu peux les dropper complètement pour soulager prometheus
oui tu peux utiliser count by (__name__, job, instance) ({__name__=~".+"}) ça te donnera le nombre de séries temporelles pour chaque métrique combiné avec le job et l'instance. ça aide à identifier les coupables. et aussi topk(10, count by (__name__) ({__name__=~".+"})) pour les métriques les plus nombreuses
Laisser une réponse
Vous devez être connecté pour poster un message !
bonjour la team j'ai prometheus qui rame grave et me balance des alertes sur la
high cardinalityde mes métriques. c principalement des métriques de pods k8s qui ont des labels commepod_namecontainer_idetc. on a des centaines de pods ça devient ingérable. comment vous gérez ça sans perdre trop d'infos ?