Les logs Linux : ou chercher et comment les lire

Credit : Logo officiel

Les logs Linux : ou chercher et comment les lire

Dylan D. — Agent Support Technique Serveur Depannage 1836 mots 10 min de lecture

Quand un serveur deconne, les logs racontent tout

Mardi 11h, un client e-commerce m'envoie un mail en mode panique : "mon site marche plus !!". Premiere question que je pose : t'as regarde les logs ? Reponse classique : "les quoi ?". En 4 minutes de SSH, j'avais la reponse. PHP-FPM saturait sa pool, les workers etaient tous occupes par des requetes WP-Admin lancees par un crawler agressif. Sans les logs, j'aurais pu chercher pendant 2 heures.

Les logs c'est ta boite noire. Quand ca plante, c'est LA qu'il faut aller. Pas sur Stack Overflow, pas dans la doc, pas en redemarrant le serveur a l'aveugle. Ce guide regroupe tout ce que j'utilise au quotidien sur des serveurs Debian 12 et Ubuntu 22.04 LTS pour identifier rapidement ce qui cloche.

L'arborescence /var/log : la carte du tresor

Sur une Debian standard, voila les fichiers que je consulte 90% du temps :

/var/log/
  syslog              # Messages systeme generaux (Debian)
  messages            # Equivalent sur RHEL/Rocky
  auth.log            # Connexions SSH, sudo, PAM
  kern.log            # Messages du noyau
  dpkg.log            # Installations/mises a jour paquets
  apt/history.log     # Historique apt detaille
  nginx/
    access.log        # Toutes les requetes HTTP
    error.log         # Erreurs Nginx (502, 504, upstream)
  apache2/
    access.log
    error.log
  mysql/
    error.log         # Erreurs MariaDB/MySQL
    mysql-slow.log    # Requetes lentes (a activer)
  php8.2-fpm.log      # Erreurs PHP-FPM
  fail2ban.log        # Bans en cours
  unattended-upgrades/ # Mises a jour automatiques

Comprendre la rotation et les .gz

Les logs en .1, .2.gz, .3.gz ce sont les anciens, compresses par logrotate. Pour les lire sans les decompresser :

zcat /var/log/auth.log.2.gz | grep "Failed password"
zgrep "sudo" /var/log/auth.log.*.gz
zless /var/log/nginx/access.log.5.gz

J'utilise zgrep au moins 3 fois par semaine pour faire des analyses post-incident sur 30 jours d'historique.

journalctl : l'outil sous-utilise par 80% des admins

Depuis systemd, journalctl est devenu mon point d'entree principal. Il agrege les logs de tous les services et offre un filtrage chirurgical :

# Logs recents, navigation au pager
journalctl -e

# Logs d'un service specifique
journalctl -u nginx
journalctl -u php8.2-fpm
journalctl -u mariadb

# Depuis une date precise
journalctl --since "2026-05-07 10:00"
journalctl --since "1 hour ago"
journalctl --since today --until "2 hours ago"

# Suivre en temps reel (mon prefere)
journalctl -u nginx -f

# Logs noyau uniquement
journalctl -k

# Que les erreurs (priorite 3 = err)
journalctl -p err -b

# Depuis le dernier boot
journalctl -b 0
# Boot precedent
journalctl -b -1

# En JSON pour parsing avec jq
journalctl -u nginx --output json | jq '.MESSAGE'

Configurer la persistence du journal

Par defaut sur certaines distros, le journal est en RAM et disparait au reboot. Pour le rendre persistant :

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Verifier la taille consommee :

journalctl --disk-usage
# Limiter a 1G dans /etc/systemd/journald.conf : SystemMaxUse=1G

auth.log : voir qui essaye de rentrer chez toi

C'est le premier fichier que je regarde quand je suspecte une tentative d'intrusion ou un comportement louche :

# Tentatives SSH ratees
sudo grep "Failed password" /var/log/auth.log | tail -20

# Top des IP qui essayent (clairement flippant la premiere fois)
sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -rn | head

# Connexions SSH reussies
sudo grep "Accepted" /var/log/auth.log | tail -20

