Comment surveiller la charge du serveur sans approximations

Publié le 14 juillet 2026

Un serveur envoie rarement un avertissement poli avant qu’un site très fréquenté ne commence à expirer. Le plus souvent, quelqu’un remarque qu’un tableau de bord WordPress ralentit, qu’une page de paiement se fige ou que l’envoi d’e-mails commence à prendre du retard. Savoir comment surveiller la charge du serveur vous donne une chance de voir la pression monter avant vos visiteurs.

La charge du serveur n’est pas un simple chiffre auquel jeter un coup d’œil puis oublier. C’est un tableau composé de la demande en CPU, de la mémoire disponible, de l’activité disque, du trafic réseau et des processus en concurrence pour attirer l’attention. Lisez ces signaux ensemble et vous pourrez faire la différence entre un pic de trafic normal et un serveur qui a besoin d’aide.

Ce que mesure réellement la charge du serveur

Sous Linux, la load average mesure le nombre de tâches qui sont soit prêtes à s’exécuter sur le CPU, soit en attente dans un état non interruptible, souvent parce qu’elles attendent des E/S disque. Vous verrez généralement trois valeurs, représentant la charge moyenne sur les 1, 5 et 15 dernières minutes.

Un affichage tel que `0.60, 0.80, 1.20` n’est pas automatiquement bon ou mauvais. La comparaison pertinente se fait entre la charge et le nombre de cœurs CPU disponibles sur le serveur. Sur un serveur avec un seul cœur CPU, une charge soutenue de 1.00 signifie que le cœur est pleinement occupé. Sur un serveur à quatre cœurs, une charge de 1.00 est généralement confortable, car il reste encore de la capacité disponible.

Même cette règle a une exception. Une load average élevée avec une faible utilisation du CPU peut indiquer des attentes disque plutôt qu’une pression sur le processeur. C’est pourquoi surveiller uniquement la load average peut vous orienter dans la mauvaise direction. Un chiffre vous indique qu’un travail est en attente. Les métriques environnantes vous disent pourquoi.

Comment surveiller la charge du serveur aux bons endroits

Commencez par une vue de surveillance qui vous permet de vérifier l’activité actuelle et les tendances récentes. Les données en temps réel aident pendant un incident, tandis que les graphiques historiques aident à répondre à la question plus utile : cela s’est-il produit une seule fois, ou cela se produit-il tous les jours à 2:00 p.m.?

Un panneau de contrôle avec une surveillance du serveur en temps réel facilite cela pour les propriétaires de sites et les équipes qui ne veulent pas garder un terminal ouvert toute la journée. Dans FASTPANEL, les ressources du serveur peuvent être consultées à côté des sites web et des comptes qui les utilisent, ce qui réduit le travail d’enquête lorsqu’un seul projet commence à consommer plus que sa part.

Pour un examen plus approfondi sous Linux, les commandes habituelles font toujours un excellent travail. `uptime` affiche rapidement les load averages. `top` ou `htop` affiche les processus qui utilisent actuellement le CPU et la mémoire. `free -m` vous aide à évaluer l’utilisation de la mémoire et du swap, tandis que `df -h` montre si un système de fichiers plein contribue au problème. Pour l’activité disque, `iostat` et `iotop` sont utiles lorsqu’ils sont installés.

La meilleure configuration utilise les deux approches : un tableau de bord clair pour la visibilité quotidienne et des vérifications en ligne de commande lorsque vous devez inspecter un processus, une requête, une tâche de sauvegarde ou un événement de trafic spécifique.

Surveillez ces signaux ensemble

Lorsque vous ouvrez un écran de surveillance du serveur, concentrez-vous sur ces signaux liés entre eux :

• L’utilisation du CPU et la load average montrent si les processus se disputent le temps processeur.
• L’utilisation de la mémoire et l’activité du swap révèlent si le serveur manque de RAM et déplace des données vers un stockage disque plus lent.
• L’espace disque, l’attente d’E/S et le débit disque permettent d’identifier les disques pleins ou un stockage qui ne suit pas les lectures et écritures.
• Le trafic réseau et le nombre de connexions montrent si une demande légitime, des bots ou un pic de trafic exerce une pression sur les services web.
• Les principaux processus révèlent quel service, utilisateur, site web ou travail planifié est à l’origine de l’activité.

Un pourcentage CPU élevé pendant le lancement d’un produit peut être attendu. Une forte attente d’E/S alors que l’utilisation du CPU reste modeste raconte une autre histoire, impliquant souvent des sauvegardes, du travail sur la base de données, la rotation des journaux ou un volume de stockage surchargé. L’objectif n’est pas de paniquer à la vue d’une ligne rouge. Il est de trouver le goulot d’étranglement.

Établissez d’abord une référence normale

Des alertes utiles dépendent de la connaissance de ce qui est normal pour votre serveur. Le site web d’une petite entreprise peut rester calme pendant la majeure partie de la journée et connaître un pic lors d’une importation planifiée. Un fournisseur d’hébergement peut avoir une activité régulière sur des dizaines de comptes. Le serveur très sollicité d’une agence peut connaître des pics prévisibles chaque fois que des campagnes clients sont mises en ligne.

Suivez au moins deux à quatre semaines de données avant de traiter chaque augmentation comme un incident. Recherchez des schémas dans la charge, le CPU, la mémoire, les E/S disque et le trafic. Faites correspondre ces schémas à des événements connus : sauvegardes, tâches cron, mises à jour de plugins, tâches de reporting ou heures de pointe des visiteurs.

