6 commentaires
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
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
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
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
Laisser une réponse
Vous devez être connecté pour poster un message !
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 ?
on est sur k8s avec un prometheus en mode centralisé, pas de sidecar