Paillasse/docs/runbooks/supervision.md

Runbook — Supervision et alertes

Ce qui tourne

Service	Adresse (interne, 10.10.0.1)	Déployé par
Prometheus	:9091	Kolla (enable_prometheus: "yes")
Alertmanager	:9093	Kolla
Grafana	:3000	Kolla
node_exporter	:9100	Kolla (+ collecteur textfile, rôle supervision)
openstack-exporter	:9198	Kolla
cAdvisor, libvirt/mysqld/memcached exporters	ports divers	Kolla
Relais Alertmanager → ntfy	127.0.0.1:9099	rôle Ansible supervision
Uptime Kuma	127.0.0.1:3001	rôle Ansible supervision (conteneur Docker en réseau hôte, écoute forcée sur 127.0.0.1 par UPTIME_KUMA_HOST)

Rien de tout cela n'est exposé sur eno1 (vérifié : seuls 22/80/443 répondent depuis Internet). Tant qu'il n'y a pas de domaine, l'accès se fait par tunnel SSH.

Accéder aux interfaces (tunnel SSH depuis le Mac)

ssh -L 3000:10.10.0.1:3000 -L 9091:10.10.0.1:9091 -L 9093:10.10.0.1:9093 -L 3001:127.0.0.1:3001 paillasse

Puis dans le navigateur : http://localhost:3000 (Grafana), :9091 (Prometheus), :9093 (Alertmanager), :3001 (Uptime Kuma — premier accès : créer le compte admin toi-même, c'est une étape interactive).

Piège (2026-10-09) : Docker tourne avec "bridge": "none" et "iptables": false (étape 5). Un conteneur sur le pont par défaut n'a donc pas de réseau, et son ports: n'est jamais publié — le conteneur reste « healthy » (son contrôle de santé interroge son propre localhost) mais rien n'écoute sur l'hôte. Vérifier avec sudo ss -tlnp | grep 3001 : attendu 127.0.0.1:3001 seulement.

Identifiants Grafana/Prometheus/Alertmanager : utilisateur admin, mot de passe dans /etc/kolla/passwords.yml sur le serveur (grafana_admin_password, prometheus_password, prometheus_alertmanager_password) — jamais affichés ici, à lire toi-même :

sudo grep '^grafana_admin_password:' /etc/kolla/passwords.yml

Alertes en place

Fichier kolla/config/prometheus/alertes.rules (poussé par le rôle supervision, chargé par Prometheus) :

Alerte	Condition	Sévérité
DisqueSature	occupation de / > 80 % pendant 5 min	avertissement
MemoireSaturee	RAM utilisée > 90 % pendant 5 min	avertissement
ServiceOpenStackArrete	un agent Nova ou Neutron à l'état différent de up pendant 2 min	critique
SauvegardeAncienne	dernière sauvegarde Dedibackup réussie il y a plus de 26 h	critique

SauvegardeAncienne dépend d'une métrique maison (syllabus_derniere_sauvegarde_reussie_timestamp), écrite par sauvegarde-dedibackup.sh dans /var/lib/node_exporter/textfile/sauvegarde.prom à chaque sauvegarde réussie (collecteur "textfile" de node_exporter).

Limite connue, assumée pour l'instant : pas d'alerte « serveur injoignable ». Toute la chaîne (Prometheus, Alertmanager, le relais, ntfy) tourne sur le même serveur que ce qu'elle surveille : si le serveur tombe complètement, rien ne peut prévenir personne. C'est exactement pour ça que CLAUDE.md prévoyait à l'origine une sonde hors du serveur (un petit Hetzner CX23). Dans ce déploiement (un seul serveur Scaleway), ce n'est pas fait — à décider avec Adam s'il veut un jour un point de supervision externe.

Le relais Alertmanager → ntfy

Alertmanager ne sait pas parler nativement le format ntfy. Un petit service Python (/usr/local/sbin/alertmanager-ntfy.py, service systemd alertmanager-ntfy, écoute uniquement sur 127.0.0.1:9099) reçoit le webhook JSON standard d'Alertmanager et le retraduit en notification ntfy.

