Surveiller son VPS : ressources, alertes et disponibilité

Un serveur qui tombe à 3 heures du matin, un disque plein qui bloque la base de données, un processus qui monopolise le processeur depuis une semaine : sans surveillance, vous l'apprenez par vos utilisateurs. Ce guide met en place une supervision en trois niveaux, du plus simple au plus complet, adaptée à un VPS.

1. Que surveiller

2. Diagnostic en direct

Quand quelque chose ralentit, ces commandes répondent en quelques secondes :

uptime                          # charge moyenne sur 1, 5 et 15 minutes
free -h                         # mémoire et swap
df -h                           # espace disque par partition
du -xh / --max-depth=2 2>/dev/null | sort -rh | head -15   # dossiers les plus lourds
journalctl -k | grep -i "out of memory"                     # processus tués par manque de mémoire

Pour une vue d'ensemble interactive, installez btop : processeur par cœur, mémoire, disque, réseau et processus sur un seul écran.

apt install -y btop && btop

3. Garder un historique avec sysstat

Les commandes précédentes montrent l'instant présent. Pour savoir ce qui s'est passé cette nuit pendant la coupure, il faut un historique. sysstat enregistre les principaux indicateurs toutes les dix minutes, pour un coût négligeable :

apt install -y sysstat
sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
systemctl enable --now sysstat

Consultez ensuite l'historique du jour, ou celui d'un jour précédent :

sar -u          # processeur
sar -r          # mémoire
sar -n DEV      # trafic réseau par interface
sar -u -f /var/log/sysstat/sa17   # historique du 17 du mois

4. Recevoir une alerte sur Discord

Un script de quelques lignes suffit pour être prévenu avant la catastrophe. Dans Discord, créez un webhook : Paramètres du salon → Intégrations → Webhooks, et copiez son adresse. Puis créez /usr/local/bin/alerte-vps.sh :

#!/bin/bash
WEBHOOK="https://discord.com/api/webhooks/VOTRE_WEBHOOK"
HOTE=$(hostname)
alerte() {
  curl -s -H "Content-Type: application/json" \
    -d "{\"content\": \"⚠️ $HOTE : $1\"}" "$WEBHOOK" >/dev/null
}

DISQUE=$(df --output=pcent / | tail -1 | tr -dc '0-9')
[ "$DISQUE" -ge 85 ] && alerte "disque à ${DISQUE} %"

MEM=$(free | awk '/Mem:/ {printf "%d", $7/$2*100}')
[ "$MEM" -le 10 ] && alerte "mémoire disponible à ${MEM} %"

for svc in nginx mariadb; do
  systemctl is-active --quiet "$svc" || alerte "le service $svc est arrêté"
done

chmod +x /usr/local/bin/alerte-vps.sh
echo '*/10 * * * * root /usr/local/bin/alerte-vps.sh' > /etc/cron.d/alerte-vps

Adaptez la liste des services à votre serveur : fivem, minecraft, docker… Le script ne dit rien quand tout va bien.

5. Surveiller la disponibilité depuis l'extérieur

Un script sur le serveur ne peut pas vous prévenir si le serveur lui-même est injoignable. La disponibilité se surveille depuis une autre machine. Uptime Kuma est l'outil libre de référence : il vérifie vos sites en HTTP, vos serveurs de jeu par ping ou port TCP, l'expiration des certificats, et envoie les alertes sur Discord, Telegram ou par e-mail.

Installez-le sur un second petit VPS, avec Docker, en suivant l'exemple complet de Docker et Docker Compose. Il peut aussi publier une page de statut publique pour votre communauté.

6. Un tableau de bord complet avec Netdata

Pour aller plus loin, Netdata collecte des centaines d'indicateurs à la seconde et les affiche dans des graphiques détaillés, sans configuration. Il consomme toutefois un peu de processeur et de mémoire : sur un VPS de 2 Go, préférez sysstat. L'installation se fait avec le script officiel publié sur le site de Netdata.

Une fois installé, le tableau de bord écoute sur le port 19999. Ne l'exposez pas publiquement : il révèle beaucoup d'informations sur votre serveur. Accédez-y par un tunnel SSH ou par WireGuard :

ssh -N -L 19999:127.0.0.1:19999 alex@IP_DU_VPS
# puis ouvrez http://127.0.0.1:19999 dans votre navigateur

7. Lire les signaux

• Swap utilisé en permanence : le VPS manque de mémoire. Réduisez la consommation, comme la mémoire allouée à Java ou le cache de la base, ou passez à une offre supérieure.
• Charge élevée mais processeur peu utilisé : les processus attendent le disque. Cherchez le coupable avec iotop.
• Disque qui se remplit régulièrement : ce sont presque toujours des journaux ou des sauvegardes locales. Vérifiez /var/log, les journaux Docker et journalctl --disk-usage.
• Trafic réseau anormal : une attaque est peut-être en cours. Voir limiter l'impact d'une attaque DDoS.

Pour recevoir chaque matin un résumé des événements du serveur, voir aussi rapports quotidiens avec Logwatch.

Questions fréquentes