Méthode de diagnostic sous Linux

Imaginez cette situation : vous êtes responsable d’une application web hébergée sur un serveur Linux. Depuis ce matin, les utilisateurs se plaignent de lenteurs. Certaines requêtes prennent 30 secondes au lieu de 2.

Vous vous connectez au serveur et commencez à chercher :

Vous lancez htop : le CPU semble normal, autour de 40%
Vous regardez free -h : il reste de la mémoire disponible
Vous vérifiez le disque avec df -h : 60% utilisé, rien d’alarmant
Les logs Apache ne montrent rien de spécial

Vous êtes bloqué. Le problème est là, mais vous ne savez pas où chercher.

Après deux heures de recherche, un collègue plus expérimenté jette un œil : « As-tu regardé l’I/O wait ? ». Un coup d’œil à iostat révèle que le disque est saturé en écriture. Un processus de backup, lancé par erreur en pleine journée, écrit des gigaoctets. Problème trouvé en 2 minutes par quelqu’un qui savait où chercher.

La différence entre vous et ce collègue ? Une méthode.

Qu’est-ce que le dépannage par symptômes ?

Une approche structurée, pas du hasard

Le dépannage par symptômes est une méthode qui part de ce que vous observez (le symptôme) pour remonter à ce qui cause le problème (la cause racine). C’est l’inverse de chercher au hasard en espérant tomber sur la solution.

Un symptôme est une manifestation visible du problème. C’est ce que vous observez directement : le serveur ne répond plus, l’application est lente, un service refuse de démarrer, le disque affiche « plein », ou la connexion réseau échoue. Le symptôme est votre point de départ, votre premier indice.

Une cause racine est l’origine réelle du problème, ce qui se cache derrière le symptôme. Par exemple, si l’application est lente (symptôme), c’est peut-être parce qu’un processus consomme toute la mémoire (cause racine). Si le disque est plein (symptôme), c’est peut-être parce que les logs s’accumulent sans rotation (cause racine). Si la connexion réseau échoue (symptôme), c’est peut-être parce qu’une règle firewall bloque le trafic (cause racine).

Le piège classique est de traiter le symptôme sans chercher la cause. Redémarrer un service qui plante peut le faire remarcher temporairement, mais si vous ne comprenez pas pourquoi il a planté, le problème reviendra.

Trois analogies pour bien comprendre

Quand vous allez chez le médecin avec de la fièvre, il ne vous prescrit pas immédiatement un antibiotique. Il pose des questions : depuis quand ? D’autres symptômes ? Il examine, fait des analyses, puis pose un diagnostic.

Le dépannage Linux fonctionne pareil : le symptôme (fièvre = serveur lent) n’est pas le problème, c’est le signal. Le vrai travail est de trouver l’infection (la cause racine).

Pourquoi une méthode est essentielle

Sans méthode, le dépannage devient frustrant : temps imprévisible, impossible de transmettre aux juniors, risque d’aggraver la situation.

Avec une méthode :

Vous savez toujours la prochaine étape
Votre approche est reproductible et documentable
Vous évitez les actions dangereuses
Vous résolvez plus vite et gagnez en confiance

Les quatre familles de symptômes

Les problèmes Linux se classent en quatre grandes familles : CPU, mémoire, disque et réseau. Identifier la bonne famille oriente immédiatement vers les bons outils.

Symptômes CPU : le processeur sature

Quand le processeur est surchargé, le système devient lent voire ne répond plus. Les commandes mettent plusieurs secondes à s’exécuter.

Causes fréquentes : processus « fou » (boucle infinie), trop de processus concurrents, attaque DDoS.

Commandes clés :

htop                              # Vue interactive
ps aux --sort=-%cpu | head -5     # Top 5 processus CPU
uptime                            # Load average

Interprétation : load average > nombre de cœurs = surcharge. %iowait élevé = problème disque, pas CPU.

Symptômes mémoire : la RAM est saturée

La saturation mémoire se manifeste par une dégradation progressive : système de plus en plus lent, puis processus tués par l’OOM Killer.

Causes fréquentes : fuite mémoire, trop de processus simultanés, application mal dimensionnée.

Commandes clés :

free -h                           # État de la mémoire
ps aux --sort=-%mem | head -5     # Top 5 processus mémoire
journalctl -k | grep -i "oom"     # OOM Killer ?

Interprétation : regardez available (pas used). Swap élevé = RAM insuffisante. OOM Killer = notez quel processus a été tué.

Symptômes disque : le stockage sature

Un disque plein se manifeste par des erreurs « No space left on device ». Les écritures échouent, les applications refusent de démarrer.

Causes fréquentes : logs qui s’accumulent, fichiers temporaires, core dumps, sauvegardes non purgées.

