Chapitre 14.2 — Métriques système

⏱️ TL;DR — Les logs disent ce qui s’est passé ; les métriques disent comment se porte la machine, maintenant. CPU saturé ? RAM pleine ? Disque au bord de l’explosion ? Disque qui rame en I/O ? Ce chapitre te donne la trousse à outils du diagnostic instantané : htop/top (CPU, mémoire, load average), free -h (RAM et swap), df -h (remplissage du disque), du/ncdu (qui remplit le disque), vmstat et iostat (I/O), uptime (charge), ss (connexions réseau). L’objectif n’est pas de connaître dix commandes par cœur, mais de savoir, face à un symptôme, quelle ressource est en cause — CPU, RAM, I/O ou réseau — et de la nommer. On ne règle bien que ce qu’on a d’abord mesuré.

🎯 Objectifs

• Lire le CPU, la mémoire et le load average avec htop/top, et interpréter le load selon le nombre de cœurs.
• Mesurer la RAM et le swap (free -h), le remplissage disque (df -h) et trouver qui remplit (du, ncdu).
• Approcher les I/O disque et le réseau (vmstat, iostat, ss, uptime).
• Identifier le goulot : distinguer un problème de CPU, de RAM, d’I/O ou de réseau.
• Distinguer la mesure ponctuelle de la surveillance continue (chapitre suivant).

CPU, mémoire, load : htop et top

top est présent partout ; htop est sa version confortable (couleurs, barres, navigation, F9 pour tuer un process). C’est ton tableau de bord vivant : la première commande que tu lances quand « le serveur est lent ».

htop        # tableau de bord interactif (installe-le : apt install htop)
top         # la version toujours presente, si htop manque

En haut de htop, tu lis trois choses capitales :

• Les barres CPU (une par cœur) : le pourcentage d’occupation. Toutes au rouge en continu → le CPU est le goulot.
• La barre mémoire : la RAM utilisée vs disponible, et juste en dessous la barre swap (RAM débordée sur le disque).
• Le load average : trois nombres (charge sur 1, 5 et 15 minutes) qu’il faut savoir lire.

Lire le load average

Le load average mesure le nombre moyen de processus qui veulent du CPU (en cours d’exécution ou en attente). Le chiffre seul ne veut rien dire : il se lit par rapport au nombre de cœurs.

Règle simple : load ÷ nombre de cœurs. À 1.0 par cœur, le CPU est pleinement utilisé sans file d’attente. En dessous, il reste de la marge. Au-dessus, des processus attendent leur tour.

💡 Réflexe — Avant de paniquer sur un load « élevé », compte tes cœurs : nproc te les donne. Un load de 4.0 est une catastrophe sur 1 cœur et un dimanche tranquille sur 8 cœurs. Et regarde les trois chiffres : si le load à 1 min est bien plus haut qu’à 15 min, c’est un pic qui monte (attention) ; l’inverse, c’est un pic qui redescend (ça se calme).

La RAM et le swap : free -h

free -h     # -h = human readable (Go/Mo lisibles au lieu d'octets)

               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       3.1Gi       1.2Gi       210Mi       3.5Gi       4.3Gi
Swap:          2.0Gi       0.4Gi       1.6Gi

Le drapeau -h (human readable) affiche des Go/Mo au lieu d’octets bruts. Ce qu’il faut vraiment regarder, c’est la colonne available (et non free) : c’est la RAM réellement disponible pour de nouveaux programmes. Linux utilise agressivement la RAM libre comme cache disque (buff/cache), qu’il rend dès qu’une appli en a besoin — donc une free basse n’est pas un problème tant que available reste confortable.

La ligne Swap est le vrai signal d’alarme mémoire : un swap qui se remplit et une machine qui rame, c’est que la vraie RAM est saturée et que le système déborde sur le disque (bien plus lent). Rappelle-toi la Partie 1 : le swap est un filet, pas une solution.

⚠️ Piège — Croire qu’il manque de la RAM parce que free est basse. Sous Linux, de la RAM libre est de la RAM gâchée : le noyau la remplit de cache. Le bon indicateur est available. Le vrai manque de mémoire se voit à un swap qui se remplit et, à l’extrême, à l’OOM killer qui tue un process (signature Killed dans les logs, cf. chapitre 14.1).

Le disque : df -h, puis du / ncdu

Deux questions distinctes : « le disque est-il plein ? » et « qui le remplit ? ».

df -h       # taux de remplissage de chaque systeme de fichiers

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        79G   68G  7.4G  91% /

df -h (disk free, en lisible) te donne le Use%. Ici 91% : c’est le rouge. Un / au-dessus de 85% mérite une action ; au-dessus de 95%, c’est l’urgence (voir la Partie 1 : disque plein = panne en cascade).

Une fois le disque plein détecté, la question devient qui le remplit. C’est là qu’interviennent du et ncdu :

# Taille totale de chaque gros suspect (-s = resume, -h = lisible)
du -sh /var/log /var/lib/postgresql /var/www
 
# Explorateur interactif de disque, tries par taille (le meilleur outil)
ncdu /var

