Ubuntu 24.04 : rsyslog vs journald — choisir la journalisation sans perdre d’événements importants

La décision : que vous devriez exécuter et pourquoi

Si vous exécutez Ubuntu 24.04 en production et que vous tenez à ne pas perdre d’événements importants, faites ceci :

1. Conservez journald. Ce n’est pas optionnel sur les systèmes systemd, et c’est votre vue de premier intervenant la plus fiable.
2. Rendez le journal persistant sur tout hôte que vous devrez un jour déboguer après un reboot.
3. Utilisez rsyslog pour un acheminement durable et contrôlable vers une plateforme centrale de logs (SIEM, ELK/OpenSearch, Splunk, ou tout ce que votre organisation appelle « la source de vérité »).
4. N’utilisez pas la stratégie « tout envoyer deux fois ». Les doublons ne sont pas de la redondance ; ce sont du bruit qui vous fait manquer la ligne dont vous aviez besoin.

En d’autres termes : journald pour la capture locale, l’indexation et les métadonnées structurées ; rsyslog pour la compatibilité avec l’écosystème syslog, le queueing et les règles de forwarding délibérées. Vous pouvez transférer depuis journald vers rsyslog, ou laisser les services logger directement vers syslog. La bonne réponse dépend de ce que vous devez prouver pendant un incident ou un audit.

Vérité sèche : vous ne choisissez pas la journalisation au feeling. Vous la choisissez selon le mode de défaillance. Demandez-vous : « Que se passe-t-il quand le disque est plein ? Quand le réseau saute ? Quand la machine redémarre ? Quand l’heure saute ? Quand le processus inonde le logger ? » et choisissez la pile qui échoue d’une façon que vous pouvez accepter.

Un modèle mental qui ne trahit pas sous pression

Ce qu’est vraiment journald

systemd-journald est un collecteur et un magasin d’événements de logs avec des métadonnées attachées : cgroup, nom d’unité, PID, UID, capacités, contexte SELinux/AppArmor (quand disponible), boot ID et horodatages monotoniques. Il stocke les entrées dans des fichiers de journal binaires. « Binaire » n’est pas une tare morale ; c’est un choix de performance et d’intégrité. Cela permet l’indexation et des requêtes relativement rapides comme « montre-moi tout depuis sshd.service lors du dernier boot ».

Par défaut sur beaucoup de systèmes, journald utilise un stockage volatile (en mémoire sous /run/log/journal) sauf si un stockage persistant est configuré. Ce comportement par défaut est adapté aux petits disques et aux machines éphémères, et impitoyable quand vous devez déboguer quelque chose qui s’est produit avant un redémarrage.

Ce qu’est vraiment rsyslog

rsyslog est un démon syslog qui ingère des messages (depuis des sockets locaux, depuis le réseau, depuis journald via un module d’entrée) puis les route selon des règles. Il excelle dans les files d’attente, les limites de débit, le buffering assisté par disque et l’envoi fiable des logs quand le réseau se comporte comme un réseau (c’est-à-dire : mal, parfois).

Les sorties rsyslog sont généralement des fichiers texte dans /var/log ou des destinations syslog distantes. Les logs textes restent la lingua franca d’un nombre déprimant d’outils. Ce n’est pas du nostalgie ; c’est la compatibilité avec des systèmes qui parsèrent syslog comme en 2009.

Le pipeline sur Ubuntu 24.04 (typique)

• Les messages du kernel vont dans le ring buffer du kernel, puis journald les collecte ; rsyslog peut aussi lire les messages kernel selon la configuration.
• Les services systemd loggent sur stdout/stderr ; journald capture cela automatiquement.
• Beaucoup d’apps traditionnelles loggent encore via /dev/log (socket syslog). Cela peut être fourni par rsyslog ou par la compatibilité socket syslog de systemd-journald.
• rsyslog peut ingérer depuis journald (via imjournal) ou depuis le socket syslog, puis écrire des fichiers et/ou transférer.

Si vous vous êtes déjà demandé pourquoi votre /var/log/syslog manque une ligne que vous avez vue dans journalctl, la réponse est généralement « ce sont deux chemins de capture différents ». La journalisation est une chaîne d’approvisionnement. Vous ne remarquez pas la chaîne tant qu’un porte-conteneurs n’est pas bloqué.

Une citation à coller sur votre écran (idée paraphrasée) : le thème de Gene Kim sur les opérations est que l’amélioration vient du raccourcissement des boucles de rétroaction. La journalisation est l’une de vos plus courtes boucles ; traitez-la comme du code de production.

Blague n°1 : La journalisation, c’est comme les dents — on l’ignore jusqu’à ce que ça fasse mal, puis soudain on est prêt à payer n’importe quel prix pour faire cesser la douleur.

Faits intéressants et contexte historique

