6 commentaires
alors pour le flapping c'est le grand classique. t'as plusieurs options. la première c'est d'utiliser l'option FOR de ton alert rule. genre si l'alerte est ON depuis moins de 5min tu la déclenches pas. ça lisse les spikes rapides.
- alert: myflappingservice
expr: up{job="my-worker"} == 0
for: 5m # l'alerte doit être vraie pendant 5 minutes avant de se déclencher
labels:
severity: warning
annotations:
summary: "my worker is down for too long"
ouais le FOR c la base. si ça suffit pas tu peux aussi jouer sur les seuils. si ton service est lent mais pas down, ptete que ton healthcheck est trop agressif. tu peux le passer de 1s à 5s pour avoir une meilleure fenêtre. ou si c une métrique, ajuste le seuil de déclenchement.
y'a aussi le concept de silences dans alertmanager si c'est un problème connu et temporaire. tu peux faire un silence de X heures. mais c'est pas une solution long terme. pour le long terme il faut des bons seuils et un bon FOR.
le FOR j'y avais pensé mais je savais pas trop quelle durée. 5m ça me semble pas mal. pour les seuils le souci c'est que le service est vraiment down quand le healthcheck fail même si c'est pour 30s. c'est la nature de ce worker batch. l'idée c'est de notifier si il est en carafe longtemps pas juste un petit hoquet.
dans ce cas un truc qu'on fait c'est une combinaison FOR et un compteur de défaillances. plutot que d'alerter si c'est DOWN, tu alertes si COUNTER_OF_FAILURES_PER_MINUTE > X pendant Y minutes. ça permet de tolérer quelques drops mais pas un flot constant.
Laisser une réponse
Vous devez être connecté pour poster un message !
yo la team j'ai un problème d'alert fatigue avec prometheus. on a une alerte sur le healthcheck d'un service interne (genre un worker qui fait du traitement batch) et elle passe son temps à flapper on/off toutes les 5min. le service est pas down complètement juste il met du temps à répondre parfois quand y'a des pics de charge. mais du coup on est spammé de notifs et on rate les vraies alertes. comment on gère ça proprement ?