Lire les journaux Linux sans perdre le contexte

01. Délimiter l’incident

Notez l’heure du symptôme, le fuseau horaire et le nom de la machine. Comparez l’horloge de l’application avec celle du système. Une erreur à 14 h peut être la conséquence d’une saturation dix minutes plus tôt ; élargissez progressivement la fenêtre.

journalctl -u nom.service --since "2026-09-07 13:45:00" \
  --until "2026-09-07 14:15:00" --no-pager
journalctl -k -b --no-pager

La première commande vise un service et un intervalle à adapter. La seconde affiche les messages du noyau pour le démarrage courant. Consultez les permissions nécessaires sur votre distribution avant de conclure qu’un journal vide signifie absence d’événement.

02. Conserver les lignes voisines

Cherchez un identifiant de requête, un PID ou un message caractéristique, puis gardez les lignes qui précèdent et suivent. Un filtrage uniquement sur « error » peut masquer le début du problème. Le redémarrage du service peut aussi changer son PID : suivez alors l’unité et la période.

Vérifiez l’espace disque, les limites de ressources et les changements de configuration concomitants. Séparez les faits observés des hypothèses dans votre compte rendu ; cette distinction évite de transformer un message secondaire en diagnostic définitif.

03. Vérifier la conservation

journalctl --list-boots
journalctl --disk-usage

La présence du journal du démarrage précédent dépend de la configuration de stockage et de rétention. Assurez-vous que la durée disponible couvre le délai habituel de détection des incidents. Les applications peuvent également écrire leurs propres fichiers, avec une rotation distincte.

Avant de transmettre un extrait, masquez les jetons, mots de passe et données personnelles. Gardez une copie originale dans un emplacement à accès limité lorsque l’enquête le nécessite. Un journal technique n’est pas destiné à être publié intégralement dans un ticket public.

04. Passer du diagnostic à la surveillance

Après résolution, retenez un signal actionnable : répétition d’un échec, délai d’une tâche ou absence de résultat attendu. Associez l’alerte à une procédure. Un volume d’alertes sans priorité finit par masquer les incidents qui comptent.

Pour les tâches planifiées, vérifiez aussi le service et son timer. Pour les sauvegardes, le journal doit être complété par un test régulier de restauration.

05. Rotation des fichiers avec logrotate

Logrotate est un outil de rotation de fichiers, pas une partie obligatoire de syslog. Le répertoire couramment inclus est /etc/logrotate.d ; l’ancien texte contenait une faute dans ce chemin. Vérifiez les inclusions réellement configurées et l’ordonnancement de la tâche.

Un service qui garde un fichier ouvert doit être informé de la rotation selon sa procédure. L’option copytruncate possède une fenêtre pendant laquelle des données peuvent être perdues ; ne la choisissez pas sans comprendre cette limite. Commencez par une analyse en mode debug, puis testez sur une configuration d’essai.

logrotate --debug /etc/logrotate.conf

06. Retrouver les journaux Solaris de l’ancien wiki

L’ancien mémo mentionnait également /var/adm/messages et /var/svc/log sur Solaris. journalctl n’est pas leur lecteur universel. Avec SMF, partez du service et du journal indiqué par son diagnostic, puis conservez l’heure et le contexte.

Consultez le guide de diagnostic Solaris pour rapprocher ces messages des défauts matériels et mesures de ressources.