Linux avancé : journaux et diagnostic de performance

Cette page associe journaux (que s’est-il passé ?) et mesures (que se passe-t-il ?). Pour la base de journalctl, voir systemd : le journal.

`journalctl` : requêtes précises

journalctl -u nginx -u php8.3-fpm --since "1 hour ago"          # plusieurs services
journalctl -p err -b                                              # erreurs depuis le démarrage
journalctl -p warning..alert --since today
journalctl -b -1                                                  # démarrage précédent
journalctl --list-boots
journalctl -k                                                     # messages du noyau (dmesg)
journalctl _PID=1234
journalctl _UID=1000 --since yesterday
journalctl _SYSTEMD_UNIT=ssh.service + _COMM=sshd
journalctl -g "timeout|refused" -u monapp                         # filtre par expression régulière
journalctl -o json-pretty -n 1 -u monapp                          # format structuré
journalctl -o cat -u monapp                                       # message seul
journalctl -f -u monapp                                           # suivre en direct
journalctl --since "2026-01-15 10:00" --until "2026-01-15 10:15"

Niveau (`-p`)	Valeur
`emerg`, `alert`, `crit`	0, 1, 2 : très grave
`err`	3 : erreur
`warning`	4
`notice`, `info`, `debug`	5, 6, 7

journalctl -p err -b est un excellent premier réflexe après un problème : les erreurs de toute la machine depuis le démarrage.

Conservation et espace

journalctl --disk-usage
sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=30d
sudo journalctl --verify

Par défaut, le journal est persistant sur Ubuntu (/var/log/journal). Limites permanentes dans /etc/systemd/journald.conf.d/limites.conf :

[Journal]
SystemMaxUse=1G
MaxRetentionSec=1month
RateLimitIntervalSec=30s
RateLimitBurst=10000

sudo systemctl restart systemd-journald après modification. Le limitage de débit peut faire disparaître des messages lors d’un pic : « Suppressed N messages » dans le journal.

Journaux traditionnels

Fichier	Contenu
`/var/log/syslog`	Messages généraux (rsyslog)
`/var/log/auth.log`	Authentifications (`sudo`, SSH, `su`)
`/var/log/kern.log`	Noyau
`/var/log/apt/history.log`	Installations et mises à jour de paquets
`/var/log/dpkg.log`	Opérations `dpkg`
`/var/log/unattended-upgrades/`	Mises à jour automatiques
`/var/log/nginx/`, `/var/log/apache2/`	Serveurs web
`/var/log/fail2ban.log`	Bannissements
`/var/log/lastlog`, `wtmp`, `btmp`	Connexions (`last`, `lastb`)

sudo tail -f /var/log/auth.log
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
sudo zgrep "erreur" /var/log/syslog.*.gz

`logrotate`

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

sudo logrotate -d /etc/logrotate.d/monapp         # simulation (debug)
sudo logrotate -f /etc/logrotate.d/monapp         # forcer
cat /var/lib/logrotate/status

copytruncate convient aux programmes qui ne rouvrent pas leur journal (au risque de perdre quelques lignes) ; sinon postrotate avec un rechargement. Voir Nginx : performances et journaux.

Méthode USE : diagnostiquer une machine

Pour chaque ressource (processeur, mémoire, disque, réseau), vérifier :

Mesure	Question
Utilisation	Quel pourcentage de la ressource est occupé ?
Saturation	Du travail attend-il sa disponibilité ? (files d’attente)
Erreurs	Des erreurs sont-elles signalées ?

Une utilisation élevée sans saturation n’est pas un problème ; la saturation (attente) est ce qui ralentit.

Vue d’ensemble : `uptime`, `top`, `vmstat`

uptime                                  # load average : 1, 5, 15 minutes
nproc                                   # nombre de processeurs
top -o %CPU                             # (htop plus confortable)
vmstat 1 10

Le load average compte les processus prêts à s’exécuter ou en attente d’entrée-sortie : le comparer au nombre de cœurs (nproc) : une charge de 4 sur 4 cœurs est saturée à 100 %, sur 16 cœurs elle est à 25 %.

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0 412344 102400 2048000    0    0    12    40  300  500 12  4 82  2  0

Colonne	Lecture
`r`	Processus prêts : supérieur au nombre de cœurs = saturation du processeur
`b`	Processus bloqués en entrée-sortie
`si`, `so`	Échanges avec le swap : valeurs durablement non nulles = manque de mémoire
`us`, `sy`	Temps utilisateur, noyau
`wa`	Attente d’entrée-sortie (disque)
`st`	Temps « volé » par l’hyperviseur (machine virtuelle surchargée)

Processeur

