Foxency
Wi-Fi, Cloud et Technologies Réseau

Télémétrie, SNMP et observabilité

SNMP interroge les équipements toutes les quelques minutes ; la télémétrie en flux pousse des données structurées en continu. Comment combiner métriques, flux, journaux et télémétrie pour comprendre réellement son réseau.

Par Rédaction Foxency Publié le 5 min de lecture

Équipements réseau envoyant en continu des données de télémétrie vers une plateforme d'observabilité

La supervision classique répond à la question « est-ce que ça fonctionne ? » : un équipement répond-il, un lien est-il actif, un seuil est-il dépassé ? L'observabilité vise une question plus large : « pourquoi ça se comporte ainsi ? ». Elle s'appuie sur des données plus riches, plus fréquentes et mieux structurées, collectées par plusieurs mécanismes complémentaires.

Objectif : comprendre les limites de SNMP, les apports de la télémétrie en flux, des données de flux et des journaux, et la manière de les combiner dans une chaîne d'observabilité. La mise en œuvre pratique de SNMP est détaillée dans Supervision réseau avec SNMP et outils de monitoring.

Les limites de SNMP

SNMP reste universel et indispensable, mais il présente des limites structurelles :

  • Modèle par interrogation (pull) : le collecteur demande les valeurs à intervalle fixe, souvent de 1 à 5 minutes. Un pic de trafic de 30 secondes peut passer inaperçu dans une moyenne sur 5 minutes.
  • Coût pour l'équipement : interroger fréquemment de grandes tables (interfaces, routes) sollicite le processeur de contrôle.
  • MIB hétérogènes : de nombreuses informations utiles sont dans des MIB propriétaires.
  • Données peu structurées pour l'analyse moderne, et sécurité dépendante de SNMPv3.

La télémétrie en flux

Avec la télémétrie en flux (streaming telemetry), c'est l'équipement qui pousse (push) les données vers un collecteur :

  • périodiquement, à une fréquence élevée (par exemple toutes les 10 secondes ou moins) ;
  • ou sur changement (on-change) : l'état d'une interface ou d'un voisin BGP est envoyé dès qu'il évolue.

Les données sont structurées selon des modèles YANG (modèles natifs des constructeurs, modèles IETF ou OpenConfig) et encodées efficacement (Protocol Buffers, JSON).

Les protocoles

Mécanisme Transport Remarque
gNMI (gRPC Network Management Interface) gRPC sur HTTP/2, TLS Abonnement à des chemins YANG ; spécifié par le projet OpenConfig ; largement adopté
NETCONF / RESTCONF SSH / HTTP Abonnements YANG-Push (RFC 8641)
Télémétrie dite « dial-out » des constructeurs gRPC, TCP, UDP L'équipement initie la connexion vers le collecteur

Exemple de chemin OpenConfig pour les compteurs d'interface :

/interfaces/interface[name=GigabitEthernet1/0/1]/state/counters

Un abonnement gNMI à ce chemin, avec un intervalle de 10 secondes, fournit des compteurs précis sans interroger toute la table des interfaces.

Exemple de chaîne de collecte

Une chaîne libre courante :

Équipements ──gNMI──▶ collecteur (Telegraf, gNMIc) ──▶ base de séries temporelles (InfluxDB, Prometheus) ──▶ visualisation et alertes (Grafana)

Configuration indicative d'un abonnement avec l'outil gNMIc :

targets:
  sw-acc-e2-01:57400:
    username: telemetrie
    password: ${GNMI_PASSWORD}
    tls-ca: /etc/gnmic/ac-interne.pem
subscriptions:
  compteurs-interfaces:
    paths:
      - /interfaces/interface/state/counters
    mode: stream
    stream-mode: sample
    sample-interval: 10s
outputs:
  prometheus:
    type: prometheus
    listen: :9804

La disponibilité de gNMI, les modèles pris en charge et la configuration côté équipement dépendent de la plateforme et de la version logicielle : consultez le guide de programmabilité de votre constructeur.