1. syslog est antérieur à Linux. Le syslog original vient du BSD Unix des années 1980, conçu pour un transport simple de logs en réseau quand le « modèle de sécurité » était surtout « ne laissez pas Dave de la compta toucher le serveur ».
2. rsyslog est plus récent qu’on ne le pense. rsyslog a été créé au début des années 2000 comme remplacement drop-in de sysklogd avec de meilleures performances et des fonctionnalités comme TCP, RELP et le queueing.
3. journald stocke les logs en format binaire par conception. Il est optimisé pour des requêtes indexées et des événements riches en métadonnées ; l’argument « les logs binaires sont mauvais » concerne surtout les attentes des outils, pas la fiabilité sous-jacente.
4. systemd a fait de stdout/stderr une première classe pour la journalisation. Cela a changé la culture de logging des applications : les services n’avaient plus besoin de gérer des fichiers de logs s’ils ne le voulaient pas. La plateforme les capture.
5. La rotation traditionnelle des logs a été inventée pour contrôler l’usage disque des logs texte. Avec journald, la rétention est souvent gérée par des plafonds de taille/temps plutôt que par la rotation basée sur les noms de fichiers, ce qui change la façon de répondre à « avons-nous gardé la semaine dernière ? ».
6. RELP existe car TCP n’était pas suffisant. TCP peut toujours perdre des données quand un expéditeur plante ou qu’une connexion se réinitialise au mauvais moment ; RELP (Reliable Event Logging Protocol) ajoute des accusés de réception au niveau applicatif.
7. Journald tague les logs avec un boot ID. Cela semble anecdotique jusqu’à ce que vous déboguiez un crash intermittent et deviez séparer « ce boot » de « le boot précédent ». C’est un vrai cadeau.
8. Le ring buffer du kernel Linux est fini. Si vous ne le videz pas sous un flux, les anciens messages kernel sont écrasés. Ce n’est pas la faute de journald, mais journald est votre chemin de vidage normal.

Compromis qui comptent vraiment en 2025

Durabilité : ce qui survit au reboot et ce qui ne survit pas

journald peut être volatile ou persistant. Un journald volatile convient aux flottes « cattle » où tout est centralisé immédiatement, et est catastrophique pour les moments « pourquoi a-t-il rebooté ? » quand votre forwarder n’a pas envoyé les dernières 30 secondes.

rsyslog écrivant sur disque est persistant par défaut (à condition qu’il écrive dans /var/log et que ce système de fichiers survive). Mais la persistance sur le même disque que votre workload n’est pas une victoire si le disque se remplit et que votre appli meurt. La durabilité est une propriété du système, pas d’un démon.

Rétro-pression et gestion des rafales

Sous des tempêtes de logs, le système de journalisation devient une partie de votre profil de performance. journald a des limitations de débit et peut supprimer des messages. rsyslog peut mettre en file en mémoire ou déverser sur disque. Si vous tenez à « ne jamais perdre les logs d’authentification » ou « capturer les 60 dernières secondes avant un crash », vous avez besoin de réglages explicites et, généralement, de queues assistées par disque.

Métadonnées et ergonomie des requêtes

journald gagne localement pour le tranchage rapide : par unité, par PID, par cgroup, par boot, par priorité, par temps. Si vous faites de l’intervention sur une seule machine, journalctl est souvent plus rapide que grep dans des fichiers — surtout quand les services spamment des données structurées ou que les PID changent.

rsyslog gagne quand vous devez vous intégrer à tout ce qui attend du syslog, du matériel réseau aux pipelines de conformité anciens. C’est « l’adaptateur universel ».

Sécurité et résistance à la falsification

Aucun des deux démons ne rend magiquement les logs à l’épreuve de la falsification. Un root local peut toujours faire des dégâts. Votre véritable contrôle est : expédier les logs hors hôte rapidement, les conserver immuables dans l’agrégateur, et contrôler l’accès. journald prend en charge des fonctions de scellement, mais ne confondez pas « plus difficile à éditer par hasard » avec « niveau judiciaire ».

Complexité et coût opérationnel

Ne faire tourner que journald est simple jusqu’au moment où vous avez besoin d’un forwarding fiable avec buffering, filtrage et choix de protocoles. Faire tourner journald + rsyslog ajoute un peu de pièces mobiles, mais vous donne un contrôle explicite du pipeline. En production, explicite bat implicite.

Blague n°2 : « Nous n’avons pas besoin de journalisation centralisée » est une stratégie audacieuse ; c’est comme refuser les ceintures de sécurité parce que vous comptez conduire prudemment.

Tâches pratiques (commandes, signification des sorties, décisions)

Voici les vérifications que je lance sur Ubuntu 24.04 quand quelqu’un dit « les logs manquent », « le disque se remplit », ou « le forwarding est instable ». Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision à prendre.

Tâche 1 : Confirmer ce qui tourne (journald, rsyslog)

