Chapitre 115 minIntermédiaire
C'est quoi la supervision informatique ?
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- définir la supervision, la métrologie et l'observabilité, et dire ce qui les distingue ;
- dresser la liste de ce qu'il faut superviser, couche par couche ;
- distinguer l'interrogation (polling) de la remontée spontanée (push, trap) ;
- situer la supervision dans le référentiel et aux épreuves E5, E6 et E7.
3 exercices corrigés1 schéma
La supervision informatique (monitoring) est la surveillance continue et automatique des équipements, des systèmes et des services d'un système d'information : un outil collecte des mesures, les compare à des seuils et alerte un technicien quand quelque chose ne va pas. Ce chapitre explique à quoi elle sert, ce qui la distingue de la métrologie et de l'observabilité, ce qu'il faut superviser, comment les données remontent, et où elle intervient dans ton BTS.
À quoi sert la supervision
Sans supervision, un service informatique apprend les pannes par le téléphone. Un lundi matin, la comptabilité appelle : le partage réseau ne répond plus. Le disque du serveur de fichiers est plein depuis samedi, à cause d'une sauvegarde mal configurée. Il a fallu quarante-huit heures et un utilisateur mécontent pour le découvrir. Avec une supervision, une alerte serait partie vendredi soir, dès 90 % d'occupation, et le problème aurait été réglé avant que quiconque s'en aperçoive.
La supervision répond à cinq besoins.
- Détecter une panne au plus vite, idéalement avant les utilisateurs : un service arrêté, un serveur injoignable, un lien coupé.
- Anticiper : repérer une dérive (un disque qui se remplit de 2 Go par jour, une mémoire qui fuit, un lien qui sature aux heures de pointe) et agir avant la panne.
- Diagnostiquer : quand un incident survient, l'historique des mesures montre ce qui a changé et quand. On passe de « ça ne marche pas » à « la latence du lien vers Marseille est passée de 8 à 900 ms à 14 h 02 ».
- Prouver qu'un engagement est tenu : un taux de disponibilité mesuré, un temps de réponse moyen, un rapport mensuel pour la direction ou pour un client (chapitre 2).
- Dimensionner : décider, chiffres à l'appui, qu'il faut plus de mémoire pour un hyperviseur ou un lien plus rapide pour une agence.
Supervision, métrologie et observabilité
Trois mots reviennent dans les sujets et les offres de stage. Ils se recouvrent en partie.
| Terme | La question à laquelle il répond | Exemple chez Sorbier |
|---|---|---|
| Supervision | Est-ce que ça marche maintenant ? Faut-il prévenir quelqu'un ? | « Le service DNS de srv-ad est arrêté » : alerte immédiate |
| Métrologie | Comment ça évolue dans le temps ? Quelle tendance ? | « Le lien vers Marseille est chargé à 85 % chaque jour de 8 h à 10 h depuis trois semaines » |
| Observabilité | Pourquoi ça se comporte ainsi ? Peut-on l'expliquer de l'extérieur ? | Corréler les métriques, les journaux et les traces d'une application pour trouver la requête lente |
La supervision porte sur l'état présent et sur l'alerte. La métrologie (du grec metron, la mesure) porte sur la mesure et son historique : graphiques, tendances, rapports, prévisions. Un même outil, Zabbix par exemple, fait les deux : il stocke chaque mesure (métrologie) et la compare à des seuils (supervision). L'observabilité est un terme plus récent, venu du monde des applications distribuées : un système est observable quand ses trois types de signaux, métriques, journaux et traces, permettent de comprendre son comportement interne sans le modifier. Le chapitre 11 détaille ces trois signaux.
Ce qu'il faut superviser
On supervise par couches, du matériel jusqu'au service rendu à l'utilisateur. Chaque couche a ses indicateurs et sa façon de collecter.
| Couche | Ce que l'on mesure | Comment on le collecte |
|---|---|---|
| Matériel et environnement | Température, ventilateurs, alimentations, état des disques (SMART), onduleur | SNMP, IPMI, agent (SMART), carte de gestion du serveur |
| Réseau | Équipement joignable, état des ports, débit, erreurs, latence, pertes | Ping (ICMP), SNMP, NetFlow |
| Système | Processeur, mémoire, espace disque, charge, processus, heure | Agent installé sur la machine |
| Virtualisation et stockage | Charge des hyperviseurs, état des VM, espace des banques de stockage, pools ZFS | API de l'hyperviseur, SNMP du NAS |
| Services | Le service tourne-t-il ? Le port répond-il ? DNS, DHCP, Active Directory, base de données, serveur web | Agent, test de port, requête DNS |
| Applications | Temps de réponse, erreurs, files d'attente, sessions | Agent, API de l'application, point de santé /health |
| Expérience utilisateur | Le site s'affiche-t-il pour l'utilisateur, avec le bon contenu, en moins de deux secondes ? | Scénario web, test depuis l'extérieur |
| Sécurité | Certificats qui expirent, mises à jour manquantes, comptes verrouillés | Agent, scénario web ; la détection d'attaques relève du SIEM |
La dernière ligne mérite une précision. La supervision vérifie qu'un service fonctionne. La détection d'une attaque (une série d'échecs de connexion, un journal effacé, un processus inconnu) demande un autre outil, le SIEM, qui collecte et corrèle les journaux de sécurité. Les deux se complètent : le chapitre 11 fait la part des choses, et le cours Cybersécurité des infrastructures présente le SIEM.
Les quatre signaux d'or
Pour un service (un site web, une API, une application), quatre mesures suffisent à repérer la plupart des problèmes. Les ingénieurs de Google les ont popularisées sous le nom de golden signals :
| Signal | Question | Exemple d'indicateur |
|---|---|---|
| Latence | Combien de temps pour répondre ? | Temps de réponse moyen et au 95e centile de la page d'accueil |
| Trafic | Quelle demande ? | Requêtes par seconde, débit en Mbit/s |
| Erreurs | Quelle part échoue ? | Pourcentage de réponses HTTP 5xx |
| Saturation | À quel point la ressource est-elle pleine ? | Processeur, mémoire, disque, file d'attente, connexions |
Un service lent mais qui répond est souvent plus grave qu'une panne franche : personne n'appelle tout de suite, mais tout le monde perd du temps.
Comment remontent les données : interrogation ou envoi
Il existe deux façons de récupérer une mesure.
- L'interrogation (polling, supervision dite active du point de vue du serveur) : le serveur de supervision demande la valeur à intervalle régulier, par exemple toutes les minutes. C'est le cas d'un ping, d'une requête SNMP get sur le port UDP 161, ou d'un contrôle passif de l'agent Zabbix sur le port TCP 10050.
- L'envoi (push) : l'équipement ou l'agent envoie lui-même ses données. Soit à intervalle régulier (l'agent Zabbix en contrôle actif, qui pousse ses mesures vers le port TCP 10051 du serveur), soit sur événement : un switch envoie un trap SNMP vers le port UDP 162 au moment précis où un port tombe.
| Interrogation | Envoi sur événement (trap) | |
|---|---|---|
| Délai de détection | Jusqu'à un intervalle (une minute, cinq minutes) | Immédiat |
| Fiabilité | Le serveur sait qu'il n'a pas eu de réponse : l'absence est une information | Un trap perdu (UDP, équipement saturé) ne prévient personne |
| Charge | Régulière, prévisible | Faible, mais une avalanche possible lors d'une panne générale |
| Usage typique | Mesures continues : débit, charge, espace disque | Événements ponctuels : port coupé, violation de sécurité de port |
En pratique, on combine les deux : l'interrogation garantit qu'un équipement muet est détecté, le trap réduit le délai pour les événements graves. Le vocabulaire varie selon les auteurs : certains appellent « supervision active » l'interrogation par le serveur et « passive » la réception de traps, alors que Zabbix appelle « actif » l'agent qui envoie. Dans une copie, décris le sens de la connexion et le port, et il n'y aura pas d'ambiguïté.
Les outils du marché
| Outil | Licence | En deux mots |
|---|---|---|
| Zabbix | Libre (AGPLv3 depuis la version 7.0) | Tout-en-un : collecte, stockage, seuils, alertes, cartes, tableaux de bord. L'outil de ce cours |
| Centreon | Cœur libre, éditions commerciales | Éditeur français, héritier de Nagios, très présent dans les administrations et les collectivités |
| Nagios Core | Libre | Le pionnier (1999) : des greffons qui répondent OK, WARNING ou CRITICAL. Base de Centreon, Icinga et Checkmk |
| Prometheus et Grafana | Libres | Collecte de métriques par interrogation HTTP, très utilisée avec les conteneurs et Kubernetes |
| Uptime Kuma | Libre | Surveillance simple de la disponibilité de sites et de ports, en un conteneur : idéal pour une petite structure |
| LibreNMS, PRTG, Checkmk | Libre ; commerciaux | Supervision réseau par SNMP ; supervision tout-en-un clés en main |
Le chapitre 12 les compare en détail. Ce cours utilise Zabbix parce qu'il couvre seul tout ce que demande le référentiel (agents, SNMP, alertes, cartes, tableaux de bord, rapports de disponibilité), qu'il est gratuit et très demandé dans les offres de stage et d'alternance, et que Grafana s'y branche directement.
Le fil rouge : la supervision de Sorbier
Sorbier Logistique a un siège à Lyon, une agence à Marseille et un entrepôt à Saint-Priest. Au siège, le pare-feu pfSense route et filtre tous les VLAN, comme l'a décidé le cours Cybersécurité des infrastructures : chaque flux entre deux zones le traverse et doit être autorisé.
| VLAN | Nom | Réseau | Passerelle (pfSense) | Ce qui s'y trouve |
|---|---|---|---|---|
| 10 | POSTES | 192.168.10.64/26 | 192.168.10.126 | Postes des salariés, imprimantes |
| 20 | SERVEURS | 192.168.10.176/28 | 192.168.10.190 | srv-ad .177 (Active Directory, DNS, DHCP), srv-fichiers .178, srv-gestion .179 (application de gestion des livraisons), srv-journaux .180 (supervision), srv-ad2 .181, srv-collecte .182 (collecteur d'événements Windows) |
| 30 | ENTREPOT | 192.168.10.128/27 | 192.168.10.158 | Terminaux de scan, imprimantes d'étiquettes |
| 40 | VISITEURS | 192.168.10.0/26 | 192.168.10.62 | Wi-Fi invité |
| 50 | TELEPHONIE | 192.168.10.160/28 | 192.168.10.174 | Téléphones IP, caméras |
| 60 | DMZ | 192.168.10.224/28 | 192.168.10.238 | srv-web .225 (site public de suivi des livraisons) |
| 99 | ADMIN | 192.168.10.208/28 | 192.168.10.222 | Poste d'administration .209, bastion .210, interfaces de gestion des switchs (SW-ETAGE1 .211, SW-ETAGE2 .212…) |
L'agence de Marseille utilise 10.30.0.0/23 ; ses serveurs sont dans 10.30.1.160/28 (srv-mrs, 10.30.1.161, y distribue les adresses). L'entrepôt de Saint-Priest utilise 10.40.0.0/24. Les trois sites sont reliés par des liens loués (cours Routage et commutation). L'adresse publique du siège est 203.0.113.17.
Le service informatique (Antoine Mercier, le responsable, et deux techniciens, Chloé Lambert et Moussa Diallo) installe Zabbix et Grafana sur srv-journaux, une VM Debian 13 hébergée sur le cluster Proxmox VE. Le plan est le suivant ; chaque chapitre en réalise une partie.
Remarque déjà une conséquence du cloisonnement : les serveurs du VLAN 20 sont dans le même réseau que srv-journaux, leurs échanges avec Zabbix ne traversent pas le pare-feu. Tout le reste (la DMZ, les équipements du VLAN 99, l'agence) demande une règle précise sur pfSense. Le plan de supervision et la matrice des flux s'écrivent ensemble.
La supervision dans ton BTS
- Épreuve E6 SISR (bloc 2). La compétence « Exploiter, dépanner et superviser une solution d'infrastructure réseau » comprend la sous-compétence « gérer des indicateurs et des fichiers d'activité des éléments d'une infrastructure ». L'environnement technologique de l'épreuve doit comporter une solution de supervision avec remontée d'alertes (environnement exigé). Une réalisation qui installe Zabbix, supervise des serveurs et des équipements réseau et prouve qu'une alerte arrive est un classique solide ; l'épreuve blanche n° 2 en est un exemple complet.
- Épreuve E5 (bloc 1, commune aux deux options). La compétence « Gérer le patrimoine informatique » comprend « vérifier les conditions de la continuité d'un service informatique », et la compétence « Répondre aux incidents et aux demandes d'assistance et d'évolution » demande de « collecter, suivre et orienter des demandes » : une alerte de supervision qui ouvre un ticket en est le point de départ. Une supervision qui mesure la disponibilité d'un service et ouvre un ticket dans GLPI illustre les deux (cours GLPI, réalisations de l'E5).
- Écrit E7 SISR « Cybersécurité des services informatiques ». Les sujets demandent comment être alerté d'un incident (traps SNMP, SNMPv3, journalisation centralisée), quels flux ouvrir pour la supervision, comment détecter une anomalie (thèmes systèmes de l'E7 SISR).
Exercices
Exercice 1 sur 3 Supervision ou métrologie ? Réussi À revoir
Classe chaque besoin : supervision (alerte sur l'état présent), métrologie (mesure dans la durée) ou les deux.
- Être prévenu quand le service d'impression de srv-fichiers s'arrête.
- Savoir si le lien vers Marseille devra être augmenté l'an prochain.
- Fournir à la direction le taux de disponibilité mensuel du site de suivi des livraisons.
- Être prévenu quand le disque de srv-journaux dépasse 90 %, et savoir dans combien de jours il sera plein.
Voir la réponseMasquer la réponse de l'exercice 1
- Supervision : un état (service arrêté) et une alerte immédiate.
- Métrologie : un historique du débit sur plusieurs mois, une tendance, une décision de dimensionnement.
- Métrologie : le taux se calcule à partir de l'historique des tests de disponibilité ; aucune alerte n'est demandée.
- Les deux : le seuil à 90 % déclenche une alerte (supervision), la prévision de remplissage s'appuie sur la tendance mesurée (métrologie). Zabbix sait faire les deux avec la même mesure (prévoir la saturation).
Tu avais trouvé ?
Exercice 2 sur 3 Le plan de supervision de srv-gestion Réussi À revoir
L'application de gestion des livraisons tourne sur srv-gestion (192.168.10.179, Debian 13, Nginx, PHP-FPM, MariaDB). Les salariés l'ouvrent en HTTPS depuis le VLAN 10. Propose au moins une mesure pour chaque couche : réseau, système, services, application, expérience utilisateur.
Voir la réponseMasquer la réponse de l'exercice 2
| Couche | Mesure proposée |
|---|---|
| Réseau | Ping depuis srv-journaux (pertes et temps de réponse) ; état et débit du port du switch ou de la carte virtuelle |
| Système | Charge processeur, mémoire disponible, espace libre de / et du volume de la base, nombre de processus, écart d'heure avec le serveur NTP |
| Services | Processus nginx, php8.4-fpm et mariadb en fonctionnement ; port TCP 443 qui répond ; port 3306 joignable en local |
| Application | Temps de réponse de la page de connexion, nombre de connexions à la base, taille des files de travail, erreurs dans le journal de l'application |
| Expérience utilisateur | Scénario web qui ouvre https://gestion.ad.sorbier.example/, vérifie le code 200 et un texte de la page, en moins de 3 secondes, toutes les minutes |
Le dernier test compte le plus : c'est lui qui dit si l'utilisateur peut travailler. Les autres servent à trouver la cause quand il échoue.
Tu avais trouvé ?
Exercice 3 sur 3 Interrogation ou trap ? Réussi À revoir
- Un switch envoie un trap à chaque coupure de port. Pourquoi ne suffit-il pas à garantir qu'on détectera la panne complète du switch ?
- Quelle mesure ajouter pour combler ce manque ?
- Pourquoi ne pas tout faire par interrogation, toutes les dix secondes ?
Voir la réponseMasquer la réponse de l'exercice 3
- Un switch hors tension ou planté n'envoie plus rien, ni trap ni message : son silence ressemble à un fonctionnement normal. De plus, un trap circule en UDP sans accusé de réception : il peut se perdre.
- Une interrogation régulière : un ping toutes les minutes, et une requête SNMP (par exemple la durée de fonctionnement,
sysUpTime). Si le switch ne répond plus, le serveur le sait et alerte. Une durée de fonctionnement qui revient à zéro révèle en plus un redémarrage. - La charge : chaque interrogation coûte du réseau, du processeur sur l'équipement et de la place dans la base. Multiplier par six la fréquence sur des centaines de mesures charge tout le monde pour un gain faible. On choisit l'intervalle selon l'urgence : une minute pour la disponibilité, cinq à quinze minutes pour l'espace disque, une heure ou un jour pour un inventaire.
Tu avais trouvé ?