Supervision (5/5) — Alertmanager & les alertes

L’idée reçue

« J’ai des tableaux de bord Grafana : je verrai les problèmes. »

À condition de regarder — or personne ne fixe un écran à 3 h du matin. Un bon système ne demande pas qu’on le surveille : il prévient quand ça dérape. C’est le rôle des alertes : passer d’une vigilance humaine et continue à une vigilance automatique. C’est le maillon qui rend toute la supervision réellement utile.

À la fin de ce module, tu sauras…

Distinguer les deux temps de l’alerting : évaluer, puis router
Écrire une règle d’alerte en PromQL dans Prometheus
Comprendre le rôle d’Alertmanager (routage, groupement, notification)
Boucler la chaîne d’observabilité de bout en bout

01Deux temps : évaluer, puis router

L’alerting se fait en deux étapes, portées par deux composants distincts. Confondre les deux est l’erreur classique.

Étape	Qui	Rôle
Évaluer	Prometheus	vérifier des règles PromQL en continu, déclencher si vrai
Router	Alertmanager	recevoir les alertes, grouper, dédupliquer, notifier

Comprends pourquoi séparer les deux

Prometheus sait quand quelque chose ne va pas (il a les données et les règles). Alertmanager sait quoi en faire (à qui envoyer, comment grouper, quand se taire). Séparer « détecter » de « notifier » permet de changer l’un sans l’autre : mêmes règles, mais notifications vers un autre canal ; ou même routage pour des alertes venant de sources différentes. Cette séparation détection/notification est un principe qu’on retrouve dans tous les systèmes d’alerting.

02Écrire une règle d’alerte

Expérience 1

Une condition PromQL qui déclenche

Une règle d’alerte est une requête PromQL (module 8.2) assortie d’une durée et d’un message. Exemple : alerter si un Pod redémarre en boucle.

Manipule

groups:
- name: soria-alertes
  rules:
    - alert: PodCrashLooping
      expr: rate(kube_pod_container_status_restarts_total{namespace="lab-soria"}[5m]) &gt; 0
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Un Pod redemarre en boucle dans lab-soria"
        description: "Le Pod {{ $labels.pod }} redemarre depuis 5 minutes."

Comprends expr, for, labels, annotations

expr = la condition PromQL ; tant qu’elle est vraie, l’alerte « couve ». for: 5m = elle ne se déclenche que si la condition reste vraie 5 minutes (évite les fausses alertes sur un pic passager). labels (ex. severity) servent au routage ; annotations portent le message lisible. Cette structure — condition + durée + métadonnées — est le cœur de toute règle d’alerte, quel que soit l’outil.

Le rôle du « for » — éviter le bruit Une alerte qui se déclenche pour un pic d’une seconde est une nuisance : à force de fausses alertes, on finit par toutes les ignorer (la « fatigue d’alerte »). Le for impose que le problème persiste avant d’alerter. Une bonne alerte est rare, vraie, et actionnable : si elle sonne, c’est qu’il faut agir.

03Alertmanager : router et notifier

Expérience 2

Que se passe-t-il quand une alerte se déclenche

Prometheus envoie les alertes actives à Alertmanager (déployé avec la stack). Sa configuration décide du routage et du canal de notification. Structure de principe :

Manipule

route:
group_by: ['alertname', 'namespace']
group_wait: 30s
repeat_interval: 4h
receiver: 'equipe-soria'
receivers:
- name: 'equipe-soria'
  email_configs:
    - to: 'ops@mondomaine.fr'

Vérifie les alertes en cours dans l’interface d’Alertmanager :

Manipule

kubectl -n observabilite port-forward svc/prometheus-alertmanager 9093:80

Sur http://localhost:9093, tu vois les alertes reçues, groupées. Alertmanager rassemble les alertes similaires, évite les doublons, et notifie le receiver configuré.

Comprends group, dédup, silence, receiver

Alertmanager fait plus que « envoyer un mail » : il groupe les alertes liées (10 Pods qui tombent = 1 notification, pas 10), déduplique, respecte un repeat_interval (ne pas répéter trop souvent), et permet des silences (couper une alerte pendant une maintenance). Les receivers définissent les canaux (email, messagerie d’équipe, système d’astreinte…). Le routage par labels envoie chaque type d’alerte au bon endroit (les critical à l’astreinte, le reste par mail). Toute cette logique est indépendante de l’outil de notification choisi.

04Boucler la chaîne : le problème des 3 h du matin, résolu

Expérience 3

Prouver toute la chaîne d’observabilité

Provoque volontairement l’incident, et suis-le à travers toute la stack :

Manipule