cr0x@server:~$ systemctl status systemd-journald rsyslog --no-pager
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Mon 2025-12-30 09:10:11 UTC; 2h 1min ago
...
● rsyslog.service - System Logging Service
     Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:10:13 UTC; 2h 1min ago
...

Signification : Les deux services sont actifs ; vous avez probablement une journalisation à double chemin. Si rsyslog est inactif, vous comptez probablement uniquement sur journald.

Décision : Si vous avez besoin d’un forwarding distant avec buffering, activez rsyslog (ou un forwarder dédié) et définissez le chemin intentionnellement.

Tâche 2 : Voir le mode de stockage de journald (volatile vs persistent)

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

Signification : Il y a des fichiers de journal sur le disque quelque part. Si cette commande renvoie une erreur ou montre une très faible utilisation alors que vous attendiez un historique, vous êtes peut-être en mode volatile uniquement.

Décision : Si vous tenez aux logs après reboots, assurez-vous que le stockage persistant est activé et que vous avez des réglages de rétention.

Tâche 3 : Vérifier si journald utilise un stockage persistant

cr0x@server:~$ ls -ld /var/log/journal /run/log/journal
drwxr-sr-x 3 root systemd-journal 4096 Dec 30 09:10 /var/log/journal
drwxr-sr-x 2 root systemd-journal  120 Dec 30 09:10 /run/log/journal

Signification : /var/log/journal existe, donc la persistance est activée (ou au moins disponible). Si il n’existe pas, journald est peut-être volatile.

Décision : Si /var/log/journal manque, créez-le et fixez Storage=persistent (détails dans la section plan).

Tâche 4 : Inspecter la rétention de journald et les limites de débit

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

Signification : Ce sont les réglages effectifs après drop-ins. Un petit SystemMaxUse signifie une éviction plus rapide. Des limites de débit agressives peuvent supprimer des rafales.

Décision : Ajustez selon votre budget disque et vos besoins d’incident. Si vous voyez des pertes lors de pics, adaptez les limites de débit et expédiez hors hôte.

Tâche 5 : Détecter les messages supprimés dans journald

cr0x@server:~$ journalctl -u systemd-journald --since "1 hour ago" | tail -n 8
Dec 30 10:44:02 server systemd-journald[412]: Suppressed 12845 messages from /system.slice/myapp.service
Dec 30 10:44:02 server systemd-journald[412]: Forwarding to syslog missed 0 messages

Signification : « Suppressed » indique des suppressions dues à la limitation de débit. Ce n’est pas théorique. Ça se produit.

Décision : Si l’unité supprimée est importante (auth, kernel, votre service critique), augmentez les limites et réduisez le spam à la source. Envisagez des queues rsyslog pour la fiabilité du forwarding.

Tâche 6 : Vérifier si rsyslog ingère depuis journald

cr0x@server:~$ grep -R "imjournal" /etc/rsyslog.d /etc/rsyslog.conf
/etc/rsyslog.conf:module(load="imjournal" StateFile="imjournal.state")

Signification : rsyslog lit le journal systemd via imjournal. Si absent, rsyslog peut lire depuis /dev/log à la place.

Décision : Choisissez une stratégie d’ingestion pour éviter les doublons : soit imjournal (le journal comme vérité), soit le socket (syslog comme source). Ne faites pas les deux par accident.

Tâche 7 : Repérer les événements dupliqués (symptôme classique de double-ingestion)

cr0x@server:~$ sudo awk 'NR<=20{print}' /var/log/syslog
Dec 30 11:01:10 server myapp[2211]: started worker=7
Dec 30 11:01:10 server myapp[2211]: started worker=7

Signification : Le même message deux fois au même horodatage suggère fortement une double ingestion (par ex., l’appli logge vers syslog et journald forwarde ensuite dans rsyslog).

Décision : Désactivez un chemin : soit arrêtez le forwarding de journald vers rsyslog, soit empêchez rsyslog de lire /dev/log, selon l’architecture.

Tâche 8 : Vérifier les queues rsyslog et si le forwarding est bloqué

cr0x@server:~$ systemctl status rsyslog --no-pager | sed -n '1,14p'
● rsyslog.service - System Logging Service
     Active: active (running) since Mon 2025-12-30 09:10:13 UTC; 2h 9min ago
   Main PID: 621 (rsyslogd)
      Tasks: 4
     Memory: 8.5M
        CPU: 1.901s
     CGroup: /system.slice/rsyslog.service
             └─621 /usr/sbin/rsyslogd -n -iNONE

Signification : Le statut seul ne vous dira pas la profondeur de la file, mais confirme la santé du démon et signale des crash loops évidentes.

Décision : Si le forwarding à distance est retardé, vérifiez la reachabilité réseau et les queues d’action rsyslog (voir les tâches de validation de config ci-dessous).

Tâche 9 : Valider la config rsyslog (syntaxe, modules, includes)

