Les métriques indispensables à surveiller sur un serveur Windows ou Linux : disque, mémoire, processeur, services, réseau. Seuils recommandés, pièges de lecture et ordre de priorité.
Les autres services
Comment surveiller l'espace disque d'un serveur Windows ou Linux : quels seuils choisir, pourquoi la tendance compte plus que le pourcentage, et comment éviter la saturation avant l'incident.
Réduire les fausses alertes Zabbix : hystérésis, durée de dépassement, seuils par volume, dépendances entre déclencheurs et calibrage sur données réelles plutôt que sur les valeurs par défaut.
Construire des tableaux de bord Grafana pour surveiller processeur, mémoire et disque : quelle source de données, quels panneaux choisir, quels intervalles de rafraîchissement et quels pièges de lecture éviter.
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.
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.
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.
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 — une machine 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 : une machine qui swappe activement a déjà un problème de mémoire, même si le service répond encore.
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 une machine à 8 cœurs, préoccupante sur une machine à 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.
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.
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.
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 une machine compromise.
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.
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.
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.
Certaines métriques sont utiles à consulter, mais génèrent du bruit si elles déclenchent des notifications :
Ces métriques ont leur place sur un tableau de bord. Elles n'ont pas leur place dans une notification qui interrompt quelqu'un.
Une supervision partielle qui fonctionne vaut mieux qu'un projet complet jamais terminé. Un ordre qui fonctionne bien en pratique :
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.
Deux besoins distincts :
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.
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.
Réparties sur 11 templates, appliqués selon le système détecté à l'enrôlement.
Seuils calibrés sur des données réelles, dont la détection d'anomalies système et réseau.
Systèmes de fichiers et interfaces réseau détectés sans déclaration manuelle.
Logiserv supervise votre parc à partir de cet article : essai gratuit sans carte bancaire.