Debian 13 : Journald a mangé votre disque — limiter les logs sans perdre l’essentiel

Playbook de diagnostic rapide

Ceci est la séquence « l’alerte sonne, le disque est à 98% et l’application lance des erreurs bizarres ». Vous voulez du signal en moins de cinq minutes. Faites ceci dans l’ordre.

Première étape : confirmer où l’espace disque est parti

• Vérifiez le système de fichiers plein et si c’est le chemin du journal (généralement /var ou la racine).
• Mesurez /var/log/journal et /run/log/journal.
• Vérifiez la vue d’utilisation propre à journald.

Deuxième étape : déterminer s’il s’agit d’une tempête de logs ou d’une rétention

• Recherchez des messages de limitation de débit, des unités qui échouent en boucle, ou un service bavard.
• Vérifiez le taux d’ingestion : comptez par unité sur les « 5 dernières minutes ».
• Vérifiez si les logs sont persistants et quelle est la taille des plafonds configurés.

Troisième étape : arrêter l’hémorragie en sécurité

• Exécutez un vacuum par taille ou par temps (pas une suppression aléatoire), et assurez-vous de ne pas supprimer la seule copie des logs dont vous avez besoin.
• Appliquez des plafonds dans journald.conf et redémarrez journald.
• Corrigez le service bavard. Sinon, vous balayez juste de l’eau avec un balai.

Blague #1 : Les logs sont comme les paillettes — parfaits pour les loisirs, catastrophiques en production, et vous en retrouvez partout où ils ne devraient pas être.

Ce que journald fait réellement à votre disque

systemd-journald collecte les logs du noyau, des services et de tout ce qui écrit sur stdout/stderr sous systemd. Il les stocke dans un format binaire de journal. Cela vous apporte indexation, champs structurés et filtrage rapide. Mais cela vous apporte aussi la capacité de remplir le disque à la vitesse où « quelqu’un a activé le logging debug sur un chemin critique ».

Persistant vs volatile : la bifurcation silencieuse

journald peut stocker les logs en mémoire (/run/log/journal) ou sur disque (/var/log/journal). Sur beaucoup de serveurs, vous voulez des logs persistants, parce que les redémarrages arrivent — parfois volontairement. Mais les journaux persistants exigent que vous définissiez des plafonds et une politique de rétention, car le disque est fini et les logs sont ambitieux.

Pourquoi « disque plein » à cause des logs casse des choses non liées

Quand le système de fichiers contenant /var est plein, journald n’est pas la seule chose qui échoue à écrire. Vous verrez des installations de paquets échouer, des sessions SSH incapables d’allouer des ptys, des bases de données refusant de créer des fichiers temporaires, et des services système échouer parce qu’ils ne peuvent pas écrire d’état. Le premier problème est « les logs ont grossi ». Le second est « tout suppose que l’écriture est possible ».

Les contrôles de stockage de journald sont par défaut basés sur un pourcentage

journald peut appliquer une utilisation maximale en termes absolus (SystemMaxUse=) et peut garder des tampons d’espace libre (SystemKeepFree=). Les valeurs par défaut peuvent être étonnamment permissives pour de petits volumes, spécialement sur des VM avec des disques root limités.

La rotation n’est pas le problème ; c’est la rétention

Les gens pensent que « faire tourner les logs » règle le problème. journald fait déjà de la rotation en interne. Les explosions de disque surviennent quand la rétention est effectivement « garder tout jusqu’à une limite que vous ignoriez être énorme », ou quand le taux de logs est si élevé qu’un plafond raisonnable est atteint trop rapidement — causant de la churn et la perte des messages les plus récents ou les plus anciens selon vos réglages et la pression.

Faits intéressants & contexte (pour arrêter de se battre contre la mauvaise cause)