cr0x@server:~$ rsyslogd -N1
rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

Signification : La validation est passée. Si des erreurs apparaissent, rsyslog peut tourner avec une config partielle ou échouer à démarrer après des changements.

Décision : Ne rebootez jamais rsyslog à l’aveugle en production. Validez d’abord, puis rechargez, puis confirmez le flux de messages.

Tâche 10 : Déterminer si le forwarding est UDP (perdu) ou TCP/RELP (meilleur)

cr0x@server:~$ grep -R "@" /etc/rsyslog.d /etc/rsyslog.conf
/etc/rsyslog.d/60-forward.conf:*.* @@logrelay.internal:514

Signification : @ est UDP, @@ est TCP. Le TCP peut encore perdre lors de crashs ; RELP est plus robuste.

Décision : Si « ne pas perdre les logs d’auth » est une exigence, n’utilisez pas UDP. Utilisez TCP avec queues disque ou RELP si votre relais le supporte.

Tâche 11 : Vérifier si journald forwarde vers syslog (et si c’est nécessaire)

cr0x@server:~$ grep -R "^ForwardToSyslog" /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null
/etc/systemd/journald.conf:ForwardToSyslog=yes

Signification : journald forwarde les entrées vers le socket syslog. Si rsyslog lit aussi le journal, cela peut dupliquer.

Décision : Choisissez un seul point de passage : soit ForwardToSyslog (journald → socket syslog), soit rsyslog imjournal (journald → rsyslog directement).

Tâche 12 : Identifier « pourquoi a-t-il rebooté ? » via les vues de journal séparées par boot

cr0x@server:~$ journalctl --list-boots | tail -n 3
-2 2f1c1b2dd0e84fbb9a1f66b2ff0f8d1e Sun 2025-12-29 22:10:17 UTC—Sun 2025-12-29 23:52:01 UTC
-1 7d8c0e3fa0f44a3b8c0de74b8b9f41a2 Mon 2025-12-30 00:10:06 UTC—Mon 2025-12-30 09:09:55 UTC
 0 94f2b5d9f61e4f57b5f3c3c7a9c2a1d1 Mon 2025-12-30 09:10:06 UTC—Mon 2025-12-30 11:19:44 UTC

Signification : Plusieurs boots sont visibles, donc la persistance fonctionne. Si vous ne voyez que « 0 », vous êtes probablement en mode volatile ou l’historique a été vacuumé.

Décision : Si les reboots sont mystérieux, activez la persistance de journald et augmentez la rétention pour que le « boot précédent » existe quand vous en avez besoin.

Tâche 13 : Raconter rapidement la séquence d’arrêt/crash

cr0x@server:~$ journalctl -b -1 -p warning..emerg --no-pager | tail -n 20
Dec 30 09:09:51 server kernel: Out of memory: Killed process 2211 (myapp) total-vm:...
Dec 30 09:09:52 server systemd[1]: myapp.service: Main process exited, code=killed, status=9/KILL
Dec 30 09:09:55 server systemd[1]: Reached target Reboot.

Signification : Le dernier boot montre un OOM kill et la mort d’un service menant au reboot. C’est le genre de vue « une seule écran » pour lequel journald excelle.

Décision : Si les événements kernel/OOM sont critiques, assurez-vous qu’ils sont forwardés hors hôte et qu’ils ne sont pas supprimés par des limites de débit sous pression mémoire.

Tâche 14 : Confirmer la pression disque sur le système de fichiers de journalisation

cr0x@server:~$ df -h /var /run
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   34G  4.2G  90% /
tmpfs           3.1G  180M  2.9G   6% /run

Signification : /var est serré. Si les logs partagent le filesystem root, une rafale de logs peut devenir une panne.

Décision : Limitez l’usage de journald (SystemMaxUse), faites correctement tourner les logs texte, et expédiez hors hôte. Si nécessaire, isolez /var sur son propre filesystem en environnements critiques.

Tâche 15 : Quantifier quels consommateurs du journal sont bruyants

cr0x@server:~$ journalctl --since "1 hour ago" -o json-pretty | head -n 20
{
        "_SYSTEMD_UNIT" : "myapp.service",
        "PRIORITY" : "6",
        "MESSAGE" : "processed batch id=9f1c...",
        "_PID" : "2211",
        "__REALTIME_TIMESTAMP" : "1735557650000000"
}

Signification : La sortie JSON montre des champs sur lesquels filtrer. Si votre appli spamme « processed batch … » au niveau info, c’est votre disque et le futur vous qui aurez un problème.

Décision : Réduisez le volume à la source. Les systèmes de logs ne sont pas un substitut aux métriques.

Tâche 16 : Vérifier qui a accès au journal (permissions de débogage)

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),4(adm)

Signification : Les utilisateurs du groupe adm peuvent souvent lire de nombreux logs ; l’accès à journald est couramment accordé via le groupe systemd-journal ou via sudo.

