Des pannes qui vous appellent : chaque service se signale, chaque livraison sait revenir en arrière

Les suites de supervision sont lourdes et regardent surtout ce qui marche. Ce qu'il faut d'abord est plus simple : quand un service tombe, vous l'apprenez, une fois, avec son nom. systemd sait déjà quand une unité échoue ; il suffit de lui donner un endroit où le dire.

Ce que vous y gagnez. Chaque service en échec envoie un événement signé avec son nom ; chaque machine dit une fois par jour qu'elle est vivante ; une livraison qui casse un service remet la version précédente et vous prévient. Le retour arrière et le saut ont été prouvés ici en les provoquant exprès.

1. Un seul modèle pour chaque échec

# ~/.config/systemd/user/notify-failure@.service
[Unit]
Description=Report the failure of %i

[Service]
Type=oneshot
ExecStart=%h/.local/bin/notify-failure %i

Puis rattachez-le à n'importe quelle unité par un fichier complémentaire, sans modifier l'unité elle-même :

# ~/.config/systemd/user/mon-tunnel.service.d/notify.conf
[Unit]
OnFailure=notify-failure@%n.service

notify-failure tient en quelques lignes qui appellent un envoyeur avec une source, un type, une gravité et un petit détail JSON. L'envoyeur signe le corps en HMAC et le poste vers une automatisation, qui écrit l'événement et pousse une notification sur le téléphone. Ses codes de sortie disent ce qui s'est passé : accepté, refusé (mauvaise signature), ou collecteur injoignable.

2. Un « je suis vivant » quotidien, avec patience

Chaque machine envoie un événement de santé une fois par jour. Le veilleur alerte quand l'une se tait trop longtemps, avec une tolérance adaptée à la machine : un portable peut rester fermé trois jours, un serveur bien moins. Un événement « info » ne sonne jamais.

3. Sauter, pas échouer, quand la cible est absente

Un service qui lisait le serveur toutes les dix minutes échouait 86 fois par démarrage du portable, dont 65 parce que le serveur dormait, et chaque échec déclenchait un signalement qui échouait à son tour. Une condition fait sauter le passage à la place :

[Service]
ExecCondition=bash -c 'ssh -o BatchMode=yes -o ConnectTimeout=3 serveur true || exit 1'

Le || exit 1 n'est pas décoratif. Pour ExecCondition, les codes 1 à 254 veulent dire « sauter », mais 255 veut dire « échec », et 255 est justement ce que renvoie ssh quand il ne peut pas se connecter.

4. Des livraisons qui reviennent en arrière

Notre script de livraison fait, pour chaque composant : sauvegarder, installer, redémarrer, vérifier la santé, et si la vérification échoue, remettre la version précédente et redémarrer à nouveau. Il retient le commit livré et envoie deploy.delivered ou deploy.rolled_back. Nous avons prouvé le retour arrière en forçant un échec avec une option --simulate-failure.

Pièges

Un service utilisateur n'a pas ~/.local/bin dans son PATH : écrivez des chemins complets, sinon c'est le signalement d'échec lui-même qui échoue.

Une avalanche de notifications apprend à les ignorer. Signalez une panne une fois, et le retour à la normale une fois.

Utile ? Dites-nous ce qu'il faut mesurer ensuite.