• Fait 1 : journald stocke les logs dans un format binaire avec champs indexés, c’est pourquoi journalctl _SYSTEMD_UNIT=foo.service est rapide comparé à grep sur des fichiers texte.
• Fait 2 : Le stockage persistant du journal nécessite que /var/log/journal existe ; sinon journald reste généralement en mode runtime sous /run.
• Fait 3 : Le format du journal prend en charge des fonctions d’intégrité (comme le scellage) destinées à détecter la falsification, mais ces fonctions ne remplacent pas la journalisation centralisée.
• Fait 4 : syslog précède journald de plusieurs décennies et a évolué autour de fichiers texte append-only et du forwarding distant ; journald a évolué en supposant des systèmes riches en métadonnées et conscients des unités.
• Fait 5 : Les noyaux Linux peuvent émettre des flots de messages si un pilote ou un système de fichiers devient instable ; la mémoire circulaire du noyau et journald peuvent devenir des complices involontaires.
• Fait 6 : Sur des systèmes occupés, le logging devient lui-même une caractéristique de performance — ou un bug de performance — parce que chaque ligne de log est IO, CPU et contention quelque part.
• Fait 7 : Les plateformes de conteneurs ont popularisé le « log to stdout », qui alimente directement journald sur les hôtes systemd à moins que vous ne routiez ailleurs.
• Fait 8 : Les plafonds basés sur un pourcentage (comme « utiliser jusqu’à 10% du système de fichiers ») se comportent très différemment sur un volume root de 20GB versus un volume de logs de 2TB, et les valeurs par défaut ne connaissent pas votre intention.

Une citation, parce que c’est toujours la meilleure contrainte opérationnelle : L’espoir n’est pas une stratégie. — idée paraphrasée souvent attribuée à des leaders en ingénierie et ops.

Tâches pratiques : commandes, sens des sorties, décisions

Ce ne sont pas des exercices de labo. Ce sont les actions à mener lorsque le disque est plein, ou sur le point de l’être. Chaque tâche inclut : une commande, ce que la sortie vous dit, et la décision à prendre ensuite.

Tâche 1 : Identifier quel système de fichiers est réellement plein

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/vda1      ext4    30G   29G  200M 100% /
tmpfs          tmpfs  3.1G  1.2M  3.1G   1% /run

Ce que cela signifie : La racine est pleine ; journald en stockage persistant vit probablement sous /var qui est sur / ici. Vos écritures échouent globalement.

Décision : Passez immédiatement à la mesure des répertoires de journal et au vacuum. Planifiez aussi un plafond à long terme, sinon cela se reproduira.

Tâche 2 : Mesurer les répertoires du journal par taille

cr0x@server:~$ sudo du -sh /var/log/journal /run/log/journal 2>/dev/null
18G	/var/log/journal
24M	/run/log/journal

Ce que cela signifie : Le journal persistant est le gros consommateur. Le journal runtime est petit.

Décision : Faites le vacuum du journal persistant ; puis appliquez des plafonds en configuration.

Tâche 3 : Demander à journald combien d’espace il pense utiliser

cr0x@server:~$ sudo journalctl --disk-usage
Archived and active journals take up 18.1G in the file system.

Ce que cela signifie : Cela confirme que le comptage de journald correspond à ce que vous avez vu avec du. Si ce n’est pas le cas, vous pouvez avoir affaire à des fichiers ouverts mais supprimés ou à d’autres chemins de logs.

Décision : Si ce nombre est élevé et pousse rapidement, vous avez besoin à la fois de limites de rétention et de contrôle du débit/volume à la source.

Tâche 4 : Voir comment journald est configuré (valeurs effectives)

cr0x@server:~$ sudo systemd-analyze cat-config systemd/journald.conf
# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
MaxRetentionSec=1month
RateLimitIntervalSec=30s
RateLimitBurst=10000

# /usr/lib/systemd/journald.conf
[Journal]
#Storage=auto
#SystemMaxUse=
#SystemKeepFree=

Ce que cela signifie : Vous pouvez voir ce qui est défini dans /etc versus les paramètres par défaut. Si vous n’avez pas de plafonds explicites, vous comptez sur des valeurs par défaut pour correspondre à la taille de votre disque. C’est un pari que vous perdez généralement.

Décision : Mettez des limites explicites dans /etc/systemd/journald.conf (ou un drop-in) adaptées à votre disque et à vos besoins de conformité.

Tâche 5 : Confirmer que journald utilise un stockage persistant et que le chemin existe

cr0x@server:~$ sudo ls -ld /var/log/journal
drwxr-sr-x+ 3 root systemd-journal 4096 Dec 28 08:11 /var/log/journal

