SRE : Prometheus 'high cardinality' avec des métriques k8s

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

d'acc je vois l'idée. du coup je dois analyser quelles sont les métriques et les labels qui causent le plus de problèmes. y'a un outil ou une requête promql pour identifier les métriques à haute cardinalité ?

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

super ces requêtes promql ! j'ai pu identifier les métriques les plus problématiques et j'ai commencé à appliquer des relabel_configs pour nettoyer les labels type container_id et pod_uid. prometheus respire déjà mieux. merci pour les tips !