Comment dépanner un serveur Linux en production
En résumé : Au 5 septembre 2026, commencez par mesurer la charge, la mémoire, le disque et l’état des services, puis reliez le symptôme aux journaux. Pour un serveur lent, un disque plein ou un service instable, corrigez la cause avant de redémarrer. Si l’incident se répète ou menace les données, faites intervenir un spécialiste plutôt que de multiplier les actions risquées.
Un dépannage efficace repose sur une séquence simple : observer, isoler, corriger, puis surveiller. Cette méthode évite qu’un redémarrage temporairement efficace masque le vrai problème.
Pourquoi commencer par l’état global du serveur ?
Avant de cibler une application, vérifiez si le problème touche l’ensemble de la machine :
uptime
free -h
df -h
df -i
systemctl --faileduptime expose la charge, free -h distingue notamment la mémoire disponible de la mémoire simplement inutilisée, et df affiche l’espace ou les inodes disponibles. La liste des unités en échec révèle ensuite les services déjà signalés par systemd.
Notez l’heure du symptôme, les commandes exécutées et leur résultat. Ces éléments rendent la suite du diagnostic plus fiable, y compris lors d’une intervention externe.
Comment diagnostiquer un serveur Linux lent ?
Commencez par observer les processus et les ressources sans modifier le système :
htop
free -h
df -h
systemctl --failedDans htop, cherchez un processus qui monopolise durablement le processeur ou la mémoire. Dans free, regardez surtout la colonne available. Un stockage saturé ou un service en échec peut aussi ralentir toute la pile applicative.
Ne redémarrez pas immédiatement le processus le plus visible. Vérifiez d’abord ses journaux et ses dépendances : il peut subir le problème plutôt que le provoquer.
Comment traiter un disque plein sans aggraver l’incident ?
Vérifiez d’abord si la saturation concerne les blocs ou les inodes :
df -h
df -i
du -sh /var/*
journalctl --disk-usageRepérez ensuite le répertoire responsable. Les journaux, caches, sauvegardes locales ou fichiers temporaires peuvent grossir, mais leur suppression aveugle peut faire perdre une preuve utile ou perturber un service.
Privilégiez la rotation prévue par le système, déplacez une sauvegarde seulement après vérification et confirmez que l’espace est réellement libéré. Recherchez enfin pourquoi la croissance n’a pas été détectée plus tôt.
Que faire lorsqu’un service tombe régulièrement ?
Inspectez son état et les messages associés. Remplacez nginx.service par l’unité concernée :
systemctl status nginx.service
journalctl -u nginx.service --since todayL’état systemd indique notamment si le service a échoué, tandis que journalctl -u limite la lecture aux entrées de cette unité. Cherchez la première erreur pertinente, puis vérifiez la configuration, les ressources et les dépendances.
Relancez le service uniquement après la correction. S’il retombe, conservez les journaux et comparez les circonstances : charge, déploiement récent, stockage, réseau ou service tiers.
Comment exploiter les journaux sans se perdre ?
Filtrez par période, priorité ou unité plutôt que de parcourir tous les fichiers :
journalctl --since today
journalctl -p err..alert --since today
journalctl -u nginx.service --since today
tail -F /var/log/syslogtail -F suit un fichier par son nom et tente de le rouvrir après une rotation. Sur une distribution sans /var/log/syslog, utilisez le journal systemd ou le fichier propre au service.
Une erreur isolée n’est pas toujours la cause. Reconstituez la chronologie autour du premier symptôme et confrontez-la aux métriques système.
Quand faire appel à un spécialiste Linux ?
Une intervention devient pertinente lorsque :
- le serveur n’est plus accessible ou redémarre sans explication ;
- un service critique échoue de façon récurrente ;
- le stockage se remplit de nouveau après nettoyage ;
- une manipulation peut compromettre les données ou la sécurité ;
- l’équipe ne peut pas isoler la cause sans prendre de risque.
Dans ce cas, limitez les changements, préservez les journaux et transmettez une chronologie précise. Un diagnostic à distance est plus rapide lorsque les symptômes et les actions déjà tentées sont documentés.
Conclusion
Le bon réflexe n’est pas de redémarrer au hasard, mais de mesurer, corréler et corriger. Charge, mémoire, disque, état des services et journaux suffisent souvent à isoler le problème. Pour un incident récurrent ou risqué, une intervention spécialisée protège mieux la disponibilité et les données qu’une succession de correctifs temporaires.
Sources
Questions fréquentes
Que vérifier en premier quand un serveur Linux est lent ?
Vérifiez la charge, la mémoire disponible, l'espace disque et les services en échec avant de redémarrer quoi que ce soit. Corrélez ensuite le symptôme avec les journaux du service concerné.
Que faire quand le disque d'un serveur Linux est plein ?
Contrôlez l'espace par système de fichiers et l'épuisement éventuel des inodes, puis repérez les répertoires volumineux. Ne supprimez pas les journaux au hasard : identifiez la cause et utilisez la politique de rotation prévue.
Pourquoi un service Linux tombe-t-il régulièrement ?
Les journaux et l'état systemd permettent souvent d'identifier une erreur de configuration, une dépendance indisponible ou un manque de ressources. Corrigez la cause avant de relancer le service, puis surveillez sa stabilité.
Quand faut-il faire appel à un spécialiste Linux ?
Demandez une intervention si le serveur devient inaccessible, si les incidents reviennent ou si les données risquent d'être altérées. Évitez alors les suppressions et redémarrages improvisés afin de préserver les éléments de diagnostic.