sudo apt install sysstat
mpstat -P ALL 1 5                        # par cœur
pidstat -u 1 5                           # par processus
pidstat -w 1 5                           # changements de contexte
ps -eo pid,pcpu,cmd --sort=-pcpu | head
sudo perf top                            # (paquet linux-tools-generic) profil en direct
sudo perf record -g -p 1234 -- sleep 30 && sudo perf report

Signe	Cause probable
`us` élevé	Calcul applicatif : profiler l’application
`sy` élevé	Appels système, réseau, pilotes : `strace -c`, `perf`
`wa` élevé	Disque : voir ci-dessous
`st` élevé	Machine virtuelle sur un hôte surchargé : demander plus de ressources
Un cœur à 100 % et les autres libres	Programme mono-thread (Node.js : PM2 : mode cluster)

Mémoire

free -h
vmstat -s | head
cat /proc/pressure/memory
sar -r 1 5                               # mémoire (sysstat)
sudo slabtop -o | head                   # mémoire du noyau

Indicateurs de saturation : available faible, si/so > 0 durable, PSI memory > 0, messages OOM (Processus et ressources).

Disque

iostat -xz 1 5
sudo iotop -oP                           # processus qui écrivent (paquet iotop)
pidstat -d 1 5
sar -d -p 1 5
cat /proc/pressure/io
df -h; df -i

Device  r/s   w/s  rkB/s  wkB/s  r_await w_await aqu-sz %util
sda     12.0  80.0 480.0 2400.0  1.2     8.5     0.7    62.3

Colonne	Lecture
`%util`	Occupation du périphérique (proche de 100 % pour un disque à rotation : saturé ; moins parlant pour NVMe)
`r_await`, `w_await`	Latence moyenne des lectures et écritures (ms) : saturation si elle grimpe
`aqu-sz`	Longueur moyenne de la file d’attente
`rkB/s`, `wkB/s`	Débit

Latences élevées + file d’attente = disque saturé ou défaillant (smartctl, Disques et systèmes de fichiers).

Réseau

sar -n DEV 1 5                           # débit par interface
ip -s link show eth0                     # erreurs, pertes
ss -s
sudo ethtool -S eth0 | grep -iE "err|drop|miss"
nstat -az | grep -iE "retrans|drop|overflow"
sudo iftop -i eth0                       # trafic par connexion (paquet iftop)
sudo nethogs eth0                        # trafic par processus (paquet nethogs)

Retransmissions TCP et pertes : voir Réseau avancé.

Historique des mesures : `sysstat`

sudo apt install sysstat
sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat
sar -u                                   # processeur d'aujourd'hui
sar -r -f /var/log/sysstat/sa15          # mémoire du 15 du mois
sar -q                                   # load average

sar conserve l’historique : indispensable pour répondre à « que se passait-il hier à 3 h du matin ? » Sans historique, on ne peut que constater l’état présent. Pour une supervision continue, voir les outils de métriques (Prometheus, Netdata) : au-delà de cette page.

Méthode générale de diagnostic

Reproduire / dater le problème (heure, durée, symptôme).
journalctl -p err --since "…" autour de cet instant.
Charge globale : uptime, vmstat 1.
Quelle ressource sature ? processeur (mpstat), mémoire (free, PSI), disque (iostat), réseau (ss, sar -n).
Quel processus ? pidstat, top, iotop.
Que fait-il ? strace -p, journaux applicatifs, perf.
Corriger une chose à la fois, mesurer après.

Dépannage

Symptôme	Piste
Charge élevée, processeur peu utilisé	Entrées-sorties (`wa`, `b` de `vmstat`, `iostat`), processus en `D`
Machine lente après quelques jours	Fuite mémoire, swap actif, journaux ou disque pleins
Pics à heure fixe	Tâche planifiée (`systemctl list-timers`, `crontab -l`), sauvegarde
Les journaux ont disparu	`journald` non persistant, limites, rotation : `journalctl --list-boots`
`Suppressed N messages`	Limitation de débit de `journald` : relever `RateLimitBurst`
`/var/log` plein	`du -sh /var/log/* \| sort -h`, `logrotate`, `journalctl --vacuum-size`
`iostat: command not found`	`sudo apt install sysstat`
`perf: command not found`	`sudo apt install linux-tools-generic linux-tools-$(uname -r)`

Ubuntu 24.04 et 26.04 : différences à connaître

Même outillage sur les deux versions (sysstat, iotop, perf via linux-tools-* correspondant au noyau). Le noyau diffère (6.8 sur 24.04, 7.0 sur 26.04) : linux-tools-$(uname -r) doit correspondre à la version en cours.

Pour aller plus loin

Manuels : man journalctl, man logrotate, man vmstat, man iostat, Méthode USE
Suite : Noyau et démarrage