Ce que cela signifie : Le répertoire existe avec le groupe attendu. Bien. S’il n’existait pas, journald serait peut-être en mode runtime et vous perdriez les logs au reboot.

Décision : Si vous exigez la persistance, assurez-vous que /var/log/journal existe et que le système est dans le groupe systemd-journal si nécessaire.

Tâche 6 : Trouver l’unité la plus bruyante des 5 dernières minutes

cr0x@server:~$ sudo journalctl --since "5 min ago" --output short-unix | awk '{print $6}' | sort | uniq -c | sort -nr | head
  8421 myapp.service:
  2103 kernel:
   611 sshd[1023]:
   222 systemd[1]:

Ce que cela signifie : myapp.service envoie des rafales. Le noyau est aussi bavard mais secondaire.

Décision : Corrigez d’abord le niveau de logging ou le bug applicatif ; puis ajustez la rétention de journald comme filet de sécurité, pas comme contrôle primaire.

Tâche 7 : Inspecter le contenu du spam (ne pas deviner)

cr0x@server:~$ sudo journalctl -u myapp.service --since "15 min ago" -n 20
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1234
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1235
Dec 28 08:34:01 server myapp[2211]: DEBUG cache miss key=user:1236

Ce que cela signifie : Il s’agit de bruit au niveau debug en production. Ce n’est pas « juste des logs » ; c’est le symptôme d’un changement ou d’une mauvaise configuration.

Décision : Revenir la configuration, corriger le niveau de logging en hotfix, ou ajouter de l’échantillonnage. Ne pas « vacuum plus fort ».

Tâche 8 : Vérifier si journald applique une limitation de débit (et perd des messages)

cr0x@server:~$ sudo journalctl -u systemd-journald --since "1 hour ago" | tail -n 20
Dec 28 08:22:12 server systemd-journald[342]: Suppressed 15432 messages from /system.slice/myapp.service
Dec 28 08:22:42 server systemd-journald[342]: Suppressed 18201 messages from /system.slice/myapp.service

Ce que cela signifie : journald est déjà en train de perdre des logs à cause des limites de débit. Votre problème disque et votre problème d’observabilité surviennent en même temps.

Décision : Traitez cela comme un incident : réduisez le volume de logs à la source. Envisagez une pipeline séparée pour les logs à haut volume (métriques, traces, ou logs échantillonnés).

Tâche 9 : Vacuum en toute sécurité par taille (le geste le plus rapide pour « faire de la place »)

cr0x@server:~$ sudo journalctl --vacuum-size=2G
Vacuuming done, freed 16.1G of archived journals from /var/log/journal.

Ce que cela signifie : Ceci applique un plafond immédiat sur les données stockées existantes. Cela supprime les anciens fichiers archivés jusqu’à ce que l’utilisation soit environ 2G.

Décision : Si le système est en feu, faites-le maintenant. Puis implémentez la configuration pour ne pas répéter l’opération manuellement.

Tâche 10 : Vacuum par temps (utile pour les fenêtres de conformité)

cr0x@server:~$ sudo journalctl --vacuum-time=14d
Vacuuming done, freed 6.3G of archived journals from /var/log/journal.

Ce que cela signifie : Garde approximativement seulement les 14 derniers jours, en supprimant les entrées plus anciennes.

Décision : Utilisez ceci quand votre politique de rétention est basée sur le temps. Combinez avec des plafonds de taille afin qu’une tempête de logs n’efface pas votre fenêtre de 14 jours en deux heures.

Tâche 11 : Vérifier la santé du disque après vacuum

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   12G   17G  42% /

Ce que cela signifie : Vous êtes revenu du précipice. Maintenant vous pouvez corriger la cause racine sans que le système de fichiers hurle.

Décision : Configurez immédiatement des plafonds journald et corrigez l’unité bavarde. « On le fera plus tard » est la façon dont vous rencontrez le même problème la semaine suivante.

Tâche 12 : Configurer des plafonds (drop-in), puis redémarrer journald

