Alertes d'indisponibilité du site

Les graphiques du panneau montrent l'état de la machine, mais ils ne répondent pas à la question « le site est-il en ligne ? ». L'application peut se bloquer alors que le processeur est au repos, et sans vérification externe, vous l'apprendrez par vos clients.

Vérifications externes

Règle principale : ne vérifiez pas depuis la machine que vous surveillez. Utilisez n'importe quel service externe de supervision de disponibilité — ils sont nombreux, avec des offres gratuites pour plusieurs adresses et un intervalle d'une minute. Les réglages qui comptent vraiment :

• Adresse de vérification. Pas la page d'accueil, mais une route dédiée comme /healthz qui contrôle à la fois la base de données et la file d'attente. Sinon, une page d'accueil mise en cache sera servie même si le backend est mort.
• Réponse attendue. Un code 200 plus une sous-chaîne dans le corps. Beaucoup d'applications renvoient 200 avec un message d'erreur lorsqu'elles tombent en panne.
• Seuil. Deux ou trois tentatives échouées d'affilée, sinon le moindre hoquet réseau vous réveillera.
• Canal. Telegram ou e-mail. Assurez-vous que l'alerte arrive réellement : désactivez le service pendant une minute et attendez le message.

N'oubliez pas une vérification distincte de l'expiration du certificat — un certificat TLS expiré ressemble à une panne et cela arrive régulièrement.

Watchdog sur la machine elle-même

La supervision externe vous dira que le site est tombé. Pour qu'il remonte tout seul, configurez systemd. Dans l'unité de service :

[Service]
Restart=always
RestartSec=5
StartLimitBurst=5
StartLimitIntervalSec=120

Ainsi, le service survivra à un crash accidentel, mais ne bouclera pas indéfiniment si la configuration est cassée. Après modification : systemctl daemon-reload && systemctl restart myapp.

Pour les applications qui ne plantent pas mais se bloquent, ajoutez une vérification HTTP. Une paire d'unités — un timer et un service :

cat >/etc/systemd/system/healthcheck.service <<'EOF'
[Service]
Type=oneshot
ExecStart=/usr/local/bin/healthcheck.sh
EOF

cat >/etc/systemd/system/healthcheck.timer <<'EOF'
[Timer]
OnUnitActiveSec=60
[Install]
WantedBy=timers.target
EOF

systemctl enable --now healthcheck.timer

Le script lui-même :

#!/bin/sh
curl -fsS --max-time 10 http://127.0.0.1:8080/healthz >/dev/null || systemctl restart myapp

Alertes sur l'état de la machine

Il est aussi utile d'être prévenu du manque d'espace disque et de mémoire avant la panne. L'option la plus simple est une tâche cron qui envoie un message Telegram lorsqu'un seuil est dépassé :

0 * * * * root [ "$(df --output=pcent / | tr -dc 0-9)" -gt 85 ] && curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT -d text="VDS disk usage is over 85%"

Une option plus avancée avec des seuils prêts à l'emploi est proposée par Netdata.

Erreurs courantes

• Supervision sur la même machine. Si la machine tombe, le watchdog et les alertes tombent avec elle.
• Seuil trop sensible. Un flot de fausses alertes fait que vous passerez à côté de la vraie.
• Restart=always au lieu de chercher la cause. Le redémarrage masque une fuite de mémoire : le service plante toutes les demi-heures et vous ne le voyez pas. Vérifiez systemctl show myapp -p NRestarts et le journal.
• Vérification uniquement par ping. La machine répond à l'ICMP même avec un serveur web complètement mort.

La première chose à vérifier lorsqu'une alerte se déclenche est « Overview » dans le panneau /hosting/vds/m/<id>. Une rupture dans les graphiques signifie un problème avec la machine ; des graphiques plats alors que le site est indisponible signifient un problème dans l'application.