Quelles métriques surveiller sur un serveur ? Le plan essentiel

Une supervision efficace ne collecte pas le maximum de métriques : elle collecte celles qui déclenchent une action. La différence est nette en pratique — un tableau de bord avec 200 courbes que personne ne regarde vaut moins qu'une dizaine d'alertes bien calibrées.

Cet article propose un plan de supervision minimal mais complet, applicable à un serveur Windows ou Linux, avec les seuils et les pièges de lecture de chaque métrique.

Le principe : une métrique par question

Avant d'ajouter une métrique, posez-vous la question à laquelle elle répond et l'action qu'elle déclenche. Si aucune action ne découle d'une valeur anormale, la métrique appartient à un tableau de bord de suivi, pas à un système d'alerte.

Ce filtre élimine à lui seul la moitié des métriques collectées par défaut.

Niveau 1 : les quatre métriques indispensables

Espace disque

Ce qu'elle détecte : la panne la plus fréquente et la plus évitable.

Seuils : avertissement à 85 %, critique à 95 %, en combinant avec un plancher d'espace libre absolu (10 Go par exemple) pour éviter les faux positifs sur les grands volumes.

Piège : surveiller uniquement la racine. Un serveur avec /, /var et un volume de données a trois points de défaillance distincts. Sur Linux, surveillez aussi les inodes : un volume peut refuser toute écriture en affichant 40 % d'occupation.

Le sujet est détaillé dans surveiller l'espace disque d'un serveur.

Mémoire disponible

Ce qu'elle détecte : l'effondrement des temps de réponse avant l'arrêt du service.

Seuil : alerte sous 15 % de mémoire disponible, maintenue plusieurs minutes.

Piège majeur : sur Linux, ne surveillez jamais la mémoire « libre ». Le système utilise délibérément toute la mémoire inoccupée comme cache disque — un système en bonne santé affiche presque toujours très peu de mémoire libre. La métrique pertinente est la mémoire disponible (available), qui tient compte du cache récupérable.

Surveillez également l'usage du swap : un système qui swappe activement a déjà un problème de mémoire, même si le service répond encore.

Charge processeur

Ce qu'elle détecte : une saturation applicative ou un processus emballé.

Seuil : alerte sur une moyenne soutenue, pas sur une valeur instantanée. Un pic à 100 % pendant une sauvegarde est normal ; une charge à 90 % maintenue trente minutes ne l'est pas.

Piège : sur Linux, la « charge moyenne » (load average) n'est pas un pourcentage. Elle compte les processus en attente d'exécution, et sa lecture dépend du nombre de cœurs : une charge de 4 est saine sur un système à 8 cœurs, préoccupante sur un système à 2 cœurs. Rapportez toujours la valeur au nombre de cœurs.

Surveillez aussi le temps passé en attente d'entrées-sorties (iowait) : un processeur peu chargé mais avec un iowait élevé signale un problème de disque, pas de calcul.

Disponibilité des services

Ce qu'elle détecte : l'incident que les utilisateurs signalent en premier.

Seuil : binaire — le service tourne ou non.

Piège : un serveur qui répond au ping avec son service applicatif arrêté est considéré comme « en ligne » par un contrôle réseau simple. Surveillez l'état des services eux-mêmes : systemctl is-active sous Linux, l'état du service Windows sous Windows.

Niveau 2 : les métriques qui complètent utilement

Redémarrages inattendus

Le temps de fonctionnement depuis le dernier démarrage (uptime) est une métrique simple et révélatrice. Un serveur qui redémarre seul signale un problème matériel, une mise à jour non maîtrisée ou un plantage — trois causes qui méritent une investigation.

Trafic réseau par interface

Utile pour détecter une saturation de lien ou un trafic anormal. Alerte à définir en fonction de la capacité réelle du lien, pas d'une valeur absolue.

Un usage souvent négligé : un trafic sortant inhabituellement élevé la nuit peut signaler une exfiltration de données ou un système compromis.

