Intermédiaire 6 min de lecture · 1 208 mots

Être alerté sur son téléphone quand ça plante (sans usine à gaz)

Un script de dix lignes, un cron et ntfy : de quoi recevoir une notification sur ton téléphone quand un disque se remplit ou qu'un service tombe.

Estimated reading time: 6 minutes

Le pire dans une panne de homelab, ce n’est pas la panne. C’est de l’apprendre trois jours plus tard, par hasard, parce qu’un membre de la famille te dit « au fait, ça marche plus ».

On l’a vécu avec Nextcloud : un disque plein, un service qui avait l’air vivant, et personne de prévenu. Depuis, j’ai une règle : si ça casse, mon téléphone vibre. Et pour y arriver, pas besoin d’une grosse plateforme d’alerting. Un petit script et un service de notifications suffisent.

Le principe

On veut juste trois briques :

  1. Quelque chose qui détecte un problème (un script, ou une règle Prometheus).
  2. Quelque chose qui envoie un message (une requête HTTP).
  3. Quelque chose qui reçoit sur le téléphone (une appli de notifications).

Pour les deux dernières, ntfy fait tout : tu envoies un message avec une simple requête, et l’application mobile l’affiche en notification.

Étape 1 : ntfy en deux minutes

Tu as deux options.

Option A : le service public (ntfy.sh). Le plus rapide pour tester. Attention : les « topics » (canaux) y sont publics, donc choisis un nom impossible à deviner et ne mets aucune donnée sensible dans les messages.

Option B : l’auto-héberger. Un petit conteneur suffit, et là tout reste chez toi :

services:
  ntfy:
    image: binwiederhier/ntfy
    command: serve
    restart: unless-stopped
    ports:
      - "8085:80"
    volumes:
      - ./ntfy-cache:/var/cache/ntfy
      - ./ntfy-config:/etc/ntfy

Ensuite, installe l’application ntfy sur ton téléphone, et abonne-toi à ton canal (par exemple homelab-alertes-x7k2q).

Étape 2 : le premier message

Depuis n’importe quelle machine :

curl -d "Test depuis le homelab" https://ntfy.sh/homelab-alertes-x7k2q

Ton téléphone vibre. C’est tout. Tu viens de construire un système de notifications.

On peut enrichir le message avec un titre, une priorité et une icône :

curl 
  -H "Title: Disque presque plein" 
  -H "Priority: high" 
  -H "Tags: warning" 
  -d "Le volume /data est à 92 % sur heighliner" 
  https://ntfy.sh/homelab-alertes-x7k2q

Étape 3 : un script qui surveille le disque

Voici un script volontairement basique :

#!/usr/bin/env bash
set -euo pipefail

SEUIL=90
TOPIC="https://ntfy.sh/homelab-alertes-x7k2q"
MACHINE="$(hostname)"

df -P --output=pcent,target -x tmpfs -x devtmpfs | tail -n +2 | while read -r pct mount; do
  usage="${pct%%}"
  if [ "$usage" -ge "$SEUIL" ]; then
    curl -s 
      -H "Title: Disque presque plein sur ${MACHINE}" 
      -H "Priority: high" 
      -H "Tags: warning" 
      -d "${mount} est à ${usage} %" 
      "$TOPIC" >/dev/null
  fi
done

Rends-le exécutable (chmod +x alerte-disque.sh), puis planifie-le avec cron, par exemple toutes les 30 minutes :

*/30 * * * * /usr/local/bin/alerte-disque.sh

Étape 4 : « est-ce que ça répond ? »

Un deuxième script, pour vérifier qu’un service web répond bien :

#!/usr/bin/env bash
# alerte-service.sh : prévient si une URL ne répond pas correctement
URL="https://wiki.exemple.net"
TOPIC="https://ntfy.sh/homelab-alertes-x7k2q"

code=$(curl -s -o /dev/null -m 10 -w "%{http_code}" "$URL" || echo "000")

if [ "$code" != "200" ]; then
  curl -s 
    -H "Title: Service injoignable" 
    -H "Priority: urgent" 
    -H "Tags: rotating_light" 
    -d "${URL} a répondu ${code}" 
    "$TOPIC" >/dev/null
fi

Astuce importante : fais tourner ce script depuis une machine autre que celle qu’il surveille. Une alerte envoyée par la machine qui vient de tomber ne partira jamais. Un petit VPS ou un Raspberry Pi dans un coin, c’est parfait.

Le piège n°1 : les alertes qui se répètent en boucle

Avec ces scripts, si le disque reste à 92 % pendant trois jours, tu reçois une notification toutes les 30 minutes. Soit 144 messages. Au bout d’une heure, tu coupes les notifications, et tu as perdu le bénéfice du système.

Il faut ajouter un minimum de mémoire : ne prévenir qu’une fois, puis de nouveau seulement si le problème persiste après un long délai ou s’il est résolu.

Une version simple avec un fichier témoin :

ETAT="/tmp/alerte-disque.etat"

if [ "$usage" -ge "$SEUIL" ]; then
  # Ne notifier que si le dernier message date de plus de 12 h
  if [ ! -f "$ETAT" ] || [ "$(find "$ETAT" -mmin +720)" ]; then
    curl ... # l'envoi de la notification
    touch "$ETAT"
  fi
else
  rm -f "$ETAT"
fi

Ici, une alerte est envoyée au plus toutes les 12 heures tant que le problème dure, et le compteur repart de zéro quand tout rentre dans l’ordre.

Si tu utilises déjà Prometheus

Bonne nouvelle : tu n’as pas besoin de réécrire tes surveillances en scripts. Alertmanager peut envoyer ses alertes vers un webhook, Comme ntfy ne comprend pas directement ce format, il faut un petit pont entre les deux : un script ou un utilitaire qui reçoit le webhook et appelle ntfy. Le principe reste le même : détecter d’un côté, notifier de l’autre. Les scripts ci-dessus restent utiles pour tout ce qui sort du périmètre de Prometheus (une sauvegarde qui n’a pas tourné, par exemple).

Un cas pratique que j’aime bien : à la fin d’un script de sauvegarde, envoyer un message de succès ou d’échec :

if rsync -a /data/ /sauvegardes/; then
  curl -s -d "Sauvegarde OK" "$TOPIC" >/dev/null
else
  curl -s -H "Priority: high" -d "Sauvegarde ÉCHOUÉE" "$TOPIC" >/dev/null
fi

Les règles que je m’impose

  1. Peu d’alertes, mais fiables. Mieux vaut trois alertes que tu lis que trente que tu ignores.
  2. Un niveau de priorité cohérent. « Urgent » seulement quand je dois agir maintenant. Le reste attend demain matin.
  3. Pas de secrets dans les messages. Surtout sur un canal public.
  4. Tester la chaîne de bout en bout. Une fois par mois, je simule une panne pour vérifier que la notification arrive bien. Un système d’alerte qui ne marche plus sans que tu le saches est pire que pas d’alerte.

Pour conclure

Pas besoin d’une plateforme à la mode pour être prévenu quand quelque chose casse. Dix lignes de bash, un cron et une appli sur ton téléphone font le travail. L’important, ce n’est pas l’outil : c’est de fermer la boucle entre « ça casse » et « je le sais ».

Et une fois que ça marche, une idée à creuser : envoyer aussi les bonnes nouvelles. Un petit « sauvegarde OK » chaque nuit, c’est étonnamment rassurant.

Une remarque, un retour ?

Cet article est vivant - corrections, contre-arguments et retours de production sont les bienvenus. Trois canaux, choisis celui qui te convient.

Laisser un commentaire