Détecter automatiquement un serveur de jeu Linux hors service

Une panne de serveur de jeu est souvent découverte par les joueurs avant l'administrateur. Un contrôle périodique permet pourtant de détecter automatiquement un service arrêté et de déclencher une alerte. Cette méthode ne remplace pas une supervision complète, mais elle constitue une base simple pour un VPS Linux hébergeant Minecraft, FiveM, Rust ou un autre serveur dédié.

Ce que la surveillance doit détecter

Il faut d'abord définir la panne à signaler. Un processus absent, un service systemd arrêté et un port fermé ne décrivent pas exactement le même problème. Un serveur peut être lancé mais ne plus accepter de connexions, ou répondre sur son port tout en étant incapable de traiter correctement une commande. Un contrôle utile combine donc plusieurs niveaux :

• la présence du service ou du processus attendu ;
• son état dans systemd lorsqu'il est géré comme un service ;
• la réponse du port réseau utilisé par le jeu ;
• la date de la dernière vérification et le nombre d'échecs consécutifs.

Le nombre d'échecs consécutifs est important. Une alerte après un seul contrôle peut signaler une perte réseau momentanée. Deux ou trois contrôles rapprochés donnent un signal plus exploitable, sans masquer une interruption réelle.

Préparer un service fiable

La surveillance est plus lisible quand le serveur de jeu est lancé par un service systemd plutôt que par une session SSH. Le service doit utiliser un utilisateur dédié, un chemin de travail explicite et une politique de redémarrage adaptée. Avant d'automatiser une alerte, vérifiez que l'arrêt volontaire du service est bien distinguable d'une panne et que les journaux permettent de comprendre le dernier démarrage.

Ne configurez pas un redémarrage automatique sans vérifier ses effets. Une boucle de redémarrage peut aggraver une erreur de configuration, remplir les journaux ou consommer des ressources. Commencez par journaliser et alerter, puis ajoutez une relance contrôlée si le comportement du serveur est connu.

Créer un contrôle local

Un contrôle local peut interroger l'état du service et écrire un résultat daté dans un journal. L'idée est de retourner un code d'erreur dès qu'un contrôle critique échoue, afin que le mécanisme d'exécution puisse distinguer un état normal d'une panne.

#!/bin/sh
SERVICE="mon-serveur-jeu.service"

if ! systemctl is-active --quiet "$SERVICE"; then
  printf '%s panne service=%s\n' "$(date -Is)" "$SERVICE" >> /var/log/jeu-monitoring.log
  exit 1
fi

printf '%s ok service=%s\n' "$(date -Is)" "$SERVICE" >> /var/log/jeu-monitoring.log
exit 0

Remplacez le nom du service et testez le script avec un arrêt volontaire dans une fenêtre de maintenance. Le fichier de journal doit avoir des permissions limitées et une rotation prévue. Un contrôle qui ne fait qu'écrire dans un fichier sans jamais être consulté ne constitue pas une alerte.

Vérifier le port du jeu

L'état du service ne suffit pas toujours. Ajoutez un test du port attendu depuis le VPS ou depuis un point de contrôle externe. Le test doit utiliser le protocole et le port réellement documentés par votre serveur de jeu. Un port ouvert prouve seulement qu'une écoute réseau répond, pas que le monde, la partie ou la base de données fonctionne correctement.

Pour éviter les faux positifs, définissez un délai d'attente, limitez la fréquence des tests et conservez l'heure du dernier succès. N'ajoutez pas de port au pare-feu uniquement pour satisfaire un outil de supervision. Le port doit rester cohérent avec votre configuration et votre politique de sécurité.

Planifier avec systemd

Un timer systemd est adapté à un contrôle périodique sur une machine Linux déjà administrée avec systemd. Il lance le contrôle à intervalle régulier et permet de consulter les exécutions dans les journaux système. Le timer doit être testé après chaque changement et son unité doit rester séparée du service de jeu.

[Unit]
Description=Contrôle du serveur de jeu

[Timer]
OnBootSec=2min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

Associez ce timer à une unité de type service qui exécute le script. Le contrôle doit rester court : il ne doit ni télécharger une mise à jour ni effectuer une sauvegarde complète. Ces opérations ont leurs propres contraintes et peuvent être traitées séparément.

Surveiller les ressources du VPS

