Comment surveiller les performances d'un serveur Linux : commandes, métriques et outils

Pour surveiller les performances d'un serveur Linux, vérifiez quatre ressources : CPU, mémoire, E/S disque et réseau. Utilisez les commandes intégrées comme top, vmstat, free, iostat et ss pour le dépannage en direct, et un outil à agent comme Prometheus avec node_exporter, Zabbix ou l'agent CloudWatch pour conserver l'historique et envoyer des alertes.

Points clés

• Pour chaque ressource, vérifiez l'utilisation, la saturation et les erreurs (méthode USE). Une utilisation élevée ne pose pas de problème en soi ; ce sont les files d'attente et les erreurs qui en posent.
• Comparez la charge moyenne (load average) au nombre de cœurs CPU et surveillez %wa (attente d'E/S) et %st (steal time) sur les machines virtuelles cloud.
• Pour la mémoire, lisez la colonne available de free, pas free. Linux utilise volontairement la mémoire inutilisée comme cache.
• Les informations de pression (pressure stall information) dans /proc/pressure/ indiquent directement combien de temps les tâches attendent le CPU, la mémoire ou les E/S.
• Les commandes montrent le présent. Pour les tendances et les alertes, il faut un agent de supervision et une base de séries temporelles.

Quelles métriques de performance Linux comptent ?

Commencez par la méthode USE de l'ingénieur performance Brendan Gregg : pour chaque ressource, vérifiez l'utilisation, la saturation et les erreurs. Elle vous donne une liste de contrôle au lieu de tâtonnements.

Comment vérifier l'utilisation du CPU et la charge sous Linux ?

Lancez top (ou htop) et lisez la ligne CPU, puis comparez la charge moyenne au nombre de cœurs donné par nproc.

top # vue en direct ; appuyez sur 1 pour afficher chaque cœur
nproc # nombre de cœurs CPU
uptime # charge moyenne sur 1, 5 et 15 minutes
mpstat -P ALL 1 # utilisation par cœur chaque seconde (paquet sysstat)

Selon la page de manuel proc_loadavg, la charge moyenne compte les tâches en cours d'exécution ou en attente d'E/S disque, moyennées sur 1, 5 et 15 minutes. Une charge de 6 sur un serveur à 8 cœurs est normale. Une charge de 6 sur un serveur à 2 cœurs signifie que du travail s'accumule en file d'attente. Comme la charge inclut les processus qui attendent le disque, une charge élevée avec une faible utilisation du CPU indique généralement un problème de stockage.

Dans la ligne CPU de top, deux champs comptent sur les serveurs cloud :

• wa : temps pendant lequel le CPU est resté inactif en attendant des E/S. Des valeurs élevées durables indiquent des disques lents ou un stockage réseau lent.
• st : d'après la page de manuel de top, le « temps volé à cette VM par l'hyperviseur ». Un steal durable sur une machine virtuelle cloud signifie que l'hôte est chargé ou qu'une instance à performances variables a épuisé ses crédits CPU.

Comment vérifier l'utilisation de la mémoire sous Linux ?

Lancez free -h et lisez la colonne available. La page de manuel de free la définit comme une estimation de la mémoire disponible pour de nouvelles applications sans recourir au swap, en tenant compte du cache de pages.

free -h # résumé de la mémoire lisible
vmstat 1 5 # les colonnes si/so indiquent le swap entrant/sortant par seconde
journalctl -k | grep -i "out of memory" # événements de l'OOM killer

Un serveur avec peu de mémoire « free » mais beaucoup de mémoire « available » est en bonne santé : Linux remplit la RAM inutilisée avec du cache disque et la libère quand les programmes en ont besoin. Les signes d'alerte sont une mémoire available qui baisse sur plusieurs jours (fuite possible), une activité de swap constante dans vmstat et des entrées de l'OOM killer dans le journal du noyau.

Comment vérifier les performances et l'espace disque ?

Utilisez iostat -xz 1 pour les performances d'E/S, et df pour l'espace et les inodes.

iostat -xz 1 # utilisation, file d'attente et latence par périphérique (sysstat)
df -h # espace disque par système de fichiers
df -i # utilisation des inodes : de nombreux petits fichiers peuvent les saturer en premier
du -sh /var/log/* | sort -h # trouver ce qui occupe de l'espace

Dans iostat, surveillez r_await et w_await (millisecondes moyennes par requête) et aqu-sz (longueur de la file). La page de manuel d'iostat précise que, pour les périphériques qui traitent des requêtes en parallèle, comme les grappes RAID et les SSD modernes, %util ne reflète pas leurs limites de performance. L'augmentation de la latence et de la longueur de la file sont de meilleurs signes de saturation.

Comment surveiller les performances réseau ?

sar -n DEV 1 # débit par interface
sar -n TCP,ETCP 1 # connexions TCP et retransmissions
ss -s # résumé des sockets
ip -s link # erreurs et pertes par interface

Des retransmissions, des pertes ou des erreurs d'interface en hausse révèlent des problèmes réseau même quand le débit paraît normal. Sur les machines virtuelles cloud, comparez le débit à la limite réseau du type d'instance.

Qu'est-ce que la pressure stall information (PSI) ?

La PSI est une fonction du noyau qui indique combien de temps les tâches passent à attendre le CPU, la mémoire ou les E/S. La documentation du noyau explique que chaque fichier de /proc/pressure/ contient une ligne « some » (part du temps pendant laquelle au moins certaines tâches sont bloquées) et, pour la mémoire et les E/S, une ligne « full » (toutes les tâches non inactives bloquées en même temps, ce que le noyau décrit comme du thrashing).

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

La PSI répond directement à la question « cette ressource ralentit-elle le travail ? », ce qui en fait un bon signal d'alerte. Si les fichiers n'existent pas, votre noyau a été compilé ou démarré sans prise en charge de la PSI.

Quels outils utiliser pour la supervision continue ?

Les commandes montrent ce qui se passe maintenant. Pour détecter les problèmes la nuit, voir les tendances et alerter la bonne personne, installez un agent de supervision qui envoie les métriques vers une base de séries temporelles.

Quelles alertes définir en premier ?

1. Espace disque et inodes au-dessus de 80–85 % sur n'importe quel système de fichiers, avec une alerte prévisionnelle « plein dans 24 heures ».
2. Mémoire disponible basse pendant plus de 10 minutes, ou tout événement de l'OOM killer.
3. Charge moyenne supérieure au nombre de cœurs pendant plus de 15 minutes, ou pression CPU en hausse.
4. Latence disque ou pression d'E/S nettement supérieure à la référence normale du serveur.
5. Contrôles de service : le port de l'application répond et une URL de santé renvoie un succès.
6. Sauvegardes et expiration des certificats, qui échouent en silence.

Ces seuils sont des points de départ. Ajustez-les au comportement normal de chaque serveur pour que les alertes restent exploitables. Notre guide sur la supervision des performances des serveurs couvre Windows et les bonnes pratiques générales, et la supervision de l'infrastructure cloud traite des services managés au-delà du serveur.

Comment Opsio vous aide

Opsio supervise et exploite des serveurs Linux sur AWS, Azure et on-premise dans le cadre de ses services informatiques managés, avec réponse aux alertes 24h/24 et 7j/7, application des correctifs et revues de capacité, grâce à Prometheus et Grafana ou à des outils natifs du cloud. Par exemple, la plateforme AWS que nous avons construite pour WorkBuster repose sur des instances EC2 dans un groupe de mise à l'échelle automatique, avec des tableaux de bord et des alarmes CloudWatch pour l'exploitation quotidienne.

Questions fréquentes

Quelle est la meilleure commande pour vérifier les performances d'un serveur Linux ?

Commencez par top pour une vue d'ensemble en direct, puis vmstat 1 pour les tendances CPU, mémoire et swap, et iostat -xz 1 pour les disques. Ensemble, elles révèlent la plupart des goulots d'étranglement en une minute.

Quelle charge moyenne est correcte pour un serveur Linux ?

Cela dépend du nombre de cœurs CPU. Une charge moyenne inférieure ou égale au nombre de cœurs signifie généralement l'absence de file d'attente. Une charge durablement supérieure au nombre de cœurs signifie que des tâches attendent le CPU ou le disque.

Pourquoi Linux affiche-t-il presque aucune mémoire libre ?

Linux utilise la RAM inutilisée comme cache disque et la restitue quand les applications en ont besoin. Consultez plutôt la colonne available de free -h : c'est la mémoire réellement disponible pour de nouveaux traitements.

Comment voir quel processus utilise le plus de CPU ou de mémoire ?

Dans top, appuyez sur P pour trier par CPU et sur M pour trier par mémoire. Depuis un script, utilisez ps aux --sort=-%cpu | head ou ps aux --sort=-%mem | head.

Comment surveiller un serveur Linux à distance ?

Installez un agent tel que node_exporter, l'agent Zabbix ou l'agent CloudWatch, et envoyez les métriques vers un serveur central ou un service cloud. Vous obtenez ainsi historique, tableaux de bord et alertes sans vous connecter à chaque machine.