Décision : Donnez aux ingénieurs d’astreinte le minimum de groupes nécessaires pour lire les logs sans accorder le root complet. Puis auditez cette décision trimestriellement, car les organigrammes dérivent.

Plan d’action pour un diagnostic rapide

Vous êtes d’astreinte. L’alerte indique « service down ». Quelqu’un dit « les logs manquent ». Ne partez pas en exploration. Faites ceci dans l’ordre.

Première étape : savoir si les événements existent localement

1. Vérifiez le journal pour le service et la période. Filtrez par unité et priorité. Si le journal contient l’événement, vous avez un point de vérité de départ.
2. Vérifiez le boot précédent. Si l’hôte a rebooté, vos « logs manquants » peuvent simplement être « vous regardez le mauvais boot ».

cr0x@server:~$ journalctl -u myapp.service --since "30 min ago" -p info..emerg --no-pager | tail -n 30
Dec 30 11:03:01 server myapp[2211]: healthcheck failed: upstream timeout
Dec 30 11:03:02 server systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

Interprétation : Si le journal contient l’événement, le service logge et journald collecte. Votre problème est probablement le forwarding, les filtres de duplication, ou des attentes basées sur les fichiers syslog.

Deuxième étape : déterminer si des données sont supprimées

1. Cherchez les messages de suppression dans journald.
2. Vérifiez la pression disque. Les disques pleins provoquent des comportements étranges et des écritures manquantes.
3. Vérifiez la santé de rsyslog et la validation de la configuration.

Troisième étape : isoler le goulot : capture, stockage ou expédition

• Goulot de capture : application qui ne logge pas, stdout non connecté, décalage du socket syslog, permissions.
• Goulot de stockage : journald volatile, rétention trop faible, disque plein, vacuuming, rotation trop agressive.
• Goulot d’expédition : forwarding rsyslog sur UDP, pas de queues, pertes réseau, problèmes DNS pour l’hôte de logs, mauvaise configuration TLS.

Quatrième étape : prouvez-le avec un message de test contrôlé

cr0x@server:~$ logger -p authpriv.notice "LOGTEST authpriv notice from $(hostname) at $(date -Is)"
cr0x@server:~$ journalctl --since "1 min ago" | grep LOGTEST | tail -n 1
Dec 30 11:18:22 server cr0x: LOGTEST authpriv notice from server at 2025-12-30T11:18:22+00:00

Interprétation : Si c’est dans le journal mais pas dans /var/log/syslog (ou pas dans votre agrégateur), vous avez restreint la défaillance au chemin de handoff/expédition.

Erreurs courantes : symptômes → cause racine → correctif

1) « Les logs disparaissent après un reboot »

Symptômes : journalctl --list-boots n’affiche que le boot 0 ; l’investigation après un crash n’a aucun historique.

Cause racine : journald utilise un stockage volatile (/run) parce que le stockage persistant n’a pas été activé ou que /var/log/journal n’existe pas.

Correctif : Créez /var/log/journal, définissez Storage=persistent, redémarrez journald et confirmez que plusieurs boots apparaissent. Fixez aussi des plafonds de rétention pour que la persistance ne devienne pas une exhaustion de disque.

2) « Nous avons des doublons partout »

Symptômes : La même ligne apparaît deux fois dans /var/log/syslog ou dans l’agrégateur, souvent avec des horodatages identiques.

Cause racine : Double ingestion : l’appli logge vers le socket syslog tandis que journald forwarde vers syslog et rsyslog lit aussi le journal (ou l’inverse).

Correctif : Choisissez une option : rsyslog lit via imjournal ou journald forwarde vers le socket syslog. Ne combinez pas sans logique de déduplication délibérée.

3) « Les logs d’authentification manquent dans le système central, mais le syslog local les a »

Symptômes : /var/log/auth.log est rempli localement ; le SIEM manque des entrées lors de coupures réseau.

Cause racine : Forwarding UDP, ou TCP sans queues disque, ou relais en panne sans buffering.

Correctif : Utilisez TCP avec queues disque ou RELP vers un relais conçu pour l’ingestion. Vérifiez les paramètres de queue et testez en bloquant temporairement le réseau.

4) « Pendant un incident, journalctl est lent ou timeout »

Symptômes : Les requêtes journalctl prennent beaucoup de temps, le CPU grimpe, I/O wait.

Cause racine : Gros journaux sur disques lents, volume de logs agressif, ou contention sur le filesystem sous-jacent. Parfois, c’est juste que l’on essaie de rendre trop de sortie.

Correctif : Filtrez agressivement (unité, priorité, période), limitez l’usage disque, vacuumez les anciennes entrées, et gardez les logs hors de vos stockages les plus lents quand c’est possible.

5) « /var est plein, et maintenant tout est en feu »

