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

Silencer une alerte connue

Certaines alertes sont exactes mais non actionnables : un disque de sauvegarde volontairement rempli franchit DiskSpaceLow en permanence. silences les empêche de notifier.

usr/modules/alerts.nix

{
  darkone.service.prometheus.alerting.silences = [
    {
      alert = "DiskSpaceLow";
      host = "srv-backup";
      matchers.mountpoint = "/mnt/backup";
      reason = ''
        Disque de sauvegarde volontairement rempli, seuil structurellement
        franchi. Retirer si la rétention est réduite.
      '';
    }
  ];
}

Champ	Rôle
alert	Nom de l’alerte à taire (alertname)
host	Nom d’hôte à cibler (label host), null pour tout le parc
matchers	Labels supplémentaires en égalité stricte, combinés en ET
reason	Obligatoire : pourquoi l’alerte est acceptée

Chaque entrée devient une route Alertmanager vers le receiver null. L’alerte continue de se déclencher et reste visible dans Prometheus, Alertmanager et Grafana, elle cesse simplement de notifier.

Un silence est chirurgical, pas global

Seul l’alertname cité est concerné : taire DiskSpaceLow sur un point de montage laisse DiskSpaceCritical et DiskWillFillSoon pleinement armés sur ce même montage. Le vrai remplissage alerte toujours.

Où déclarer ces silences

Les règles et routes d’une zone sont générées sur l’hôte qui fait tourner Prometheus, pas sur la machine concernée. Chaque hôte étant évalué indépendamment, usr/machines/<hôte>/ n’y suffit pas. Un module consumer (usr/modules/alerts.nix) est importé partout et regroupe en un seul fichier ce qui est volontairement ignoré, toutes zones confondues.

Vérifier le routage sur l’hôte Prometheus :

amtool config routes test --config.file=/etc/alertmanager.yml \
  alertname=DiskSpaceLow host=srv-backup mountpoint=/mnt/backup

Pour taire un mode de défaillance systémique plutôt qu’un cas ponctuel, voir ignoredUnits (dnf/config/alerts.nix), qui exclut une unité systemd de SystemdUnitFailed sur tout le parc.

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