cr0x@server:~$ sudo install -d -m 0755 /etc/systemd/journald.conf.d
cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/00-limits.conf >/dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
RuntimeMaxUse=256M
RuntimeKeepFree=64M
MaxRetentionSec=1month
MaxFileSec=1day
RateLimitIntervalSec=30s
RateLimitBurst=5000
EOF
cr0x@server:~$ sudo systemctl restart systemd-journald

Ce que cela signifie : Vous avez défini des plafonds explicites et un tampon « garder de l’espace libre » pour protéger le reste du système. Vous avez aussi fixé la cadence de rotation (MaxFileSec) et les limites de débit.

Décision : Ajustez ces nombres selon la taille de votre disque et vos besoins en réponse aux incidents. Si votre disque root fait 20–40GB, un journal de 2GB est généralement sensé. Sur des volumes de logs dédiés, vous pouvez monter plus haut.

Tâche 13 : Confirmer les paramètres effectifs après les changements

cr0x@server:~$ sudo systemd-analyze cat-config systemd/journald.conf | sed -n '1,80p'
# /etc/systemd/journald.conf.d/00-limits.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
RuntimeMaxUse=256M
RuntimeKeepFree=64M
MaxRetentionSec=1month
MaxFileSec=1day
RateLimitIntervalSec=30s
RateLimitBurst=5000

Ce que cela signifie : Vous ne comptez pas sur votre mémoire. Vous lisez la configuration réelle en couches que systemd appliquera.

Décision : Si vous voyez plusieurs drop-ins conflictuels, consolidez-les. L’explosion de configuration est la façon dont les limites cessent de fonctionner silencieusement.

Tâche 14 : Identifier les fichiers supprimés mais encore ouverts (le piège « df dit plein, du dit pas »)

cr0x@server:~$ sudo lsof +L1 | head
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NODE NAME
systemd-j 342 root   12w  REG  253,0  1048576     0 1234 /var/log/journal/.../system@000000.journal (deleted)

Ce que cela signifie : L’espace peut rester « utilisé » tant que le processus garde le handle du fichier, même si le fichier est supprimé.

Décision : Redémarrez le processus en faute (souvent journald lui-même) après vacuum ou nettoyage si vous voyez beaucoup de fichiers journal supprimés tenus ouverts.

Tâche 15 : Vérifier que journald est sain et ne tourne pas en boucle

cr0x@server:~$ systemctl status systemd-journald --no-pager
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Sun 2025-12-28 08:40:12 UTC; 2min ago
       Docs: man:systemd-journald.service(8)
           man:journald.conf(5)

Ce que cela signifie : journald est en cours d’exécution. Cela ne garantit pas qu’il ne supprime pas des messages, mais cela écarte le cas basique « le service est mort ».

Décision : Si journald redémarre en boucle, la corruption du disque ou des problèmes de permissions peuvent être en cause. Passez aux vérifications d’intégrité des fichiers et à la vérification des permissions.

Tâche 16 : Surveiller la tendance d’utilisation du disque (un avertisseur peu coûteux)

cr0x@server:~$ sudo watch -n 2 'journalctl --disk-usage; df -h / | tail -n 1'
Archived and active journals take up 1.9G in the file system.
 /dev/vda1        30G   12G   17G  42% /

Ce que cela signifie : Vous pouvez voir si l’utilisation du journal est stable ou monte rapidement.

Décision : Si elle monte rapidement même après plafonnement, vous observez de la churn (suppression constante et réécriture) qui peut nuire aux performances et toujours faire perdre des logs importants. Corrigez la source des logs.

Plafonner les logs sans regrets : rétention, limites de débit et séparation

Choisissez une politique de rétention comme vous choisissez des sauvegardes : basée sur la récupération, pas sur l’intuition

La rétention des logs est une exigence d’ingénierie qui porte un chapeau de conformité. Vous voulez suffisamment de logs pour répondre aux questions : « Qu’est-ce qui a changé ? », « Qu’est-ce qui a échoué en premier ? », et « Qui/quoi a touché ce système ? » Si vous ne pouvez pas répondre, vous n’avez pas d’observabilité — vous avez un flux d’anxiété défilant.

