Surveiller la disponibilité de son VPS

3 min de lecture07 novembre 2026

Un service qui répond en local peut être injoignable de l'extérieur. La disponibilité se mesure donc depuis Internet, pas depuis la machine surveillée. L'objectif n'est pas d'accumuler des graphiques, mais de savoir en quelques secondes si le problème vient du réseau, du serveur ou de l'application.

Choisir ce qui est testé

Testez une URL qui prouve que l'application fonctionne, pas seulement que Nginx répond. Une route /health qui vérifie la connexion à la base est plus utile que la page d'accueil :

Bash

curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 10 https://votre-domaine.fr/health

Pour un service non HTTP (jeu, base, SSH), testez le port TCP. Évitez de fonder l'alerte sur ping : l'ICMP est souvent filtré et ne prouve rien sur l'application.

Vérifier depuis l'extérieur

Une vérification lancée depuis le VPS ne détecte pas la panne du VPS. Utilisez au minimum un point externe : un service de supervision, une autre machine, ou votre téléphone en partage de connexion.

Bash

curl -6 -sS -o /dev/null -w '%{http_code}\n' https://votre-domaine.fr/
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://votre-domaine.fr/

Si votre serveur est en IPv6 seule, l'échec en IPv4 est normal tant qu'aucune IPv4 dédiée n'est commandée. Notez-le pour ne pas confondre cette absence avec une panne.

Automatiser avec cron

Un script local complète la supervision externe : il détecte une application qui tourne mais ne répond plus, et il peut journaliser localement.

Texte

#!/bin/sh
url="https://votre-domaine.fr/health"
for i in 1 2 3; do
  code=$(curl -sS -o /dev/null -w '%{http_code}' --max-time 10 "$url")
  [ "$code" = "200" ] && exit 0
  sleep 30
done
logger -t veille "site indisponible, dernier code $code"
exit 1

Placez-le dans /usr/local/bin/verifier-site.sh, rendez-le exécutable, puis appelez-le toutes les cinq minutes dans la crontab root. Trois échecs consécutifs évitent les alertes sur un redémarrage de Nginx.

Distinguer les pannes

Symptôme	Cause probable	Vérification
Console OK, SSH muet	pare-feu ou `sshd`	`systemctl status ssh`, `ss -ltnp`
SSH OK, HTTP en erreur	Nginx ou application	`journalctl -u nginx`, `curl localhost`
Rien ne répond, console OK	réseau ou pare-feu	`ip -6 addr`, `nft list ruleset`
Console inaccessible	plateforme ou conteneur	support NeoHeberg

La console noVNC du dashboard reste le meilleur recours quand le réseau du conteneur ne répond plus.

Réduire les faux positifs

Exigez deux ou trois échecs avant d'alerter.
Vérifiez depuis un second emplacement avant de conclure à une panne globale.
Annoncez les fenêtres de maintenance et suspendez les alertes pendant celles-ci.
Choisissez un canal d'alerte qui ne dépend pas du serveur surveillé : une alerte envoyée par le serveur en panne n'arrivera jamais.
Documentez la procédure de reprise pour que quelqu'un d'autre puisse agir.

Un service de supervision externe reste la base : il voit ce que vos utilisateurs voient.