Cette référence évite deux erreurs courantes. La première consiste à définir des alertes si basses qu’elles deviennent un bruit de fond. La seconde consiste à accepter un ralentissement récurrent parce qu’il est devenu familier. Si la charge atteint 6 chaque nuit sur un serveur à quatre cœurs et que les sites restent rapides, cela peut être gérable. Si le même schéma coïncide avec des requêtes de base de données lentes et des temps de réponse en hausse, cela mérite votre attention.

Définissez des alertes qui conduisent à l’action

Une alerte doit indiquer à quelqu’un d’enquêter sur une condition spécifique, pas simplement annoncer qu’un serveur existe. Définissez des seuils en fonction de la durée ainsi que de la valeur. Un bref pic de CPU est normal. Un CPU au-dessus de 90 % pendant 15 minutes est plus informatif. Le même principe s’applique à la mémoire, à l’utilisation du disque et à la load average.

Utilisez des règles d’alerte pour une charge élevée soutenue par rapport aux cœurs CPU, une forte utilisation du CPU, une faible mémoire disponible, une augmentation active du swap, une attente d’E/S disque élevée et des disques approchant de leur capacité. L’espace disque mérite un avertissement plus précoce que ne l’imaginent la plupart des équipes. Attendre qu’un volume soit rempli à 100 % transforme un simple nettoyage en interruption de service.

Incluez du contexte dans l’alerte lorsque c’est possible : le serveur affecté, la charge actuelle, l’état de la mémoire, l’utilisation du disque et l’heure à laquelle la condition a commencé. Si les alertes arrivent sans contexte, les gens passent les dix premières minutes à comprendre ce que l’alerte signifie. Ce n’est pas de la surveillance. C’est du cardio administratif.

Enquêter sur une charge élevée sans deviner

Lorsque la charge augmente, commencez par le chemin le plus court vers les preuves. Vérifiez si l’utilisation du CPU est également élevée. Si c’est le cas, triez les processus en cours d’exécution par utilisation du CPU et identifiez le service responsable. Les workers du serveur web, les processus PHP, les requêtes de base de données, les analyses de malwares et les tâches cron mal planifiées sont des sources courantes.

Si la charge est élevée mais que l’utilisation du CPU ne l’est pas, vérifiez l’attente d’E/S et l’activité disque. Une sauvegarde écrivant de nombreux fichiers, une base de données reconstruisant un index ou un disque presque plein peuvent laisser des processus en attente même lorsque de la capacité CPU est disponible. Vérifiez l’espace du système de fichiers, examinez les tâches planifiées récentes et recherchez une activité de lecture ou d’écriture inhabituellement intense.

Vérifiez ensuite la mémoire. Une faible RAM disponible et une utilisation soutenue du swap peuvent donner l’impression que chaque service est lent, car le serveur déplace constamment des pages mémoire vers et depuis le disque. Redémarrer un service peut offrir un court répit, mais cela ne corrigera pas une application qui a besoin de plus de mémoire, un processus incontrôlé ou un serveur tout simplement trop petit pour sa charge de travail.

Enfin, examinez le trafic et les connexions. Une augmentation soudaine peut être une bonne nouvelle, comme une campagne réussie, ou être moins bienvenue, comme des bots agressifs frappant les pages de connexion. Les journaux d’accès web, le nombre de connexions et les vues des ressources par site aident à distinguer la demande réelle des visiteurs du bruit indésirable.

Corrigez la cause, pas le graphique

La bonne réponse dépend du goulot d’étranglement. En cas de pression sur le CPU, optimisez le code applicatif coûteux, mettez en cache le travail répétitif, ajustez les workers PHP ou déplacez les tâches récurrentes hors des heures de pointe. En cas de pression sur la base de données, examinez les requêtes lentes, les index manquants et les limites de connexion avant d’ajouter davantage de ressources serveur.

En cas de pression liée au disque, supprimez les fichiers inutiles, confirmez que les sauvegardes n’entrent pas en concurrence avec le trafic des visiteurs et utilisez un stockage plus rapide si la charge de travail l’exige. En cas de pression sur la mémoire, réduisez les services gourmands, ajustez soigneusement les limites de l’application ou augmentez la RAM. Monter en capacité peut être la bonne décision, mais cela doit découler des preuves plutôt que de la frustration.

Pensez aussi à l’isolation des comptes sur les serveurs partagés ou multi-sites. Un site web mal optimisé ne devrait pas être autorisé à transformer tous les autres sites en excuses lentes. La visibilité par compte facilite grandement l’identification de la source et la définition de limites équitables lorsque c’est nécessaire.

Continuez la surveillance après la correction

Après avoir effectué un changement, surveillez les mêmes métriques pendant la prochaine période chargée. Une load average plus faible est encourageante, mais les temps de réponse, les taux d’erreur et l’expérience utilisateur comptent aussi. Le serveur peut sembler plus calme alors qu’une file d’attente de base de données ou une erreur d’application subsiste.

Une bonne surveillance consiste moins à fixer des graphiques qu’à instaurer la confiance : vous savez à quoi ressemble un fonctionnement normal, vous recevez des avertissements utiles et vous avez une étape suivante claire quand quelque chose se comporte de manière créative. C’est ainsi que la gestion des serveurs devient une partie routinière de l’exploitation des sites web, et non la raison pour laquelle votre soirée disparaît.