Sur une VM Debian typique avec un disque root de 20–50GB, un plafond de journal dans la fourchette 1–4GB est raisonnable. Si vous avez besoin de plus, montez un système de fichiers séparé pour /var/log ou au moins pour /var/log/journal. Garder les journaux persistants sur votre système root convient jusqu’à ce que ça ne convienne plus — et c’est toujours « jusqu’à ce que ça ne convienne plus ».

Utilisez à la fois des limites temporelles et de taille

La rétention basée uniquement sur le temps échoue pendant les tempêtes de logs : vous pouvez brûler « 14 jours » en une après-midi. La rétention basée uniquement sur la taille échoue pendant les périodes calmes : vous pouvez garder 90 jours involontairement, ce qui semble bien jusqu’à ce que quelqu’un demande pourquoi des logs de debug sensibles sont encore présents.

Une combinaison pragmatique :

• SystemMaxUse= fixe une borne supérieure.
• SystemKeepFree= protège le reste du système de fichiers contre la croissance du journal.
• MaxRetentionSec= exprime l’intention de la politique.
• MaxFileSec= contrôle la granularité de rotation, ce qui peut rendre les opérations de vacuum moins « tout ou rien ».

Les limites de débit ne remplacent pas la correction des services bruyants

La limitation de débit dans journald protège le système d’un effondrement. Elle masque aussi des preuves quand vous en avez le plus besoin. Si vous voyez des messages de suppression, traitez-les comme un signal d’échec.

Le schéma correct est :

1. Réduire le volume de logs à la source (niveau de log, échantillonnage, corriger les boucles).
2. Plafonner l’usage de journald pour que le nœud reste vivant.
3. Transmettre les logs vraiment nécessaires à un système central avec sa propre rétention et ses contrôles d’accès.

Séparez le « tampon local d’analyse forensique » de la « rétention d’entreprise »

Les journaux locaux sont excellents pour le triage immédiat : ils survivent aux redémarrages, ont des métadonnées, et sont là. Mais le disque d’un nœud unique n’est pas votre archive de conformité et pas votre source de vérité unique.

Si vous avez besoin d’une rétention durable, poussez les logs hors du nœud. Que vous utilisiez rsyslog, les options de forwarding de journald, ou un agent, le principe reste : le disque local est l’amortisseur de choc, pas l’entrepôt à long terme.

Soyez intentionnel sur ce qui « compte »

Ce qui compte n’est pas « tout ». Ce qui compte est :

• Les logs d’authentification (tentatives de connexion, sudo, sshd, échecs PAM).
• Les changements de privilèges et les redémarrages de services.
• Les erreurs noyau et stockage (timeouts I/O, erreurs de système de fichiers).
• Les marqueurs de déploiement et les changements de configuration.
• Les erreurs applicatives et les échecs de requêtes, mais idéalement pas chaque trace de debug.

Quand vous plafonnez les logs, vous décidez consciemment de ce que vous pouvez vous permettre de perdre. Prenez cette décision volontairement, pas en laissant le disque décider pour vous.

Trois mini-histoires d’entreprise (douleur, en triple)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une société de taille moyenne a migré une flotte de serveurs Debian de « syslog classique avec fichiers texte rotatifs » vers une journalisation centrée sur systemd. L’équipe SRE appréciait la rapidité du filtrage par unité et le fait que journald capturait stdout des services qui auparavant disparaissaient dans le vide.

Quelqu’un a fait une hypothèse propre et confiante : « journald a des valeurs par défaut sensées ; il ne remplira pas le disque. » Personne n’a vérifié ce que « sensé » signifiait sur leurs plus petits nœuds de production. Ces nœuds avaient des volumes root modestes parce qu’« ils ne font que des services secondaires ».

Un lundi, un service a commencé à échouer à parler à une dépendance interne. La boucle de retry loggait en INFO à chaque tentative, avec des dumps de payload complets parce qu’un flag debug avait été laissé après un test. Le service n’est pas tombé. Il est resté up et a crié.

En quelques heures, les systèmes root étaient pleins. Soudain, des services non liés ont échoué : mises à jour de paquets, agents de métriques, même SSH sur quelques machines. L’équipe a chassé des fantômes réseau parce que les premiers symptômes étaient « impossible de déployer » et « vérifications de santé échouent ». Il a fallu trop de temps pour remarquer la taille du journal.

