7 commentaires
Ouais le flapping d'alertes c'est chiant. Tu utilises quelle clause FOR dans tes règles d'alerte ? Si t'en as pas ou si elle est trop courte, genre FOR 1m, dès que ça dépasse la métrique paf ça alerte. Essaye de mettre un FOR 5m ou 10m pour que la condition persiste avant de déclencher.
J'ai déjà un FOR 2m sur la plupart. C'est pas ouf mais on veut être réactifs. Le problème c'est que le CPU monte et descend régulièrement mais jamais très longtemps. Du coup ça déclenche, ça résout, ça déclenche, etc. même avec 2min.
en plus du for, regarde la config de ton alertmanager. t'as configuré des inhibit rules ou des group_by pour éviter le spam ? si tes alertes sont similaires sur plusieurs instances mais que tu t'en fous d'être notifié pour chaque instance séparément, le group_by aide à ne recevoir qu'une seule notification groupée.
Alors l'Alertmanager a des group_by sur l'alerte name mais pas plus fin que ça. Et pas d'inhibit rules spécifiques à ce genre de cas de flapping.
Essaie d'ajouter un group_by: ['alertname', 'service', 'severity'] si ça a du sens pour toi. Et regarde les repeat_interval sur tes receivers. Si c'est trop court genre 1m, tu peux avoir des repush de l'alerte si elle se résout et revient vite.
Ok, le avg_over_time et le group_by plus précis dans Alertmanager, je tente ça. J'ai remonté le FOR à 3m et j'ai mis le avg_over_time sur 5m pour les CPU. Ça a l'air de beaucoup mieux fonctionner, on a quasiment plus de spam pour ces petites variations. Merci pour les tips !
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la team ! j'ai un souci avec nos alertes prometheus. on a des alertes qui se déclenchent pour un rien ou qui reviennent en boucle alors que le problème est résolu. par exemple, une alerte sur l'utilisation cpu d'un service qui monte à 90% pendant 30s, l'alerte part, puis ça redescend, et 5 min après ça remonte 30s, l'alerte repart. ça spamme nos channels slack pour des micro-incidents. y'a un truc pour calmer le jeu ?