Membre depuis le 17/02/2025
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
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
Commentaires
lucas-hernandez
Membre depuis le 16/06/2024
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
Membre depuis le 02/04/2024
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
Membre depuis le 17/02/2025
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
Membre depuis le 16/06/2024
tu peux utiliser un join genre group_left. un truc comme ça :
ça te donne le nombre de pods failed par déploiement. tu peux ensuite mettre un threshold là-dessus
jacques95
Membre depuis le 04/11/2024
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
Membre depuis le 17/02/2025
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 !