Monitoring local Linux : load, free, df, top et iostat

À la fin de ce tutoriel, vous saurez lire le load average (uptime, nproc), inspecter CPU/RAM avec top / htop, interpréter free -h (dont la colonne available), contrôler l’espace et les inodes avec df -h / df -i, lancer un aperçu iostat (paquet sysstat), et enchaîner un mini lab de charge contrôlée sous /tmp — le tout sur VM jetable, sans agents cloud ni prod.

Niveau : Intermédiaire · Temps estimé : 40–50 min · Versions testées : Ubuntu 22.04 / 24.04, Debian 12 ; notes Rocky/Alma 9 · Dernière vérification : 2026-09-11

Slug proposé : linux-monitoring-local · Série : Linux Admin · Remplace / fusionne : N/A — création (chapitre 7)

Prérequis

• Hub Linux Admin et chapitres amont : Backups Linux : rsync, tar et stratégie 3-2-1, Logs Linux : journalctl…, Disques et partitions
• Bases processus & systemd (ps, top basique)
• VM ou WSL jetable ; compte non-root + sudo pour installer htop / sysstat si absents
• Pas de charge longue sur un hôte partagé ; labs dans /tmp ; arrêt explicite des process de stress

Coût estimé : 0 €. Paquets optionnels : htop, sysstat (et éventuellement stress-ng pour le lab).

Ce que nous allons construire

uptime / load average + nproc
  → top & htop (tri CPU/MEM)
  → free -h (available vs used)
  → df -h / df -i (espace + inodes)
  → iostat aperçu (sysstat) — deep dive → performance-tuning
  → Lab charge courte + lecture + nettoyage

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Monitoring local Linux Admin : load average, top/htop, free -h, df -h, aperçu iostat ».)

Septième chapitre de Linux Admin. Après avoir planifié (cron) et sauvegardé (rsync), on observe la machine : une load élevée, une RAM saturée ou un filesystem à 100 % expliquent souvent un backup lent, un cron qui « disparaît » ou un service qui rame. Ici : boîte à outils locale (pas Prometheus/Grafana). L’approfondissement disque/CPU (iostat/vmstat poussés) arrive dans Performance tuning.

Étape 1 — Load average : uptime et nproc

Le load average (1 / 5 / 15 min) compte les process runnable ou en attente disque — ce n’est pas un %CPU. Sur 4 vCPU, load ~4 ≈ saturation ; ~8 = file d’attente claire.

uptime
nproc
# Équivalent lecture : /proc/loadavg
cat /proc/loadavg
# Mémoire rapide du contexte
free -h | head -n 2

Indicateur	Où	Lecture rapide
Load 1 / 5 / 15	uptime, /proc/loadavg	Tendance courte → longue
CPU count	nproc	Référentiel pour juger la load
Who / since	uptime	Uptime hôte + users

Règle lab : comparez load₁ à nproc. Si load₁ ≫ nproc plusieurs minutes → top (CPU) puis iostat / df (I/O ou disque plein).

Étape 2 — top et htop : qui mange CPU et RAM

top est partout ; htop (si installé) gagne en lisibilité (couleurs, tris).

# Instantané non interactif (scriptable)
top -b -n 1 | head -n 20
ps -eo pid,user,pcpu,pmem,cmd --sort=-pcpu | head -n 12
ps -eo pid,user,pcpu,pmem,cmd --sort=-pmem | head -n 12

# htop si disponible (sinon install lab)
command -v htop >/dev/null && echo "htop OK" || echo "htop absent — voir install ci-dessous"
# Ubuntu/Debian : sudo apt-get update && sudo apt-get install -y htop
# Rocky/Alma  : sudo dnf install -y htop

Touche / vue	top	htop (typique)
Quitter	q	q
Tri CPU	P	clic / F6
Tri MEM	M	clic / F6
Kill	k	F9 — PID lab seulement

En interactif : triez CPU puis MEM, notez 2–3 PID chauds, croisez avec systemctl status / journalctl -u si besoin. Ne tuez jamais sshd / systemd.

