Qu'est-ce que la supervision réseau ?

Qu'est-ce que la supervision réseau ?

La supervision réseau est l'observation continue du réseau qui relie vos serveurs, vos services et vos utilisateurs : équipements comme les routeurs, commutateurs et pare-feu, liens entre eux et trafic qui y circule. Son but est de repérer un lien saturé, une interface qui perd des paquets ou une route défaillante avant que les utilisateurs ne constatent des pages lentes ou des appels d'API en échec.

Le résultat est généralement une vue de topologie, des graphiques par interface, des alertes sur des seuils comme l'usage de la bande passante ou les compteurs d'erreurs, et des enregistrements de flux (NetFlow, sFlow, IPFIX) qui répondent à « quel trafic a traversé ce lien à 14 h 32 ». Parmi les outils du domaine : Zabbix, LibreNMS, Nagios et PRTG.

Supervision réseau, infrastructure et applicative

Les trois couches se recoupent côté outils, mais répondent à des questions différentes :

• La supervision réseau surveille les tuyaux : usage des liens, perte de paquets, changements de routage, résolution DNS. Elle répond à « le réseau est-il lent ? »
• La supervision d'infrastructure surveille les hôtes : CPU, mémoire, disque, conteneurs. Elle répond à « ce serveur est-il surchargé ? »
• La supervision des performances applicatives surveille le code : latence par endpoint, requêtes lentes, taux d'erreur. Elle répond à « pourquoi le paiement est-il lent pour ce client ? »

Une exploitation complète utilise les trois.

Ce que couvre la supervision réseau

• Disponibilité : ping (ICMP), état SNMP actif ou inactif et tests d'accès aux ports à intervalles fixes.
• Bande passante et débit : octets par seconde par interface, pic par rapport à la moyenne, usage par centile dans le temps.
• Perte, latence et gigue (jitter) : mesurées par des sondes actives ou par analyse passive des flux ; les trois grandeurs qui pénalisent d'abord la voix, la vidéo et le temps réel.
• Routage et état des protocoles : état des sessions BGP, changements de voisins OSPF.
• Données de flux : enregistrements par conversation pour la planification de capacité et l'analyse forensique.
• Dérive de configuration : configurations d'équipements sauvegardées et comparées, avec alerte en cas de changement inattendu.

Métriques clés

1. Disponibilité : pourcentage du temps pendant lequel un équipement ou un lien est joignable.
2. Utilisation de la bande passante : part de la capacité du lien utilisée, souvent lue au 95e centile.
3. Perte de paquets : paquets perdus rapportés aux paquets envoyés.
4. Latence et gigue : temps aller-retour et sa variation (voir latence).
5. Compteurs d'erreurs et de rejets : erreurs CRC et pertes en sortie ; des valeurs durablement non nulles pointent un problème de câblage, d'optique ou de tampon.
6. Temps de résolution DNS : un résolveur lent retarde la première requête vers n'importe quel hôte.

Exemple et mise en place

Des utilisateurs d'une région signalent un paiement lent, alors que les tableaux de bord applicatifs semblent normaux. La vue réseau montre le lien de cette région à pleine capacité, avec des pertes en sortie sur une interface. La cause est le trafic, pas le code, et la solution est plus de capacité ou une régulation du trafic.

Pour la mise en place : interrogez les équipements par SNMP, ou par télémétrie en continu sur le matériel récent, et stockez les séries temporelles. Ajoutez des sondes actives entre sites pour la latence et la perte, et un collecteur de flux pour voir chaque conversation. Construisez des tableaux de bord par site et par service, et alertez sur ce qui touche l'utilisateur (perte, latence, saturation) plutôt que sur chaque compteur.

Lien avec les tests de charge

Quand un test de charge montre des temps de réponse qui montent, la supervision réseau aide à savoir si la limite est dans le réseau, comme un lien saturé ou des pertes de paquets, ou au-dessus, dans l'application ou la base de données. Lisez les deux signaux ensemble avant une mise en production. Les guides sur la gigue réseau dans les tests de charge cloud et les protocoles réseau en test de performance approfondissent le sujet.

Ce que LoadFocus couvre, et ce qu'il ne couvre pas

LoadFocus n'est pas un outil de supervision d'équipements réseau : il n'interroge ni routeurs ni commutateurs en SNMP et ne collecte pas de données de flux. Il contrôle de l'extérieur, comme le ferait un utilisateur. La surveillance d'API exécute des contrôles planifiés depuis 25 régions cloud au choix et décompose chaque temps de réponse en attente, DNS, connexion TCP, premier octet et téléchargement. Elle propose aussi des contrôles TCP (un port est-il ouvert et accepte-t-il les connexions) et DNS (vos enregistrements se résolvent-ils vers les bonnes valeurs). Les contrôles gratuits tournent toutes les 5 minutes. C'est une forme de surveillance synthétique : elle montre si les utilisateurs d'une région voient un problème, pas quel équipement le cause.

Questions fréquentes : supervision réseau

Qu'est-ce que la supervision réseau, en bref ?

C'est surveiller la santé du réseau qui relie vos serveurs et vos utilisateurs, pour trouver tôt un lien ou un équipement défaillant. Elle mesure disponibilité, bande passante, perte de paquets et latence.

Quelle différence entre supervision et administration réseau ?

La supervision observe et alerte. L'administration inclut aussi la modification du réseau : configurer les équipements, appliquer des mises à jour et corriger les pannes. Beaucoup d'outils combinent les deux.

Quels protocoles la supervision réseau utilise-t-elle ?

Les plus courants sont SNMP pour l'état et les compteurs des équipements, ICMP pour le ping, NetFlow, sFlow ou IPFIX pour les flux de trafic, et la télémétrie en continu sur le matériel récent.

La supervision réseau remplace-t-elle la supervision applicative ?

Non. Elle indique si le réseau est sain, pas pourquoi un endpoint ou une requête précis est lent. Il faut aussi de la supervision d'infrastructure et applicative.

LoadFocus peut-il superviser mes routeurs et commutateurs ?

Non. LoadFocus contrôle des sites web et des API de l'extérieur, avec des contrôles HTTP, TCP et DNS depuis des régions cloud. Il n'utilise pas SNMP et ne collecte pas de données de flux.