Sauvegardes

Une sauvegarde qui échoue silencieusement pendant trois mois ne se découvre qu'au moment de la restauration. Surveillez trois éléments : le service de sauvegarde tourne, la date du dernier succès est récente, et l'espace disponible sur la destination est suffisant.

Certificats TLS

Leur expiration provoque une panne complète et parfaitement datée à l'avance. Une alerte 30 jours avant l'échéance coûte peu et évite un incident bête.

Température et état matériel

Sur du matériel physique, l'état des disques (SMART), des alimentations et des ventilateurs anticipe des pannes matérielles. Sans intérêt sur une machine virtuelle, où ces informations appartiennent à l'hyperviseur.

Ce qu'il ne faut pas transformer en alerte

Certaines métriques sont utiles à consulter, mais génèrent du bruit si elles déclenchent des notifications :

• Le nombre de processus : varie fortement et normalement selon l'activité.
• Les pics de charge courts : une sauvegarde, un antivirus ou une compilation saturent le processeur pendant quelques minutes, sans conséquence.
• Le trafic réseau instantané : très fluctuant par nature.
• La mémoire cache : son remplissage est le comportement attendu du système.
• Les événements de sécurité bruts : sur un serveur Windows sain, certains identifiants d'événement se produisent des centaines de fois par heure. Les compter individuellement produit un volume d'alertes ingérable ; ils n'ont de sens que rapportés à une base de comparaison.

Ces métriques ont leur place sur un tableau de bord. Elles n'ont pas leur place dans une notification qui interrompt quelqu'un.

Un ordre de mise en place

Une supervision partielle qui fonctionne vaut mieux qu'un projet complet jamais terminé. Un ordre qui fonctionne bien en pratique :

1. Semaine 1 : disque, mémoire, processeur, disponibilité du système — sur les serveurs critiques uniquement.
2. Semaine 2 : services applicatifs et sauvegardes, sur ces mêmes serveurs.
3. Semaine 3 : observation des données réelles, ajustement des seuils, suppression des alertes qui se sont révélées bruyantes.
4. Ensuite seulement : extension au reste du parc, puis métriques de niveau 2.

L'étape 3 est celle que l'on saute le plus souvent, et c'est celle qui détermine si la supervision sera utilisée dans six mois. Voir comment éviter les faux positifs.

Combien de temps conserver les données

Deux besoins distincts :

• L'historique détaillé (chaque valeur collectée) sert au diagnostic d'un incident récent. Quelques semaines suffisent généralement.
• Les tendances agrégées (moyennes horaires) servent à la capacité et aux rapports. Elles se conservent sur plusieurs mois pour un coût de stockage bien moindre.

Distinguer les deux évite une base de données qui grossit sans limite — le point de fragilité le plus courant d'une supervision auto-hébergée.

Avec Logiserv

Les templates appliqués selon le système détecté couvrent l'ensemble des métriques de niveau 1 et une bonne partie du niveau 2, avec des seuils préréglés sur des valeurs éprouvées plutôt que sur les valeurs par défaut de Zabbix.

Métriques collectées

232 au total

Réparties sur 11 templates, appliqués selon le système détecté à l'enrôlement.

Déclencheurs préréglés

139

Seuils calibrés sur des données réelles, dont la détection d'anomalies système et réseau.

Découverte automatique

Volumes et interfaces

Systèmes de fichiers et interfaces réseau détectés sans déclaration manuelle.

Pour aller plus loin

• Surveiller l'espace disque d'un serveur — la métrique la plus rentable, en détail
• Éviter les faux positifs Zabbix — calibrer les seuils pour que les alertes restent lues
• Pourquoi superviser un serveur Linux et comment surveiller Windows Server
• Supervision serveur Windows et Linux : le guide — la démarche complète
• Installer Zabbix Agent 2 — collecter ces métriques sur vos systèmes