Il y a un moment, en prod, où ton cerveau passe en mode tunnel. Les alertes. Le téléphone. Le client qui dit « ça rame ». Et toi, devant un shell, à essayer de rester calme.
Je garde une liste de commandes simples, pas forcément sexy, mais qui sortent des situations très concrètes. Pas des « astuces de blog », plutôt les trucs que tu tapes à 3 h 12 du matin, quand tu as besoin d’un signal clair.
Dans cet article, je te partage 25 commandes Linux que j’utilise en incident. Avec du contexte, des exemples, et quelques pièges. Et si tu veux d’autres checklists du même genre, j’en publie régulièrement sur Le Blog Tech Pro de Samyn-Antoy ABASSE : https://monblog-sa-abasse.blogspot.com/ (c’est un peu mon carnet de terrain).
1) voir la charge globale (le réflexe top)
bash top
Tu regardes vite : load average, %CPU, mémoire, swap, et surtout quel process est en haut.
Astuce : dans top, tape P pour trier par CPU, M pour mémoire.
2) top mais lisible et interactif (souvent mieux)
bash htop
Si dispo, c’est plus clair. Tu peux tuer un process, trier, voir les threads, etc. En incident, ça fait gagner du temps.
3) comprendre la charge (load average) sans paniquer
bash uptime
Le load average ne veut pas dire « CPU à 100 % ». Ça peut être de l’I/O wait. Donc on corrèle ensuite avec iostat, vmstat, etc.
4) voir les logs en live (et arrêter de scroller)
bash tail -f /var/log/syslog
Ou sur systemd :
bash journalctl -f
En pratique, tu ajoutes un filtre :
bash journalctl -f -u nginx
5) remonter dans le temps sur un service systemd
bash journalctl -u nginx --since "1 hour ago"
Tu peux aussi viser l’heure exacte. Très utile quand tu as l’heure de l’alerte.
6) lister les services en échec
bash systemctl --failed
Simple. Efficace. Ça donne souvent la première piste.
7) status complet d’un service (avec les dernières lignes de log)
bash systemctl status nginx
Tu vois l’état, le PID, la commande de lancement, parfois une erreur explicite.
8) redémarrer proprement un service (oui, parfois ça suffit)
bash systemctl restart nginx
Mais en prod, je fais souvent :
bash systemctl reload nginx
Si c’est juste une conf à recharger. Moins violent.
9) vérifier l’espace disque (la panne classique)
bash df -h
Cherche un filesystem à 100 %. Ensuite :
bash du -sh /var/* 2>/dev/null | sort -h
Le 2>/dev/null évite de se faire polluer par les permissions.
10) trouver les plus gros fichiers vite
bash find /var -type f -size +500M -print0 | xargs -0 ls -lh
Quand /var/log part en vrille, tu le vois tout de suite.
11) vérifier la mémoire, swap, et le « vrai » disponible
bash free -h
Le point clé : la colonne available.
Si la swap est pleine et la RAM aussi, tu regardes quels process gonflent.
12) voir la pression système (CPU, mémoire, I/O) en une commande
bash vmstat 1
Tu laisses tourner 10 secondes.
Regarde wa (I/O wait), si/so (swap in/out). Si tu swaps fort, c’est rarement bon signe.
13) diagnostiquer l’I/O disque (goulot d’étranglement fréquent)
bash iostat -xz 1
Il faut le paquet sysstat.
Tu regardes await, %util. Si %util est proche de 100 % et await monte, ton disque est saturé.
14) voir l’utilisation disque par process (quand iostat crie)
bash iotop -oPa
Tu repères le coupable. Souvent un backup, une rotation de logs mal réglée, un process qui écrit en boucle.
15) voir les processus les plus gourmands en CPU
bash ps aux --sort=-%cpu | head
Et pour la mémoire :
bash ps aux --sort=-%mem | head
Simple tri. Ça marche même quand tu n’as pas htop.
16) voir l’arbre des processus (pour comprendre qui lance quoi)
bash pstree -aps
Tu vois la hiérarchie. Pratique quand un service spawn 200 workers.
17) repérer un port occupé (et quel process écoute)
bash ss -lntp
Tu cherches :80, :443, :5432, etc.
Exemple :
bash ss -lntp | grep ":443"
18) voir les connexions actives (et un début de DDoS ou de fuite)
bash ss -antp
Tu peux résumer par IP :
bash ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
Tu repères vite une IP qui ouvre 10 000 connexions.
19) tester un endpoint HTTP sans navigateur
bash curl -i http://127.0.0.1/
Pour voir les headers, codes, redirections.
Avec timing (super utile pour prouver que « c’est lent ») :
bash curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com/
20) vérifier un DNS rapidement (et éviter les suppositions)
bash dig +short example.com
Ou :
bash resolvectl query example.com
Quand l’incident vient d’un changement DNS pas propagé, ça évite les débats.
21) tracer le chemin réseau (quand ça part au mauvais endroit)
bash traceroute example.com
Sur certains environnements, mtr est encore mieux :
bash mtr -rw example.com
22) voir les sockets et ports avec l’ancien réflexe (parfois nécessaire)
bash netstat -tulpn
Oui c’est legacy, mais sur certaines machines, tu l’as, et tu n’as pas ss. On fait avec.
23) regarder les limites et la santé du filesystem (quand tu suspectes du bizarre)
bash dmesg -T | tail -n 80
Tu cherches des erreurs disque, des timeouts, du « EXT4-fs error », du « I/O error ».
En prod, un dmesg peut te sauver 30 minutes de fausses pistes.
24) vérifier les fichiers ouverts (quand « disk full » alors que df dit non)
bash lsof | grep deleted | head
Cas classique : un gros fichier log supprimé, mais encore ouvert par un process. L’espace n’est pas libéré tant que le process ne relâche pas le handle. Solution typique : restart du service concerné, ou rotation correcte.
25) vérifier une conf avant reload (le petit geste qui évite la catastrophe)
Pour Nginx :
bash nginx -t
Pour Apache :
bash apachectl configtest
Pour HAProxy :
bash haproxy -c -f /etc/haproxy/haproxy.cfg
Ça prend 2 secondes. Et ça évite le reload qui met tout down.
mini check de survie (quand tu as 2 minutes)
Je fais souvent ça, dans cet ordre, sans réfléchir :
uptimetopouhtopdf -hfree -hjournalctl -foujournalctl -u service --since "30 min ago"ss -lntppuisss -ant | headvmstat 1et si besoiniostat -xz 1
Et seulement après, je commence à « réparer ». Parce que si tu modifies trop tôt, tu perds le contexte. Et après tu racontes une histoire au post mortem, mais elle est fausse. Ça arrive.
notes rapides, un peu en vrac
Ne tue pas un process au hasard juste parce qu’il est en haut de top. Regarde ce que c’est, qui l’a lancé, et si c’est un symptôme.
Pareil pour la RAM. Linux utilise la mémoire pour cache, et c’est normal. Ce qui est moins normal, c’est swapper en continu avec une latence applicative qui explose.
Et pense aux limites : ulimit -n (fichiers ouverts) peut faire tomber un service en silence. Je ne l’ai pas mis dans le top 25, mais en incident web, ça vaut le coup d’œil.
pour aller plus loin
Je publie d’autres articles pratiques autour de Linux, l’admin, la productivité et aussi des sujets plus « business en ligne » sur Le Blog Tech Pro de Samyn-Antoy ABASSE : https://monblog-sa-abasse.blogspot.com/
Si tu veux, tu peux le garder en favori. J’ajoute des checklists, des retours d’expérience, et des scripts que j’utilise vraiment.
Et si tu as un type d’incident précis (CPU haut, latence DB, saturation disque, fuite de sockets), dis moi lequel. Je peux faire une version « playbook » plus guidée, étape par étape.
Questions fréquemment posées
Quels sont les outils Linux essentiels pour surveiller la charge système en production ?
Pour surveiller la charge système en production, les commandes essentielles sont 'top' pour voir rapidement le load average, l'utilisation CPU, mémoire et swap ainsi que les processus actifs ; 'htop' pour une interface plus lisible et interactive ; et 'uptime' pour comprendre la charge sans paniquer. Ces outils permettent une analyse rapide et efficace en situation d'incident.
Comment analyser les logs système en temps réel sous Linux ?
Pour analyser les logs système en temps réel, utilisez 'tail -f /var/log/syslog' pour suivre un fichier de log classique. Sur les systèmes utilisant systemd, la commande 'journalctl -f' permet de suivre les journaux en direct. Vous pouvez également filtrer par service avec 'journalctl -f -u nom_du_service', ce qui est très utile pour cibler un service spécifique lors d'un incident.
Quelle commande permet de vérifier rapidement l'état des services systemd en échec ?
La commande 'systemctl --failed' liste tous les services systemd actuellement en échec. C'est une vérification simple et efficace qui donne souvent la première piste lors du diagnostic d'incidents liés aux services.
Comment identifier rapidement les fichiers volumineux qui peuvent saturer l'espace disque ?
Pour trouver rapidement les gros fichiers, vous pouvez utiliser la commande : 'find /var -type f -size +500M -print0 | xargs -0 ls -lh'. Cette commande recherche dans /var tous les fichiers de plus de 500 Mo et affiche leurs tailles. Cela permet de détecter facilement des fichiers volumineux qui peuvent saturer le disque, notamment dans /var/log.
Quels indicateurs surveiller pour diagnostiquer un problème d'I/O disque sous Linux ?
Pour diagnostiquer un problème d'I/O disque, utilisez 'iostat -xz 1' (nécessite le paquet sysstat). Surveillez particulièrement la colonne '%util' qui indique l'utilisation du disque (proche de 100% signifie saturation) et 'await' qui représente le temps moyen d'attente des opérations I/O. Une augmentation de ces valeurs signale un goulot d'étranglement sur le disque.
Comment vérifier l'utilisation mémoire réelle et la pression sur le système ?
La commande 'free -h' affiche la mémoire utilisée, libre, swap et surtout la colonne 'available' qui indique la mémoire réellement disponible pour les applications. Pour évaluer la pression système globale (CPU, mémoire, I/O), 'vmstat 1' fournit une vue dynamique avec des indicateurs comme 'wa' (I/O wait) ou 'si/so' (swap in/out). Une forte utilisation de swap combinée à peu de mémoire disponible est souvent un signe critique.
0 Commentaires