Limiter les journaux et vérifier la récupération d’espace

Lorsque les écritures en base de données échouent alors qu’aucun nouveau fichier de données métier n’est apparu sur le disque, une cause fréquente est la répétition de messages d’erreur qui finit par remplir la partition système. Maîtriser le volume des journaux ne consiste pas à supprimer périodiquement un répertoire : il faut contrôler séparément l’écriture, la rotation et la conservation, puis vérifier que l’espace a réellement été récupéré. Cet article prend Debian 12 comme exemple pour traiter le journal système et les journaux fichiers de tâches de courte durée, sans modifier les fichiers de la base de données ni l’organisation existante du stockage.

Les serveurs dédiés CloudSFP sont équipés de série de deux disques NVMe de 1TB, chacun raccordé directement, sans RAID matériel. La capacité des deux disques ne peut pas être assimilée à l’espace disponible dans le système de fichiers qui héberge les journaux : leur budget doit être établi à partir du point de montage réel. Toutes les capacités indiquées ci-dessous sont des exemples de configuration, et non des réglages par défaut du service.

1. Localiser l’occupation et distinguer blocs disque et inodes

Après le paiement, consultez les identifiants dans la console et connectez-vous par SSH. Si le serveur possède plusieurs adresses, utilisez la première. Commencez par des vérifications en lecture seule :

df -hT / /var/log
df -i / /var/log
findmnt -T /var/log
sudo du -xhd1 /var/log
sudo journalctl --disk-usage

df indique l’occupation du système de fichiers, tandis que du mesure les fichiers visibles dans un répertoire. Leurs résultats ne sont pas nécessairement identiques. L’option -x évite de parcourir d’autres systèmes de fichiers et réduit le risque d’inclure dans le calcul des volumes montés séparément. Si /var/log n’est pas sur une partition distincte, les journaux consomment l’espace de la partition racine avec les fichiers système.

Si l’espace disponible est suffisant mais que les inodes sont presque épuisés, recherchez une accumulation de petits fichiers plutôt que les seuls journaux les plus volumineux. Relevez le système de fichiers, l’espace disponible, l’utilisation des inodes et les répertoires dont le volume augmente le plus vite avant de choisir quoi traiter. N’enregistrez pas les résultats du diagnostic sur une partition déjà proche de la saturation.

Ne supprimez pas directement tout le répertoire /var/log et ne tronquez pas des journaux d’incident dont le contenu n’a pas encore été préservé. Avant le nettoyage, conservez les éléments correspondant à la période concernée et vérifiez que les fichiers visés ne sont ni des données de base de données, ni des journaux de transactions, ni des sauvegardes.

2. Définir un budget de capacité propre à journald

Le journal persistant se trouve généralement dans /var/log/journal. Définir les limites dans un fichier de configuration complémentaire, ou drop-in, facilite leur audit et leur retrait par rapport à une modification directe de la configuration principale. L’exemple suivant fixe un budget pour le journal ainsi qu’une réserve d’espace libre sur le système de fichiers :

sudo install -d -m 0755 /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/60-capacity.conf >/dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=4G
MaxFileSec=1day
EOF

sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
sudo journalctl --flush
sudo journalctl --disk-usage
sudo systemctl status systemd-journald --no-pager

SystemMaxUse définit le budget d’espace du journal, tandis que SystemKeepFree impose de conserver de l’espace libre sur le même système de fichiers. Le comportement effectif dépend aussi de l’espace actuellement disponible. Ces paramètres ne limitent pas les fichiers écrits directement par les applications. MaxFileSec définit la durée maximale couverte par un fichier actif ; il ne signifie pas que les journaux ne sont conservés qu’un jour.

Si un autre programme écrit simultanément les mêmes messages dans un journal texte, limiter le journal système ne supprime pas cette copie. Il faut vérifier la chaîne de journalisation et gérer chaque destination séparément. Ne désactivez pas le service de journalisation système sans avoir effectué ces vérifications.

Effectuer une rotation avant le nettoyage, puis vérifier le résultat

sudo journalctl --rotate
sudo journalctl --vacuum-size=1G
sudo journalctl --disk-usage
df -h /var/log

L’opération vacuum ne supprime que les fichiers archivés, pas directement les fichiers actifs. L’occupation finale n’est donc pas garantie d’être exactement égale à la valeur indiquée. Le redémarrage de journald fait partie du changement de configuration : vérifiez d’abord l’état actuel du service, puis contrôlez l’absence de nouvelles erreurs et la poursuite de l’arrivée des journaux applicatifs dans le journal système.

3. Attribuer clairement la responsabilité de la rotation des journaux fichiers

Identifiez d’abord le processus qui écrit le journal, vérifiez s’il garde le fichier ouvert en permanence et si des règles existantes couvrent déjà ce chemin. Un même fichier ne doit pas être géré à la fois par la rotation intégrée à l’application et par logrotate. N’ajoutez pas non plus de motifs trop larges qui feraient doublon avec les règles système existantes.

