| name | linux-troubleshooter |
| description | Diagnostic de problèmes Linux — performance, disque, mémoire, réseau et processus. Se déclenche avec "Linux lent", "top", "htop", "df", "dmesg", "strace", "debug Linux". Also triggers on "Linux troubleshooting", "server is slow", "disk full", "high memory usage". |
Linux Troubleshooter
Étape 0 — Snapshot initial (toujours en premier)
Avant tout : collecter les métriques de référence. Ne jamais agir sans baseline.
uptime
free -h
df -h && df -i
top -bn1 | head -20
dmesg -T | tail -30
systemctl --failed
Critère de décision :
- Load average > nb_vCPU × 2 → diagnostic CPU/I-O
Mem available < 5 % de la RAM totale → diagnostic mémoire
Use% disque > 90 % ou inodes saturés → diagnostic disque
- Services
failed listés → diagnostic service en priorité
Étape 1 — CPU et processus
ps aux --sort=-%cpu | head -12
mpstat -P ALL 1 5
perf top -s comm,dso
strace -c -p <PID>
Critères :
us (user) élevé → code applicatif ; profiler avec perf ou async-profiler
sy (system) élevé → I/O ou appels système excessifs ; strace
wa (iowait) élevé → goulot I/O disque → Étape 3
si/hi élevés → interruptions réseau/hardware → vérifier NIC
Étape 2 — Mémoire
free -h
vmstat 1 5
cat /proc/meminfo | grep -E 'MemAvailable|Dirty|Writeback|Slab'
dmesg -T | grep -i 'oom\|killed process'
journalctl -k --since "1h ago" | grep -i oom
ps aux --sort=-%mem | head -12
cat /proc/<PID>/status | grep -E 'VmRSS|VmSwap'
smem -rs pss | head -15
Critères :
si/so dans vmstat > 0 → swap actif ; investiguer qui swapper
- Slab élevé (>20 % RAM) → fuite cache noyau ;
slabtop
- OOM dans dmesg → le processus victime est dans les logs ; ajuster
vm.overcommit_memory
Étape 3 — Disque et I/O
iostat -xz 1 5
iotop -o -b -n 3
du -ah /var /tmp /home 2>/dev/null | sort -rh | head -20
df -i
lsof | grep deleted | awk '{print $1, $7, $9}' | sort -k2 -rn | head -10
fsck -n /dev/sdX
Critères :
%util iostat ≈ 100 % → ajouter du stockage ou passer à SSD/NVMe
- Inodes saturées → supprimer petits fichiers nombreux (logs, tmp, sockets)
- Fichiers
deleted encore ouverts → libération immédiate par restart du processus
Étape 4 — Réseau
ping -c 5 8.8.8.8
traceroute -n 8.8.8.8
ip addr show
ip route show
ss -tulnp
ss -s
ss -tn state time-wait | wc -l
tcpdump -i eth0 -n -c 200 host <IP>
tcpdump -i eth0 -n -c 200 port 443 -w /tmp/cap.pcap
dig @8.8.8.8 example.com +short
resolvectl status
Critères :
- Drop packets dans
ip -s link → problème hardware/driver
- Beaucoup de
TIME_WAIT → ajuster net.ipv4.tcp_tw_reuse=1 + tcp_fin_timeout
- Latence DNS > 500 ms → changer resolver ou vérifier
/etc/resolv.conf
Étape 5 — Services et logs
systemctl status nginx --no-pager -l
journalctl -u nginx -f
journalctl -xe --since "30 min ago"
grep -rE 'error|fail|crit|panic' /var/log/ --include='*.log' -l
journalctl -p err..emerg --since "2h ago"
systemctl list-dependencies nginx --failed
fuser 80/tcp
ss -tulnp | grep ':80'
Étape 6 — Appliquer et valider
- Snapshot avant (métriques de l'étape 0 sauvegardées)
- Appliquer le correctif minimal (redémarrer service, libérer espace, tuer le bon processus)
- Snapshot après — comparer avec l'avant
- Si le problème revient → investiguer la cause racine, pas juste les symptômes
systemctl restart <service>
systemctl status <service>
sync && echo 3 > /proc/sys/vm/drop_caches
fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
Garde-fous et anti-patterns
| Anti-pattern | Risque | Bonne pratique |
|---|
kill -9 sans investigation | Corruption de données, état inconsistant | Envoyer SIGTERM d'abord, attendre 10 s |
strace -p <PID> en prod longtemps | Ralentit le processus de 2x à 10x | Utiliser strace -c (résumé) ou perf trace |
echo 3 > /proc/sys/vm/drop_caches en prod | Spike I/O brutal, latences en cascade | Réservé aux urgences RAM critique hors heure |
Modifier /etc/sysctl.conf sans tester | Régression réseau ou mémoire | Tester avec sysctl -w puis valider avant persistance |
| Supprimer des logs pour libérer de l'espace | Perte de preuves pour l'audit | truncate -s 0 /var/log/app.log si actif, ou logrotate |
| Relancer un service sans lire ses logs | Boucle de crash, masquage du problème | Toujours lire journalctl -u <service> -n 50 avant restart |
| Diagnostiquer sur un snapshot prod sans baseline | Pas de référence pour valider | Toujours collecter métriques avant action |
Monitoring préventif (post-incident)
systemctl enable --now sysstat
sar -u 1 10
nohup sh -c 'while true; do
load=$(awk "{print \$1}" /proc/loadavg)
ncpu=$(nproc)
if awk "BEGIN{exit !($load > $ncpu * 0.8)}"; then
echo "HIGH LOAD $load" | mail -s ALERT admin@example.com
fi
sleep 60
done' &
Pour les environnements avec Prometheus + Alertmanager, préférer les alertes sur node_load15, node_memory_MemAvailable_bytes, node_filesystem_avail_bytes.