Symptômes : Les services échouent au démarrage, les mises à jour échouent, les logs ne se mettent plus à jour, des daemons plantent.

Cause racine : Logs fichiers non bornés, journald mal configuré côté rétention, ou appli runaway écrivant à haute cadence.

Correctif : Définissez des caps journald (SystemMaxUse, SystemKeepFree), assurez le fonctionnement de logrotate pour les logs texte, et corrigez l’appli bruyante. Si l’environnement est critique, isolez /var sur son propre filesystem.

6) « Je vois les logs avec sudo, mais pas en tant qu’utilisateur d’astreinte »

Symptômes : journalctl affiche « No journal files were found » ou permission denied sans sudo.

Cause racine : L’utilisateur d’astreinte n’appartient pas au bon groupe (systemd-journal ou adm selon la politique), ou des permissions renforcées ont été appliquées.

Correctif : Accordez un accès contrôlé en ajoutant l’utilisateur au groupe approprié, pas en partageant des identifiants root, et documentez-le.

Trois micro-histoires d’entreprise issues du terrain de la journalisation

Micro-histoire 1 : Un incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a migré une flotte d’Ubuntu 20.04 vers 24.04. Ils avaient un runbook bien rodé : vérifier /var/log/syslog, vérifier /var/log/auth.log, expédier vers un syslog central. La migration « a marché », les services sont revenus, et l’équipe est passée à autre chose.

Deux semaines plus tard, un lot de nœuds a rebooté suite à un kernel panic déclenché par un firmware NIC défaillant. L’astreinte a tiré /var/log/syslog et a vu… pas grand-chose. On aurait dit que la machine avait simplement redémarré proprement. Le responsable d’incident a demandé les « 60 dernières secondes ». L’astreinte avait 3 secondes et un sentiment croissant d’effroi.

L’hypothèse erronée était subtile : ils supposaient que rsyslog restait le collecteur principal pour tout ce qui était important. Mais plusieurs services étaient natifs systemd et loggaient sur stdout ; journald les capturait, et seule une partie étaient forwardée vers rsyslog. Les événements manquants n’étaient pas « perdus ». Ils étaient dans un journal volatile qui disparaissait au reboot selon certains profils de nœuds.

Le correctif était ennuyeux mais efficace : rendre journald persistant sur tous les nœuds non éphémères, définir des caps de taille raisonnables, et router journald vers rsyslog via un chemin unique et explicite. Le reboot suivant a été toujours pénible, mais au moins les logs racontaient l’histoire au lieu de gazouiller tout le monde.

Micro-histoire 2 : Une optimisation qui s’est retournée contre eux

Une grande équipe plateforme interne a décidé qu’ils payaient trop en stockage pour les logs. Ils ont constaté que le journal grossissait vite sur les nœuds bavards. Ils ont donc réduit agressivement la rétention de journald et resserré les limites de débit. Leur but était raisonnable : garder les disques sains et réduire le bruit.

Pendant un mois, tout semblait gagné. L’usage disque a baissé. Les dashboards étaient plus propres. Puis une dépendance a commencé à mal se comporter : des échecs intermittents de poignée de main TLS entre services. Les échecs duraient des secondes, quelques fois par heure. Les métriques montraient des pics d’erreur, mais les logs qui auraient expliqué le pourquoi étaient souvent absents. Les pics étaient exactement ceux qui se faisaient supprimer par les limites de débit et la faible rétention quand plusieurs composants deviennent bruyants simultanément.

Ils ont fini par trouver un motif en corrélant quelques logs survivants avec des captures de paquets : un mismatch de MTU après un changement réseau. La vraie leçon n’était pas le MTU. C’était qu’ils « ont optimisé » la journalisation en supprimant les données nécessaires pour déboguer des événements rares qu’on ne peut pas reproduire à la demande.

L’approche corrigée a été de réduire le volume à la source (niveaux de logs, échantillonnage, conception d’événements structurés), garder une rétention journald suffisante pour un triage local, et se reposer sur un store central pour la forensique longue durée. Couper la rétention doit être un scalpel ; ils l’avaient utilisé comme une tondeuse.

Micro-histoire 3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe liée aux paiements gérait des nœuds Ubuntu qui faisaient de l’authentification. Rien de glamorous : services systemd, forwarding rsyslog, et un relais central de logs. L’équipe avait une habitude qui semblait excessive : chaque trimestre, ils réalisaient un test contrôlé de « défaillance d’envoi de logs » pendant les heures ouvrables sur un hôte canari.

Le test était simple. Ils bloquaient l’egress vers le relais de logs pendant quelques minutes sur une machine canari, généraient une poignée de messages logger de test sur différentes facilities et priorités, puis réactivaient l’egress. L’attente : les messages se mettent en file localement et apparaissent ensuite dans l’agrégateur dans l’ordre, sans perte.

