Prometheus alerte fatigue ca soule à force

laurent-roger 08/02/2025
RÉSOLU

putain mais ras le bol des alertes prometheus qui sonnent pour rien ! on a une tonne d'alertes "service down" ou "high latency" qui sont des faux positifs parce que la métrique a fait un petit pic une seconde. ca rend les ops fous et on finit par ignorer. comment vous faites pour tuner vos alerts sans rater les vrais trucs ?

08/02/2025 à 09:18

10 commentaires

yvalette
Membre
Avatar de yvalette
yvalette
Membre

classique le for clause. au lieu d'alerter direct si up == 0, fais for: 5m. ça veut dire que la condition doit être vraie pendant 5 minutes avant que ça alerte. et regarde bien tes sum by ou avg by pour éviter d'agréger trop large.

Modifié le 23/05/2026 à 16:20
sabine13
Membre Actif
Avatar de sabine13
sabine13
Membre Actif

les recording rules c'est la vie. si tu calcules un truc complexe ou qui demande du cpu, tu le pré-agrèges dans une recording rule. ça allège les query alertes et ça peut lisser des petits pics. par exemple un sum_over_time ou avg_over_time sur 1m ou 5m.

Modifié le 23/05/2026 à 16:20
leon92
Membre Actif Secouriste
Avatar de leon92
leon92
Membre Actif Secouriste

étiquette tes alertes avec des niveaux de sévérité. severity: critical, severity: warning, severity: info. et tu routes les critiques vers pagerduty, les warnings vers slack et les infos vers un dashboard. ça filtre le bruit et les gens savent quoi regarder.

Modifié le 23/05/2026 à 16:20
yvalette
Membre
Avatar de yvalette
yvalette
Membre

pour les services down, utilise blackbox exporter. plutôt que de te baser sur l'uptime de l'instance, blackbox va faire un vrai appel HTTP ou TCP vers ton service. ça détecte mieux un service qui tourne mais répond plus.

11/02/2025 à 21:10
sabine13
Membre Actif
Avatar de sabine13
sabine13
Membre Actif

attention aussi à la fonction absent(). si une métrique disparait totalement (genre un pod s'est crashé et n'expose plus rien), l'alerte up == 0 ne sonnera pas. absent(up{job="mon_service"}) est là pour ça.

Modifié le 23/05/2026 à 16:20
celina14
Membre Actif
Avatar de celina14
celina14
Membre Actif

côté alertmanager, utilise les group_by et les repeat_interval pour pas te spammer. si 100 pods tombent, tu veux une seule alerte "mon service est en PLS" pas 100 "pod X est down". et les silences temporaires pour les maintenances.

Modifié le 23/05/2026 à 16:20
leon92
Membre Actif Secouriste
Avatar de leon92
leon92
Membre Actif Secouriste

les alertes basées sur les SLO/SLI sont bien plus efficaces. au lieu de dire "cpu > 80%", tu dis "la latence p99 des requêtes est > X ms pendant Y minutes". ça alerte sur l'impact utilisateur pas sur une métrique d'infra brute.

14/02/2025 à 15:29
yvalette
Membre
Avatar de yvalette
yvalette
Membre

quand tu fais du rate() sur des compteurs, assure-toi d'utiliser des intervalles suffisamment longs pour lisser les pics. rate(http_requests_total[5m]) est souvent mieux que [1m]. et les métriques de type histogram pour bien comprendre la distribution des latences.

Modifié le 23/05/2026 à 16:20
sabine13
Membre Actif
Avatar de sabine13
sabine13
Membre Actif

si tu as plusieurs métriques pour une même alerte, utilise group_left ou group_right avec on (label) pour joindre et ajouter du contexte. ça enrichit tes alertes et aide au debugging direct sans avoir à chercher 10 dashboards.

Modifié le 23/05/2026 à 16:20

ok merci pour les tips ! les recording rules j'y avais pas pensé pour le lissage et le for clause je vais revoir tous mes alertes critiques avec ça. et le SLO based alerting c'est clairement la direction à prendre. good job la commu !

Modifié le 23/05/2026 à 16:20

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