Cisco France Blog

Cisco France Blog / Réseaux / J’ai testé… la streaming telemetry avec IOS-XE

7 December 2023 Leave a Comment
Réseaux

J’ai testé… la streaming telemetry avec IOS-XE

4 min read



En tant qu’administrateur réseau, vous devez pouvoir répondre rapidement aux questions du genre :

 

Comment surveillez-vous l’état de votre réseau aujourd’hui ?

Les outils de supervision traditionnels s’appuient sur SNMP afin de remonter les données dans des graphiques.

Pourquoi ? Parce que SNMP est simple à mettre en place, est supporté par tous les produits réseaux / NPM, et bénéficie en plus d’un grand support de la communauté.

Néanmoins, des outils de supervision plus modernes comme ceux de Catalyst Center ou du dashboard Meraki utilisent plutôt de la streaming telemetry,

Pourquoi ? Parce que SNMP présente des limites, surtout lorsque l’on parle de données temps-réel : un transport non fiable, un encodage pas toujours cohérent entre les versions, un manque de flexibilité pour le filtrage, des MIBs pas très lisibles, un impact non négligeable sur le CPU / la mémoire des équipements réseau, …

Autant de points qui ont amené la création de la streaming telemetry.

 

Mais la streaming telemetry, qu’est ce que c’est ?

Lorsque l’on parle de télémétrie, on entend souvent ces deux termes : Model-Driven Telemetry (MDT) et Streaming Telemetry. Deux noms qui font référence à deux aspects importants de la télémétrie moderne :

  • “Model-Driven” signifie que les données sont structurées via YANG, un langage de modélisation de données. Cet élément remplace les MIB en SNMP
  • “Streaming” signifie que les données vont être envoyées directement des équipements réseaux vers le NPM. Cet élément remplace le modèle de “pulling” SNMP avec le SNMP GET

J’en veux ! Comment mettre en place la streaming telemetry sur mes équipements Cisco IOS-XE ?

En pratique, l’implémentation peut sembler complexe. Par où commencer ? Il faut choisir le protocole de transport, mettre en place le collecteur, la base de données et la visualisation, configurer les équipements, et faire communiquer tous ces éléments ensemble…

  • Le protocole de transport : NETCONF, gNMI, gRPC, …
  • Le collecteur : Logstach, Telegraf, Prometheus, Kafka, …
  • La base de données : InfluxDB, ElasticSearch, Prometheus, …
  • L’outil de visualisation : Kibana, Grafana, Splunk, …

 

Il faut choisir !

Dans notre cas, nous allons choisir gRPC pour le transport, et la stack TIG (Telegraf, InfluxDB, et Grafana) pour respectivement le collecteur, la base de données et la visualisation (rien ne vous empêche de faire d’autres choix) :

Maintenant que les choix sont faits, comment allons-nous les mettre en place ? Doit-on le faire à la main ? Je vous rassure, la réponse est non.

Automatisons ce déploiement !

Pour cela, nous allons “dockeriser” la stack TIG, en trois conteneurs : un pour le collecteur (Telegraf), un pour la base de données (InfluxDB), et un pour la visualisation (Grafana) :

Pour créer ces conteneurs, nous avons besoin d’images. Quelles images allons-nous utiliser ? Doit-on les construire nous-mêmes ? Inutile ! Les images sont déjà disponibles dans la librairie Docker :

Maintenant, si l’on veut que nos conteneurs communiquent ensemble, il va falloir leur donner les informations nécessaires (compte admin, token API, …). Comment ? Cela va dépendre de chaque application… certaines utilisent des variables d’environnement, d’autres des fichiers de configuration, et parfois un mélange des deux. Pour savoir comment configurer chaque conteneur, rendez-vous sur la documentations des images.

Dans notre cas :

Dans les faits, voici à quoi ressemble le passage de ces informations aux conteneurs :

Telegraf

docker run --name=telegraf -p 57000:57000 \
    --link influxdb \
    -v ./tg/telegraf.conf:/etc/telegraf/telegraf.conf:ro \
    telegraf

InfluxDB

docker run --name=influxdb -p 8086:8086 \
    -e DOCKER_INFLUXDB_INIT_MODE=setup \
    -e DOCKER_INFLUXDB_INIT_USERNAME=testUser \
    -e DOCKER_INFLUXDB_INIT_PASSWORD=testPassword \
    -e DOCKER_INFLUXDB_INIT_ORG=devnet.com \
    -e DOCKER_INFLUXDB_INIT_BUCKET=devnet \
    -e DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=testToken \
    influxdb