Étape 3 — Mémoire avec free -h

free -h montre RAM et swap. Sur noyaux récents, lisez surtout available (RAM encore allocatable) : le cache/buffers est souvent récupérable.

free -h
# Détail /proc
awk '/MemTotal|MemAvailable|SwapTotal|SwapFree/ {print}' /proc/meminfo
# Pression mémoire ? (si présent)
grep -E 'oom|Out of memory' /var/log/syslog /var/log/messages 2>/dev/null | tail -n 5 || 
  journalctl -b -p err --no-pager 2>/dev/null | grep -i oom | tail -n 5 || 
  echo "Pas de trace OOM récente visible — OK"

Colonne / notion	Signification	Piège
used	Estimé utilisé	Ne paniquez pas si free est bas
buff/cache	Cache page / buffers	Souvent récupérable
available	Mieux pour « reste-t-il de la RAM ? »	Préférez-la à free
Swap used	Débordement vers disque	Swap plein + load haute = alerte

Si available est bas et le swap grimpe : ps --sort=-pmem / htop, puis cgroups (ch. processus avancés).

Étape 4 — Disque : df -h et df -i

Filesystem à 100 % ou inodes épuisés : writes, logs et backups cassent. df est le check quotidien après disques/LVM.

df -hT
df -i
# Focus racines usuelles
df -h / /tmp /var /home 2>/dev/null || df -h /
# Gros répertoires sous /tmp (lab sûr)
du -h --max-depth=1 /tmp 2>/dev/null | sort -h | tail -n 15

Commande	Voit	Symptôme classique
df -h	Octets libres	No space left on device
df -i	Inodes libres	Même erreur avec df -h encore « OK »
du -h	Usage réel d’un arbre	Trouver qui remplit

Mêmes flags sur Rocky/Alma. Surveillez /, /var, /var/log ; lien logrotate + LVM extend si /var sature.

Étape 5 — Aperçu iostat (sysstat)

iostat (paquet sysstat) montre le débit et l’util% des disques. Ici : aperçu pour confirmer une hypothèse I/O. Le réglage fin (await, filesystems, vmstat poussé) est pour Performance tuning.

# Install lab si besoin
# Ubuntu/Debian : sudo apt-get install -y sysstat
# Rocky/Alma    : sudo dnf install -y sysstat
command -v iostat >/dev/null || { echo "Installez sysstat pour iostat"; exit 0; }
# 3 échantillons, intervalle 1 s
iostat -xz 1 3
# Option : vmstat une fois (aperçu)
vmstat 1 5

Regardez %util / await. %util ~100 pendant le lab disque = goulot I/O (pas forcément CPU).

Étape 6 — Lab charge courte, lecture, arrêt

Objectif : voir load/CPU/disque bouger, puis couper. Court (≤30 s), sous /tmp.

mkdir -p /tmp/lab-monitoring
# 1) Baseline
echo "=== BASELINE ==="
uptime; nproc; free -h | head -n 2; df -h /tmp | tail -n 1

# 2) Charge CPU courte (boucle) — arrêt garanti
echo "=== CHARGE CPU ~15s ==="
(timeout 15s bash -c 'while true; do :; done') &
CPID=$!
sleep 2
uptime
ps -p "$CPID" -o pid,pcpu,pmem,cmd 2>/dev/null || true
wait "$CPID" 2>/dev/null || true

# 3) Charge disque courte sous /tmp
echo "=== CHARGE DISQUE ==="
dd if=/dev/zero of=/tmp/lab-monitoring/blob.bin bs=1M count=256 status=progress 2>/dev/null || 
  dd if=/dev/zero of=/tmp/lab-monitoring/blob.bin bs=1M count=256
uptime
df -h /tmp | tail -n 1
command -v iostat >/dev/null && iostat -xz 1 2 | tail -n 20 || true

