DevOps

Debug serveur Linux : Commandes essentielles pour diagnostiquer vos problèmes

Les commandes indispensables pour diagnostiquer et résoudre les problèmes sur un serveur Linux. Réseau, processus, disque, logs et services systemd.

05 Feb 2026 6 min de lecture 39 vues
39

Lectures

6

Minutes

0

Partages

Introduction

Diagnostiquer un serveur Linux peut parfois sembler être un véritable défi, surtout lorsque chaque seconde compte et que le système ne répond pas comme prévu. Que vous soyez un administrateur système aguerri, un développeur ou un ingénieur DevOps, avoir un répertoire de commandes de diagnostic à portée de main est essentiel pour identifier rapidement la source d'un problème et le résoudre efficacement. Dans cet article, nous explorerons des commandes essentielles qui vous aideront à diagnostiquer les problèmes de ressources, de réseau, de services et de logs sur vos serveurs Linux.

Diagnostic des ressources système

Surveiller la charge CPU et mémoire

La première étape pour diagnostiquer un problème sur un serveur est de vérifier l'état général du système. Les commandes comme `top` et `htop` sont indispensables pour obtenir une vue d'ensemble des processus en cours et de leur utilisation des ressources.
# Vue en temps réel des processus
top

# Trier par utilisation mémoire
top -o %MEM

# Afficher seulement les 20 premiers processus
top -n 1 -b | head -25
Pour ceux qui préfèrent une interface plus conviviale, `htop` est une excellente alternative à `top`. Il offre une interface colorée avec des raccourcis clavier intuitifs.
# Installation sur Debian/Ubuntu
sudo apt install htop

# Lancer htop
htop

Comprendre la charge système (load average)

Le "load average" est une métrique cruciale qui indique le nombre moyen de processus en attente d'exécution. Les trois valeurs retournées représentent la moyenne sur 1, 5 et 15 minutes.
# Voir le load average
uptime

# Résultat: 14:32:01 up 45 days, load average: 0.52, 0.48, 0.51
Une règle d'or est que si le load average est supérieur au nombre de CPU disponibles, cela peut indiquer une surcharge du système.
# Voir le nombre de CPU
nproc

# ou
cat /proc/cpuinfo | grep processor | wc -l

Surveillance des ressources disque

Utilisation de l'espace disque

L'espace disque est souvent un facteur limitant sur les serveurs. Utilisez `df` pour surveiller l'utilisation de l'espace disque.
# Afficher l'utilisation du disque en format lisible
df -h

Identifier les fichiers volumineux

Pour libérer de l'espace disque, vous devez souvent identifier les fichiers les plus volumineux. La commande `du` est votre alliée dans ce cas.
# Lister les 10 plus gros fichiers dans le répertoire courant
du -ah . | sort -rh | head -n 10

Diagnostic des problèmes réseau

Vérification de la connectivité réseau

La connectivité réseau est souvent au cœur des problèmes de serveur. Utilisez `ping` pour tester la connectivité à d'autres hôtes.
# Tester la connectivité à google.com
ping -c 4 google.com

Analyse des connexions réseau

Pour un diagnostic plus approfondi des connexions réseau, `netstat` et `ss` sont des outils puissants.
# Afficher toutes les connexions réseau actives
netstat -tuln

# Utiliser ss pour une alternative plus rapide
ss -tuln

Surveillance des services et des démons

Vérifier l'état des services

Sur les systèmes modernes, `systemctl` est l'outil de choix pour gérer et diagnostiquer les services.
# Vérifier l'état d'un service, par exemple nginx
systemctl status nginx

Redémarrer un service

Redémarrer un service est souvent la première étape pour résoudre un problème de service.
# Redémarrer le service nginx
sudo systemctl restart nginx

Analyse des logs système

Exploration des logs avec journalctl

`journalctl` est un outil puissant pour explorer les logs système sous Linux. Il vous permet de filtrer et de rechercher des événements spécifiques.
# Voir les logs récents
journalctl -xe

# Filtrer par service, par exemple nginx
journalctl -u nginx

Compréhension du format des logs

La compréhension du format des logs est essentielle pour diagnostiquer les problèmes. Les logs sont généralement formatés avec des informations sur la date, l'heure, le service et le message.
Date Service Message
2023-10-15 14:32:01 nginx Error 404: Page not found
2023-10-15 14:33:45 sshd Accepted password for user from 192.168.1.1

Bonnes pratiques de debugging

Documenter les problèmes et solutions

Documenter chaque problème rencontré et la solution appliquée est une pratique courante et recommandée. Cela vous permet de construire une base de connaissances qui peut être précieuse lors de futures pannes.

Conseil pro : Utilisez un système de gestion de version ou un outil de documentation pour garder une trace de vos diagnostics et solutions.

Mettre en place des alertes et des moniteurs

Mettre en place des solutions de monitoring telles que Nagios, Zabbix ou Prometheus peut aider à détecter les problèmes avant qu'ils ne deviennent critiques.

Conclusion

