Alerting — du dashboard qui attend au système qui prévient
Le concept en une phrase
Section intitulée « Le concept en une phrase »Une alerte est une règle qui évalue en continu une condition sur vos données et notifie un humain quand elle devient vraie — le dashboard regarde, l’alerte réveille.
Un dashboard Grafana affiché sur un écran ne sert à rien si personne ne le regarde à 3h du matin quand le disque de la VM monitoring de Port-aux-Français se remplit. L’alerting inverse la logique : au lieu d’attendre qu’un humain vienne consulter l’état du système, c’est le système qui vient chercher l’humain — par un message, au bon moment, sur le bon canal.
Les grands principes
Section intitulée « Les grands principes »1. Seuil vs symptôme — alerter sur ce qui fait mal
Section intitulée « 1. Seuil vs symptôme — alerter sur ce qui fait mal »Le premier réflexe est d’alerter sur des seuils techniques bruts : « CPU > 80 % ». C’est souvent une mauvaise alerte : un pic de CPU pendant une sauvegarde nocturne ne dérange personne. La bonne question n’est pas « qu’est-ce qui dépasse un chiffre ? » mais « qu’est-ce qui dégrade ce que vit l’utilisateur ou la mission ? ».
- Alerte sur seuil technique — utile en complément, jamais suffisante seule (le CPU à 95 % pendant 2 secondes n’est pas un incident).
- Alerte sur symptôme — le service ne répond plus, la latence dépasse ce que le métier tolère, une base devient inaccessible. C’est ce qui mérite de réveiller quelqu’un.
Sur les bases australes, le symptôme qui compte souvent est simple : « ce service est-il joignable et répond-il dans un délai acceptable ? » — pas la cause technique sous-jacente.
2. La chaîne — règle → évaluation → routage → notification
Section intitulée « 2. La chaîne — règle → évaluation → routage → notification »Une alerte n’est jamais un seul mécanisme, mais une chaîne à quatre étapes :
flowchart LR
R[Règle\nex: up == 0 pendant 2min] --> E[Évaluation continue]
E -->|condition vraie| A[Alerte déclenchée]
A --> RT[Routage\npar sévérité/équipe]
RT --> N[Notification\nDiscord]
Dans TAAF, cette chaîne s’incarne concrètement : Grafana Alerting (ou Prometheus + Alertmanager) évalue les règles en continu, décide de la sévérité, route vers le bon canal, et pousse la notification vers Discord. Chaque maillon peut être la cause d’une alerte qui n’arrive jamais — une règle mal écrite, un routage oublié, un webhook expiré.
3. Sévérités et routage — qui est prévenu, comment
Section intitulée « 3. Sévérités et routage — qui est prévenu, comment »Toutes les alertes ne méritent pas le même traitement. Une hiérarchie simple :
| Sévérité | Exemple | Canal |
|---|---|---|
| Critique | Base inaccessible, disque plein | Notification immédiate, canal dédié |
| Avertissement | Latence dégradée, ressource proche du seuil | Canal de suivi, pas de réveil |
| Info | Tendance à surveiller | Dashboard seul, pas de notification |
Router toutes les alertes vers le même canal, avec la même urgence, revient à ne plus avoir de hiérarchie du tout.
4. La fatigue d’alerte — l’ennemi n°1
Section intitulée « 4. La fatigue d’alerte — l’ennemi n°1 »Une alerte ignorée équivaut à l’absence d’alerte. Si un canal Discord reçoit cinquante notifications par jour dont quarante-cinq sont sans conséquence, l’humain apprend très vite à ne plus les lire — y compris le jour où l’alerte critique arrive. C’est la fatigue d’alerte : le vrai risque n’est pas de sous-alerter, c’est de sur-alerter jusqu’à rendre le signal inutile.
Retenez : une bonne alerte est rare, actionnable, et pousse vers une action claire. Sinon, elle n’a pas sa place en notification — au mieux sur un dashboard.
5. Silence, regroupement, répétition
Section intitulée « 5. Silence, regroupement, répétition »Trois mécanismes évitent la sur-notification sans supprimer l’information :
- Silence — désactiver temporairement une alerte connue (maintenance planifiée, incident déjà pris en charge).
- Regroupement (grouping) — fusionner plusieurs alertes liées à la même cause en une seule notification, plutôt que de spammer une par service touché.
- Répétition (repeat interval) — ne renvoyer la notification qu’après un délai si la condition persiste, au lieu de la répéter à chaque évaluation.
Ces trois leviers, portés par Alertmanager ou par Grafana Alerting, sont ce qui rend une stack d’alerting vivable au quotidien plutôt qu’épuisante.
Où ça sert dans TAAF
Section intitulée « Où ça sert dans TAAF »- TP4 — Alerting (Acte 1) — créer des règles d’alerte Prometheus et router les notifications par webhook : l’usage opérationnel, sur la santé de l’infrastructure.
- TP — Alerting & Notification Discord (Acte 2) — provisionner une alerte Grafana depuis une règle Sigma, la router vers Discord, et tuner les faux positifs : le même concept, appliqué cette fois à la détection de sécurité plutôt qu’à la disponibilité.
- Métriques & le modèle pull — l’alerting s’appuie sur les métriques et les logs déjà collectés ; sans eux, aucune règle n’a de donnée à évaluer.
Ressources associées
Section intitulée « Ressources associées »Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Observabilité.
- Grafana Alerting — documentation officielle : la chaîne règle/évaluation/notification côté Grafana.
- Prometheus Alertmanager — documentation officielle : grouping, silences, routing en détail.
À chercher par vous-même : « alert fatigue », « symptom-based alerting vs cause-based », « Alertmanager routing tree », « Grafana Alerting vs Prometheus Alertmanager ».