Dernière modification le 11 janvier 2020
Le modèle traditionnel de monitoring de réseau est basé sur un modèle dit « pull », utilisant SNMP et CLI pour interroger périodiquement les équipements du réseau. Ces méthodes ont des limites inhérentes en matière d’évolutivité et sont gourmandes en ressources, en particulier lorsqu’un grand nombre de métriques sont interrogées à une fréquence très élevée.
JTI (Junos Telemetry Interface) contourne le problème et élimine le besoin de scrutation, en utilisant plutôt un modèle « push » pour transmettre les données de télémétrie à un collecteur de manière asynchrone sous forme de flux. Cette approche est beaucoup plus évolutive et prend en charge la surveillance de milliers d’objets dans un réseau avec une résolution granulaire.
Cependant, la collecte de données de télémétrie n’est pas une tâche aisée, car elle implique généralement trois types de fonctions :
- Collecte et analyse des données de télémétrie à l’aide d’un moteur de collecte de données approprié, tel que FluentD, Telegraf, Logstash, etc…
- Persistance des données de télémétrie collectées dans un datastore, qu’il s’agisse d’un fichier, d’une base de données time-series (telle que InfluxDB) ou même d’une plate-forme de streaming distribuée (telle qu’Apache Kafka).
- Affichage de la télémétrie collectée à l’aide d’un type d’outil de visualisation de données ou de tableau de bord, tel que Grafana ou Kibana.
Juniper OpenNTI est un exemple d’implémentation Open Source de ce concept de télémétrie.
Les deux aspects les plus intéressants de cette approche de la télémétrie sont les deux modes « push » proposés par Juniper :
- Native Streaming : Ce format utilise un modèle de données propriétaire défini par Juniper et basé sur gpb ( Google protocol buffers ) comme moyen de sérialiser et de structurer les messages de données de télémétrie. Les données sont transportées via UDP et sont exportées au plus proche de la source comme depuis une line card ou une NPU ( Network Processing Unit ).
- OpenConfig Streaming : Ce format utilise le modèle de données OpenConfig et la paire key/value des « Google protocol buffer messages » pour la transmission en continu des données de télémétrie. Contrairement au format natif, les données sont transportées via gRPC sur HTTP2 et sont exportées vers le collecteur de manière centralisée à partir du Routing Engine (RE).
Alors que le mode natif ne peux passer qu’en In-Band (par un port de l’architecture réseau), le mode OpenConfig passe par le Out-of-Band (port spécifique de gestion des équipements), ce qui en fait un choix privilégié pour les approches d’automatisation actuelles.