# casser volontairement soria-web (image inexistante -> CrashLoop)
kubectl -n lab-soria set image deploy/soria-web soria-web=harbor.mondomaine.fr/soria/soria-web:inexistant

Métrique (Prometheus/Grafana) : le taux de redémarrage grimpe.
Règle (Prometheus) : après 5 min, l’alerte PodCrashLooping passe en firing.
Routage (Alertmanager) : l’alerte est groupée et notifiée au receiver.
Log (Loki) : tu ouvres les logs du Pod et lis la cause exacte (image introuvable).

Manipule

# reparer
kubectl -n lab-soria set image deploy/soria-web soria-web=harbor.mondomaine.fr/soria/soria-web:2.0

Tu viens de vivre la chaîne complète : détecter (métrique) → alerter (règle + routage) → diagnostiquer (log). Le problème des 3 h du matin est résolu : tu es prévenu automatiquement, et tu as tout pour comprendre.

Comprends ce que tu as vraiment construit

Ton infrastructure n’est plus muette : elle mesure (Prometheus), montre (Grafana), garde la mémoire (Loki) et prévient (Alertmanager). Les quatre piliers du module 8.1 sont en place et connectés. Surtout, tu as compris les rôles — collecte, visualisation, agrégation de logs, alerting — qui restent valables sur n’importe quelle plateforme d’observabilité. Tu ne connais pas « quatre outils » : tu maîtrises une architecture.

✓Ce que tu retiens

L’alerting se joue en deux temps : Prometheus évalue des règles PromQL (avec un for pour n’alerter que sur un problème persistant), Alertmanager route (groupe, déduplique, fait taire, notifie le bon receiver). En le branchant aux métriques et aux logs, tu boucles la chaîne détecter → alerter → diagnostiquer. Ton infrastructure te parle enfin — et te prévient avant toi.

Mini-projet — clôture de la Phase 8

Ta chaîne d’alerte de bout en bout

À faire

Écris une règle d’alerte (Pod en CrashLoop, ou mémoire node > 90 %) avec un for raisonnable.
Vérifie qu’elle apparaît dans Prometheus (onglet Alerts) à l’état inactive/pending/firing.
Configure un receiver dans Alertmanager (email de test ou autre canal).
Provoque l’incident, observe la métrique monter, l’alerte se déclencher, la notification partir.
Ouvre les logs Loki du Pod fautif et identifie la cause. Répare, vois l’alerte se résoudre.
Documente dans BookStack : les deux temps (évaluer/router), le rôle du for, la chaîne complète.

Fil rouge — C’est la dernière brique du parcours. Ton projet fil rouge est complet : de la virtualisation à l’observabilité, en passant par les conteneurs, Kubernetes, le CI/CD et l’IaC. Prends un instant pour regarder le chemin parcouru — juste en dessous.

Le chemin parcouru Reviens au début : une machine nue. Aujourd’hui, tu as bâti — et compris — une plateforme complète.

Ton parcours, phase par phase

Phase 0-2 — Fondations : virtualisation, Linux, réseau. Le socle.
Phase 3 — Docker : de « ça marche sur ma machine » à l’image portable.
Phase 4 — Registre, code, HTTPS : Harbor, Git, et le trafic sécurisé.
Phase 5 — Kubernetes : orchestrer, exposer, configurer, dimensionner.
Phase 6 — CI/CD : du git push au déploiement automatique.
Phase 7 — Infrastructure as Code : l’infra décrite, reproductible, versionnée.
Phase 8 — Supervision : une infra qui mesure, montre, mémorise et prévient.

Ce que tu emportes Au-delà des outils (Docker, Kubernetes, Jenkins, Terraform, Ansible, Prometheus…), tu emportes des concepts qui survivent aux outils : l’immutabilité, le déclaratif, la réconciliation d’état, l’idempotence, le pipeline-as-code, le moindre privilège, l’observabilité. Changer d’outil demain — Argo CD, AWS, Datadog — ne sera qu’apprendre une nouvelle interface, pas réapprendre le métier. C’est ça, être DevOps.

?Auto-évaluation

1. Quels sont les deux temps de l’alerting, et qui les porte ?

Évaluer (Prometheus vérifie des règles PromQL et déclenche) et router (Alertmanager groupe, déduplique, fait taire et notifie).

2. À quoi sert le champ for dans une règle d’alerte ?

À n’alerter que si la condition reste vraie pendant une durée donnée, évitant les fausses alertes sur un pic passager (lutte contre la fatigue d’alerte).

3. Cite trois choses qu’Alertmanager fait, au-delà d’« envoyer un message ».

Grouper les alertes liées, dédupliquer, respecter un intervalle de répétition, permettre des silences (maintenance), et router par labels vers le bon receiver.