Configurer la rotation des journaux Linux avec logrotate

Les journaux Linux permettent de comprendre ce qui se passe sur un VPS, mais leur accumulation peut devenir difficile à suivre. Une rotation bien réglée conserve les événements utiles, limite la taille des fichiers et facilite les recherches lors d’un incident. Ce guide présente une méthode prudente pour configurer la rotation des journaux avec logrotate, vérifier la configuration et éviter de supprimer trop tôt les traces dont vous avez besoin.

Pourquoi configurer la rotation des journaux Linux

Un serveur Linux produit des journaux pour les services, l’authentification, le noyau et les tâches planifiées. Sur Ubuntu comme sur Debian, ces informations peuvent être écrites dans des fichiers classiques ou consultables avec journalctl. Un serveur Web, une base de données, un agent de sauvegarde ou un serveur de jeu peuvent également produire leurs propres fichiers de log. Sans politique de rétention, ces fichiers peuvent occuper une part croissante du stockage et compliquer le diagnostic.

La rotation ne consiste pas à effacer aveuglément les logs. Elle organise leur archivage, leur compression et leur suppression selon une règle définie. Avant toute modification, vérifiez l’espace disponible et identifiez les journaux importants pour votre serveur. Vous pouvez aussi consulter notre guide pour surveiller l’espace disque d’un VPS Linux.

Vérifier la présence de logrotate

Sur de nombreuses distributions Linux, logrotate est déjà installé ou fourni par les paquets système. Vérifiez sa présence depuis la ligne de commande :

command -v logrotate
logrotate --version

La commande command -v indique si l’exécutable est accessible dans le chemin courant. La seconde affiche la version disponible. Si le programme n’est pas présent, utilisez le gestionnaire de paquets officiel d’Ubuntu ou de Debian et consultez la documentation de votre distribution avant l’installation. N’exécutez pas une configuration copiée depuis un autre système sans vérifier ses chemins et ses permissions.

Lire la configuration existante

La configuration principale se trouve généralement dans /etc/logrotate.conf, tandis que des règles de services sont souvent placées dans /etc/logrotate.d/. Commencez par lire les fichiers concernés :

sudo less /etc/logrotate.conf
sudo ls -la /etc/logrotate.d/

Recherchez notamment la fréquence de rotation, le nombre d’archives conservées, la compression et les directives propres au service. Un administrateur doit aussi vérifier qui possède le fichier, quel groupe peut le lire et quel processus continue d’écrire après la rotation. Pour les journaux d’authentification, ne confondez pas rotation et protection SSH : l’analyse des connexions échouées répond à un besoin de diagnostic, alors que la limitation des tentatives répond à un besoin de réduction du risque.

Créer une règle pour un service

Ajoutez une règle dédiée dans /etc/logrotate.d/ uniquement lorsque le service n’en fournit pas déjà une. Exemple générique à adapter au chemin réel du journal :

/var/log/mon-service/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
}

weekly définit une fréquence hebdomadaire, rotate 8 conserve huit archives, et compress réduit leur taille. delaycompress reporte la compression de l’archive la plus récente. missingok évite une erreur si le fichier est absent, tandis que notifempty empêche une rotation d’un fichier vide. Les droits de création doivent rester cohérents avec l’utilisateur et le groupe attendus par le service.

Ne réutilisez pas cet exemple tel quel : remplacez le chemin, la fréquence, la rétention et les droits après avoir identifié le comportement documenté du logiciel concerné. Une rotation mal paramétrée peut empêcher un service d’écrire dans son journal ou rendre un diagnostic incomplet. Si le service est lancé par un script ou par une unité systemd, vérifiez aussi la manière dont il recharge sa configuration.

Tester la règle sans modifier les fichiers

Avant d’attendre l’exécution planifiée, demandez à logrotate de vérifier la configuration en mode verbeux et simulé :

sudo logrotate -d /etc/logrotate.conf

Le mode de diagnostic affiche les actions envisagées sans effectuer la rotation. Lisez les messages liés au chemin, aux permissions et aux scripts de post-traitement. Corrigez d’abord les erreurs signalées, puis relancez le test. Pour les services qui continuent d’écrire dans un fichier après sa rotation, suivez la procédure officielle du logiciel afin de recharger ou rouvrir ses descripteurs.

Effectuer une rotation manuelle avec prudence

Après un test satisfaisant, une exécution forcée peut servir à valider le résultat sur un environnement de test ou pendant une fenêtre de maintenance :