# Qui utilise sudo et avec quelle commande
sudo grep "COMMAND=" /var/log/auth.log | tail -20

# Ajouts/modifs de comptes utilisateurs
sudo grep -E "useradd|usermod|userdel|groupadd" /var/log/auth.log

La premiere fois que j'ai lance le top des IP sur un serveur fraichement installe expose sur Internet, j'ai flippe : 3000 tentatives en 24h depuis des IP chinoises et russes. D'ou l'interet de securiser SSH avec sshd_config et de coupler avec fail2ban pour bloquer les brute force.

Lire les logs Nginx comme un detective

Le format par defaut du access.log :

203.0.113.50 - - [07/May/2026:14:30:00 +0200] "GET /article/123 HTTP/1.1" 200 4523 "https://google.fr" "Mozilla/5.0 (Windows NT 10.0)"

Les champs : IP, identite, user, timestamp, requete, code, taille, referer, user-agent.

Mes commandes du quotidien

# Top 10 IP les plus actives (pour reperer un crawler agressif)
awk '{print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head

# Pages en 404 par frequence
awk '$9 == 404' /var/log/nginx/access.log \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Les 500 et 502 (celles qui font mal)
awk '$9 ~ /^5/' /var/log/nginx/access.log | tail -30

# Requetes par heure (visualiser un pic)
awk '{print $4}' /var/log/nginx/access.log \
  | cut -d: -f1-2 | sort | uniq -c

# Bots et crawlers
grep -iE "bot|crawler|spider" /var/log/nginx/access.log \
  | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn

# Taille moyenne des reponses
awk '{sum+=$10; count++} END {print sum/count}' /var/log/nginx/access.log

Logs d'erreur Nginx

Le error.log est ou j'identifie les problemes upstream PHP-FPM, les permissions cassees ou les worker_connections saturees :

tail -50 /var/log/nginx/error.log

# Compter les erreurs par type
grep -oP '\[\K[a-z]+(?=\])' /var/log/nginx/error.log \
  | sort | uniq -c

Dans 60% des incidents que je traite, l'erreur Nginx pointe directement vers le coupable : PHP-FPM down, socket inaccessible, ou upstream timed out synonyme de 502 Bad Gateway a debug.

Logs MySQL et requetes lentes

# Erreurs recentes MariaDB
sudo tail -50 /var/log/mysql/error.log

# Activer le slow query log
mysql -u root -p <<EOF
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;
SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';
EOF

# Analyser les requetes lentes les plus frequentes
mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log

# Par temps total cumule
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log

Sur un WordPress lent, le slow query log m'a deja sauve la mise : un plugin de stats faisait un SELECT * sur wp_postmeta sans index. 4 secondes par chargement de page. Identifie en 5 minutes grace au log.

Logrotate : eviter que tes logs bouffent tout le disque

J'ai deja vu un access.log de 18 Go sur un serveur d'un client a Lyon. Le site etait down parce que /var etait plein a 100%. Logrotate evite ca, mais il faut le configurer correctement.

Config dans /etc/logrotate.d/monapp :

/var/log/monapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload monapp > /dev/null 2>&1 || true
    endscript
}

Tester sans appliquer

# Mode debug, ne fait rien mais montre ce qui se passerait
sudo logrotate -d /etc/logrotate.d/monapp

# Forcer l'execution maintenant
sudo logrotate -f /etc/logrotate.d/monapp

# Verifier l'etat global
cat /var/lib/logrotate/status | grep monapp

Surveiller la taille

# Top 10 des plus gros fichiers de log
sudo du -ah /var/log/ | sort -rh | head -10

# Espace total /var/log
sudo du -sh /var/log/

# Alerte rapide via mail si depasse 80%
df -h /var | awk 'NR==2 {gsub("%",""); if ($5 > 80) print "ALERT /var:" $5"%"}'

Erreurs courantes et leur fix

1. "No space left on device" mais df montre du libre

Classique : tu as supprime un gros log avec rm mais un processus le tient encore ouvert. Le fichier disparait du FS mais l'espace n'est pas libere. Fix :