Un trimestre, le test a échoué. Les messages n’apparaissaient jamais en amont. Les logs locaux existaient, mais le forwarding n’a jamais rattrapé le retard. Comme c’était un test et non une panne, ils ont eu le temps d’enquêter sans adrénaline. Il s’est avéré qu’un changement de configuration avait basculé le forwarding en UDP « temporairement » et que personne ne l’avait remis. « Temporaire » est le mot le plus permanent en IT d’entreprise.

Ils ont rétabli TCP avec queues disque et écrit un petit check CI qui signalait la présence d’UDP dans les configs de production. Un mois plus tard, un incident réseau réel a touché leur segment datacenter. La file a absorbé l’interruption, le SIEM a rattrapé son retard ensuite, et le rapport d’incident contenait une phrase inhabituelle : « Aucune perte de données constatée ». L’ennuyeux a gagné. Encore.

Listes de contrôle / plan étape par étape

Plan A (recommandé) : journald persistant + forwarding rsyslog avec un seul point d’ingestion

1. Rendre journald persistant.

   cr0x@server:~$ sudo mkdir -p /var/log/journal
   cr0x@server:~$ sudo systemd-tmpfiles --create --prefix /var/log/journal
   cr0x@server:~$ sudo sed -i 's/^#Storage=.*/Storage=persistent/' /etc/systemd/journald.conf
   cr0x@server:~$ sudo systemctl restart systemd-journald

   Vérification : journalctl --list-boots doit montrer plus que le boot 0 après le prochain reboot, et /var/log/journal doit se remplir.

2. Définir des caps de rétention qui n’écraseront pas les disques.

   cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/99-retention.conf >/dev/null <<'EOF'
   [Journal]
   SystemMaxUse=2G
   SystemKeepFree=1G
   MaxRetentionSec=14day
   EOF
   cr0x@server:~$ sudo systemctl restart systemd-journald

   Décision : Choisissez des caps selon la taille du disque et les besoins d’incident. Sur de petits systèmes root, soyez conservateur et expédiez hors hôte.

3. Choisir le handoff vers rsyslog : utilisez imjournal OU ForwardToSyslog, pas les deux.

   Option 1 (commune) : rsyslog lit le journal avec imjournal.

   cr0x@server:~$ sudo grep -R "module(load=\"imjournal" /etc/rsyslog.conf
   module(load="imjournal" StateFile="imjournal.state")

   Puis désactivez le forwarding de journald vers syslog pour éviter la duplication si vous n’utilisez pas ce chemin :

   cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/10-forwarding.conf >/dev/null <<'EOF'
   [Journal]
   ForwardToSyslog=no
   EOF
   cr0x@server:~$ sudo systemctl restart systemd-journald

4. Utilisez un forwarding fiable (TCP + queues ; RELP si disponible).

   cr0x@server:~$ sudo tee /etc/rsyslog.d/60-forward.conf >/dev/null <<'EOF'
   # Forward everything to a relay over TCP with a disk-assisted queue.
   # Adjust rules so you don't forward noisy debug logs if you don't need them.
   
   action(
     type="omfwd"
     target="logrelay.internal"
     port="514"
     protocol="tcp"
     action.resumeRetryCount="-1"
     queue.type="LinkedList"
     queue.filename="fwdAll"
     queue.maxdiskspace="2g"
     queue.saveonshutdown="on"
     queue.dequeuebatchsize="500"
   )
   EOF
   cr0x@server:~$ sudo rsyslogd -N1
   cr0x@server:~$ sudo systemctl restart rsyslog

   Décision : Si vous avez des exigences de conformité, associez cela à un relais interne et envisagez RELP/TLS. Le TCP seul est une bonne base, pas une garantie.

5. Prouvez le flux bout-en-bout avec des messages contrôlés.

   cr0x@server:~$ logger -p user.notice "LOGPIPE e2e test id=$(uuidgen)"
   cr0x@server:~$ journalctl --since "2 min ago" -o short-iso | grep LOGPIPE | tail -n 1
   2025-12-30T11:20:41+00:00 server cr0x: LOGPIPE e2e test id=3e0c2aef-7e0f-4a43-a3c2-9c3e5c4f2f8b

   Décision : Si c’est visible localement mais pas centralement, corrigez l’expédition. Si ce n’est pas visible localement, corrigez la capture.

Plan B : journald seul (acceptable pour des flottes éphémères avec centralisation forte)

• Utilisez journald persistant uniquement si les disques et les politiques de rétention le permettent ; sinon, comptez sur un envoi immédiat via un collecteur compatible journald.
• Réglez strictement les limites de débit : vous protégerez peut-être le nœud au prix de la perte de l’événement unique dont vous aviez besoin.
• Assurez-vous d’avoir quand même une copie hors hôte. « Local uniquement » est un prélude à « nous ne pouvons pas prouver ce qui s’est passé ».

