Serveur dans le rouge : la méthode de diagnostic en 4 étapes

Votre serveur rame, l’application ne répond plus, mais la mémoire RAM semble pourtant disponible ? Ne paniquez pas et n’appuyez pas tout de suite sur le bouton de redémarrage. Voici la méthode de diagnostic rapide que j’utilise pour identifier le coupable en moins de 2 minutes.

Récemment, j’ai fait face à un cas d’école : une base de données surchargée qui plante, entraînant une réaction en chaîne. Un service d’API a perdu la connexion, a tenté de se reconnecter en boucle, créant plus de 6 400 processus « zombies ». Résultat : un processeur étouffé, un serveur paralysé, mais une RAM presque vide.

Pour éviter de chercher une aiguille dans une botte de foin, voici la routine de diagnostic systématique à suivre.

Étape 1 : Prendre les constantes vitales avec top (ou htop)

C’est le stéthoscope du sysadmin.

• La commande : top ou htop
• Ce qu’on cherche :
  • Le Load Average : s’il dépasse largement le nombre de cœurs CPU, la machine sature.
  • Les Zombies : s’ils s’accumulent (comme mes 6 400 fantômes), un processus parent est figé et bloque le système.

Étape 2 : Vérifier l’espace disque avec df

Un disque saturé à 100 % empêche l’écriture des logs et des bases de données, provoquant des crashs instantanés.

• La commande : df -h
• Ce qu’on cherche : Vérifier qu’aucune partition (surtout / ou celle de vos données Docker) n’affiche 100 % d’utilisation.

Étape 3 : Inspecter la couche Docker (si vous utilisez docker)

Si vos applications tournent dans des conteneurs, il faut isoler le fautif.

• Les commandes :
  • docker ps : pour repérer un conteneur qui redémarre en boucle (Restarting…).
  • docker stats : pour voir en temps réel quel conteneur consomme anormalement les ressources.

Étape 4 : Lire le verdict dans les logs

Une fois le conteneur ou le service suspect identifié, on cherche l’explication logique du crash.

• La commande : docker logs –tail 100 <nom_du_conteneur>
• Ce qu’on cherche : Les erreurs de connexion, les dépassements de mémoire (OOM) ou les requêtes SQL trop lourdes qui s’accumulent.

Retenue de cette expérience : Le redémarrage brutal (reboot) résout souvent le problème temporairement, mais comprendre la cascade d’événements (Requête lourde ➡️ Crash DB ➡️ Boucle de reconnexion ➡️ Processus zombies) permet de corriger le problème à la racine.