Monitoring & Alertes

La supervision collecte des métriques (Prometheus 🡕) et les affiche (Grafana 🡕). Par-dessus, une couche d’alertes entièrement déclarative prévient l’administrateur dès qu’un nœud, un service, une ressource ou le réseau dérape. Activée, elle s’adapte seule à ce qui est déployé.

Deux services, un hôte

Le collecteur d’une zone porte deux services distincts, sur le même hôte :

Service	Rôle	Accès
`prometheus`	Métriques, règles d’alerte, sondes réseau, Alertmanager	`https://prometheus.<zone>.domain.tld` (protégé SSO)
`monitoring`	Tableaux de bord Grafana	`https://stats.<zone>.domain.tld` (protégé SSO)

monitoring requiert prometheus sur le même hôte : le générateur refuse une configuration où Grafana n’a pas de source de données. On peut activer prometheus seul (métriques + alertes sans Grafana).

Le flux d’alerte

Prometheus évalue des règles générées à partir de la topologie ; quand l’une se déclenche, Alertmanager route la notification selon sa sévérité.

Alertmanager déduplique, regroupe (par alerte et instance) et inhibe les alertes redondantes : un critical éteint le warning du même incident.

Sévérité et escalade

L’escalade est portée par la sévérité, pas par le temps :

Sévérité	Destination
`warning`	Salon Matrix `#alert-warnings`
`critical`	Salon Matrix `#alert-incidents` + e-mail

Le mail part par le relais Postfix local de l’hôte ; le pont Matrix est un bot dédié (@alertbot:domain.tld) qui poste dans les deux salons.

Classes de nœuds

La sévérité d’une panne dépend de l’importance du nœud. Un serveur critique qui tombe est un incident ; un poste de travail éteint, une simple info.

Classe	Qui	Effet
critique	profils `gateway`, `hcs`, `server`	pannes en `critical`
non critique	postes, portables	pannes en `warning`
désactivée		aucune alerte sur ce nœud

La classe par défaut suit le profil de l’hôte ; on la force avec une feature :

alert-critical : relève le nœud au niveau critique.
alert-non-critical : le rabaisse.
alert-disabled : le sort des alertes.

Comme monitoring-node:<zone>, ces features acceptent une zone propriétaire : alert-critical:main fait surveiller un nœud externe (typiquement le HCS) par la zone main.

Ce qui est surveillé

Les règles sont dérivées de ce que chaque nœud déclare ; rien à lister à la main.

Famille	Déclencheur
Nœud injoignable	`node-exporter` muet (`NodeDown`)
Service actif mais en panne	unité systemd attendue non `active` (`ServiceDown`)
Unité en échec	une unité systemd `failed` (`SystemdUnitFailed`)
Ressources	disque, RAM, charge, inodes, OOM (seuils surchargeables)
Réseau	passerelle, tailnet (headscale) ou DNS injoignable (sondes blackbox)

Silence pendant les rebuilds

Un nixos-rebuild peut faire clignoter des alertes (services qui redémarrent). Le nœud en cours de déploiement dépose un drapeau de maintenance que Prometheus voit ; Alertmanager inhibe alors toutes les alertes de ce nœud le temps de l’opération. Le drapeau se pose et se lève avec dnf-maintenance on|off, que le flux de déploiement enroule automatiquement autour du rebuild.