Preuve — première alerte de bout en bout (Grafana → mail), 29/10/2026

Document autonome. Copie des deux mails reçus lors du test de la règle d’alerte « Service injoignable » (tâche 14.8, étape 54 de Documentation-pfSense.md). Les adresses sont masquées. Source : la boîte de copie, relevée le 29/10/2026 ; la boîte de l’administrateur a reçu les mêmes.

Le test

Chronologie (heure de Paris)

Le journal du test, en une image

Données relevées après le test : ① la sonde dans Prometheus (probe_success, une mesure par minute), ② l’historique d’état de la règle dans Grafana (API GET /api/v1/rules/history), ③ l’heure de remise des deux mails. Les trois sources concordent : la sonde échoue de 13:56 à 14:00, la règle passe Pending à 13:56, Alerting à 13:58, Normal à 14:01.

Mail 1 — la panne

Objet    : [FIRING:1] Service injoignable Lab BTS (srv-docker http://10.0.30.12:443/ sonde_termix termix critique)
De       : <compte d'envoi> (« Grafana Lab BTS »)
À        : <boîte de l'administrateur> ; <boîte de copie>
Reçu     : 29/10/2026 13:58:11

 Lab BTS › Service injoignable —  1 firing instances
Summary      : termix ne répond plus
Description  : La sonde de termix (machine srv-docker) échoue depuis plus de 2 minutes.
Values       : A=0 C=1
Labels       : alertname=Service injoignable · grafana_folder=Lab BTS · host=srv-docker
               instance=http://10.0.30.12:443/ · job=sonde_termix · service=termix · severite=critique
Observed 10s before this notification was delivered, at 2026-10-29 13:58:00 +0100 CET
Sent by Grafana v13.2.4

Mail 2 — le retour à la normale

Objet    : [RESOLVED] Service injoignable Lab BTS (srv-docker http://10.0.30.12:443/ sonde_termix termix critique)
Reçu     : 29/10/2026 14:03:11

 Lab BTS › Service injoignable —  1 resolved instances
Summary      : termix ne répond plus
Values       : A=1 C=0
Labels       : (identiques au mail 1)

Lecture

• A=0 C=1 : la requête A (probe_success) vaut 0 (la sonde échoue), la condition C (« A est inférieur à 1 ») est vraie → alerte. Au retour, A=1 C=0.
• Les étiquettes du mail (host, service, severite…) sont celles qui rempliront plus tard le ticket GLPI.
• Point à corriger : les liens « View alert » et « Silence » pointent vers http://localhost:3000, parce que l’adresse publique de Grafana (root_url) n’est pas déclarée. Ils ne s’ouvrent donc pas depuis la boîte mail. Corrigé le 29/10 à 14:44 : GF_SERVER_ROOT_URL=https://grafana.pangolin.<domaine>/ dans /etc/default/grafana-server ; le mail de test de 14:47 porte bien des liens https://grafana.pangolin.<domaine>/….

Test 2 — règle « Machine injoignable » (29/10/2026)

Message reçu : « srv-ha ne répond plus — L’exporteur de srv-ha (zone WEB) ne répond plus depuis plus de 2 minutes : machine arrêtée, réseau coupé ou exporteur en panne. » Les liens du mail pointent vers https://grafana.pangolin.<domaine>/….

Ce test simule une machine injoignable du point de vue de la supervision (l’exporteur se tait). Une machine réellement arrêtée produit le même signal (up = 0) : un arrêt réel de VM sera fait avec les tests de panne (14.9).

Test 3 — règle « Galera incomplet » et test de bascule 7.10 (29/10/2026)

Détail à corriger : le mail [RESOLVED] reprend le résumé au présent (« ne voit plus que 3 nœud(s) sur 3 »), ce qui se lit mal. Formulation plus neutre à prévoir : « Galera : {{ valeur }} nœud(s) actifs sur 3 ».

Test 4 — règle « Sauvegarde trop ancienne » et regroupement des alertes (29/10/2026)

La description du mail de test indique « a plus de 1 h » : elle reprend le seuil en vigueur au moment de l’alerte. Avec le seuil normal, elle indique « a plus de 26 h ».

Test 5 — règle « Disque presque plein » (avertissement) (29/10/2026)

Le résumé affichait « disque /[no value] » : le modèle collait le point de montage (Linux) et la lettre de lecteur (Windows), dont l’un manque toujours. Corrigé à 17:42 ({{ with $labels.mountpoint }}…{{ end }}) ; le mail [RESOLVED] garde l’ancien texte, figé au moment du déclenchement.

Tests 6 à 8 — mémoire, processeur, datastore (avertissements, 30/10/2026)

Même méthode que le test 5 : seuil abaissé, gardé 6 minutes après le déclenchement (pour que le mail parte, H-58), puis remis. Rien n’a été chargé ni rempli.

Effet de bord utile — après le test, l’historique de « Mémoire saturée » montre une instance réelle : poste-win11 passe en Pending à 09:30, 09:35 et 10:14 (mémoire utilisée jusqu’à 95 % entre 09:29 et 10:19), puis repasse à Normal avant les 15 minutes : aucun mail, ce qui est le but de l’attente. Cause À COMPLÉTER (piste : le ballooning, minimum 2 Gio réglé le 28/10, compté comme mémoire utilisée par Windows).

Tests 9 à 11 — pannes provoquées (tâche 14.9, 30/10/2026)

Ces tests se sont déroulés pendant une saturation du NAS de l’école (incident H-61) : l’arrêt propre de srv-web-02 a pris ≈ 3 min au lieu de quelques secondes. Les alertes ont fonctionné malgré tout.

Test 12 — règle « Site lent (temps de réponse) » (tâche 14.12, 30/10/2026)

Test 7.13 — non-régression du cloisonnement (30/10/2026)

Depuis poste-win11 (zone USERS) : Test-NetConnection vers 10.0.20.10, 10.0.20.11 et 10.0.20.12, port 3306 → TcpTestSucceeded : False sur les trois nœuds Galera. Le poste utilisateur ne joint toujours pas les bases.