Grafana

docker run --name=grafana -p 3000:3000 \
    --link influxdb \
    -e GF_SECURITY_ADMIN_USER=testUser \
    -e GF_SECURITY_ADMIN_PASSWORD=testPassword \
    -v ./gf/datasources/influxdb.yml:/etc/grafana/provisioning/datasources/influxdb.yml \
    -v ./gf/dashboards:/var/lib/grafana/dashboards \
    grafana/grafana

Une syntaxe un peu lourde, avec beaucoup de variables et de fichiers à spécifier, le tout sur plusieurs conteneurs… Comment simplifier ces opérations ?

Docker compose nous permet de regrouper toutes les informations relatives à plusieurs conteneurs dans un seul fichier YAML :

Telegraf / InfluxDB / Grafana (docker-compose.yml)

version: '3.6'
services:

  telegraf:
    image: telegraf
    container_name: telegraf
    restart: always
    volumes:
      - ./tg/telegraf.conf:/etc/telegraf/telegraf.conf:ro
    depends_on:
      - influxdb
    links:
      - influxdb
    ports:
      - '57000:57000'

  influxdb:
    image: influxdb
    container_name: influxdb
    ports:
      - '8086:8086'
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=testUser
      - DOCKER_INFLUXDB_INIT_PASSWORD=testPassword
      - DOCKER_INFLUXDB_INIT_ORG=devnet.com
      - DOCKER_INFLUXDB_INIT_BUCKET=devnet
      - DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=testToken

  grafana:
    image: grafana/grafana
    container_name: grafana
    restart: always
    depends_on:
      - influxdb
    environment:
      - GF_SECURITY_ADMIN_USER=testUser
      - GF_SECURITY_ADMIN_PASSWORD=testPassword
    links:
      - influxdb
    ports:
      - '3000:3000'
    volumes:
      - ./gf/datasources/influxdb.yml:/etc/grafana/provisioning/datasources/influxdb.yml
      - ./gf/dashboards:/var/lib/grafana/dashboards

Dans ce fichier, on retrouve quasiment toutes les informations nécessaires au bon fonctionnement de nos conteneurs. Nous avons le nom des conteneurs, les ports, les variables d’environnement, les chemins des fichiers de configuration, … il nous manque simplement les fichiers de configuration eux-mêmes, à savoir :

Le pipeline est prêt ! Il faut maintenant que les équipements réseaux envoient les données à Telegraf. C’est dans la configuration de ces équipements que nous allons spécifier les données désirées, et leurs destinataires.

Dans notre cas, voici un exemple de configuration :

telemetry ietf subscription 101
    encoding encode-kvgpb
    filter xpath /access-point-oper-data/ssid-counters/tx-bytes-data
    source-address 10.1.0.1
    stream yang-push
    update-policy periodic 60000
    receiver ip address 10.2.0.1 57000
    protocol grpc-tcp

C’est la ligne filter xpath qui définit les données à envoyer. Si vous ne savez pas comment formater le chemin, je vous invite à découvrir les bases de YANG, puis de voir comment bien s’outiller avec YANG Suite

Concrètement, une dizaine de lignes de configuration par souscription et par équipement sont nécessaires. Si nous avons un grand parc réseau avec des centaines d’équipements et des dizaines de métriques à surveiller, le nombre de lignes de configuration va vite exploser… Là aussi, un peu d’automatisation va nous aider !

Dans l’exemple, l’administrateur réseau utilise Ansible pour rajouter la configuration nécéssaire aux équipements réseau. Si vous vous demandez comment faire, j’avais écrit un article sur le sujet : Manager vos équipements Cisco avec Ansible

Et voilà le résultat !

Les équipements sont configurés, le pipeline est en place, nous n’avons plus qu’à regarder les dashboards sur Grafana :

 

Vous voulez voir un déploiement grandeur nature ?

La streaming telemetry est déployée sur l’infrastructure du Cisco Live chaque année. Si vous souhaitez voir la stack TIG en live sur une infrastructure réseau avec plus de 20 000 clients, n’hésitez pas à nous rejoindre à Amsterdam du 5 au 9 février 2024 !

 

Références

 

Authors

Avatar

Xavier VALETTE

Solutions Engineer

Laisser un commentaire