• L'URL ntfy (avec le topic) est lue à chaque notification depuis /root/.alertes-webhook (600 root:root) — jamais mise en cache, jamais journalisée, jamais dans Git.
• Configuration Alertmanager : kolla/config/prometheus/prometheus-alertmanager.yml (receveur unique ntfy, webhook vers le relais local).

Déclencher une alerte de test

Sans toucher à rien de réel sur le serveur, via l'API d'Alertmanager :

ssh paillasse
sudo bash -c '
PASS=$(awk -F": " "/^prometheus_alertmanager_password:/{print \$2}" /etc/kolla/passwords.yml)
MAINTENANT=$(date -u +%Y-%m-%dT%H:%M:%S.000Z)
FIN=$(date -u -d "+5 minutes" +%Y-%m-%dT%H:%M:%S.000Z)
curl -s --user "admin:$PASS" -XPOST http://10.10.0.1:9093/api/v2/alerts -H "Content-Type: application/json" -d "[{
  \"labels\": {\"alertname\": \"TestManuel\"},
  \"annotations\": {\"description\": \"Test manuel.\"},
  \"startsAt\": \"$MAINTENANT\", \"endsAt\": \"$FIN\"
}]"
unset PASS
'

Vérifié le 2026-10-07 : alerte de test reçue par Adam sur ntfy, par ce mécanisme et en testant aussi le relais directement (curl -XPOST http://127.0.0.1:9099/alertmanager ...).

Après tout changement à kolla/config/prometheus/* ou kolla/globals.yml

cd ansible && script -q /dev/null ansible-playbook kolla.yml -i inventory.ini
cd ansible && script -q /dev/null ansible-playbook supervision.yml -i inventory.ini
ssh paillasse "sudo -i bash -c 'export PATH=/opt/kolla-venv/bin:\$PATH; kolla-ansible reconfigure -i /etc/kolla/all-in-one --tags prometheus'"

Piège vécu le 2026-10-07 : modifier kolla/globals.yml ou un fichier de kolla/config/ dans le dépôt ne suffit pas : il faut d'abord rejouer kolla.yml/supervision.yml pour le copier sur le serveur, puis kolla-ansible reconfigure. Oublier la première étape fait tourner reconfigure sur l'ancienne config, sans erreur visible.

Mettre à jour l'image Uptime Kuma

Figée par digest, pas par le tag flottant louislam/uptime-kuma:1 (qui peut changer de contenu à tout moment, sans avertissement ni changelog attaché au tag) : supervision_image_uptime_kuma (ansible/roles/supervision/defaults/main.yml). Version actuelle : 1.23.17, sous son propre tag versionné depuis le 2026-10-14 (avant cette date, le digest figé était celui du tag flottant :1 au même contenu — build différent, avec un script d'avertissement sans impact).

1. Choisir la version visée sur https://hub.docker.com/r/louislam/uptime-kuma/tags (préférer un tag de version exacte, ex. 1.23.18, jamais 1 ou latest) et lire les notes de version https://github.com/louislam/uptime-kuma/releases.
2. Trouver son digest exact (pas celui d'un tag flottant) :

   curl -s "https://hub.docker.com/v2/namespaces/louislam/repositories/uptime-kuma/tags/1.23.18" \
     | python3 -c "import json,sys; print(json.load(sys.stdin)['digest'])"
   

3. Mettre à jour supervision_image_uptime_kuma dans defaults/main.yml (louislam/uptime-kuma@sha256:...) et le commentaire de version.
4. cd ansible && script -q /dev/null ansible-playbook supervision.yml -i inventory.ini (tire la nouvelle image, recrée le conteneur ; le volume uptime-kuma-data est conservé, rien n'est perdu).
5. Vérifier : ss -tlnp | grep 3001 (toujours 127.0.0.1 seulement), rouvrir le tunnel SSH, se connecter, vérifier que les sondes existantes sont toujours là et actives. Rejouer visio-e2e.mjs/parcours-lab.py n'est pas nécessaire (Kuma ne fait pas partie du chemin critique d'un lab).