La correction fut ennuyeuse : plafonner explicitement le journal et ajouter un tampon « keep free ». La correction de la cause racine était aussi ennuyeuse : enlever les dumps de payload des logs par défaut et déplacer les retries vers des métriques structurées avec échantillonnage. La leçon a été nette : les valeurs par défaut ne sont pas une politique, et « ne remplira pas le disque » n’est pas une propriété — c’est une configuration.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a voulu être maligne. Ils exécutaient beaucoup de services sur une même classe de nœud et voulaient réduire l’usage disque et l’IO. Ils ont donc fixé des plafonds journald agressifs : SystemMaxUse minuscule, rétention courte, et limites de débit basses. L’idée était de « protéger le nœud » et de « forcer les équipes à utiliser la plateforme de logs centralisée ».

Ça a marché. L’usage disque est resté bas. Le nœud est resté vivant sous les tempêtes de logs. Tout le monde s’est félicité et est passé à autre chose.

Puis un incident de production est survenu : un bug lent qui se produisait toutes les quelques heures et laissait une faible trace dans les logs. Pendant l’incident, le système a aussi produit une rafale de logs non liés d’une dépendance instable. Le petit plafond de journald signifiait que les logs d’erreur pertinents ont été évincés rapidement ; la limitation agressive de débit a supprimé les rafales ; et la pipeline centrale — en maintenance — avait des lacunes.

Ils se sont retrouvés avec le mauvais résultat : le système a survécu, mais les preuves ont disparu. Le postmortem fut douloureux parce que ce n’était pas « nous n’avons pas loggé ». C’était « nous avons loggé, mais nous avons conçu le système pour oublier au pire moment ».

Ils ont rétabli un tampon local plus grand sur chaque nœud et ont traité la pipeline centrale comme un stockage durable, pas comme un point de défaillance unique. L’optimisation qui sauvait l’espace disque avait augmenté silencieusement le temps moyen de diagnostic.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise réglementée et réputée pour être « lente » avait une pratique dont les ingénieurs se moquaient : chaque classe de nœud avait une politique journald explicite dans la gestion de configuration. Elle spécifiait des plafonds, la rétention et un tampon d’espace libre minimum. Chaque changement était relu en code. Chaque nœud forwardait aussi les logs critiques hors hôte.

Pendant une régression d’un pilote fournisseur, le noyau a commencé à émettre des avertissements de stockage sur certains hôtes. Ces avertissements ont déclenché une cascade : un service user-space a commencé à retenter et à logguer. Le système a connu une tempête de logs, exactement du type qui fait disparaître les disques.

Mais les nœuds n’ont pas chuté. journald a atteint ses plafonds, a préservé le tampon d’espace libre, et a continué d’accepter assez de messages pour montrer la chronologie. Comme les logs étaient forwarded, l’équipe a pu analyser la séquence même sur des nœuds qui ont redémarré.

L’incident fut toujours réel — les problèmes matériels et de pilotes le sont toujours. Mais il est resté dans la limite « performance dégradée » au lieu de devenir « hôtes non amorçables avec preuves manquantes ». La pratique ennuyeuse n’obtient pas d’applaudissements. Elle assure la disponibilité.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : Disque plein ; /var/log/journal est énorme

Cause racine : Pas de SystemMaxUse / SystemKeepFree explicite, ou les plafonds sont trop élevés pour la taille du système root.

Correction : Faites un vacuum immédiatement, puis définissez des plafonds explicites dans un drop-in et redémarrez journald. Envisagez un système de fichiers de logs dédié.

2) Symptom : Disque plein, mais du n’indique pas où l’espace est parti

Cause racine : Fichiers supprimés encore tenus ouverts (commun après suppressions manuelles), ou croissance sur un autre mount.

Correction : Utilisez lsof +L1 pour trouver les fichiers supprimés encore ouverts ; redémarrez le processus en faute. Évitez les suppressions manuelles ; utilisez journalctl --vacuum-*.

3) Symptom : Logs manquants pendant l’incident

Cause racine : La limitation de débit a supprimé des messages, les plafonds du journal sont trop petits provoquant une éviction rapide, ou les logs étaient volatils et perdus au reboot.