sudo logrotate -vf /etc/logrotate.conf

L’option -f demande une rotation même si l’intervalle normal n’est pas atteint et -v affiche les opérations. N’utilisez pas cette commande comme réflexe sur un serveur en production : vérifiez d’abord le volume de logs, la place disponible et l’impact sur le service. Contrôlez ensuite les fichiers actifs, les archives et les droits. Une sauvegarde ne remplace pas une règle de rotation, mais elle peut être nécessaire avant une modification sensible de configuration.

Contrôler les journaux après la rotation

Après une rotation, vérifiez que le service écrit bien dans le nouveau fichier et que les archives attendues sont présentes :

sudo ls -lh /var/log/mon-service/
sudo journalctl --since "10 minutes ago"

Adaptez la seconde commande au service étudié. Si un journal semble incomplet, comparez l’heure de rotation, le processus qui écrit le fichier et la configuration du service. Pour un diagnostic global, notre guide sur l’analyse des logs d’un serveur de jeu avec journalctl complète cette méthode. En cas de difficulté réseau, consultez aussi le guide de diagnostic d’un VPS inaccessible.

Relier les logs aux autres contrôles du serveur

Les logs ne sont utiles que s’ils sont replacés dans le contexte du serveur. Un administrateur peut rapprocher la date d’une erreur d’un redémarrage systemd, d’un changement de configuration, d’une règle de pare-feu ou d’une saturation du disque. Cette méthode évite de modifier plusieurs paramètres à la fois et facilite le retour arrière.

Pour un service Web, contrôlez séparément le journal d’accès et le journal d’erreur. Un site Web peut réunir un serveur comme Apache ou Nginx, une application PHP ou Python et une base de données MySQL ou PostgreSQL : chaque composant peut avoir sa propre configuration et ses propres journaux. Pour un serveur de jeu, séparez les événements du moteur, du proxy et des extensions. Pour SSH, distinguez une mauvaise clé, un mauvais identifiant et une série de tentatives répétées. Dans tous les cas, ne publiez pas un journal contenant des adresses IP, des identifiants ou des secrets sans les anonymiser.

Méthode de diagnostic en ligne de commande

Pour isoler un problème de configuration du serveur, avancez du répertoire vers le service. Listez d’abord le fichier de règle dans /etc/logrotate.d/, contrôlez son propriétaire et relisez son contenu. Lancez ensuite le test en mode diagnostic, puis examinez les messages du service avec journalctl. Cette progression donne aux administrateurs une trace claire des changements et limite les interventions inutiles.

sudo ls -l /etc/logrotate.d/mon-service
sudo logrotate -d /etc/logrotate.conf
sudo systemctl status mon-service --no-pager

Si l’application ne produit plus de log, ne redémarrez pas immédiatement le serveur entier. Vérifiez d’abord le service, son chemin de fichier, ses permissions et son espace disponible. Un redémarrage ciblé peut être envisagé uniquement selon la documentation de l’application et votre fenêtre de maintenance. Le pare-feu, le DNS et l’adresse IP expliquent une connexion impossible, mais ne corrigent pas une règle de rotation locale : séparez ces hypothèses.

La même logique vaut sur un serveur dédié ou une machine virtuelle : chaque environnement possède ses propres répertoires, utilisateurs et services. Notez la distribution, la version du paquet, le chemin du journal et la configuration testée avant de demander de l’aide. Cette fiche rend le diagnostic reproductible et facilite la comparaison entre deux serveurs. Conservez également vos sauvegardes de configuration dans un emplacement distinct du répertoire des logs.

Bonnes pratiques de rétention

• Définissez une rétention liée à votre besoin réel de diagnostic et à votre capacité de stockage.
• Conservez séparément les journaux nécessaires à la sécurité, à la conformité ou à l’analyse d’un incident.
• Testez une règle avec le mode de diagnostic avant toute rotation forcée.
• Surveillez l’espace disque après modification, notamment si plusieurs services produisent des logs.
• Documentez chaque changement pour pouvoir revenir à une configuration connue.
• Vérifiez les permissions des archives et limitez leur accès aux comptes qui en ont besoin.

La rotation n’est qu’un élément de l’exploitation d’un serveur. Pour préparer un environnement administrable, consultez nos pages VPS Linux et serveurs dédiés. Les recommandations doivent toujours être adaptées à la distribution, au service et aux exigences de conservation de vos journaux.