Gérer la taille des journaux systemd avec journalctl

Les journaux de systemd sont indispensables pour administrer un VPS Linux, un serveur cloud ou un serveur dédié. Ils aident à comprendre un redémarrage, une panne réseau, un service web arrêté ou une erreur SSH. Sans limite, ils peuvent toutefois consommer une part importante du stockage SSD et aggraver une saturation du disque. Ce guide explique comment mesurer, nettoyer et encadrer leur taille avec journalctl.

Pourquoi contrôler les journaux systemd

Un serveur virtuel dispose d'une capacité de stockage définie. Sur une machine qui héberge un site web, une base de données MySQL, un serveur de jeu ou un panneau de contrôle, les journaux systemd s'ajoutent aux sauvegardes, aux fichiers de l'application et aux journaux d'Apache ou d'autres services. Un disque presque plein peut empêcher l'écriture de nouveaux fichiers, perturber un service et compliquer un diagnostic.

La première étape consiste à observer l'espace global, puis la taille réellement utilisée par le journal systemd. Ne supprimez pas les journaux avant d'avoir conservé les éléments utiles à l'analyse d'un incident. Cette méthode s'applique notamment aux distributions Linux courantes comme Debian et Ubuntu, avec les droits d'administration nécessaires.

Mesurer la taille occupée

Affichez l'espace utilisé par les journaux persistants et volatils avec :

journalctl --disk-usage

Pour connaître l'espace libre du système de fichiers, utilisez également :

df -h

Ces deux contrôles répondent à des questions différentes : le premier mesure le journal consultable par journalctl, tandis que le second montre la capacité disponible sur chaque système de fichiers. Vérifiez aussi les points de montage si votre serveur dédié utilise plusieurs volumes.

Nettoyer les anciennes entrées

Avant toute suppression, exportez si nécessaire les lignes utiles à votre ticket ou à votre analyse. Pour conserver uniquement une période récente, journalctl accepte une durée avec l'option --vacuum-time :

sudo journalctl --vacuum-time=14d

Pour ramener les journaux sous une taille donnée, utilisez --vacuum-size :

sudo journalctl --vacuum-size=1G

La purge agit sur les fichiers de journal archivés. Il est donc normal que la taille ne tombe pas exactement à la valeur demandée si le journal actif reste en cours d'utilisation. Contrôlez le résultat avec journalctl --disk-usage, puis vérifiez que les services importants répondent toujours.

Définir des limites persistantes

Une purge ponctuelle ne suffit pas si le serveur produit continuellement des événements. La configuration de journald peut encadrer l'espace utilisé par les journaux persistants avec des paramètres comme SystemMaxUse= et SystemKeepFree=. Les journaux volatils peuvent être contrôlés avec les paramètres correspondants commençant par Runtime.

La configuration locale se place généralement dans un fichier sous /etc/systemd/journald.conf.d/, afin de séparer vos réglages des fichiers fournis par le paquet. Par exemple :

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/limits.conf

Ajoutez uniquement les valeurs adaptées à votre disque et à votre besoin de conservation :

[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
RuntimeMaxUse=256M

Après modification, rechargez journald :

sudo systemctl restart systemd-journald
journalctl --disk-usage

La limite de conservation n'est pas une sauvegarde. Si vous devez conserver des preuves d'incident plus longtemps, prévoyez une copie hors du serveur ou un système de centralisation adapté. Une sauvegarde distante reste nécessaire pour les données de l'application, de la base de données et du serveur web.

Choisir une limite adaptée à un VPS

Une valeur fixe n'est pas universelle. Sur un petit VPS Linux, une limite de 1 Go peut déjà représenter une part notable du stockage. Sur un serveur dédié avec plusieurs SSD, davantage d'historique peut être conservé si le besoin de diagnostic le justifie. Tenez compte de la RAM disponible, du CPU, du processeur, du volume de trafic et du nombre de services démarrés.

Dans un hébergement cloud, plusieurs serveurs virtuels ou machines virtuelles peuvent avoir des usages différents. Un serveur web recevra des requêtes HTTP, un serveur de base de données écrira ses propres événements et un panneau de gestion ajoutera parfois ses journaux. La bonne limite dépend donc du rôle du serveur, de son espace de stockage et de la durée de conservation souhaitée, pas seulement de son adresse IP.

Adapter la méthode au type d'hébergement

Sur un VPS ou une machine dédiée, l'administrateur dispose généralement des droits root et peut configurer journald. En hébergement mutualisé, cette configuration appartient plutôt à l'hébergeur ou à l'infogérance. La virtualisation et le niveau de support technique déterminent donc ce que vous pouvez modifier. Vérifiez le périmètre de votre offre avant d'utiliser sudo ou de redémarrer un service système.

Cette distinction évite de confondre le nettoyage des journaux avec une action sur la plateforme. Un serveur mutualisé, un VPS cloud et une machine dédiée n'offrent pas la même visibilité sur le système d'exploitation, les journaux, le stockage ou le monitoring.

Relier les logs au diagnostic du serveur

Une erreur d'accès ne vient pas toujours de journald. Vérifiez la résolution DNS, le firewall, le service qui écoute sur le port attendu et l'état de l'application. Les journaux SSH documentent l'administration distante, tandis que les logs du serveur web, de la base MySQL ou d'un service de jeu répondent à d'autres questions. Ne mélangez pas les fichiers de log avec les sauvegardes, les fichiers FTP ou le contenu du site.

Cette distinction est particulièrement importante avec un VPS, un serveur privé ou un hébergement dédié : une purge de journald ne libère pas nécessairement l'espace utilisé par un CMS, un panel, une base de données ou une archive de backup. Mesurez chaque emplacement séparément avant d'agir. Un outil de monitoring peut ensuite suivre l'espace disque, la mémoire et la charge pour prévenir une nouvelle saturation.

Vérifier après la purge

Relisez les messages récents et vérifiez que le service principal fonctionne toujours :

journalctl -p warning -b
systemctl --failed
systemctl status systemd-journald

Si un service de jeu vient de subir une interruption, complétez ce contrôle par notre guide pour analyser les logs d'un serveur de jeu avec journalctl. Pour surveiller le risque de saturation, consultez aussi le guide de surveillance de l'espace disque d'un VPS.

Bonnes pratiques d'administration

• Mesurez avant et après chaque purge avec journalctl --disk-usage.
• Conservez les journaux nécessaires à l'incident avant de réduire leur durée.
• Réservez une marge d'espace libre avec SystemKeepFree, au lieu d'attendre la saturation.
• Documentez la durée de conservation choisie pour pouvoir l'expliquer lors d'un diagnostic.
• Surveillez aussi les autres répertoires qui grossissent, notamment les sauvegardes et les fichiers temporaires.

Pour poursuivre le diagnostic d'un VPS, vous pouvez vérifier les inodes disponibles, analyser les I/O disque avec iostat ou interpréter la charge système avec uptime. Pour sécuriser l'accès d'administration, consultez également le guide consacré à la configuration d'une clé SSH sans perdre l'accès.