"Surveillance des ressources système"

1. Les 4 ressources vitales et la méthode USE

Avant de nous jeter sur les commandes, il est crucial de comprendre ce que nous cherchons. Un serveur, comme toute machine, jongle avec quatre types de ressources principales. Un problème de performance est presque toujours lié à un goulot d'étranglement, ou contention, sur l'une d'elles.

Pour une introduction claire à ces concepts, je vous invite à lire les premières sections d'un excellent guide.

Pour résumer, lorsque vous analysez une ressource, vous devez vous poser trois questions :

1. Utilisation : À quel point la ressource est-elle occupée ? (ex: le CPU est-il utilisé à 95% ?)
2. Saturation : Y a-t-il une file d'attente ? (ex: des programmes attendent-ils leur tour pour accéder au CPU ?)
3. Erreurs : Y a-t-il des erreurs signalées ? (ex: le disque signale-t-il des secteurs défectueux ?)

Gardez cette grille d'analyse en tête, nous allons maintenant voir les outils pour y répondre.

2. Surveiller les ressources sur Linux

Dans votre machine virtuelle Ubuntu Server, nous allons utiliser une combinaison d'outils en ligne de commande.

A. Obtenir un aperçu rapide (les "constantes vitales")

Ces commandes vous donnent un instantané de l'état du système. Elles sont parfaites pour une première évaluation rapide.

1. Charge du système (uptime)
   La commande uptime vous donne une information cruciale : le load average (charge moyenne).

   uptime
   

   Vous verrez trois chiffres, qui représentent la charge moyenne sur la dernière minute, les 5 dernières, et les 15 dernières minutes. Comme expliqué dans l'article de S. Robert, un bon point de repère est le nombre de cœurs de votre CPU (que vous pouvez trouver avec la commande nproc). Si le load average dépasse durablement le nombre de cœurs, votre système est en surcharge.

2. Utilisation de la mémoire (free -h)
   Cette commande est essentielle pour vérifier l'état de la RAM. L'option -h (human-readable) la rend plus facile à lire.

   free -h
   

   Le point le plus important ici est la colonne available. Comme expliqué dans l'article, un free bas n'est pas un problème. C'est un available bas qui indique un manque de mémoire pour les applications. Surveillez aussi la ligne Swap : si sa valeur used n'est pas nulle, cela signifie que le système a déjà manqué de RAM et a dû utiliser le disque, ce qui ralentit considérablement les performances.

3. Utilisation de l'espace disque (df -h)
   Un disque plein est une cause très fréquente de problèmes. La commande df -h (disk free) vous montre l'espace utilisé et disponible pour chaque partition.

   df -h
   

   Regardez la colonne Use%. Si une partition, notamment la partition racine (/), approche les 100%, vous devez agir rapidement.

B. Analyse dynamique avec htop

Les commandes précédentes sont statiques. Pour voir ce qui se passe en temps réel, l'outil htop est un incontournable. Il est plus moderne et interactif que son prédécesseur top.

Si htop n'est pas installé, faites-le avec :

sudo apt update
sudo apt install htop

La vidéo suivante vous montrera comment vous servir de htop pour identifier les processus qui consomment le plus de ressources.

Une fois htop lancé (htop), voici les actions clés à maîtriser :

• Trier par CPU : Appuyez sur la touche F6, puis sélectionnez PERCENT_CPU et Entrée. Les processus les plus gourmands en CPU apparaîtront en haut.
• Trier par Mémoire : Appuyez sur F6, puis sélectionnez PERCENT_MEM et Entrée.
• Quitter : Appuyez sur q ou F10.

htop est votre meilleur ami pour répondre à la question "Quel programme ralentit ma machine en ce moment ?".

3. Surveiller les ressources sur Windows Server

En tant qu'administrateur, vous travaillerez probablement aussi sur des environnements Windows. Bien que le Gestionnaire des tâches (taskmgr) soit connu, l'outil le plus puissant pour le diagnostic est le Moniteur de ressources (resmon).

La vidéo suivante est un guide complet de cet outil.

Pour résumer les points clés pour Windows Server :

• Lancement : Menu Démarrer -> tapez resmon -> Entrée.
• Onglet CPU : Permet de voir l'utilisation par processus, comme avec htop. Très utile pour identifier un programme qui monopolise le processeur.
• Onglet Mémoire : Le graphique "Erreurs de page/s" (Hard Faults) est crucial. Une valeur élevée et constante indique que le système manque de RAM et utilise le fichier d'échange sur le disque (l'équivalent du swap Linux). C'est un signe clair de saturation mémoire.
• Onglet Disque : Permet de voir quels processus lisent ou écrivent sur le disque. Le graphique "Longueur de la file d'attente du disque" (Disk Queue Length) indique si le disque peine à suivre la cadence des demandes. Une file d'attente constamment élevée est un signe de goulot d'étranglement au niveau du stockage.

Conclusion

Aujourd'hui, vous avez appris à utiliser les outils de première ligne pour surveiller la santé d'un système, que ce soit sous Linux ou Windows. Vous êtes maintenant capable de passer de l'observation d'un symptôme à la collecte de données concrètes, une étape essentielle du dépannage professionnel.

Points clés à retenir :

• Les problèmes de performance proviennent généralement d'une contention sur le CPU, la RAM ou le Disque.
• Sur Linux, les commandes de base sont uptime, free -h, df -h pour un diagnostic rapide, et htop pour une analyse dynamique en temps réel.
• Sur Windows, le Moniteur de ressources (resmon) est l'outil de choix pour une analyse détaillée des performances du CPU, de la mémoire et des disques.
• Des indicateurs comme le load average (Linux), les hard faults (Windows) ou la queue length (Windows) sont des signaux puissants de saturation.
• Le plus important est de vous familiariser avec ce qui est "normal" sur vos systèmes. Lancez ces outils régulièrement sur une machine qui fonctionne bien pour établir une ligne de base. C'est en connaissant le normal que vous pourrez repérer l'anormal.

Dans la prochaine leçon, nous irons un cran plus loin dans l'investigation. Les outils d'aujourd'hui montrent ce qui se passe maintenant. Mais que faire si le problème a eu lieu pendant la nuit ? Pour cela, nous devons apprendre à lire le journal de bord du système. Nous nous pencherons donc sur la consultation et le filtrage des journaux système (journalctl) pour trouver la cause racine d'une erreur passée.