Correction : Réduisez le volume à la source ; ajustez RateLimit* ; assurez-vous de Storage=persistent et que le répertoire existe ; forwardez les logs critiques hors hôte.

4) Symptom : Utilisation CPU de journald monte ; système ralenti pendant les tempêtes

Cause racine : Volume élevé de logs provoquant contention et IO ; rotations trop fréquentes ; churn constant de vacuum sous plafonds serrés.

Correction : Corrigez l’unité bruyante, augmentez modestement les plafonds pour réduire le churn, et maintenez une rotation raisonnable (MaxFileSec). Envisagez de déplacer les journaux sur un stockage plus rapide ou un volume séparé.

5) Symptom : Après reboot, l’historique du journal a disparu

Cause racine : journald est en mode runtime (/run) parce que /var/log/journal n’existe pas ou que Storage est en auto sans répertoire persistant.

Correction : Créez /var/log/journal, mettez Storage=persistent, redémarrez journald.

6) Symptom : Vous avez plafonné journald, mais le disque continue de se remplir

Cause racine : Une autre pipeline de logs écrit ailleurs (fichiers rsyslog, logs applicatifs), ou les plafonds journald ne sont pas appliqués à cause de couches de configuration.

Correction : Vérifiez systemd-analyze cat-config pour journald, vérifiez les cibles rsyslog, et utilisez du -x pour identifier d’autres croissances sous /var.

Blague #2 : Si vous voulez vous sentir puissant, définissez correctement SystemKeepFree et regardez votre futur vous arrêter d’envoyer des messages en colère à votre passé.

Checklists / plan étape par étape

Quand le disque est déjà plein (mode incident)

1. Exécutez df -hT et confirmez quel mount est plein.
2. Mesurez /var/log/journal et confirmez avec journalctl --disk-usage.
3. Identifiez les principaux émetteurs sur les 5–15 dernières minutes (journalctl --since ... pipeline).
4. Vacuumez par taille pour restaurer de l’espace (journalctl --vacuum-size=...).
5. Redémarrez journald si vous suspectez des fichiers supprimés mais ouverts.
6. Réduisez le volume de logs à la source : niveau de log, rollback, ou désactivation des flags debug.
7. Définissez des plafonds explicites et un tampon keep-free via un drop-in ; redémarrez journald.

Plan de durcissement pour les 90 prochains jours (ennuyeux, correct, efficace)

1. Définir la politique : Déterminez l’intention de rétention (ex. : tampon local 30 jours, 180 jours centralisés pour les flux critiques).
2. Dimensionner le stockage : Décidez si /var/log/journal doit rester sur root. Sinon, créez un volume dédié ou au moins un mount séparé pour /var.
3. Implémenter les plafonds : Utilisez SystemMaxUse + SystemKeepFree, et une limite temporelle (MaxRetentionSec).
4. Rendre les tempêtes visibles : Surveillez les messages de suppression journald et les augmentations rapides de journalctl --disk-usage.
5. Améliorer l’hygiène des logs : Faites respecter les règles de logging : pas de dumps de payload en INFO, pas de logging en boucle sans backoff, échantillonnage des erreurs répétitives.
6. Transmettre ce qui compte : Assurez-vous que les logs d’authentification, de privilèges, noyau et déploiement sont copiés hors hôte.
7. Tester : En staging, simulez une tempête de logs et vérifiez que vous ne perdez pas les preuves clés du « premier échec ».

Guidance de configuration : nombres qui fonctionnent généralement

• Disques root petits (20–40GB) : SystemMaxUse=1G–3G, SystemKeepFree=1G, MaxRetentionSec=2week–1month.
• Volume de logs dédié (100GB+) : SystemMaxUse=10G–50G, SystemKeepFree=5G–20G, plus forwarding central.
• Nœuds à fort churn : Préférez corriger les émetteurs bruyants plutôt qu’augmenter les plafonds ; le churn peut devenir un problème de performance et d’usure des SSD.

FAQ

1) journald est-il « mauvais » comparé à rsyslog ?

Non. journald est excellent pour la journalisation locale structurée avec le contexte des unités. rsyslog est excellent pour les logs texte et le forwarding flexible. En production, ils sont souvent complémentaires : journald localement, forwarding central.