sudo lsof | grep deleted
# Identifie le PID, puis
sudo kill -HUP <PID>  # ou redemarre le service

2. journalctl vide apres un reboot

Le journal n'est pas persistant. Fix : creer /var/log/journal/ et redemarrer systemd-journald (cf section dediee plus haut).

3. Logs Nginx avec des IP en 127.0.0.1

Tu es derriere Cloudflare ou un reverse proxy. Tes logs montrent l'IP du proxy, pas du visiteur. Fix dans /etc/nginx/nginx.conf :

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
real_ip_header CF-Connecting-IP;

Details dans le guide reverse proxy Nginx avec SSL.

4. Logrotate ne tourne plus

Verifier le timer :

systemctl list-timers | grep logrotate
sudo systemctl status logrotate.timer
# Si HS, le forcer une fois
sudo logrotate -f /etc/logrotate.conf

5. PHP-FPM n'ecrit rien dans son log

90% du temps c'est error_log mal configure dans /etc/php/8.2/fpm/php-fpm.conf. Forcer :

error_log = /var/log/php8.2-fpm.log
log_level = notice

Puis systemctl restart php8.2-fpm. Si toujours rien, verifier les permissions sur /var/log/.

Commandes de survie quand ca brule

Celles que je tape en mode reflexe quand je me connecte a un serveur qui ne repond plus :

# Combien de place prennent les logs
sudo du -sh /var/log/* | sort -rh | head

# Chercher "error" partout, fichiers concernes
sudo grep -rli "error" /var/log/ --include="*.log"

# Suivre plusieurs logs en parallele
sudo tail -f /var/log/nginx/error.log /var/log/php8.2-fpm.log /var/log/mysql/error.log

# Logs des 5 dernieres minutes tous services confondus
sudo journalctl --since "5 min ago" -p warning

# Top services qui ont logge le plus aujourd'hui
sudo journalctl --since today --output cat | head -10000 \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head

Centraliser les logs avec rsyslog

Quand vous gerez plusieurs serveurs, courir d'un SSH a l'autre pour lire des logs devient vite penible. La solution intermediaire avant de passer a Loki ou ELK : rsyslog en mode central.

Sur le serveur central, dans /etc/rsyslog.d/00-central.conf :

module(load="imtcp")
input(type="imtcp" port="514")

template(name="PerHost" type="string"
  string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")

*.* ?PerHost
& stop

Sur chaque serveur client, dans /etc/rsyslog.d/99-forward.conf :

*.* @@logs.monsite.fr:514

Apres systemctl restart rsyslog sur les deux machines, tous les logs systeme remontent dans /var/log/remote/<hostname>/. Couple a logrotate, ca tient des annees sans intervention.

Parser les logs avec lnav

lnav est un outil sous-cote qui transforme la lecture de logs. Il colorise, deduplique, parse les timestamps et permet du SQL sur les logs :

sudo apt install lnav
lnav /var/log/nginx/access.log

# Dans lnav, taper :
# ; SELECT cs_uri_stem, COUNT(*) FROM access_log WHERE sc_status = 404 GROUP BY 1 ORDER BY 2 DESC LIMIT 10

C'est ma combinaison preferee avec journalctl quand je dois faire de l'analyse rapide sans monter une stack complete.

Pour aller plus loin

Lire les logs, c'est la moitie du metier

Un serveur qui plante a toujours laisse des indices. La difference entre un junior qui galere 2h et un senior qui resout en 10 minutes, c'est rarement la connaissance theorique : c'est le reflexe de regarder les logs avant tout. Prenez l'habitude de consulter auth.log, nginx/error.log et journalctl -p err au moins une fois par semaine, meme quand tout va bien. Vous decouvrirez des trucs etranges, et le jour ou ca casse vraiment, vous saurez exactement ou regarder.

PS: Si vous gerez plusieurs serveurs, regardez du cote de Loki + Grafana ou de la stack ELK pour centraliser les logs. C'est un autre niveau de confort, mais a reserver quand vous etes deja a l'aise avec les outils de base.

# Articles similaires

Sur les memes sujets et plus loin