Plan C : rsyslog comme primaire (seulement si contraintes legacy)

• C’est possible, mais vous aurez toujours journald qui capture stdout/stderr pour les services systemd.
• Si vous insistez pour des workflows basés fichiers, assurez-vous que les services loggent vers syslog ou des fichiers de manière intentionnelle. Sinon vous courrez après des événements manquants dans deux mondes.
• Soyez explicite au sujet des sources de logs kernel pour éviter les trous.

FAQ

1) Sur Ubuntu 24.04, ai-je besoin de rsyslog du tout ?

Si vous avez besoin de layouts syslog classiques, de règles de routage fines, de queues assistées par disque, ou d’une large compatibilité avec l’écosystème syslog, oui. Si vous disposez d’un collecteur natif journald qui expédie hors hôte de façon fiable, vous pouvez vous passer de rsyslog.

2) journald perdra-t-il des logs ?

Ça peut arriver. En mode volatile, les logs ne survivent pas au reboot. Si les limites de débit s’activent, il peut supprimer des messages lors de rafales. Si le disque est plein ou que les caps de rétention sont petits, les anciens logs sont vacuumés. Rien de cela n’est malveillant ; c’est juste la physique.

3) Les logs binaires posent-ils un problème pour la conformité ?

Généralement, l’exigence de conformité est « rétention, intégrité, contrôle d’accès, auditabilité », pas « doit être en texte clair ». Le vrai geste de conformité est d’expédier hors hôte vers un stockage immuable et de contrôler l’accès. Binaire vs texte est une préférence d’outillage, pas une garantie.

4) Pourquoi je vois des logs dans journalctl mais pas dans /var/log/syslog ?

Parce que journald capture stdout/stderr des services systemd par défaut. À moins de forwarder ces entrées vers syslog, elles n’apparaîtront pas dans les fichiers syslog. De plus, des filtres ou des mappages de facility peuvent router les messages différemment.

5) Dois-je forwarder depuis journald vers rsyslog ou laisser rsyslog lire le journal ?

Choisissez un seul, pour la clarté et éviter la duplication. Je préfère que rsyslog lise le journal via imjournal pour avoir un point d’ingestion unique avec des queues explicites et des actions de forwarding.

6) Le forwarding syslog UDP est-il acceptable ?

Pour la télémétrie à faible enjeu et les flux debug bruyants où la perte est acceptable, oui. Pour l’auth, la sécurité ou les logs critiques : non. Utilisez TCP avec buffering, ou RELP si possible.

7) Quelle rétention de journald devrais-je garder ?

Gardez suffisamment pour couvrir votre fenêtre de réponse humaine : au moins « le boot précédent + quelques jours » sur les hôtes importants. Puis comptez sur la rétention centrale pour des semaines/mois. Limitez l’usage local pour qu’il ne puisse pas manger la machine.

8) Puis-je faire en sorte que journald écrive directement des logs texte traditionnels ?

Pas comme format primaire. journald peut forwarder vers syslog, et les démons syslog peuvent écrire des fichiers texte. C’est le pont supporté : journald capture, rsyslog écrit/forwarde.

9) Qu’en est-il des logs de containers ?

Si les containers loggent sur stdout/stderr et que le runtime s’intègre à systemd, journald peut capturer avec des métadonnées riches. Si vous utilisez un autre runtime, assurez-vous que votre collecteur récupère explicitement les logs de containers. Ne présumez pas.

10) Comment empêcher les logs de mettre la machine hors service ?

Limitez l’usage disque de journald, assurez-vous que logrotate fonctionne pour les logs texte, et réduisez le volume à la source. Évitez aussi de mettre une journalisation lourde sur le même filesystem contraint que votre base de données.

Conclusion : prochaines étapes qui ne vous trahiront pas

Ubuntu 24.04 ne force pas une guerre religieuse entre journald et rsyslog. Il vous offre deux outils avec des modes de défaillance différents. En production, le schéma souvent approprié est : journald persistant pour la vérité locale, plus rsyslog pour un forwarding délibéré, bufferisé et compatible.

Prochaines étapes :

1. Rendez journald persistant sur tout hôte que vous pourriez déboguer après un reboot, et limitez-le pour qu’il ne puisse pas remplir les disques.
2. Décidez d’un point d’ingestion unique vers rsyslog pour éviter les doublons.
3. Basculez le forwarding vers TCP (ou RELP) avec queues assistées par disque pour tout ce que vous ne pouvez pas vous permettre de perdre.
4. Exécutez trimestriellement un test de « défaillance d’envoi de logs » sur un canari. Si cela vous semble excessif, attendez votre premier audit ou incident de sécurité.

La journalisation n’est pas seulement de l’observabilité. C’est une preuve. Construisez-la comme si vous en auriez besoin au tribunal — parce qu’un jour, en interne, ce sera le cas.