Prometheus alerte fatigue ca soule à force

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.

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.

é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.

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.

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.

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.

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.

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.

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.

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 !