Alertes

Le système d’alertes livre les alertes Prometheus dans des salons Matrix (et par e-mail pour les incidents). Un provisionnement unique du bot suffit : ensuite tout est déclaratif. Le fonctionnement d’ensemble est décrit dans Monitoring & Alertes.

Pré-requis

Pré-requis	Pourquoi
prometheus + monitoring sur le collecteur	porte Alertmanager et les règles
Service matrix joignable	héberge le bot et les salons
Secret d’enregistrement en sops (matrix-rss-password)	crée le compte bot
Clé admin sops présente	écrit les secrets du bot

Installer le bot

Une seule commande, idempotente (rejouable sans risque) : elle crée le compte bot, les salons, et écrit l’identité dans var/generated/matrix.nix.

1. Déclarer l’administrateur humain (partie locale) dans la configuration :

   etc/config.yaml

   network:
     matrix:
       admin: "alice"

2. Lancer le provisionnement :

   just configure-alert-bot

   La commande, en s’appuyant sur la clé admin sops :

   • crée le compte @alertbot:domain.tld (flux nonce + HMAC sur le secret partagé) ;
   • crée ou résout les salons #alert-warnings et #alert-incidents, y fait entrer le bot et invite l’admin ;
   • écrit bot + les ID de salons dans var/generated/matrix.nix ;
   • stocke mot de passe, jeton d’accès et secret de webhook dans sops.

   API admin non publique

   Si /_synapse/admin n’est pas exposé, le script ouvre automatiquement un tunnel SSH vers l’hôte Matrix (via l’utilisateur de déploiement nix).

   Filtre anti-bots de Caddy

   Le vhost Matrix rejette (403) un User-Agent de type curl. Le script envoie donc un agent neutre : ne pas reproduire les appels avec curl brut.

3. Déployer le collecteur :

   just generate
   just apply <collecteur>

   L’alerting s’active tout seul dès que les salons existent (var/generated/matrix.nix rempli). Pour le désactiver malgré tout : darkone.service.prometheus.alerting.enable = false;.

Changer le nom du bot

Le bot s’appelle alertbot par défaut. Pour un autre nom : ALERT_BOT=supervision just configure-alert-bot.

Secrets créés

Le provisionnement dépose trois secrets dans usr/secrets/secrets.yaml :

Clé sops	Rôle
alertmanager-matrix-password	mot de passe du compte bot (reconnexion)
alertmanager-matrix-token	jeton d’accès du bot (envoi des messages)
alertmanager-webhook-secret	authentifie Alertmanager auprès du pont Matrix

Tester une alerte

1. Sur un nœud supervisé, couper un service surveillé :

   sudo systemctl stop <unité>

2. Sous une minute, un message ServiceDown (ou SystemdUnitFailed) apparaît dans #alert-warnings, #alert-incidents et un e-mail si le nœud est critique. Le lien de l’alerte pointe vers https://prometheus.<zone>.domain.tld.

3. Relancer le service : l’alerte se résout (notification de résolution).

   sudo systemctl start <unité>

Silencer pendant un rebuild

Le flux de déploiement pose un drapeau de maintenance pour ne pas déclencher de fausses alertes pendant un nixos-rebuild. Manuellement :

dnf-maintenance on    # inhibe les alertes du nœud
dnf-maintenance off   # les réactive

Dépannage

Symptôme	Cause probable	Remède
Aucun message dans un salon	bot absent du salon ou jeton expiré	rejouer just configure-alert-bot
Création de salon en 403	filtre anti-bots de Caddy	déjà géré (agent neutre) ; ne pas utiliser curl brut
admin API not public	/_synapse/admin fermé	laisser le tunnel SSH automatique opérer (hôte Matrix joignable)
Lien d’alerte non résolu	DNS ou certificat du vhost prometheus absent	déployer la passerelle / le HCS pour le nouveau sous-domaine
matrix.nix ignoré au déploiement	fichier non lisible par nix	le script fait un chmod 644 ; vérifier les permissions de var/generated/
Pas de mail d’incident	relais Postfix local inactif	l’alerting l’active par défaut ; vérifier darkone.service.prometheus.alerting.email