# 4) Nettoyage immédiat
rm -f /tmp/lab-monitoring/blob.bin
rmdir /tmp/lab-monitoring 2>/dev/null || rm -rf /tmp/lab-monitoring
echo "=== APRÈS NETTOYAGE ==="
uptime
df -h /tmp | tail -n 1
ls /tmp/lab-monitoring 2>/dev/null || echo "lab monitoring nettoyé — OK"

Variante : stress-ng --cpu 1 --timeout 15s si installé. Sur WSL/hôte partagé, restez très court.

Étape 7 — Vérification et checklist ops

# Checklist lecture seule
uptime && nproc
free -h
df -h / && df -i / | tail -n 1
top -b -n 1 | head -n 8
command -v iostat >/dev/null && iostat -xd 1 1 | head -n 12 || echo "iostat optionnel"
# Aucun reste lab
ls /tmp/lab-monitoring 2>/dev/null && echo "ATTENTION: lab encore présent" || echo "pas de lab résiduel"

Validé si : load vs nproc, available lu correctement, df/df -i OK, process chaud identifié, aperçu iostat compris (sans digérer Performance tuning).

Erreurs fréquentes

Symptôme	Cause	Correction
« Load 4 = 400 % CPU »	Confusion load ↔ %CPU	Comparer à nproc ; regarder %CPU dans top
Panique car free bas	Cache compté comme used	Lire available
No space left avec df -h OK	Inodes épuisés	df -i ; purger petits fichiers
iostat: command not found	sysstat absent	apt/dnf install sysstat
Lab qui tourne encore	Oubli kill / timeout	ps + kill ; rm sous /tmp/lab-monitoring
htop manquant	Paquet non installé	Install lab ; sinon rester sur top/ps
Charge sur / racine	dd hors /tmp	Toujours blobs sous /tmp

Quiz (3 questions)

1. Sur un hôte à 2 vCPU, une load average 1 minute à ~2 signifie surtout :
– A. Exactement 2 % CPU
– B. Une machine à peu près saturée côté file d’exécution / attente
– C. Que le swap est forcément plein

2. Quelle colonne de free -h estime le mieux la RAM encore allocatable ?
– A. shared
– B. available
– C. buff/cache seule

3. df -h OK mais écriture impossible : que vérifier ensuite ?
– A. df -i (inodes)
– B. nice -n 19
– C. chmod 777 /

Réponses : 1‑B · 2‑B · 3‑A

FAQ

Load average ou %CPU dans top ?
Les deux : la load donne la tendance ; top/htop montrent qui. Load haute + peu de %CPU → piste I/O (iostat, df, D-state).

Faut-il htop et sysstat partout ?
Lab/admin : utiles. Image minimale : top, ps, free, df, uptime suffisent ; ajoutez sysstat pour le disque.

Vs Performance tuning ?
Ici le socle quotidien. Performance tuning pousse iostat/vmstat et l’optimisation — sans remplacer Prometheus/Grafana.

Pour aller plus loin

• man uptime, free, df, top, iostat
• Suite : Quiz & FAQ Admin · Performance tuning
• Aussi : journalctl, cgroups

Maillage série Linux Admin

← Précédent	Backups Linux : rsync, tar et stratégie 3-2-1
→ Suivant	Quiz & FAQ Linux Admin
Hub	Linux Admin
Aussi	Logs journalctl · Disques & partitions · Performance tuning

---

Meta publication (à remplir dans Rank Math / SEO)

• Title SEO : Monitoring local Linux : load, free, df (2026)
• Meta description (≤ 155) : Surveillez load, RAM et disque avec uptime, free, df, top/htop et iostat. Guide monitoring local Linux Admin DevOps 2026.
• Focus keyphrase : monitoring local Linux
• KW secondaires : load average, free -h, df -h, htop, iostat
• Schemas Rank Math : Article + HowTo (étapes lab) + FAQ (3 questions ci-dessus)
• Image mise en avant : assets/web/devopelastichayway/cover-linux-monitoring-local-1200x630.webp (Visuels Linux — WebP 1200×630)
• Catégorie : Linux · Niveau : Intermédiaire
• Slug : linux-monitoring-local
• Statut : HOLD — draft only (ne pas publier)