Prometheus alerte sur la cardinalité quand un service crash en boucle

Question

salut les pros de l'op
on a un microservice qui fait des siennes en prod, il crash en boucle depuis ce matin. le souci c'est que prometheus hurle à cause de la cardinalité. notre règle d'alerte pour les pods down (kube_pod_status_phase{phase="Failed"}) génère des milliers de timeseries nouvelles à chaque crash car le pod a un nouveau nom à chaque fois. du coup prometheus galère, ça bouffe le storage et le query engine. comment vous gérez ça ?

# règle d'alerte simplifiée
ALERT PodFailed
  IF kube_pod_status_phase{phase="Failed"} == 1
  FOR 5m
  LABELS {
    severity = "warning"
  }
  ANNOTATIONS {
    summary = "Pod {{ $labels.pod }} failed to start",
    description = "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} has been in a failed state for more than 5 minutes."
  }

on est sur k8s avec un prometheus en mode centralisé, pas de sidecar

lucas-hernandez · Answer

salut
classique. le problème c'est que le label pod c'est le nom du pod qui inclut un hash ou un uuid. ce que tu veux c'est alerter sur le déploiement ou le service qui est derrière, pas chaque instance de pod qui échoue. essaie de regrouper par deployment ou owner.name

tmartineau · Answer

exactement ce que dit l'autre. utilise kube_pod_owner pour mapper les pods à leurs contrôleurs (deployment, replicaset). tu peux faire un count sur les pods failed par owner_name. ça réduit drastiquement la cardinalité et tu as une alerte par déploiement défectueux

anais67 · Answer

ah ok je vois l'idée. donc au lieu de kube_pod_status_phase je ferais un truc avec kube_pod_owner ? mais comment je lie les deux pour avoir le statut failed ?

lucas-hernandez · Answer

tu peux utiliser un join genre group_left. un truc comme ça :

sum by (owner_name, namespace) (
  kube_pod_status_phase{phase="Failed"} * on (pod, namespace) group_left(owner_name)
  kube_pod_owner{owner_kind="Deployment"}
)

ça te donne le nombre de pods failed par déploiement. tu peux ensuite mettre un threshold là-dessus

jacques95 · Answer

ouais et même plus simple si tu veux juste alerter quand un seul pod fail et pas spammer, tu peux faire un count over time sur un laps de temps plus long, ça lisse le bruit et tu captes les vrais problèmes récurrents sans créer 50k timeseries temporaires

anais67 · Answer

j'ai testé la query avec group_left et c exactement ça qu'il me fallait ! maintenant j'ai une métrique agrégée par deployment, ça gère la cardinalité et l'alerte est plus pertinente. j'ai pu virer les vieilles alerts. merci un max !

Prometheus alerte sur la cardinalité quand un service crash en boucle

Commentaires

Laisser une réponse

Comprendre et utiliser Packetbeat dans la stack ELK

2 Ans d'Expérience : Intégrer l'IA dans les Workflows de Développement

La gestion de l'audio en SDL2

Rejoindre la communauté