Alertes prometheus qui spamment sur mes pods en init

Posté par gros-victor le 07/01/2025
RÉSOLU

gros-victor

Membre depuis le 16/08/2019

yo la team SRE

j'ai un problème chiant avec prometheus quand je déploie une nouvelle version de mon app sur k8s (un service statefulset postgres) mes alertes "PodNotReady" ou "ContainerCrashing" se déclenchent en boucle pendant 2-3 minutes le temps que les pods postgres se synchronisent et deviennent healthy

c'est super bruyant et ça masque les vrais problèmes. comment vous gérez ça ? j'ai pas envie de mettre un for: 5m sur toutes les alertes c'est trop long pour les vrais incidents


# exemple d'alerte
- alert: PodNotReady
  expr: |
    sum by (namespace, pod) (
      kube_pod_container_status_ready{job="kube-state-metrics", container=~".+"} == 0
      and
      kube_pod_status_phase{job="kube-state-metrics"} == "Running"
    ) > 0
  for: 1m
  labels:
    severity: warning
  annotations:
    summary: Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} is not ready

Commentaires

pascal-dominique

Membre depuis le 28/01/2020

hello bah le truc classique c de jouer avec le for. mais si tu veux pas ça la solution c des labels dynamiques sur tes pods. quand tu déploies tu ajoutes un label genre "monitoring=paused" et ton alerte rule exclut ces pods

ou alors mieux dans ta règle prometheus tu ajoutes un `unless` ou `and on(pod, namespace) (kube_pod_status_phase != "Pending")` ou des choses comme ça. regarde les metrics kube_pod_status_phase kube_pod_status_condition

gros-victor

Membre depuis le 16/08/2019

ouais j'ai déjà le `kube_pod_status_phase == "Running"` pour éviter les pending ou terminated. mais les pods en init sont "Running" avant d'être "Ready"

le label dynamique c'est une option mais ça veut dire intégrer ça dans mon ci/cd c'est pas ouf

pascal-dominique

Membre depuis le 28/01/2020

ok je vois. alors la solution propre c'est `kube_pod_container_status_started{job="kube-state-metrics", container=~".+"} == 1`. ça indique si le container a commencé à tourner. si tu combines ça avec ready et une durée tu peux filter

ou alors regarde la condition `Initialized` ou `ContainersReady` via `kube_pod_status_condition{condition="Initialized", status="true"}` ça te donne quand les init containers sont passés. tu peux ajouter un `for: 30s` sur cette condition

gros-victor

Membre depuis le 16/08/2019

hum kube_pod_container_status_started c'est intéressant ça. si je dis podnotready et container est started depuis moins de x minutes alors pas d'alerte. ça peut être pas mal

pascal-dominique

Membre depuis le 28/01/2020

exactement. tu peux faire un truc du genre :


sum by (namespace, pod) (
  kube_pod_container_status_ready{container=~".+"} == 0
  and
  kube_pod_status_phase == "Running"
  and
  # et là tu ajoutes une condition sur le temps depuis le démarrage du container
  # par exemple, on alerte que si le container est démarré depuis plus de 5min
  # faut trouver la bonne métrique de temps de démarrage
  # ou utiliser `kube_pod_container_status_started` avec un offset
) > 0

c'est plus complexe à écrire mais beaucoup plus précis pour éviter le bruit

gros-victor

Membre depuis le 16/08/2019

ok je vois. en fait j'ai trouvé un truc plus simple en combinant kube_pod_status_condition{condition="Ready", status="false"} avec un truc pour dire que le pod est plus jeune que 5min. comme ça les pods qui viennent de spawn sont ignorés. ça a l'air de marcher avec ma phase de rollout. je vais tester ça en prod

pascal-dominique

Membre depuis le 28/01/2020

nickel. l'essentiel c'est de trouver la métrique qui reflète le "je suis en train de me setup" et l'exclure du périmètre d'alerte pour une courte période. thx pour le feedback

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire