Suivre un log en temps réel sous Linux

Quand un service plante ou se comporte bizarrement, le premier réflexe est d'ouvrir ses logs. Mais si vous ouvrez un fichier statique, vous voyez une photo. Ce qu'il vous faut, c'est un flux en direct, voir les lignes qui arrivent au moment où elles arrivent, filtrer les erreurs pendant qu'un déploiement se déroule, surveiller plusieurs fichiers simultanément.

Sous Linux, deux outils couvrent ce besoin : tail -f pour les fichiers plats, journalctl -f pour les journaux systemd. Ce guide vous montre comment les utiliser seuls et en combinaison.

Ce que vous allez apprendre

• Suivre un fichier de log en temps réel avec tail -f et --follow=name
• Filtrer les erreurs en temps réel dans un pipeline avec grep --line-buffered
• Observer plusieurs fichiers à la fois avec tail -f
• Interroger journalctl par unité, priorité, plage horaire ou démarrage
• Choisir le bon outil selon la source du log

Dans quel contexte ?

Vous déployez une nouvelle version d'une application et vous voulez voir les logs au moment où le service redémarre. Un cron s'exécute la nuit et vous soupçonnez une erreur que vous n'arrivez pas à reproduire dans la journée. Un service est intermittent et vous voulez être alerté dès que ERROR apparaît, sans lancer une commande toutes les 30 secondes. La surveillance de logs en temps réel est une compétence de premier recours en administration système, elle vous donne les informations au bon moment, pendant l'événement, pas après.

tail, suivre des fichiers plats

Beaucoup de services écrivent encore dans des fichiers texte sous /var/log/, indépendamment de systemd : nginx, apache, postgresql, ou n'importe quelle application maison qui redirige sa sortie. Pour ceux-là, tail est l'outil de lecture, et son mode suivi transforme une lecture ponctuelle en observation continue. Deux points méritent votre attention, la rotation des fichiers et le comportement du tampon quand vous branchez un filtre derrière.

Les bases

tail affiche les dernières lignes d'un fichier. Sans option, il en affiche 10 :

tail /var/log/syslog              # 10 dernières lignes
tail -n 50 /var/log/syslog        # 50 dernières lignes
tail -n +100 /var/log/syslog      # à partir de la ligne 100

Mode suivi : tail -f

-f (follow) ouvre le fichier et affiche les nouvelles lignes au fur et à mesure qu'elles sont écrites. Il ne rend pas la main, il reste actif jusqu'à Ctrl+C :

tail -f /var/log/nginx/access.log

tail -f vs tail --follow=name

C'est une distinction importante en production. Un descripteur de fichier est le numéro que le noyau attribue à un fichier ouvert : il reste attaché au contenu même si le fichier change de nom. tail -f s'accroche à ce descripteur, alors que --follow=name réinterroge le chemin à intervalles réguliers et rouvre le nouveau fichier dès qu'il apparaît. L'option --retry complète la seconde forme en la rendant patiente si le fichier disparaît quelques instants.

Option	Comportement
tail -f	Suit le descripteur de fichier, s'arrête si le fichier est renommé (rotation)
tail --follow=name --retry	Suit le nom du fichier, survit à la rotation logrotate

Glissez pour voir

# Pour les logs avec rotation (nginx, apache, syslog...)
tail --follow=name --retry /var/log/nginx/access.log

tail -f et logrotate

Si logrotate tourne pendant votre session tail -f, le fichier est renommé en access.log.1 et un nouveau access.log est créé. Votre tail -f continue de suivre l'ancien fichier, il ne voit plus les nouvelles entrées. Utilisez --follow=name pour éviter ce piège.

Suivre plusieurs fichiers

tail -f accepte plusieurs arguments. Il les préfixe avec le nom du fichier :

tail -f /var/log/nginx/access.log /var/log/nginx/error.log

==> /var/log/nginx/access.log <==
192.168.1.10 - - [09/Apr/2026:10:05:00] "GET /api/users HTTP/1.1" 200 523

==> /var/log/nginx/error.log <==
2026/04/09 10:05:01 [error] 1234#0: upstream timed out

Filtrer en temps réel

Sur un serveur chargé, un tail -f brut défile trop vite pour être lu. Le réflexe est de brancher un filtre derrière, avec un tube (|), pour ne garder que les lignes qui vous intéressent. Cette combinaison a un piège spécifique au temps réel : par défaut les commandes en milieu de tube n'écrivent leur sortie que par blocs, ce qui gèle l'affichage pendant des minutes.

grep --line-buffered : l'option indispensable

Dans un pipeline normal, grep accumule sa sortie dans un tampon avant de l'écrire, ce qui casse l'effet temps réel. --line-buffered force l'écriture ligne par ligne :

# Ne montrer que les erreurs et avertissements
tail -f /var/log/app.log | grep --line-buffered -iE 'error|warn'

# Exclure les requêtes de monitoring (/health, /metrics)
tail -f /var/log/nginx/access.log | grep --line-buffered -v '/health\|/metrics'

# Afficher les erreurs HTTP 5xx avec couleur
tail -f /var/log/nginx/access.log | grep --line-buffered --color=always '" 5[0-9][0-9] '

Oublier --line-buffered

Sans --line-buffered, grep dans un pipeline avec tail -f peut rester silencieux pendant des minutes, puis afficher tout d'un coup quand son tampon est plein. Le comportement semble aléatoire, c'est en fait le buffering par défaut. Ajoutez toujours --line-buffered dans ces pipelines.

Enchaîner plusieurs filtres

Rien n'interdit de chaîner plusieurs grep : le premier sélectionne, les suivants excluent le bruit résiduel. Chaque maillon du tube a son propre tampon, donc --line-buffered doit être répété sur chacun d'eux, sauf sur le dernier qui écrit directement dans le terminal. Oublier l'option sur un seul maillon suffit à figer tout l'affichage.

# Erreurs mais pas les erreurs de monitoring
tail -f /var/log/app.log \
  | grep --line-buffered 'ERROR' \
  | grep --line-buffered -v 'healthcheck'

less +F, l'alternative interactive

less +F démarre en mode suivi et vous laisse naviguer dans l'historique en cours de session :

less +F /var/log/syslog

• Ctrl+C : arrête le suivi, permet de défiler avec les flèches
• F : reprend le suivi temps réel
• q : quitte

C'est utile quand vous voulez à la fois voir les nouvelles lignes ET remonter dans l'historique sans quitter.

journalctl, les journaux systemd

journalctl interroge le journal binaire de systemd. Contrairement aux fichiers plats, ce journal centralise les messages de tous les services, avec métadonnées, priorités et numérotation de boot.

Suivi en temps réel

-f affiche les dernières entrées puis reste actif, ajoutant chaque nouvelle ligne à mesure que les services l'écrivent, jusqu'à Ctrl+C. Les filtres se cumulent avec ce mode : -u restreint à une ou plusieurs unités systemd, -p à un niveau de priorité. Répéter -u affiche les unités entrelacées dans l'ordre chronologique, ce qui montre l'enchaînement réel entre deux services.

journalctl -f                           # toutes les unités, en direct
journalctl -f -u nginx                  # service nginx seulement
journalctl -f -u nginx -u postgresql    # nginx ET postgresql
journalctl -f -p err                    # erreurs seulement, en direct

-f c'est l'équivalent de tail -f

journalctl -f est le tail -f du journal systemd. Il affiche les entrées au fur et à mesure, sans l'ambiguïté de la rotation de fichiers.

Filtrer par unité systemd

Le nom passé à -u est celui de l'unité systemd, tel que systemctl list-units l'affiche ; le suffixe .service est optionnel. --no-pager désactive l'ouverture de less et écrit directement dans le terminal, ce qui est indispensable dans un script ou quand vous voulez enchaîner la sortie sur un autre outil. -n limite au nombre de lignes les plus récentes, le réflexe pour ne pas dérouler des mois d'historique.

journalctl -u nginx --no-pager          # tout l'historique de nginx
journalctl -u nginx -n 50 --no-pager    # 50 dernières lignes
journalctl -u nginx -f                  # en direct

Filtrer par priorité

Les niveaux suivent la convention syslog (du plus au moins critique) :

Niveau	Valeur	Signification
emerg	0	Système inutilisable
alert	1	Action immédiate requise
crit	2	Condition critique
err	3	Erreurs
warning	4	Avertissements
notice	5	Conditions normales notables
info	6	Messages informatifs
debug	7	Messages de debug

Glissez pour voir

-p err filtre les niveaux err et plus critiques (0 à 3) :

journalctl -p err --since "1 hour ago" --no-pager
journalctl -p warning --since today --no-pager   # avertissements et plus critiques

Filtrer par plage horaire

--since et --until acceptent aussi bien une date absolue (AAAA-MM-JJ HH:MM:SS) qu'une expression relative en anglais, calculée depuis l'heure courante de la machine. C'est ce qui permet de revenir sur un incident déjà terminé : vous encadrez la fenêtre signalée par la supervision et vous ne lisez que ces minutes-là. Attention au fuseau horaire, journalctl affiche l'heure locale du serveur, pas la vôtre.

journalctl --since "2026-04-09 10:00:00" --until "2026-04-09 11:00:00" --no-pager
journalctl --since today --no-pager
journalctl --since yesterday --no-pager
journalctl --since "1 hour ago" --no-pager

Filtrer par démarrage système

journald attribue un identifiant à chaque démarrage du système et permet de s'y référer par un numéro relatif : 0 pour le boot en cours, -1 pour le précédent. Ce découpage est précieux après un redémarrage subi, car les dernières lignes avant la coupure se trouvent dans le boot précédent, pas dans l'actuel. Si --list-boots ne renvoie qu'une ligne, le journal n'est pas persistant et l'historique s'arrête au dernier démarrage.

