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.

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.

Pour aller plus loin

Consultez le guide Gestion des processus pour maîtriser top, htop, ps et la gestion des processus. Pour comprendre pourquoi un processus existe (sa chaîne d'ancêtres), au-delà de ce que montrent ps et lsof, l'outil witr remonte jusqu'au service ou au conteneur responsable.

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.

Pour aller plus loin

Consultez le guide Gestion de la mémoire pour comprendre free, vmstat et le fonctionnement de la mémoire sous Linux.

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é.

Le cache n'est pas un problème

Sur Linux, la mémoire « used » inclut le cache disque. C'est normal : Linux utilise la RAM libre pour accélérer les accès disque.

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.

Pour aller plus loin

Consultez les guides Gérer l'espace disque et Gestion des logs avec logrotate pour prévenir ces problèmes.

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 ».

Pour aller plus loin

Consultez les guides Gestion du réseau et Comprendre le réseau Linux pour maîtriser les commandes réseau.

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   # ancien équivalent, absent des installations récentes

# 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

Le schéma ci-dessous se lit de gauche à droite, mais retenez surtout les boucles de retour : si l'étape 6 (Tester) infirme toutes vos hypothèses, vous ne continuez pas vers la résolution, vous revenez collecter des données. De même, un problème non reproductible à l'étape 3 ne vous bloque pas, il vous fait préparer l'instrumentation pour la prochaine occurrence. Les quatre premières étapes sont du diagnostic et ne modifient rien sur le serveur ; seule la dernière touche à la production.

É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. »

Ne faites rien sans comprendre le symptôme

Résister à la tentation de « regarder vite fait » avant d'avoir bien compris le problème. Chaque minute passée à clarifier le symptôme en économise dix en diagnostic.

É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 :

1. Identifier les conditions

   Quand le problème se produit-il ? Sous quelle charge ? Avec quelles données ?

2. Créer un cas de test minimal

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

3. 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 » :

1. (Probable) Un processus consomme trop de ressources
2. (Probable) La base de données est lente
3. (Possible) Le disque est saturé en I/O
4. (Possible) Le réseau est congestionné
5. (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 :

1. Évaluez le risque

   Cette action peut-elle aggraver la situation ?

2. Préparez un rollback

   Comment revenir en arrière si ça ne fonctionne pas ?

3. Prévenez les personnes concernées

   Informez l'équipe de ce que vous allez faire.

4. Documentez ce que vous allez faire

   Notez les commandes avant de les exécuter.

Après avoir corrigé :

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

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

2. Surveillez la stabilité

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

3. Documentez la résolution

   Cause, solution, temps de résolution. Cette documentation servira au prochain incident similaire.

4. Partagez le retour d'expérience

   Informez l'équipe. Rédigez 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 sauvegarde : toujours copier un fichier avant de le modifier. Toujours.
• Travailler seul trop longtemps : après 30 minutes 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 avertissements : ils deviennent des erreurs, et 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

Ce schéma oppose deux trajectoires à partir du même incident. Ce qui les sépare n'est pas la compétence technique mais le moment où l'administrateur touche au serveur : sur la branche hasardeuse, la première action modifie l'état avant tout diagnostic, et détruit au passage les traces qui auraient permis de comprendre. Sur la branche méthodique, la première action est une lecture. Une seule règle résume les deux : tant que vous n'avez pas de cause, vous observez, vous ne corrigez pas.

Checklist de dépannage

Deux checklists, deux usages. La première se déroule pendant l'incident, sans quitter le terminal ; la seconde encadre un incident qui engage plusieurs personnes et devra être justifié après coup. Choisissez selon la question « devrai-je rendre des comptes sur cet incident ? ».

Checklist rapide (incidents simples)

Sept points à parcourir de haut en bas sur un incident isolé, service unique, sans impact client majeur. Le point qui saute le plus souvent est le dernier, la documentation : personne ne la fait quand le service est reparti. C'est pourtant lui qui transforme un dépannage réussi en procédure réutilisable.

• 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)

Sur un incident majeur, la moitié des points ci-dessous ne concernent pas la technique mais la communication et la traçabilité. Deux d'entre eux se préparent obligatoirement avant de toucher au système, pas après : la sauvegarde et le rollback. Et la chronologie se construit au fil de l'eau, la reconstituer de mémoire deux jours plus tard donne un postmortem faux.

• Symptôme documenté avec horodatage
• Personnes affectées identifiées
• Communication envoyée (« incident en cours »)
• Logs collectés et sauvegardés
• Métriques historiques analysées
• Chronologie établie (quand ça a commencé, quoi changé)
• Hypothèses listées et priorisées
• Chaque test documenté (commande, résultat)
• Backup fait avant modification
• Rollback préparé
• Solution appliquée
• Vérification post-résolution
• Communication de fin d'incident
• Postmortem planifié
• Mesures préventives identifiées

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

1. Pas de panique, méthode d'abord

   Respirez. Suivez les étapes dans l'ordre. La précipitation aggrave les problèmes.

2. 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.

3. Les logs sont vos amis

   Une grande partie des incidents laisse une trace explicite dans les journaux. journalctl et dmesg avant toute autre commande.

4. 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.

5. Documenter tout

   Votre moi de 3h du matin vous remerciera d'avoir noté la solution la dernière fois.

6. 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.

7. Prévenir plutôt que guérir

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

Pour aller plus loin

• Un service actif qui ne répond pas : Le cas où systemd affiche active (running) alors que plus aucune requête n'aboutit.
• Retrouver l'accès SSH : La même méthode appliquée à un refus de connexion, jusqu'au piège SELinux du port non standard.
• Un système de fichiers en lecture seule : Reconnaître un remontage en lecture seule décidé par le noyau et remonter à la panne disque.
• Un serveur bloqué au démarrage : Le déroulé de diagnostic quand la machine n'atteint plus le mode multi-utilisateur.

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

×

📖 Voir la documentation →