• du -sh <dossier> donne la taille totale d’un dossier. On le lance sur les suspects habituels (/var/log, la base, les uploads, les images Docker).
• ncdu est bien plus agréable : il scanne un dossier et affiche son contenu trié par taille, navigable aux flèches. En quelques secondes tu vois quel dossier — souvent un log oublié ou de vieilles sauvegardes locales — mange l’espace.

🐚 Au terminal — Le protocole « disque plein », dans l’ordre :

df -h                          # 1. confirmer : quel systeme de fichiers, quel %
du -sh /var/* 2>/dev/null | sort -h   # 2. localiser le gros dossier
ncdu /var/log                  # 3. zoomer avec ncdu sur le coupable

I/O disque et réseau : vmstat, iostat, uptime, ss

Le CPU et la RAM ne sont pas les seuls goulots possibles. Deux autres se cachent souvent.

Les I/O disque (vitesse de lecture/écriture). Un serveur peut ramer alors que CPU et RAM sont OK : c’est le disque qui n’arrive pas à suivre (base qui écrit beaucoup, swap intensif). Signes : dans vmstat, la colonne wa (iowait, temps CPU passé à attendre le disque) grimpe ; iostat détaille l’activité par disque.

# Un rafraichissement toutes les 2s : regarder la colonne "wa" (iowait)
vmstat 2
 
# Detail des I/O par disque, toutes les 2s (paquet sysstat)
iostat -x 2

Un iowait élevé = ton goulot est le disque, pas le CPU. C’est un diagnostic qu’on rate souvent faute de le connaître.

Le réseau et les connexions. ss (le successeur de netstat) liste les connexions et les ports en écoute :

# Ports en ecoute : -t (TCP) -u (UDP) -l (listening) -n (numerique) -p (process)
ss -tulpn
 
# Combien de connexions etablies (utile en cas de pic de trafic)
ss -t state established | wc -l

ss -tulpn répond à « qui écoute sur quel port ? » — indispensable pour vérifier que ton app écoute bien en 127.0.0.1:3000 et non en 0.0.0.0 (cf. Partie 6). Compter les connexions établies aide à confirmer un afflux de trafic.

Enfin uptime, la commande la plus rapide : depuis quand la machine tourne, et le load average en une ligne. Utile pour repérer un reboot inattendu (uptime étonnamment court).

Identifier le goulot : symptôme → commande

C’est le cœur du chapitre, et le prolongement direct de la Partie 1 (« quelle ressource pour quel symptôme »). Face à une prod qui va mal, tu nommes la ressource avant de toucher à quoi que ce soit.

💡 Réflexe — Diagnostiquer, c’est isoler une ressource. Un seul écran de htop répond déjà à trois questions (CPU ? RAM ? un process fou ?). S’il ne montre rien d’anormal alors que ça rame, pense I/O (vmstat, regarde wa) — le goulot le plus souvent oublié. Nommer la ressource, c’est déjà avoir à moitié résolu.

⚠️ Piège — Traiter le symptôme au lieu de la cause. « Le site est lent » → on redémarre l’app au hasard, ça repart cinq minutes, ça retombe. Sans avoir mesuré, on n’a rien réglé. Trente secondes de htop + df -h + free -h disent où est le mal ; le reste n’est que devinette coûteuse.

Ponctuel vs continu

Toutes ces commandes sont ponctuelles : elles montrent l’instant T. Formidable pour diagnostiquer un problème en cours, inutile pour le prévoir ou pour savoir ce qui s’est passé cette nuit à 3 h pendant que tu dormais.

C’est toute la limite : htop ne t’appelle pas quand le disque atteint 85%. Pour ça, il faut enregistrer les métriques dans le temps et déclencher des alertes sur des seuils — c’est le sujet du chapitre suivant. Les commandes de ce chapitre restent tes outils du diagnostic à chaud ; le monitoring, lui, veille à ta place.

🔒 Sécurité — Les métriques ont aussi une lecture sécurité. Un pic de CPU, de trafic ou de connexions établies inexpliqué peut trahir une attaque (DDoS, bruteforce, minage après compromission). Un ss -tulpn qui révèle un port ouvert inconnu, ou un process gourmand que tu ne reconnais pas dans htop, sont des signaux à ne pas balayer : croiser avec auth.log (chapitre 14.1).

🧭 Sur FormaCampus — Un soir, formacampus.fr répond lentement. L’équipe ne devine pas : htop → le CPU d’un cœur est à fond sur un process Node, le load est à 3.8 sur 2 cœurs (donc surchargé x2). free -h → RAM OK, available confortable. df -h → disque à 62%, rien à signaler. Diagnostic en trente secondes : CPU, à cause d’un export PDF déclenché en boucle. Ils corrigent la cause (une file d’attente pour les exports) au lieu de rebooter à l’aveugle. La mesure a remplacé la panique.

✏️ Exercices

Exercice 1 — Lis le load. Sur ton VPS, uptime affiche load average: 5.20, 4.80, 4.10. nproc renvoie 2. La machine est-elle en difficulté ? Et si nproc renvoyait 8 ?

Exercice 2 — « No space left on device ». L’app renvoie des erreurs 500 et les logs mentionnent No space left on device. Décris les commandes, dans l’ordre, pour diagnostiquer et localiser le coupable.

🧠 Quiz de révision

Chapitre suivant : Monitoring & alerting — passer du contrôle ponctuel à une surveillance continue qui t’alerte.