journalctl -b --no-pager           # boot actuel
journalctl -b -1 --no-pager        # boot précédent
journalctl --list-boots            # liste tous les démarrages connus

C'est utile après un crash : journalctl -b -1 -p err montre les erreurs du dernier boot.

Messages kernel

-k ne garde que les entrées émises par le noyau : détection du matériel, erreurs de disque, processus tués par manque de mémoire, paquets rejetés par le pare-feu. C'est la première chose à regarder quand la panne semble venir de la machine plutôt que de l'application. Contrairement à dmesg, journalctl horodate ces messages avec la date réelle, ce qui permet de les recouper avec les logs des services.

journalctl -k --no-pager           # messages kernel (équivalent dmesg)
journalctl -k --since "1 hour ago" --no-pager

Combiner journalctl et grep

journalctl filtre sur les métadonnées (unité, priorité, date), pas sur le contenu du message. Dès que la recherche porte sur un texte précis, un tube vers grep ou awk prend le relais. --no-pager devient alors obligatoire, sans lui less intercepte la sortie et le tube ne reçoit rien d'exploitable. Le second exemple compte les occurrences par service, une façon rapide de repérer le composant le plus bruyant.

# Chercher les connexions SSH échouées
journalctl -u sshd --since today --no-pager | grep 'Failed\|Invalid'

# Compter les erreurs par service sur la dernière heure
journalctl -p err --since "1 hour ago" --no-pager \
  | awk '{print $5}' | sort | uniq -c | sort -rn

Choisir entre tail -f et journalctl

Le critère de choix n'est pas une préférence, c'est la source du log. Si le service écrit lui-même dans un fichier sous /var/log/, tail y accède directement ; s'il se contente d'écrire sur sa sortie standard, systemd capte le flux et seul journalctl le voit. En cas de doute, journalctl -u <service> répond immédiatement : une sortie vide signifie que les messages partent ailleurs, donc dans un fichier.

Situation	Outil recommandé
Service avec logs dans /var/log/*.log	tail -f
Service systemd sans fichier de log dédié	journalctl -f -u <service>
Filtrer par priorité ou plage horaire	journalctl
Investigation post-crash (boot précédent)	journalctl -b -1
Suivre plusieurs fichiers non-systemd	tail -f fichier1 fichier2
Mode interactif avec navigation historique	less +F

Glissez pour voir

Les deux peuvent coexister

Certains services (nginx, apache, postgresql) écrivent dans /var/log/ et dans le journal systemd. Dans ce cas, tail -f donne la même information que journalctl -f -u nginx, choisissez selon ce qui est le plus commode.

Cas d'usage admin

Les commandes ci-dessous combinent les briques vues plus haut sur des situations réelles d'exploitation : accompagner un déploiement, réagir à une ligne d'erreur, comprendre pourquoi un service refuse de démarrer, hiérarchiser les composants les plus bruyants. La boucle while read mérite une remarque, elle traite chaque ligne dès son arrivée et n'existe que grâce au --line-buffered placé sur le grep qui la précède. La ligne logger commentée expédierait l'alerte vers syslog au lieu de l'afficher.

# Surveiller un déploiement : voir les logs app + nginx simultanément
tail -f /var/log/app/production.log /var/log/nginx/error.log

# Alerter sur les erreurs pendant un déploiement
tail --follow=name --retry /var/log/app/production.log \
  | grep --line-buffered 'ERROR\|FATAL' \
  | while read -r line; do
      echo "[ALERTE] $line"
      # logger -t deploy_monitor "$line"  # optionnel : envoyer dans syslog
    done

# Diagnostiquer pourquoi un service n'a pas démarré
journalctl -u mon-service -b --no-pager | tail -n 30

# Voir toutes les erreurs depuis hier
journalctl -p err --since yesterday --no-pager | grep -v 'kernel'

# Top des services les plus bruyants en erreurs (dernière heure)
journalctl -p err --since "1 hour ago" --no-pager \
  | awk 'NR>1 {print $5}' | sort | uniq -c | sort -rn | head -10

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• tail -f suit un fichier par descripteur ; --follow=name --retry survit à la rotation, utilisez le second en production.
• grep --line-buffered est obligatoire dans un pipeline avec tail -f pour éviter le buffering silencieux.
• journalctl -f -u <service> est l'équivalent systemd de tail -f, sans risque de rotation.
• journalctl -b -1 -p err est le premier réflexe après un crash : erreurs du boot précédent.
• less +F permet de naviguer dans l'historique sans quitter le mode suivi.

Pour aller plus loin

• Logs avec journalctl : Gérer la rétention, la persistance et l'export des journaux systemd.
• Gestion des services avec systemctl : Démarrer, arrêter, activer et diagnostiquer les services systemd.
• Référence grep : Toutes les options grep, dont --line-buffered, -E et -v indispensables dans un pipeline tail -f.

×

📖 Voir la documentation →