Commandes clés :

df -h                                    # Espace par partition
du -sh /* 2>/dev/null | sort -rh | head  # Plus gros répertoires
lsof | grep deleted                      # Fichiers supprimés mais ouverts

Interprétation : Use% à 100% = action urgente. Fichiers deleted = redémarrer le processus pour libérer l’espace.

Symptômes réseau : la connectivité échoue

Les problèmes réseau sont souvent les plus stressants : SSH impossible, timeouts, « Connection refused ».

Causes fréquentes : service non démarré, firewall qui bloque, interface down, DNS mal configuré.

Commandes de diagnostic :

# État des interfaces réseau
ip addr
ip link

# Table de routage
ip route

# Tester la connectivité
ping -c 4 8.8.8.8
ping -c 4 google.com  # teste aussi le DNS

# Vérifier qu'un port est ouvert
ss -tlnp | grep :80
netstat -tlnp | grep :80

# Règles firewall
iptables -L -n
# ou avec firewalld
firewall-cmd --list-all

# Résolution DNS
nslookup google.com
dig google.com

Comment interpréter :

Interface DOWN : problème physique ou configuration
ping IP OK mais ping DNS échoue : problème de résolution DNS
Port non listé dans ss -tlnp : le service n’écoute pas
REJECT/DROP dans iptables : le firewall bloque le trafic

La méthode en 7 étapes

Voici la méthode structurée pour dépanner n’importe quel incident Linux. Suivez ces étapes dans l’ordre, sans sauter d’étape, même si vous « pensez savoir » où est le problème.

Vue d’ensemble

Les 7 étapes de la méthode de dépannage Linux : Observer, Collecter, Reproduire, Isoler, Hypothèses, Tester, Résoudre

Étape 1 : Observer — Quel est le symptôme exact ?

Ne vous précipitez pas sur le clavier. Commencez par bien comprendre ce qui est rapporté. Cette étape est souvent bâclée, pourtant elle conditionne toute la suite.

Posez des questions précises, à l’utilisateur qui signale le problème ou à vous-même. Que se passe-t-il exactement ? « Ça marche pas » n’est pas un symptôme exploitable. Depuis quand le problème existe-t-il ? Est-ce permanent ou intermittent ? Si c’est intermittent, à quelle fréquence, et avez-vous identifié un pattern ?

Qui est affecté : tous les utilisateurs ou seulement certains ? Un seul utilisateur touché peut indiquer un problème de compte, de réseau local ou de navigateur. Tous les utilisateurs touchés pointent vers le serveur.

Qu’est-ce qui a changé récemment ? Un déploiement, une mise à jour système, une modification de configuration ? Enfin, y a-t-il un message d’erreur ? Si oui, notez-le mot pour mot : c’est souvent la clé du diagnostic

Exemple de mauvais symptôme :

« Le serveur est lent »

Exemple de bon symptôme :

« Depuis 14h, les pages du site mettent 15 secondes à charger au lieu de 2, pour tous les utilisateurs. Aucun changement déployé aujourd’hui. »

Étape 2 : Collecter — Logs, métriques, contexte

Maintenant que vous savez quoi chercher, rassemblez les informations.

Logs système :

# Logs système récents
journalctl -xe --since "1 hour ago"

# Logs d'un service spécifique
journalctl -u nginx --since "1 hour ago"

# Logs kernel (problèmes matériel, OOM, etc.)
dmesg -T | tail -50

# Logs applicatifs
tail -100 /var/log/nginx/error.log
tail -100 /var/log/apache2/error.log

Métriques système :

# Vue d'ensemble rapide
htop                     # CPU, mémoire, processus
df -h                    # Espace disque
free -h                  # Mémoire
uptime                   # Charge et durée de fonctionnement

# Historique si disponible
sar -u                   # Historique CPU
sar -r                   # Historique mémoire

Contexte :

# Dernières connexions
last -10

# Dernières commandes (si accès au .bash_history)
tail -20 ~/.bash_history

# Changements récents de fichiers
find /etc -mtime -1 -type f   # fichiers modifiés dans les 24h

Étape 3 : Reproduire — Le problème est-il reproductible ?

Un problème reproductible est dix fois plus facile à résoudre qu’un problème fantôme.

Pouvoir reproduire le problème vous apporte trois avantages majeurs. D’abord, ça confirme que le problème existe vraiment et que vous n’êtes pas en train de chasser un fantôme. Ensuite, ça vous permet de tester vos hypothèses : si vous pensez avoir trouvé la cause, vous pouvez vérifier en reproduisant le problème dans des conditions contrôlées. Enfin, après avoir appliqué votre correction, vous pouvez vérifier qu’elle fonctionne en tentant de reproduire le problème et en constatant qu’il a disparu

Comment reproduire :

Identifier les conditions

Quand le problème se produit-il ? Sous quelle charge ? Avec quelles données ?
Créer un cas de test minimal

Quelle est la plus petite action qui déclenche le problème ?
Documenter la procédure

Étapes exactes pour reproduire, à partager avec les collègues.

Si le problème n’est pas reproductible :

Certains problèmes sont intermittents et refusent de se manifester quand vous les cherchez. Dans ce cas, préparez-vous pour la prochaine occurrence. Mettez en place des scripts qui collectent automatiquement les données utiles (logs, métriques, état des processus). Renforcez votre monitoring pour capturer plus de détails. Et surtout, cherchez des patterns : le problème se produit-il toujours à la même heure ? Le même jour de la semaine ? Sous une certaine charge ? Ces indices peuvent révéler la cause.

Étape 4 : Isoler — Quel composant est en cause ?

Le système Linux est composé de couches empilées les unes sur les autres. Identifier la couche où se situe le problème vous évite de chercher au mauvais endroit.

Tout en bas, le matériel : CPU, RAM, disques, cartes réseau. Les problèmes matériels se manifestent souvent dans dmesg sous forme de messages d’erreur cryptiques. L’outil smartctl permet de vérifier la santé des disques, et lshw donne une vue complète du matériel.

Au-dessus, le noyau Linux lui-même. Les problèmes kernel apparaissent dans dmesg et journalctl -k. Ils sont rares mais graves : kernel panic, bug dans un driver, corruption mémoire.

Ensuite vient la couche système : les services de base gérés par systemd, le système d’initialisation. Un systemctl status sur le service concerné vous dit s’il tourne et s’il a eu des erreurs récentes.

La couche réseau inclut les interfaces, le firewall, le DNS. Les outils ip, ss et iptables vous permettent de diagnostiquer cette couche.

Enfin, tout en haut, votre application métier. C’est souvent là que se trouve le problème, et les logs applicatifs sont votre meilleure source d’information

Technique d’isolation :

# Le problème est-il sur CE serveur ?
# → Tester le même service sur un autre serveur

# Le problème est-il CE service ?
# → Tester d'autres services sur le même serveur

# Le problème est-il le réseau ?
# → Tester en local (localhost) vs distant

# Le problème est-il lié à la charge ?
# → Tester avec un seul utilisateur

Étape 5 : Hypothèses — Quelles causes possibles ?

Basé sur le symptôme et les données collectées, listez les causes possibles.

Comment formuler de bonnes hypothèses :

Partez du plus probable au moins probable. Si un serveur web est lent, il est plus probable qu’un processus consomme trop de ressources que d’avoir un problème matériel sur la carte mère.

Basez vos hypothèses sur les données que vous avez collectées, pas sur votre intuition. « Je suis sûr que c’est la base de données » n’est pas une hypothèse, c’est un préjugé. Une hypothèse ressemble à : « Le temps de réponse de la base de données a augmenté de 500ms dans les métriques, ce qui pourrait expliquer la lenteur ».

Considérez ce qui a changé récemment. La plupart des incidents surviennent après un changement : déploiement, mise à jour, modification de configuration. Si quelque chose a changé juste avant que le problème apparaisse, c’est une piste prioritaire

Exemple pour « serveur web lent » :

(Probable) Un processus consomme trop de ressources
(Probable) La base de données est lente
(Possible) Le disque est saturé en I/O
(Possible) Le réseau est congestionné
(Peu probable) Problème matériel

Comment prioriser vos hypothèses :

Trois critères pour décider par quoi commencer. La probabilité d’abord : commencez par ce qui arrive le plus souvent. Les logs qui remplissent le disque, c’est banal. Un bug dans le kernel, c’est rare.

Ensuite, la facilité de vérification. Entre deux hypothèses aussi probables, commencez par celle qui se teste en 30 secondes plutôt que celle qui demande une heure d’investigation.

Enfin, l’impact. Si une hypothèse, même peu probable, implique une perte de données ou un risque de sécurité, vérifiez-la rapidement pour vous rassurer ou agir vite.

Étape 6 : Tester — Vérifier chaque hypothèse

Testez chaque hypothèse dans l’ordre, une par une. C’est tentant de tout essayer en même temps pour aller plus vite, mais c’est un piège.

La règle d’or : un seul changement à la fois. Si vous modifiez trois choses et que le problème disparaît, vous ne savez pas ce qui l’a résolu. Pire, vous avez peut-être introduit deux nouveaux problèmes en corrigeant le premier.

Documentez chaque test au fur et à mesure. Notez la commande exacte que vous avez exécutée, ce que vous attendiez comme résultat, et ce que vous avez réellement observé. Cette documentation vous sera précieuse si vous devez passer le relais à un collègue ou revenir sur l’incident plus tard.

Assurez-vous de pouvoir revenir en arrière avant chaque modification. Ne faites rien d’irréversible sans backup. Un fichier de configuration modifié doit d’abord être copié. Un service arrêté doit pouvoir être redémarré.

Structure d’un test :

Hypothèse : Le processus PHP-FPM consomme trop de mémoire
Test : ps aux --sort=-%mem | head -5
Résultat attendu : PHP-FPM en tête de liste
Résultat observé : [ce que vous voyez]
Conclusion : Hypothèse confirmée / infirmée

Si une hypothèse est confirmée :

Creusez dans cette direction. Pourquoi ce processus consomme-t-il tant ?

Si toutes les hypothèses sont infirmées :

Retournez à l’étape 2 (collecter plus de données) ou reformulez vos hypothèses.

Étape 7 : Résoudre — Corriger et documenter

Une fois la cause identifiée, corrigez le problème.

Avant de corriger :

Évaluez le risque

Cette action peut-elle aggraver la situation ?
Préparez un rollback

Comment revenir en arrière si ça ne fonctionne pas ?
Prévenez les personnes concernées

Informez l’équipe de ce que vous allez faire.
Documentez ce que vous allez faire

Notez les commandes avant de les exécuter.

Après avoir corrigé :

Vérifiez que le problème est résolu

Reproduisez le scénario initial : le symptôme a-t-il disparu ?
Surveillez la stabilité

Le problème peut revenir. Gardez un œil sur les métriques.
Documentez la résolution

Cause, solution, temps de résolution. Cette documentation servira au prochain incident similaire.
Partagez le retour d’expérience

Informez l’équipe. Redigez un postmortem si l’incident était majeur.

Anti-patterns à éviter

Les erreurs classiques

Voici les pièges dans lesquels tombent même les administrateurs expérimentés :

Redémarrer sans comprendre — Le problème reviendra et vous aurez perdu l’occasion de collecter des données. Diagnostiquez d’abord.
Lancer des commandes au hasard — Perte de temps et risque d’aggravation. Suivez la méthode.
Ne pas lire les logs — La réponse est souvent dedans. journalctl -xe devrait être votre premier réflexe.
Modifier la prod sans backup — Toujours copier un fichier avant de le modifier. Toujours.
Travailler seul trop longtemps — Après 30 min sans progrès, demandez de l’aide. Un regard frais voit ce que vous ratez.
Ne pas documenter — Notez ce que vous faites pendant l’incident. Votre futur vous remerciera.
Supposer sans vérifier — « Je suis sûr que c’est ça » n’est pas un diagnostic. Testez vos hypothèses.
Plusieurs changements à la fois — Impossible de savoir ce qui a marché. Un changement = un test.
Ignorer les warnings — Ils deviennent des erreurs, les erreurs des pannes.
Ne pas faire de postmortem — Vous répéterez les mêmes erreurs. Analysez et documentez.

Anti-pattern vs bonne pratique

Comparaison anti-pattern vs bonne pratique : l'approche hasardeuse mène au stress, l'approche méthodique mène à la résolution

Checklist de dépannage

Checklist rapide (incidents simples)

Symptôme clairement identifié
Logs consultés (journalctl, dmesg)
Ressources vérifiées (CPU, mémoire, disque)
Hypothèse formulée
Solution testée
Problème résolu vérifié
Documentation mise à jour

Checklist complète (incidents majeurs)

À retenir

Pas de panique, méthode d’abord

Respirez. Suivez les étapes dans l’ordre. La précipitation aggrave les problèmes.
Le symptôme n’est pas la cause

« Serveur lent » est un symptôme. La cause est ailleurs (processus fou, disque saturé, etc.). Cherchez la cause racine.
Les logs sont vos amis

90% des réponses sont dans les logs. journalctl et dmesg avant toute autre commande.
Un changement à la fois

Si vous changez trois choses et que ça marche, vous ne savez pas ce qui a résolu le problème.
Documenter tout

Votre moi de 3h du matin vous remerciera d’avoir noté la solution la dernière fois.
Demander de l’aide n’est pas un échec

Après 30 minutes sans progrès, escaladez. Deux paires d’yeux valent mieux qu’une.
Prévenir plutôt que guérir

Le meilleur dépannage est celui qu’on n’a pas à faire. Monitoring, alertes, documentation.

Références externes

USE Method — Brendan Gregg, méthode Utilization-Saturation-Errors pour le diagnostic de performance
Linux Performance — Brendan Gregg, outils et méthodes de performance Linux
Site Reliability Engineering — Google, chapitre sur la gestion des incidents
Red Hat System Administration Guide — Documentation officielle RHEL