Gestion des logs serveur : maîtriser la taille avec logrotate

Si vous gérez un serveur de jeu, la gestion des logs serveur finira tôt ou tard par vous poser problème. Connexions, historiques de chat, commandes GM, messages d'erreur et les milliers de lignes produites par le moteur de jeu s'accumulent jour après jour. Un seul fichier syserr.txt qui atteint plusieurs gigaoctets et sature le disque jusqu'à faire planter le serveur, faute d'espace pour écrire, est un scénario classique. Dans cet article, j'explique comment utiliser l'outil standard de Linux, logrotate, pour faire tourner, compresser et garder automatiquement vos fichiers de logs sous contrôle.

Pourquoi les fichiers de logs deviennent-ils incontrôlables ?

Peu importe que vous fassiez tourner Metin2, Minecraft, FiveM ou votre propre serveur en C++ ; tous produisent des fichiers de logs constamment alimentés. Le problème vient d'un seul fichier qui grossit sans fin :

• Aux heures de pointe, des centaines de lignes par seconde peuvent être écrites ; syslog, chat.log ou syserr enflent rapidement.
• Chercher une erreur dans un fichier géant devient impossible ; même grep prend des minutes.
• Quand le disque est plein, non seulement les logs mais aussi la base de données et les processus de jeu ne peuvent plus écrire ; le serveur s'arrête complètement.
• Copier ces énormes fichiers de logs à chaque sauvegarde gaspille espace et temps pour rien.

La solution est de « faire tourner » les logs à intervalles réguliers : archiver le fichier actif, en démarrer un nouveau, compresser les anciens et supprimer tout ce qui dépasse un nombre défini. C'est exactement ce que fait logrotate.

Comment fonctionne logrotate ?

logrotate est installé sur presque toutes les distributions Linux. Ce n'est pas un service (daemon) à part ; il est déclenché une fois par jour par cron ou par un timer systemd. Sur la plupart des systèmes, le script /etc/cron.daily/logrotate s'en charge. À son exécution, il lit les fichiers de configuration, décide quels logs doivent tourner et enregistre son état dans /var/lib/logrotate/status, afin de se rappeler « quand ai-je fait tourner ce log pour la dernière fois ? »

La configuration se trouve à deux endroits :

• /etc/logrotate.conf — réglages globaux.
• /etc/logrotate.d/ — un fichier distinct par application. C'est ici que vous déposez votre règle pour le serveur de jeu.

Un exemple de configuration pour un serveur de jeu

Supposons que vos logs serveur soient conservés sous /var/log/metin2/ avec l'extension .log. Créez un fichier nommé /etc/logrotate.d/metin2 :

/var/log/metin2/*.log {
    daily
    rotate 14
    size 100M
    missingok
    notifempty
    compress
    delaycompress
    copytruncate
}

Signification des directives :

• daily — faire tourner une fois par jour. weekly ou monthly fonctionnent aussi.
• size 100M — faire tourner dès que le fichier dépasse 100 Mo, sans attendre la période. Crucial sur les serveurs chargés.
• rotate 14 — conserver au plus 14 anciennes copies ; la 15^e est supprimée.
• compress — compresser les anciens logs avec gzip ; cela réduit généralement l'espace d'environ 90 %.
• delaycompress — compresser le fichier le plus récemment tourné un cycle plus tard ; évite la perte de données si un processus y écrit encore.
• missingok — ne pas générer d'erreur si le fichier est absent.
• notifempty — ne pas faire tourner un fichier vide.
• copytruncate — copier le fichier puis vider l'original, pour que le moteur continue à écrire sans redémarrage.

copytruncate ou create ?

C'est l'erreur la plus fréquente. Par défaut, logrotate fonctionne selon la logique create : il renomme le fichier actif et crée un fichier vide du même nom. Mais les serveurs de jeu gardent le fichier de log ouvert et continuent d'écrire sur le même descripteur de fichier ; même si le nom change, les écritures vont toujours vers l'ancien fichier (devenu .1). Résultat : le nouveau fichier reste vide et l'ancien continue de grossir.

Il existe deux solutions :

• copytruncate : logrotate fait une copie du fichier, puis vide l'original (taille zéro). Le serveur, sans rien remarquer, continue d'écrire sur le même descripteur. Quelques lignes écrites dans le bref instant entre la copie et la troncature peuvent être perdues, mais aucun redémarrage n'est nécessaire. Pour la plupart des serveurs de jeu prêts à l'emploi, c'est la voie la plus pratique.
• postrotate avec un signal : si votre serveur sait rouvrir son fichier de log sur un signal, vous le prévenez après la rotation. Cela élimine le risque de copytruncate de perdre ne serait-ce qu'une ligne :

/var/log/metin2/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload metin2.service > /dev/null 2>&1 || true
    endscript
}

sharedscripts n'exécute le bloc postrotate qu'une seule fois, même si plusieurs fichiers correspondent au motif.

Testez d'abord, faites confiance ensuite

Une fois la configuration écrite, n'attendez pas à l'aveugle. Essayez logrotate en mode simulation (dry-run) ; il montre ce qu'il ferait sans rien modifier :

logrotate -d /etc/logrotate.d/metin2

La sortie indique quels fichiers seraient tournés et les opérations comme copytruncate. Pour forcer réellement une rotation, utilisez -f :

logrotate -f /etc/logrotate.d/metin2

Deux pièges fréquents : logrotate ignore un fichier de configuration, pour des raisons de sécurité, s'il est modifiable par d'autres utilisateurs (world-writable) ou s'il n'appartient pas à root. Gardez les permissions à chmod 0644 et la propriété à root:root. Vous aurez peut-être aussi besoin de la directive su utilisateur groupe pour déclarer le propriétaire du répertoire de logs.

Questions fréquentes

Puis-je exécuter logrotate plus souvent, par exemple toutes les heures ?

Oui. Vous pouvez ajouter hourly à la configuration, mais comme logrotate est déclenché par un cron quotidien, une exécution horaire nécessite une entrée cron distincte ou un timer systemd. Dans la plupart des cas, la directive size est plus pratique : le fichier est tourné lors de l'exécution quotidienne dès qu'il dépasse la taille choisie.

Puis-je faire des recherches dans les anciens logs compressés ?

Oui. La commande zgrep "error" syserr.log.3.gz cherche dans les fichiers .gz sans les décompresser. zcat et zless fonctionnent également.

Dois-je d'abord réduire mon énorme fichier de log actuel ?

Non ; logrotate le fera tourner à sa première exécution. Néanmoins, si le disque est à un niveau critique, vous pouvez forcer une rotation avec -f pour libérer immédiatement de l'espace. Ne supprimez jamais le fichier avec rm pendant que le processus tourne ; l'espace ne reviendra pas, car le processus garde encore le fichier ouvert.

Vous voulez des logs maîtrisés et un serveur à l'abri des plantages ? Nous pouvons mettre en ordre ensemble l'infrastructure de logs de votre serveur de jeu et la maintenance Linux générale. Contactez-moi et établissons un plan de rotation adapté à votre serveur.