Les données de flux

Les compteurs disent combien de trafic passe sur une interface ; les données de flux disent qui parle à qui. Les routeurs, commutateurs et pare-feu exportent des enregistrements résumant chaque flux (adresses, ports, protocole, volume, durée) :

  • NetFlow (Cisco, version 9 décrite dans la RFC 3954) ;
  • IPFIX (standard IETF, RFC 7011), dérivé de NetFlow v9 ;
  • sFlow : échantillonnage de paquets, très utilisé sur les commutateurs à haut débit.

Usages : identifier les applications et machines qui saturent un lien, planifier la capacité, détecter des comportements anormaux (balayage, exfiltration), vérifier une politique de filtrage.

L'échantillonnage (1 paquet sur N) réduit la charge sur les équipements à haut débit, au prix d'une précision statistique.

Les journaux et événements

Les journaux (syslog, journaux des contrôleurs, des pare-feu) apportent le contexte : un voisin OSPF perdu, une interface qui bascule, une modification de configuration. Corrélés aux métriques, ils expliquent souvent la cause d'une anomalie. Voir Analyse et gestion des journaux système.

Les tests actifs

Les mesures passives ne voient que le trafic existant. Les tests actifs (sondes synthétiques) mesurent en continu la latence, la gigue, les pertes ou le temps de réponse d'un service : IP SLA sur Cisco, TWAMP (RFC 5357), sondes HTTP et DNS depuis plusieurs sites. Ils détectent une dégradation avant que les utilisateurs ne s'en plaignent.

Combiner les sources

Source Question à laquelle elle répond Granularité
SNMP L'équipement et ses interfaces sont-ils en bonne santé ? Minutes
Télémétrie en flux Comment évoluent précisément états et compteurs ? Secondes, ou à chaque changement
Données de flux Qui consomme la bande passante ? Quels échanges ont lieu ? Par flux
Journaux Que s'est-il passé et quand ? Par événement
Tests actifs Quelle est l'expérience réelle d'un service ? Selon la fréquence des sondes

L'observabilité naît de la corrélation : un pic de latence mesuré par une sonde, associé à une saturation visible en télémétrie, expliqué par un flux de sauvegarde identifié en IPFIX et déclenché après une modification consignée dans les journaux.

Bonnes pratiques

  • Commencer par les besoins : quelles questions voulez-vous pouvoir résoudre ? Quels indicateurs pour vos services critiques ?
  • Conserver SNMP pour l'inventaire, les équipements anciens et les informations non disponibles autrement.
  • Introduire la télémétrie progressivement sur les équipements récents et les liens critiques.
  • Normaliser les noms d'équipements et d'interfaces, et enrichir les données (site, rôle, criticité) pour des tableaux de bord lisibles.
  • Maîtriser le volume : fréquence, rétention et agrégation adaptées, car la télémétrie à haute fréquence génère beaucoup de données.
  • Sécuriser : TLS pour gNMI, comptes dédiés en lecture, réseau de gestion, contrôle d'accès aux plateformes de données.
  • Définir des alertes sur les symptômes perçus par les utilisateurs (latence, pertes, disponibilité des services), pas seulement sur les ressources.

Erreurs courantes

  • Tout collecter à haute fréquence sans besoin identifié, et saturer le stockage.
  • Moyennes trop longues qui masquent les pics.
  • Sources non corrélées : métriques, flux et journaux dans des outils séparés, sans horodatage commun.
  • Oublier la synchronisation horaire des équipements.
  • Abandonner SNMP trop tôt, alors qu'une partie du parc ne prend pas en charge la télémétrie.

Conclusion

L'observabilité réseau combine des sources complémentaires : SNMP pour la base, télémétrie en flux pour la précision temporelle, données de flux pour comprendre les échanges, journaux pour le contexte, tests actifs pour l'expérience réelle. Leur valeur vient de leur corrélation. Pour exploiter ces données dans vos propres outils, voir Automatisation réseau avec Python.

Références