Un service peut être actif tout en devenant injouable lorsque les ressources du serveur virtuel sont saturées. Surveillez la mémoire RAM, la charge CPU, le processeur et l'espace disponible sur le disque SSD. Un serveur de jeu consomme aussi des ressources lors d'une sauvegarde, d'une génération de monde, d'une mise à jour ou d'un redémarrage.

Conservez des seuils propres à votre usage plutôt que des valeurs universelles. Une alerte d'espace disque doit laisser le temps de supprimer ou déplacer des journaux anciens. Une alerte mémoire doit conduire à vérifier les processus, le nombre de joueurs et la configuration du jeu. Si une base de données MySQL est utilisée par votre serveur, elle doit être surveillée séparément du processus de jeu.

Envoyer une alerte sans exposer de secret

Une alerte utile indique le serveur concerné, l'heure, le type d'échec et le nombre de tentatives. Stockez les jetons, mots de passe et URL privées hors du script, avec des permissions adaptées. N'inscrivez jamais un secret dans une commande copiée dans un ticket ou dans un dépôt public.

Une notification peut passer par un outil de supervision, un webhook ou un canal d'équipe. L'adresse IP et le nom du service peuvent être inclus si ces informations ne sont pas publiques. En revanche, ne diffusez pas de clé API, de mot de passe, d'identifiant de base de données ou de lien d'administration.

Prévoyez aussi une alerte de retour à la normale. Elle évite de continuer à intervenir alors que le service a redémarré. Pour une équipe, associez chaque alerte à une procédure : vérifier les ressources, lire les journaux, tester le port, puis examiner le réseau ou l'hôte si nécessaire.

Choisir l'environnement Linux à surveiller

Pour héberger un serveur de jeu, un serveur VPS Linux fournit une machine virtuelle avec un accès administrateur, souvent utilisé via SSH. Ubuntu et Debian sont des environnements courants, mais la procédure doit suivre la distribution réellement installée. Le compte root, les utilisateurs dédiés, le firewall et les mises à jour doivent être traités avec prudence.

Un hébergeur peut proposer un panneau de contrôle, un accès console ou une adresse IP publique. Ces éléments aident à récupérer la main lorsque le réseau ou le service est en panne, mais ils ne remplacent pas le contrôle exécuté sur la machine. Un VPS reste un serveur virtuel : il faut surveiller ses ressources et conserver une sauvegarde indépendante.

La virtualisation permet d'isoler plusieurs serveurs virtuels sur une infrastructure cloud, mais chaque instance garde ses limites de RAM, de processeur, de stockage et de bande passante. Vérifiez donc l'espace de stockage restant et la bande-passante réellement nécessaire avant de regrouper plusieurs serveurs de jeu sur la même offre VPS. Un backup externe doit rester accessible même lorsque le serveur virtuel est hors service.

Pour un projet plus important, comparez les besoins entre serveur virtuel et serveur dédié. Un serveur physique peut offrir davantage de ressources réservées, tandis qu'un VPS est souvent plus simple à faire évoluer. Dans les deux cas, l'alerte doit couvrir le service de jeu, le réseau, le stockage et l'hôte.

Tester et faire évoluer la surveillance

Une supervision fiable se teste comme une sauvegarde. Arrêtez le service dans un créneau maîtrisé, vérifiez la réception de l'alerte, mesurez le délai puis relancez le serveur et vérifiez le message de rétablissement. Testez également un port fermé, un disque presque plein et une perte temporaire de connectivité si votre procédure le permet.

Commencez avec un seul serveur et quelques indicateurs. Quand le dispositif est stable, ajoutez la mesure d'espace disque, de mémoire et de charge CPU. Ces contrôles répondent à d'autres causes de panne et doivent être interprétés avec le type de serveur, le nombre de joueurs et les tâches planifiées.

Documentez enfin le nom de domaine, l'adresse IP, les ports, les services, le firewall et la méthode de sauvegarde. Cette fiche accélère le diagnostic lorsqu'une personne différente intervient sur le VPS. Un panel d'administration ou une solution d'infogérance peut compléter les scripts, mais il ne dispense pas de tester les alertes et les backups.

Pour aller plus loin, consultez aussi notre diagnostic réseau d'un VPS inaccessible, le guide pour sécuriser un serveur dédié, les conseils sur la mise à jour d'un serveur de jeu Linux, notre guide des sauvegardes haute disponibilité et les solutions pour restaurer un serveur Pterodactyl.