La maintenance d'un serveur Linux nécessite une compréhension approfondie des outils de diagnostic disponibles. En maîtrisant les commandes essentielles abordées dans cet article, vous serez en mesure de diagnostiquer efficacement les problèmes liés aux ressources système, au réseau, aux services et aux logs. N'oubliez pas que la clé d'un bon diagnostic est la documentation et la mise en place de systèmes de surveillance proactive pour anticiper les problèmes. En suivant ces pratiques, vous serez mieux préparé pour assurer le bon fonctionnement de vos serveurs Linux.

Analyser les logs système en profondeur

Les logs sont la première source d'information lors d'un incident. Linux centralise les logs dans /var/log/ et via le service systemd journal. Savoir les lire efficacement est une compétence fondamentale pour tout développeur ou administrateur.

Les logs les plus importants

# Logs système généraux
sudo tail -f /var/log/syslog

# Logs d'authentification SSH
sudo tail -f /var/log/auth.log

# Logs du kernel
sudo dmesg | tail -50

# Logs d'une application systemd spécifique
sudo journalctl -u nginx -f --since "1 hour ago"

# Filtrer par priorité (err, warning, crit)
sudo journalctl -p err -n 50

Rechercher des erreurs dans les logs

# Compter les erreurs 500 dans les logs Nginx
grep " 500 " /var/log/nginx/access.log | wc -l

# Voir les 20 dernières erreurs PHP-FPM
sudo grep "PHP Fatal" /var/log/php8.2-fpm.log | tail -20

# Analyser les tentatives de connexion SSH échouées
sudo grep "Failed password" /var/log/auth.log | tail -20

Diagnostiquer les problèmes réseau

Un problème applicatif est souvent en réalité un problème réseau. Ces commandes permettent de diagnostiquer la connectivité et les ports ouverts :

# Vérifier les ports en écoute
sudo ss -tlnp

# Tester la connexion à un port spécifique
telnet localhost 3306

# Vérifier la résolution DNS
nslookup jordaneyeno.site
dig jordaneyeno.site

# Tester la latence et la perte de paquets
mtr --report jordaneyeno.site

# Vérifier les routes réseau
ip route show

Conseil pro : Quand un service refuse de démarrer, commencez toujours par sudo journalctl -u nom-du-service -n 100 --no-pager. Cette commande affiche les 100 dernières lignes de log du service et révèle presque toujours la cause exacte du problème.

Gérer les processus et les ressources système

CommandeUtilitéAlternative
htopVue interactive CPU/RAM/processustop
df -hEspace disque par partitiondu -sh /*
free -hUtilisation de la RAM et swapvmstat
ss -tlnpPorts TCP en écoutenetstat -tlnp
iostat -x 1Performance disque en temps réeliotop
strace -p PIDAppels système d'un processusltrace

Script de diagnostic rapide

Voici un script de diagnostic à lancer en premier lors d'un incident :

#!/bin/bash
echo "=== DIAGNOSTIC SERVEUR $(date) ==="
echo ""
echo "--- CPU et mémoire ---"
free -h
echo ""
echo "--- Espace disque ---"
df -h /
echo ""
echo "--- Services critiques ---"
for service in nginx php8.2-fpm mysql; do
  status=$(systemctl is-active $service 2>/dev/null || echo "non installé")
  echo "$service: $status"
done
echo ""
echo "--- Dernières erreurs syslog ---"
sudo grep -i "error\|critical\|failed" /var/log/syslog | tail -10

Mettre en place une surveillance proactive

Plutôt que de déboguer manuellement après un incident, une surveillance automatisée vous alerte avant que les problèmes deviennent critiques.

#!/bin/bash
# /home/ubuntu/monitor.sh - Surveillance serveur

DISK_THRESHOLD=85
RAM_THRESHOLD=90

# Vérifier l'espace disque
DISK_USAGE=$(df / | awk "END{print int($5)}")
if [ $DISK_USAGE -gt $DISK_THRESHOLD ]; then
    echo "ALERTE: Disque à ${DISK_USAGE}%" | logger -t monitor
    # Ajouter envoi email ou notification Slack ici
fi

# Vérifier la RAM disponible
RAM_USAGE=$(free | awk "/^Mem:/{printf int($3/$2*100)}")
if [ $RAM_USAGE -gt $RAM_THRESHOLD ]; then
    echo "ALERTE: RAM à ${RAM_USAGE}%" | logger -t monitor
fi

# Vérifier et relancer les services critiques
for service in nginx php8.2-fpm; do
    if ! systemctl is-active --quiet $service; then
        systemctl restart $service
        echo "Relancé: $service" | logger -t monitor
    fi
done
# Planifier toutes les 5 minutes avec cron
crontab -e
# Ajouter cette ligne :
*/5 * * * * /home/ubuntu/monitor.sh

Analyser les tendances avec les logs système

# Compter les erreurs 500 par heure dans les logs Nginx
awk '{print $4}' /var/log/nginx/access.log   | cut -d: -f1-2   | sort | uniq -c   | sort -rn | head -20

# Identifier les URLs générant le plus d'erreurs
grep " 500 " /var/log/nginx/access.log   | awk '{print $7}'   | sort | uniq -c | sort -rn | head -10

Tags

SSH Linux Debug Systemd Serveur Logs

Partagez cet article

Twitter Facebook LinkedIn
JY
Jordane YENO

Developpeur Full Stack passionne par le web et les nouvelles technologies

En savoir plus

Articles similaires