2) Si je définis SystemMaxUse, journald arrêtera-t-il de logger quand la limite est atteinte ?

Il continuera de fonctionner en tournant et supprimant les entrées plus anciennes pour rester dans les limites. Cela signifie que le système survit, mais que de vieilles preuves sont évincées. C’est pourquoi vous devez forwarder les logs critiques hors hôte.

3) Quelle est la différence entre SystemMaxUse et SystemKeepFree ?

SystemMaxUse plafonne l’empreinte maximale du journal. SystemKeepFree assure un espace libre minimum sur le système de fichiers. Si vous tenez à la stabilité du nœud, SystemKeepFree est la garde-fou qui empêche « les logs de tuer l’OS ».

4) Dois-je supprimer manuellement des fichiers sous /var/log/journal ?

Évitez-le. Utilisez journalctl --vacuum-size ou --vacuum-time. La suppression manuelle augmente le risque de fichiers supprimés mais ouverts, d’état incohérent, et vous fait sauter la décision de politique.

5) Pourquoi je vois « Suppressed N messages » et dois-je paniquer ?

Vous devez y prêter attention. Cela signifie que vous perdez des lignes de log. Parfois c’est acceptable pendant une tempête, mais souvent c’est le symptôme d’un service cassé ou d’un niveau de logs mal configuré. Corrigez la source.

6) J’ai besoin de logs pour des audits. Puis-je quand même plafonner journald ?

Oui, et vous devriez. Traitez le journal on-host comme un tampon limité, puis forwardez les logs d’audit vers un stockage central immuable ou à contrôles d’accès. Auditabilité et « rétention locale infinie » ne sont pas la même chose.

7) Et pour les conteneurs — est-ce que ça empire ?

Souvent, oui. Les conteneurs loggent tendanciellement sur stdout, et si vous exécutez beaucoup de conteneurs bavards sur un hôte, journald devient l’évier de tout cela. Vos plafonds doivent en tenir compte, et votre plateforme doit appliquer des niveaux de log et de l’échantillonnage.

8) Comment savoir si mes plafonds sont trop petits ?

Deux signes : (1) vous ne pouvez pas reconstituer des chronologies parce que des messages pertinents sont évincés vite, et (2) journald effectue constamment des vacuum/rotations sous charge (churn). Augmentez modestement les plafonds et réduisez le logging bruyant à la source.

9) Déplacer /var/log/journal vers un système de fichiers séparé aide-t-il vraiment ?

Oui. Cela isole les domaines de défaillance. Si les logs remplissent le volume de logs, ils n’empêcheront généralement pas l’OS d’écrire l’état critique sur root. Vous avez toujours besoin de plafonds, mais votre rayon d’explosion diminue.

10) Quel est le nettoyage d’urgence le plus sûr si je n’ai pas de temps ?

journalctl --vacuum-size=..., puis redémarrez journald si nécessaire, puis corrigez l’unité bavarde. Ne commencez pas à supprimer des fichiers au hasard sous /var en étant fatigué.

Conclusion : prochaines étapes réalisables aujourd’hui

Quand journald mange votre disque, ce n’est généralement pas parce que journald est « hors de contrôle ». C’est parce que vous ne lui avez pas donné de limites, et parce qu’un service a décidé que la meilleure façon d’exprimer sa détresse était d’écrire un roman à la milliseconde.

Faites ceci ensuite :

1. Définissez des plafonds explicites avec SystemMaxUse et SystemKeepFree via un drop-in, pas sur la mémoire tribale.
2. Combinez rétention temporelle et de taille pour que les tempêtes n’effacent pas votre fenêtre d’investigation.
3. Trouvez et corrigez les principaux émetteurs — les logs debug en production sont une taxe payée en espace disque et en sommeil.
4. Forwardez ce qui compte hors hôte pour que le nœud puisse mourir sans emporter les preuves.
5. Surveillez les messages de suppression ; ce sont vos premiers signes que l’observabilité est en train d’échouer.

Si vous retenez une chose : plafonner les logs n’est pas supprimer l’historique. C’est choisir volontairement quelle histoire vous pouvez vous permettre de garder.