Télémétrie · Méthodologie de mesure

Télémétrie passive et mesure active : pourquoi il faut les deux

Note méthodologique — supervision vs. qualification

Un dashboard peut être entièrement vert et votre application peut quand même perdre des paquets. Ce n'est pas une contradiction : la télémétrie (gNMI, streaming, SNMP) et la mesure active répondent à deux questions différentes, et confondre les deux est la cause la plus commune d'incidents « invisibles » jusqu'à ce qu'un utilisateur se plaigne.

Deux questions, pas une

La télémétrie passive répond à : qu'est-ce que chaque équipement observe de lui-même, en continu ? Compteurs d'interface, charge CPU, files d'attente, flaps — tout ce qu'un équipement sait déjà sur son propre état. La mesure active répond à une question structurellement différente : que vivrait un flux précis, avec un protocole précis, s'il traversait ce chemin maintenant ? On génère du trafic réel — RTP, UDP, multicast — et on mesure ce qu'il subit, de bout en bout.

Où la télémétrie seule se trompe

Un lien WAN peut afficher 0 % de perte au niveau interface — le compteur ne voit que les trames qu'il a reçues et retransmises correctement — pendant qu'un chemin asymétrique ou une congestion en aval dégrade un flux UDP temps réel que personne ne génère pour vérifier. Un MOS dégradé, une gigue excessive sur un flux multicast, une perte en rafale corrélée à un pic d'un autre trafic : rien de tout cela n'apparaît dans un compteur SNMP ou gNMI, parce que ces métriques décrivent l'équipement, pas le service.

Notre position

C'est pourquoi notre outil ne cherche pas à remplacer la supervision en place — il la complète là où elle est structurellement aveugle : en générant le trafic réel que la télémétrie ne peut qu'observer après coup, sur les chemins et les protocoles qui comptent pour vous, et en le rejouant à l'identique pour comparer avant/après une migration, un changement de config, ou une évolution d'architecture.