Installez les outils de vérification :

sudo apt-get update
sudo apt-get install logrotate lsof

Supposons qu’une tâche de courte durée ouvre à nouveau /var/log/local-batch/run.log à chaque démarrage et ferme le fichier à la fin de son exécution. Vous pouvez alors placer la règle suivante dans /etc/logrotate.d/local-batch :

/var/log/local-batch/run.log {
    daily
    maxsize 100M
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640
}

Le répertoire et le journal initial doivent déjà exister, et leurs propriétaires doivent être adaptés au compte qui exécute la tâche. Lorsque create 0640 ne précise pas de propriétaire, le propriétaire et le groupe du fichier d’origine sont repris. Si un compte non privilégié peut écrire dans le répertoire, évaluez séparément la directive su et les permissions du répertoire : ne recopiez pas la règle sans vérification.

sudo logrotate -d /etc/logrotate.conf
systemctl list-timers --all --no-pager

L’option -d affiche uniquement le résultat d’une simulation, sans effectuer de rotation. Vérifiez la fréquence réelle d’exécution du timer ou de cron : maxsize n’est contrôlé que lorsque logrotate est appelé, ce n’est pas une limite stricte appliquée en temps réel. rotate 7 signifie que sept archives sont conservées, pas nécessairement sept jours de journaux.

Un processus qui reste en fonctionnement a besoin d’un mécanisme de réouverture des journaux pris en charge par l’application. Après le renommage d’un fichier, il peut continuer à écrire dans l’ancien. Ne choisissez pas un signal au hasard et n’utilisez pas copytruncate par défaut : cette méthode comporte une fenêtre de perte de messages entre la copie et la troncature.

4. Tester la rotation et les permissions dans un répertoire isolé

Ne testez pas une nouvelle règle en forçant la rotation de la configuration globale. Le test suivant utilise un répertoire et un fichier d’état distincts, sans toucher aux journaux de production :

umask 077
test_dir=$(mktemp -d)
printf '%0200d\n' $(seq 1 20) >"$test_dir/run.log"

cat >"$test_dir/rules" <<EOF
"$test_dir/run.log" {
    size 1k
    rotate 2
    create 0640
}
EOF

logrotate -d -s "$test_dir/state" "$test_dir/rules"
logrotate -s "$test_dir/state" "$test_dir/rules"
ls -l "$test_dir"
printf 'after rotation\n' >>"$test_dir/run.log"
cat "$test_dir/run.log"

Vous devez retrouver le fichier archivé, le nouveau fichier actif et les permissions attendues. La dernière écriture prouve seulement qu’il est possible de rouvrir le chemin du fichier ; elle ne prouve pas qu’une application fonctionnant en continu basculera automatiquement vers le nouveau fichier. Pour valider en production, faites également produire une entrée identifiable par la tâche réelle et vérifiez qu’elle apparaît dans le nouveau fichier actif.

Conservez le répertoire de test le temps d’examiner les résultats, puis supprimez-le après validation. Les règles de production doivent toujours être gérées par le fichier d’état habituel du système. Ne laissez pas un lancement manuel s’exécuter en même temps que la tâche planifiée et ne gérez pas durablement un même journal avec deux fichiers d’état.

5. Valider l’espace récupéré et traiter les erreurs répétitives

Si la suppression de fichiers n’augmente pas l’espace disponible, vérifiez d’abord les fichiers encore maintenus ouverts par des processus :

sudo lsof +L1
df -h /var/log
df -i /var/log
sudo du -xhd1 /var/log

lsof +L1 liste les fichiers ouverts dont le nombre de liens est inférieur à un. Interprétez les résultats à partir du chemin, de la taille et du processus : tous les fichiers affichés ne sont pas des journaux. Une fois la cible identifiée, rouvrez les journaux conformément à la documentation de l’application, redémarrez le service concerné si nécessaire, puis vérifiez à nouveau df. Ne forcez pas la récupération d’espace en arrêtant des processus non identifiés ou en écrivant dans leurs descripteurs de fichiers.

Conservez au minimum quatre résultats de validation : les nouvelles entrées arrivent dans le fichier actif, le nombre d’archives respecte la règle, le compte peut continuer à écrire et l’espace disponible du système de fichiers ne diminue pas de façon anormale et continue. Si les messages d’erreur se répètent toujours en masse, corrigez leur source : nouvelles tentatives après échec, requêtes invalides ou sortie de débogage. La rotation ne remplace pas la résolution des incidents.

Un budget de capacité ne garantit pas non plus une durée fixe d’historique. En période de pointe, les journaux grossissent plus vite et, à budget égal, les anciennes entrées sont supprimées plus tôt. Pour les éléments qui doivent être conservés à long terme, prévoyez séparément leur transfert, le contrôle des accès et les sauvegardes, puis vérifiez réellement leur lecture. La rotation locale sert uniquement à limiter l’espace occupé sur le serveur ; elle ne constitue pas une sauvegarde.

Questions fréquentes