Configuration et vérification de la télémétrie sur la plate-forme Nexus
Table des matières
Introduction
Ce document décrit comment mettre en oeuvre et vérifier la télémétrie en continu sur les commutateurs Cisco Nexus 9000 exécutant Cisco NX-OS.
Conditions préalables
Exigences
Cisco vous recommande d'avoir des connaissances de base sur les sujets suivants :
- CLI Cisco NX-OS
- Connectivité IP de base de couche 3
- Concepts de surveillance réseau de base
- Connaissance de base des concepts de télémétrie réseau
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
| Composante | Plate-forme/Logiciels | Version / Valeur | Objectif |
|---|---|---|---|
| N9K-TÉLÉMÉTRIE-SW1 | N9K-C9348GC-FXP | 10.6(4) | Source de télémétrie |
| Récepteur de télémesure | Serveur Ubuntu | 22.04.5 | Récepteur de télémesure externe |
| Application de télémétrie | Telegraf | 1.40.0 | Récepteur de télémétrie GPB (Google Protocol Buffers) sur gRPC |
| Port d'écoute | TCP | 57000 | Port récepteur de télémesure |
| Format de sortie du récepteur | Notation d'objet JavaScript (JSON) | — | Sortie de télémétrie lisible par l'homme |
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Topologie
Ces travaux pratiques utilisent un commutateur Cisco Nexus 9000 connecté directement à un serveur Ubuntu qui fonctionne comme récepteur de télémétrie externe.
Le commutateur Nexus et le récepteur de télémétrie sont directement connectés via Ethernet1/10 et les ports 192.
Connectivité Nexus vers le récepteur
Ethernet1/10 fournit une connectivité de couche 3 entre le commutateur Nexus et le récepteur Ubuntu.
La configuration de l’interface est :
N9K-TELEMETRY-SW1# show running-config interface ethernet1/10 interface Ethernet1/10 description TELEMETRY-COLLECTOR ip address 192.168.100.1/24 no shutdown
The Ubuntu receiver uses: Interface: ens192 IP address: 192.168.100.10/24
Informations générales
La surveillance et la visibilité du réseau sont essentielles pour comprendre l'état du réseau, identifier les comportements anormaux et résoudre les problèmes réseau.
Cisco NX-OS fournit plusieurs mécanismes pour récupérer ou exporter des informations opérationnelles à partir d'un commutateur Nexus, notamment l'interface de ligne de commande, le protocole SNMP (Simple Network Management Protocol) et Syslog. Les workflows de surveillance traditionnels, tels que l'interrogation SNMP et la collecte basée sur l'interface de ligne de commande, reposent généralement sur un modèle d'extraction, dans lequel un système de surveillance externe demande périodiquement des informations au périphérique réseau.
La télémétrie en continu introduit un modèle push, dans lequel le périphérique réseau envoie des données opérationnelles sélectionnées vers un récepteur externe en fonction des abonnements configurés. Cela permet d'obtenir un mécanisme structuré de collecte d'informations réseau sans que le système de surveillance n'interroge en permanence le périphérique.
Télémétrie par interrogation traditionnelle et par diffusion en continu
Dans un modèle d'interrogation traditionnel, le système de surveillance détermine le moment où les informations sont récupérées à partir du périphérique réseau.
Par exemple, un système de gestion de réseau (NMS) peut demander des statistiques d'interface toutes les 60 secondes. Cela fournit des instantanés périodiques de l'état du périphérique ; cependant, la visibilité disponible pour l'application de surveillance est directement liée à l'intervalle d'interrogation configuré.
Avec la télémétrie en continu, le commutateur Nexus envoie les informations sélectionnées vers le récepteur de télémétrie conformément à l'abonnement configuré.
Les différences fondamentales peuvent se résumer comme suit :
| Sondage traditionnel | Télémétrie en continu |
|---|---|
| Le client initie la requête. | Le périphérique réseau envoie les données. |
| Modèle de tirage | modèle push |
| Les données sont récupérées en fonction des intervalles d'interrogation. | Les données sont envoyées en fonction d'un abonnement de télémétrie. |
| Fournit généralement des instantanés périodiques. | Prise en charge de la collecte périodique et événementielle. |
| Le système de surveillance demande des informations au périphérique. | Le périphérique transmet les informations sélectionnées vers un récepteur. |
La télémétrie en continu ne remplace pas nécessairement les mécanismes de surveillance traditionnels. CLI, SNMP, Syslog et Telemetry peuvent coexister et servir à des fins opérationnelles différentes.
La principale différence est le modèle de collecte de données.
Cas d'utilisation réels
Dans les environnements de production, la télémétrie en continu est couramment utilisée pour fournir une visibilité continue sur l'état du réseau et du système.
Les exemples d'utilisation typiques incluent la surveillance des compteurs d'interface et des changements d'état, des ressources système telles que l'utilisation du processeur et de la mémoire, et des informations de structure de centre de données telles que les homologues VXLAN (Virtual Extensible LAN) et l'état homologue BGP (Border Gateway Protocol). La télémétrie basée sur les événements peut également être utilisée pour signaler les changements d'état opérationnel au fur et à mesure que les changements se produisent.
Les données télémétriques exportées peuvent ensuite être utilisées par des plates-formes de surveillance et d'observabilité externes pour les tableaux de bord, les alertes, l'analyse historique et le dépannage.
Présentation du traitement télémétrique
À un niveau élevé, la télémétrie en continu sur NX-OS peut être comprise comme quatre étapes principales :
+-----------------------+
| Data Collection |
+-----------+-----------+
|
v
+-----------------------+
| Data Encoding |
+-----------+-----------+
|
v
+-----------------------+
| Data Transport |
+-----------+-----------+
|
v
+-----------------------+
| Telemetry Receiver |
+-----------------------+
Ces étapes répondent à quatre questions de base :
- Collecte de données : Quelles sont les informations collectées ?
- Codage des données : Comment l'information est-elle représentée ?
- Transport de données : Comment les données de télémétrie sont-elles fournies ?
- Récepteur de télémétrie : Où les données de télémétrie sont-elles envoyées ?
Architecture et terminologie de la télémétrie
Collecte des données
La première étape consiste à déterminer les informations à collecter auprès du commutateur.
Pour les exemples de ce document, les données de télémétrie sont collectées à partir du moteur de gestion des données (DME).
Moteur de gestion de données — DME
Le moteur de gestion des données conserve une représentation structurée des informations de configuration et de fonctionnement dans NX-OS.
Au lieu de représenter les informations de périphérique uniquement sous forme de texte CLI, DME organise les informations sous forme d'objets gérés accessibles via des chemins hiérarchiques.
Exemple :
sys/intf/phys-[eth1/10]
Identifie l'objet DME associé à Ethernet1/10.
Les autres chemins DME utilisés dans ces travaux pratiques sont les suivants :
sys/intf/phys-[eth1/10]/dbgIfIn
sys/intf/phys-[eth1/10]/dbgIfOut
sys/intf/phys-[eth1/10]/phys
sys/intf/lb-[lo100]
Chaque chemin représente un objet ou une partie différente des informations disponibles via DME. Il s’agit des mêmes chemins déjà utilisés dans la configuration des travaux pratiques.
Objets gérés et arborescence des informations de gestion
La base de données DME est composée d'objets gérés (MO).
Un objet géré représente une entité du modèle de gestion NX-OS, telle que :
- Une interface physique
- Une interface de bouclage
- Statistiques d'entrée interface
- Statistiques de sortie interface
Les objets gérés sont organisés hiérarchiquement dans une arborescence des informations de gestion (MIT).
Voici une représentation simplifiée des objets utilisés dans ces travaux pratiques :
sys
|
+-- intf
|
+-- phys-[eth1/10]
| |
| +-- dbgIfIn
| +-- dbgIfOut
| +-- phys
|
+-- lb-[lo100]
Cette hiérarchie est utile pour comprendre comment les chemins des capteurs de télémétrie identifient des informations spécifiques dans DME.
Nom distinctif — DN
Chaque objet géré peut être identifié de manière unique par un nom distinctif (DN).
Le DN représente le chemin hiérarchique de la racine de l'arborescence DME à l'objet cible.
For example: sys/intf/lb-[lo100]
Identifie l'objet géré Loopback100.
De même :
sys/intf/phys-[eth1/10]/dbgIfIn
Identifie l'objet de statistiques d'entrée associé à Ethernet1/10.
Une façon simple de comprendre un DN consiste à le considérer comme l'adresse complète d'un objet à l'intérieur de la hiérarchie DME.
Trajectoire Du Capteur
Un chemin de capteur identifie les informations que NX-OS doit surveiller pour un abonnement de télémétrie.
Dans les exemples de travaux pratiques initiaux, les noms distinctifs DME sont utilisés comme chemins de capteur. Un autre exemple pratique illustre l'étiquette de chemin de ressources prédéfinies.
Exemple :
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
Ces chemins fournissent des statistiques d’entrée, de sortie et des informations opérationnelles pour Ethernet1/10.
Codage des données
Une fois que NX-OS a collecté les informations demandées, les données doivent être codées avant de pouvoir être transmises.
Le codage utilisé dans ces travaux pratiques est le protocole GPB (Google Protocol Buffers).
La configuration de destination spécifie :
ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB
Le protocole GPB définit la manière dont les informations télémétriques collectées sont représentées dans le message.
Le codage et le transport sont des fonctions distinctes : Le protocole GPB définit la représentation des données, tandis que le mécanisme de transport détermine la manière dont le message est transmis.
Transport de données
Le protocole de transport utilisé dans ces travaux pratiques est gRPC.
Le commutateur Nexus envoie les données de télémétrie codées GPB à :
192.168.100.10:57000
en utilisant gRPC.
Par conséquent :
Le protocole GPB définit le mode de codage des informations télémétriques.
gRPC fournit le mécanisme de transport utilisé pour transmettre les messages de télémétrie au récepteur.
Le transport gRPC utilisé par la télémétrie en continu ne doit pas être confondu avec l'agent gRPC de NX-OS utilisé pour des services tels que gRPC Network Management Interface (gNMI) et gRPC Network Operations Interface (gNOI).
Récepteur De Télémesure
Le récepteur de télémétrie est le système ou l'application externe qui reçoit et traite le flux de télémétrie.
Au cours de ces travaux pratiques, un serveur Ubuntu exécutant Telegraf est utilisé comme récepteur. Le récepteur écoute sur le port TCP 57000 et accepte le flux de télémétrie GPB sur gRPC généré par le commutateur Nexus.
La mise en oeuvre du récepteur utilisée dans ces travaux pratiques est décrite plus loin dans la section Préparation du récepteur de télémétrie.
Groupe de destinations
Le groupe de destinations définit où les données de télémétrie doivent être envoyées et comment elles doivent être transportées.
Ces travaux pratiques utilisent les éléments suivants :
destination-group 1 ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB use-vrf default
Définit l'adresse du récepteur, le port de destination, le protocole de transport, le codage et l'instance VRF (Virtual Routing and Forwarding) utilisés pour la transmission de télémétrie.
Groupe de capteurs
Le groupe de capteurs définit les informations à surveiller.
Exemple :
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
Dans cet exemple, le groupe de capteurs 2 surveille les statistiques d'entrée, les statistiques de sortie et les informations d'interface opérationnelle Ethernet1/10. Le chemin dbgIfIn fournit des statistiques d'interface d'entrée, dbgIfOut fournit des statistiques d'interface de sortie et phys fournit des informations opérationnelles pour l'interface.
Un groupe de capteurs peut inclure plusieurs chemins de capteurs associés et répond donc à la question suivante :
Quelles données sont collectées ?
Abonnement
Un abonnement associe un groupe de capteurs à un groupe de destinations et définit le comportement de collecte.
Exemple :
subscription 2 dst-grp 1 snsr-grp 2 sample-interval 60000
Dans cet exemple :
- Le groupe de capteurs 2 détermine les informations collectées.
- L'intervalle d'échantillonnage détermine le comportement de collecte.
- Le groupe de destinations 1 détermine où et comment les informations sont envoyées.
L'abonnement connecte donc les principaux éléments de configuration de télémétrie :
Groupe de capteurs + Comportement de collecte + Groupe de destinations
Télémétrie périodique et basée sur les événements
Cisco NX-OS Streaming Telemetry prend en charge la collecte périodique et basée sur les événements pour les abonnements DME.
Le comportement de collecte est contrôlé par l'intervalle d'échantillonnage associé au groupe de capteurs dans un abonnement.
Télémétrie Périodique
Avec la télémétrie périodique, NX-OS collecte et envoie les informations surveillées à un intervalle configuré.
L'intervalle d'échantillonnage est spécifié en millisecondes.
For example: snsr-grp 2 sample-interval 60000
Configure un intervalle de collecte de 60 secondes.
La télémétrie périodique est utile pour les informations qui changent continuellement et qui sont généralement analysées au fil du temps, telles que :
- Compteurs de paquets d'interface
- Compteurs d'octets
- Erreurs et abandons
- Statistiques opérationnelles
- Utilisation des ressources
Dans ces travaux pratiques, les abonnements 1 et 2 utilisent la collecte périodique.
L'abonnement 1 collecte l'objet d'interface Ethernet1/10 toutes les 10 secondes, tandis que l'abonnement 2 collecte des statistiques d'interface et des informations opérationnelles toutes les 60 secondes.
Télémétrie Événementielle
Avec la télémétrie basée sur les événements, NX-OS n'utilise pas de minuteur de collecte récurrent.
Pour la télémétrie basée sur DME, le comportement basé sur les événements est configuré avec :
sample-interval 0
Lorsqu'un objet surveillé change, la télémétrie peut générer une mise à jour associée à cette modification.
Cette méthode de collecte est utile pour obtenir des informations telles que :
- Problèmes liés à la modification de la configuration
- Changements d'état administratif
- Création ou suppression d'objets
- Autres modifications sous un objet DME surveillé
Au cours de ces travaux pratiques, Subscription 3 surveille l'objet DME Loopback100 :
sys/intf/lb-[lo100]: snsr-grp 3 sample-interval 0
Les modifications apportées à l'objet Loopback100 surveillé sont donc utilisées plus loin dans ce document pour illustrer la télémétrie basée sur les événements.
Comportement de collecte utilisé dans les travaux pratiques
Les trois abonnements utilisés dans la configuration initiale des travaux pratiques peuvent être résumés comme suit :
| Abonnement | Informations surveillées | Intervalle D'Échantillonnage | Comportement de collecte |
|---|---|---|---|
| 1 | Objet interface Ethernet1/10 | 10000 ms | Périodique |
| 2 | Statistiques et état opérationnel d’Ethernet1/10 | 60000 ms | Périodique |
| 3 | Objet Loopback100 | 0 | Basé sur les événements |
La principale distinction est le déclencheur utilisé pour générer des données de télémétrie :
| Télémétrie Périodique | Télémétrie Événementielle |
|---|---|
| Utilise un minuteur configuré. | N'utilise pas de minuteur périodique. |
| intervalle-échantillon > 0 | sample-interval 0 |
| Produit des échantillons répétés. | Produit des mises à jour lorsque les objets surveillés changent. |
| Généralement utilisé pour les compteurs et les statistiques. | Généralement utilisé pour les modifications de configuration ou d'état. |
Les sections de configuration et de vérification illustrent les deux comportements de collecte à l'aide des abonnements définis ci-dessus.
Préparation du récepteur de télémétrie
La télémétrie en continu nécessite un récepteur externe capable d'accepter et de traiter les données de télémétrie envoyées par le commutateur Nexus.
Pour le transport GPB sur gRPC utilisé dans ce document, le récepteur doit être capable de :
- Réception de connexions gRPC
- Écoute sur le port de destination configuré
- Décodage des messages de télémétrie GPB
- Traitement ou stockage des données reçues
La mise en oeuvre du récepteur de télémétrie est indépendante de la configuration de télémétrie NX-OS décrite dans ce document.
Remarque : L'installation, la configuration, le fonctionnement et le dépannage de logiciels récepteurs de télémétrie tiers ne sont pas abordés dans ce document. Reportez-vous à la documentation fournie par le fournisseur du récepteur pour obtenir des informations sur la configuration et l'assistance.
Récepteur utilisé dans ces travaux pratiques
À des fins de démonstration, ces travaux pratiques utilisent un serveur Ubuntu externe exécutant Telegraf comme récepteur de télémétrie.
Les paramètres du récepteur sont les suivants :
| Paramètre | Valeur |
|---|---|
| Adresse du destinataire | 192.168.100.10 |
| Transport | gRPC |
| Port d'écoute | TCP/57000 |
| Codage | GPB |
La configuration logicielle côté récepteur n'est pas traitée dans ce document.
Remarque : Les exemples de résultats du récepteur présentés dans ce document sont filtrés pour mettre en surbrillance les champs pertinents pour chaque étape de vérification.
Avant de configurer la télémétrie en continu sur le commutateur Nexus, vérifiez que :
- Il existe une connectivité IP entre le commutateur Nexus et le récepteur.
- L'application du récepteur est en cours d'exécution.
- Le port de destination configuré écoute.
- Le récepteur prend en charge le protocole de transport configuré.
- Le récepteur prend en charge le codage télémétrique configuré.
Pour ces travaux pratiques, Ethernet1/10 sur le commutateur Nexus utilise 192.168.100.1/24 et le récepteur de télémétrie utilise 192.168.100.10/24. L’accessibilité de base de la couche 3 doit être confirmée avant de dépanner un comportement spécifique à la télémétrie.
Une fois que le récepteur est accessible et prêt à accepter la télémétrie GPB-over-gRPC sur le port TCP 57000, la configuration de télémétrie NX-OS peut être appliquée.
Configuration de la télémétrie en continu sur NX-OS
La configuration utilise trois composants principaux :
- Groupe de destinations : Définit où les données de télémétrie sont envoyées et comment elles sont transportées.
- Groupe de capteurs : Définit les informations collectées.
- Abonnement : Associe un groupe de capteurs à un groupe de destinations et définit le comportement de collecte.
Les travaux pratiques utilisent la destination de télémétrie suivante :
| Paramètre | Valeur |
|---|---|
| Destination | 192.168.100.10:57000 |
| Transport | gRPC |
| Codage | GPB |
| VRF | manquer à ses obligations |
La configuration initiale des travaux pratiques utilise trois abonnements :
| Abonnement | Capteur | Type de collection | Intervalle D'Échantillonnage |
|---|---|---|---|
| 1 | Objet interface Ethernet1/10 | Périodique | 10000 ms |
| 2 | Statistiques et état opérationnel d’Ethernet1/10 | Périodique | 60000 ms |
| 3 | Objet Loopback100 | Basé sur les événements | 0 |
Activer la fonctionnalité de télémétrie
La télémétrie en continu doit d'abord être activée globalement.
N9K-TELEMETRY-SW1# configure terminal N9K-TELEMETRY-SW1(config)# feature telemetry
Passez en mode de configuration télémétrique :
N9K-TELEMETRY-SW1(config)# telemetry N9K-TELEMETRY-SW1(config-telemetry)#
La configuration télémétrique restante est effectuée dans ce mode.
Configurer le groupe de destinations
Le groupe de destination identifie le récepteur de télémétrie externe et définit le transport et le codage utilisés pour envoyer les données de télémétrie.
Configurer:
N9K-TELEMETRY-SW1(config-telemetry)# destination-group 1 N9K-TELEMETRY-SW1(conf-tm-dest)# ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB N9K-TELEMETRY-SW1(conf-tm-dest)# use-vrf default
Cette configuration définit :
- Adresse de destination: 192.168.100.10
- Port de destination : 57000
- Transport : gRPC
- Codage : GPB
- VRF : manquer à ses obligations
Le VRF par défaut est utilisé car le récepteur de télémétrie est accessible via Ethernet1/10 dans le VRF par défaut.
Le VRF sélectionné pour le transport de télémétrie doit fournir l'accessibilité IP au récepteur configuré.
Configuration du groupe de capteurs 1
Le groupe de capteurs 1 surveille l'objet interface DME Ethernet1/10.
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 1 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]
Le chemin du capteur identifie l'objet géré Ethernet1/10 dans la hiérarchie DME et fournit des informations d'interface générales associées à cet objet.
Configurer l'abonnement 1
Associer le groupe de capteurs 1 au groupe de destinations 1 :
N9K-TELEMETRY-SW1(config-telemetry)# subscription 1 N9K-TELEMETRY-SW1(conf-tm-sub)# dst-grp 1 N9K-TELEMETRY-SW1(conf-tm-sub)# snsr-grp 1 sample-interval 10000
L'intervalle d'échantillonnage est spécifié en millisecondes.
10000 ms = 10 secondes
L'abonnement 1 collecte donc régulièrement l'objet DME Ethernet1/10 toutes les 10 secondes et envoie les données de télémétrie au groupe de destinations 1.
Configurer le groupe de capteurs 2
Le groupe de capteurs 2 collecte des statistiques et des informations opérationnelles pour Ethernet1/10.
Configurer:
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 2 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]/dbgIfIn N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]/dbgIfOut N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]/phys
Les chemins des capteurs fournissent :
| Trajectoire Du Capteur | Informations |
|---|---|
| sys/intf/phys-[eth1/10]/dbgIfIn | Statistiques d'interface d'entrée |
| sys/intf/phys-[eth1/10]/dbgIfOut | Statistiques d'interface |
| sys/intf/phys-[eth1/10]/phys | Informations d’interface opérationnelle |
Un groupe de capteurs peut contenir plusieurs chemins de capteurs associés, ce qui permet à l'abonnement de collecter plusieurs catégories d'informations à partir de la même interface surveillée.
Configurer l'abonnement 2
Associez le groupe de capteurs 2 au groupe de destinations 1 :
N9K-TELEMETRY-SW1(config-telemetry)# subscription 2 N9K-TELEMETRY-SW1(conf-tm-sub)# dst-grp 1 N9K-TELEMETRY-SW1(conf-tm-sub)# snsr-grp 2 sample-interval 60000
L'intervalle d'échantillonnage configuré est :
60000 ms = 60 secondes
L'abonnement 2 collecte donc les statistiques et les informations opérationnelles d'Ethernet1/10 toutes les 60 secondes.
Cet abonnement est utilisé plus loin dans le document pour vérifier le comportement de télémétrie périodique.
Configuration de l'interface de bouclage
Une interface de bouclage est utilisée pour démontrer la télémétrie basée sur les événements sans nécessiter de connexion physique supplémentaire.
Configurer:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# ip address 10.255.255.100/32
L'objet DME correspondant est :
sys/intf/lb-[lo100]
L'interface de bouclage offre un moyen simple de générer une configuration contrôlée et des changements d'état administratifs lors de la vérification de télémétrie basée sur des événements.
Configuration du groupe de capteurs 3
Configurez le chemin du capteur DME Loopback100 :
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 3 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/lb-[lo100]
Le groupe de capteurs 3 surveille l'objet géré Loopback100.
Configurer l'abonnement 3
Associez le groupe de capteurs 3 au groupe de destinations 1 et configurez la collecte basée sur les événements :
N9K-TELEMETRY-SW1(config-telemetry)# subscription 3 N9K-TELEMETRY-SW1(conf-tm-sub)# dst-grp 1 N9K-TELEMETRY-SW1(conf-tm-sub)# snsr-grp 3 sample-interval 0
Pour les abonnements DME, un exemple d'intervalle de zéro configure le comportement basé sur les événements.
Les modifications effectuées sous l'objet Loopback100 surveillé peuvent donc générer des notifications de télémétrie sans utiliser de minuteur de collecte récurrent.
Cet abonnement est utilisé ultérieurement pour illustrer les changements de description et d'état administratif.
Terminer la configuration télémétrique initiale
Une fois la configuration terminée, vérifiez-la à l'aide des éléments suivants :
N9K-TELEMETRY-SW1# show running-config telemetry feature telemetry telemetry destination-group 1 ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB use-vrf default sensor-group 1 path sys/intf/phys-[eth1/10] sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys sensor-group 3 path sys/intf/lb-[lo100] subscription 1 dst-grp 1 snsr-grp 1 sample-interval 10000 subscription 2 dst-grp 1 snsr-grp 2 sample-interval 60000 subscription 3 dst-grp 1 snsr-grp 3 sample-interval 0
À ce stade, le commutateur dispose de la destination, des groupes de capteurs et des abonnements nécessaires pour commencer à envoyer des données de télémétrie vers le récepteur configuré.
La section suivante vérifie la session de transport et la télémétrie périodique générées par les abonnements Ethernet1/10.
Vérification de la télémétrie périodique
Une fois la configuration télémétrique appliquée, vérifiez que la session de transport est établie, que les groupes de capteurs périodiques sont actifs et que les données télémétriques sont collectées et transmises au récepteur.
Vérification du transport de télémétrie
Exécutez cette commande :
N9K-TELEMETRY-SW1# show telemetry transport Session Id Dst Grp IP Address Port Encoding Transport Status -------------------------------------------------------------------------------- 0 1 192.168.100.10 57000 GPB gRPC Connected -------------------------------------------------------------------------------- Retry buffer Size: 10485760 Event Retry Messages (Bytes): 0 Timer Retry Messages (Bytes): 0 Total Retries sent: 0 Total Retries Dropped: 0 N9K-TELEMETRY-SW1#
L'état Connecté confirme que la session de transport gRPC vers le récepteur de télémétrie configuré est établie.
Les paramètres de transport appropriés correspondent également au groupe de destinations configuré.
Vérification des groupes de capteurs périodiques
Utilisation:
N9K-TELEMETRY-SW1# show telemetry control database Subscription Database size = 3 -------------------------------------------------------------------------------- Subscription ID Data Collector Type Reachability Configuration Method -------------------------------------------------------------------------------- 3 DME Reachable CONFIG_DME-ADMIN 2 DME Reachable CONFIG_DME-ADMIN 1 DME Reachable CONFIG_DME-ADMIN Sensor Group Database size = 3 ---------------------------------------------------------------------------------------------------- Row ID Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions SubID ---------------------------------------------------------------------------------------------------- 1 3 Event /DME 0/No Timer 1 3 Collection Time in ms (Cur/Min/Max): 0/0/0 Encoding Time in ms (Cur/Min/Max): 0/0/0 Transport Time in ms (Cur/Min/Max): 2/1/414 Streaming Time in ms (Cur/Min/Max): 2/1/414 Collection Statistics: collection_id_dropped = 0 last_collection_id_dropped = 0 drop_count = 0 Configuration method: CONFIG_DME-ADMIN 2 2 Timer /DME 60000/Running 1 2 Collection Time in ms (Cur/Min/Max): 0/0/1 Encoding Time in ms (Cur/Min/Max): 0/0/1 Transport Time in ms (Cur/Min/Max): 2/1/415 Streaming Time in ms (Cur/Min/Max): 3/2/416 Collection Statistics: collection_id_dropped = 0 last_collection_id_dropped = 0 drop_count = 0 Configuration method: CONFIG_DME-ADMIN 3 1 Timer /DME 10000/Running 1 1 Collection Time in ms (Cur/Min/Max): 0/0/1 Encoding Time in ms (Cur/Min/Max): 0/0/1 Transport Time in ms (Cur/Min/Max): 2/1/415 Streaming Time in ms (Cur/Min/Max): 3/2/417 Collection Statistics: collection_id_dropped = 0 last_collection_id_dropped = 0 drop_count = 0 Configuration method: CONFIG_DME-ADMIN ---------------------------------------------------------------------------------------------------- Row ID Subscribed Linked Groups Sec Groups Retrieve level Path(GroupId) : Query : Filter ---------------------------------------------------------------------------------------------------- 1 No 1 0 Self sys/intf/phys-[eth1/10](1) : NA : NA <snip> 2 No 1 0 Self sys/intf/phys-[eth1/10]/dbgIfIn(2) : NA : NA <snip> 4 No 1 0 Self sys/intf/phys-[eth1/10]/dbgIfOut(2) : NA : NA
La base de données des groupes de capteurs confirme que les groupes de capteurs périodiques sont actifs :
| Groupe de capteurs | Type | intervalle d’échantillonnage | Abonnement |
|---|---|---|---|
| 1 | Minuteur / DME | 10000 ms / En cours | 1 |
| 2 | Minuteur / DME | 60000 ms / En cours | 2 |
Le groupe de capteurs 1 collecte l'objet d'interface Ethernet1/10 toutes les 10 secondes.
Le groupe de capteurs 2 collecte des statistiques et des informations opérationnelles sur Ethernet1/10 toutes les 60 secondes.
La même commande affiche également les chemins de capteur configurés :
sys/intf/phys-[eth1/10] sys/intf/phys-[eth1/10]/dbgIfIn sys/intf/phys-[eth1/10]/dbgIfOut sys/intf/phys-[eth1/10]/phys
Pour les chemins de capteurs utilisés dans ces travaux pratiques, les temps de collecte et de codage étaient généralement compris entre 0 et 1 ms, et aucune suppression de message de télémétrie n’a été observée.
Vérifier la collecte des données
Utilisation:
N9K-TELEMETRY-SW1# show telemetry data collector brief ------------------------------------------------------------------------------------------------------------------- Row ID Collector Type Successful Payloads Failed Skipped Dropped ------------------------------------------------------------------------------------------------------------------- 1 YANG 0 0 0 0 0 2 DME 513 513 0 44 0 3 NX-API 0 0 0 0 0 N9K-TELEMETRY-SW1#
Les travaux pratiques ont rapporté :
DME Successful Collections: 513 Payloads: 513 Failed: 0 Skipped: 44 Dropped: 0
Les compteurs Successful et Payload confirment que des données de télémétrie DME sont collectées et que des données utiles de télémétrie sont générées.
Les 44 collections ignorées sont des compteurs historiques observés alors que la destination télémétrique était temporairement indisponible pendant les travaux pratiques. Ces compteurs sont examinés ultérieurement dans la section Dépannage de base.
Pour obtenir des informations supplémentaires par chemin de capteur, utilisez :
N9K-TELEMETRY-SW1# show telemetry data collector details
Cette commande permet d'identifier les chemins d'accès de capteur configurés qui ont contribué à la réussite, à l'échec, à l'omission ou à l'abandon des collectes.
Vérification des données périodiques au niveau du récepteur
L'abonnement 2 collecte des statistiques Ethernet1/10 toutes les 60 secondes.
Le récepteur de télémétrie a signalé ces statistiques d'entrée à 21:44:45 temps universel coordonné (UTC) :
timestamp: 2026-09-17T21:44:45Z source: N9K-TELEMETRY-SW1 subscription: 2 path: sys/intf/phys-[eth1/10]/dbgIfIn broadcastPkts: 5074 discards: 0 errors: 0 multicastPkts: 143403 octets: 12870535 ucastPkts: 31256
Une minute plus tard, un autre échantillon a été reçu :
timestamp: 2026-09-17T21:45:45Z source: N9K-TELEMETRY-SW1 subscription: 2 path: sys/intf/phys-[eth1/10]/dbgIfIn broadcastPkts: 5075 discards: 0 errors: 0 multicastPkts: 143430 octets: 12875428 ucastPkts: 31292
Les variations de compteur entre les deux échantillons sont résumées ci-dessous :
| Compteur | 21:44:45 | 21:45:45 |
|---|---|---|
| Paquets de monodiffusion | 31,256 | 31,292 |
| Paquets de multidiffusion | 143,403 | 143,430 |
| Paquets de diffusion | 5,074 | 5,075 |
| Octets | 12,870,535 | 12,875,428 |
| Erreurs | 0 | 0 |
| Rebuts | 0 | 0 |
Les horodatages sont séparés d'environ 60 secondes, correspondant à l'intervalle d'échantillonnage configuré pour l'abonnement 2.
Les compteurs de paquets et d'octets croissants confirment également que des statistiques d'interface mises à jour sont collectées et envoyées au récepteur.
Vérification des informations de sortie et de fonctionnement
Le chemin du capteur dbgIfOut fournit des statistiques de sortie pour Ethernet1/10.
Un échantillon prélevé à 21:45:45 UTC a rapporté :
broadcastPkts: 8 discards: 0 errors: 0 multicastPkts: 4712 octets: 2444721 ucastPkts: 4092
Le chemin du capteur physique fournit des attributs opérationnels pour la même interface.
Le destinataire a signalé :
adminSt: up operSt: up operSpeed: 1G operDuplex: full operMtu: 1500 operDescr: TELEMETRY-COLLECTOR
Ces exemples confirment que le groupe de capteurs 2 fournit des statistiques d'interface et des informations opérationnelles via ses trois chemins de capteurs DME configurés.
Récapitulatif des vérifications périodiques par télémétrie
La vérification télémétrique périodique confirme :
| Vérification | Résultat |
|---|---|
| Session de transport gRPC | connected |
| codage GPB | Confirmé |
| Groupe de capteurs 1 | Exécution à 10000 ms |
| Groupe de capteurs 2 | Exécution à 60000 ms |
| Collections DME | Réussi |
| Collections ayant échoué | 0 |
| Charges utiles abandonnées | 0 |
| Échantillons de récepteur périodiques | Reçu |
| Compteurs d'interface | Mise à jour entre échantillons |
Vérification de la télémétrie événementielle
Après avoir vérifié la télémétrie périodique, utilisez Subscription 3 pour valider la télémétrie basée sur les événements en générant des modifications contrôlées de l'objet géré Loopback100.
Vérification de l'abonnement basé sur des événements
Utilisation:
N9K-TELEMETRY-SW1# show telemetry control database Subscription Database size = 3
--------------------------------------------------------------------------------
Subscription ID Data Collector Type Reachability Configuration Method -------------------------------------------------------------------------------- 3 DME Reachable CONFIG_DME-ADMIN 2 DME Reachable CONFIG_DME-ADMIN 1 DME Reachable CONFIG_DME-ADMIN <snip> Sensor Group Database size = 3 ---------------------------------------------------------------------------------------------------- Row ID Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions SubID ---------------------------------------------------------------------------------------------------- 1 3 Event /DME 0/No Timer 1 3 <snip> Sensor Path Database size = 5 ---------------------------------------------------------------------------------------------------- Row ID Subscribed Linked Groups Sec Groups Retrieve level Path(GroupId) : Query : Filter ---------------------------------------------------------------------------------------------------- 4 Yes 1 0 Self sys/intf/lb-[lo100](3) : NA : NA <snip> Subscription Id: 3 Snapshot Stats: Sent = 1 Error = 0 Drops = 0 The Sensor Group Database reports: Sensor Group ID: 3 Sensor Group Type: Event / DME Sampling Interval: 0 / No Timer Subscription ID: 3 The Event / DME type and 0 / No Timer state confirm that Sensor Group 3 is configured for event-based collection. The associated sensor path is: sys/intf/lb-[lo100]
La même base de données de télémétrie confirme que le chemin du capteur est souscrit via l'abonnement 3.
Générer des mises à jour basées sur des événements
Afin de vérifier la génération d'événements, modifiez la description de Loopback100 :
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# description TELEMETRY-EVENT-DEMO
Le récepteur de télémétrie a signalé :
{
"timestamp": "2026-09-17T21:41:12Z",
"source": "N9K-TELEMETRY-SW1",
"subscription": "3",
"event": {
"descr": "TELEMETRY-EVENT-DEMO",
"dn": "sys/intf/lb-[lo100]",
"status": "modified"
}
}
Le dn identifie l'objet DME surveillé et l'attribut descr identifie la propriété qui a été modifiée.
Ensuite, désactivez et restaurez administrativement l'interface :
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# shutdown
Puis :
N9K-TELEMETRY-SW1(config-if)# no shutdown
Le récepteur a détecté les deux changements d'état.
| Horodatage | Attribut modifié | Valeur |
|---|---|---|
| 21:41:12 | descr | DÉMONSTRATION D'ÉVÉNEMENT DE TÉLÉMÉTRIE |
| 21:41:19 | adminSt | descendant |
| 21:41:24 | adminSt | ascendant |
Chaque mise à jour faisait référence au même objet surveillé :
sys/intf/lb-[lo100]
Il a signalé l'état de l'objet comme modifié.
Ces résultats confirment que les modifications apportées aux différents attributs de l'objet géré surveillé peuvent générer des mises à jour de télémétrie individuelles.
Vérifier le snapshot initial et les messages d'événement
Lorsque l'abonnement basé sur les événements a été établi, NX-OS a généré un instantané initial de l'objet surveillé.
La base de données Sensor Path rapporte :
Statistiques du snapshot :
Sent = 1 Error = 0 Drops = 0
Après les trois modifications contrôlées, le même chemin de capteur a signalé :
Statistiques des messages :
Sent = 3 Error = 0 Drops = 0
Les résultats peuvent donc être résumés comme suit :
| Collecte | Comptage |
|---|---|
| Instantané initial | 1 |
| Modification de description | 1 |
| État administratif désactivé | 1 |
| État administratif activé | 1 |
| Total | 4 |
L'instantané initial représente l'état de l'objet surveillé lorsque la souscription devient active, tandis que les messages suivants correspondent aux modifications de l'objet.
Vérifier les statistiques de collecte des événements
N9K-TELEMETRY-SW1# show telemetry event collector stats -------------------------------------------------------------------------------- Row ID Collection Count Latest Collection Time Sensor Path(GroupId) -------------------------------------------------------------------------------- 1 4 Thu Sep 17 21:41:24.045 UTC sys/intf/lb-[lo100](3) N9K-TELEMETRY-SW1#
Les travaux pratiques ont rapporté :
Collection Count: 4
Latest Collection Time: Thu Sep 17 21:41:24.045 UTC
Sensor Path: sys/intf/lb-[lo100]
Le nombre de collectes correspond à l'instantané initial et aux trois modifications générées au cours du test.
Vérifier les erreurs du collecteur d'événements
N9K-TELEMETRY-SW1# show telemetry event collector errors -------------------------------------------------------------------------------- Error Description Error Count -------------------------------------------------------------------------------- Dme Event Subscription Init Failures - 0 Event Data Enqueue Failures - 0 Event Subscription Failures - 0 Pending Subscription List Create Failures - 0 Subscription Hash Table Create Failures - 0 Subscription Hash Table Destroy Failures - 0 Subscription Hash Table Insert Failures - 0 Subscription Hash Table Remove Failures - 0 N9K-TELEMETRY-SW1#
Aucune erreur du collecteur d'événements n'a été observée pendant le test.
Récapitulatif de vérification de la télémétrie basée sur les événements
La vérification de télémétrie basée sur les événements confirme :
| Vérification | Résultat |
|---|---|
| Groupe de capteurs | 3 |
| Trajectoire Du Capteur | sys/intf/lb-[lo100] |
| Type de collection | Événement / DME |
| intervalle d’échantillonnage | 0 / Pas de minuteur |
| Instantané initial | Envoyé |
| Changement de description | Détecté |
| adminSt Down | Détecté |
| adminSet Up | Détecté |
| Total des collectes | 4 |
| Erreurs du collecteur d'événements | 0 |
La détection réussie des modifications du bouclage contrôlé100 confirme que l'abonnement 3 fonctionne comme prévu.
La section suivante examine les principales commandes de vérification et de dépannage utilisées pour évaluer le fonctionnement de la télémétrie en continu.
Dépannage de base
Lorsque les données de télémétrie ne sont pas reçues comme prévu, commencez le dépannage en déterminant si le problème est lié à la session de transport, à la collecte de données, à la configuration du capteur ou au récepteur externe.
Ce workflow utilise un problème observé au cours de ces travaux pratiques, où NX-OS a signalé 44 collectes ignorées et une erreur de transmission gRPC historique.
Vérification de l'état de transport actuel
N9K-TELEMETRY-SW1# show telemetry transport Session Id Dst Grp IP Address Port Encoding Transport Status -------------------------------------------------------------------------------- 0 1 192.168.100.10 57000 GPB gRPC Connected
-------------------------------------------------------------------------------- Retry buffer Size: 10485760 Event Retry Messages (Bytes): 0 Timer Retry Messages (Bytes): 0 Total Retries sent: 0 Total Retries Dropped: 0 N9K-TELEMETRY-SW1#
Au cours de la vérification finale, la session de télémétrie a rapporté :
Session ID: 0
Destination Group: 1
IP Address: 192.168.100.10
Port: 57000
Encoding: GPB
Transport: gRPC
Status: Connected
Un état Connecté confirme que la session de transport est actuellement établie.
Cependant, l'état actuel de la session n'indique pas nécessairement si des problèmes de connectivité se sont produits plus tôt. Par conséquent, passez également en revue les compteurs de collecte et de transport historiques.
Consulter les compteurs de collecte de données
N9K-TELEMETRY-SW1# show telemetry data collector brief
-------------------------------------------------------------------------------------------------------------------
Row ID Collector Type Successful Payloads Failed Skipped Dropped
-------------------------------------------------------------------------------------------------------------------
1 YANG 0 0 0 0 0
2 DME 513 513 0 44 0
3 NX-API 0 0 0 0 0
N9K-TELEMETRY-SW1#
Les travaux pratiques ont rapporté :
DME Successful Collections: 513
Payloads: 513
Failed: 0
Skipped: 44
Dropped: 0
Les compteurs Successful et Payload confirment que des collectes de télémétrie DME et la génération de données utiles ont eu lieu.
Cependant, le compteur Ignoré indique que 44 collectes planifiées n'ont pas été effectuées.
Afin d'identifier les chemins de capteurs qui ont été affectés, utilisez :
N9K-TELEMETRY-SW1# show telemetry data collector details
--------------------------------------------------------------------------------------------------------------
Row ID Successful Payloads Failed Skipped Dropped Sensor Path(GroupId)
--------------------------------------------------------------------------------------------------------------
1 414 414 0 29 0 sys/intf/phys-[eth1/10](1)
2 54 54 0 5 0 sys/intf/phys-[eth1/10]/dbgIfIn(2)
3 54 54 0 5 0 sys/intf/phys-[eth1/10]/dbgIfOut(2)
4 54 54 0 5 0 sys/intf/phys-[eth1/10]/phys(2)
N9K-TELEMETRY-SW1#
Le résultat détaillé indique :
| Trajectoire Du Capteur | Ignoré |
|---|---|
| sys/intf/phys-[eth1/10] | 29 |
| sys/intf/phys-[eth1/10]/dbgIfIn | 5 |
| sys/intf/phys-[eth1/10]/dbgIfOut | 5 |
| sys/intf/phys-[eth1/10]/phys | 5 |
| Total | 44 |
Les collections ignorées ont été distribuées sur les chemins de détection périodiques, indiquant que le problème n'était pas isolé sur un seul objet DME.
Remarque : Les compteurs de collecte sont cumulatifs. Un compteur historique différent de zéro n'indique pas nécessairement que la même condition est actuellement présente.
Déterminer Pourquoi Les Collections Ont Été Ignorées
N9K-TELEMETRY-SW1# show telemetry control stats
--------------------------------------------------------------------------------
Error Description Error Count
--------------------------------------------------------------------------------
<snip>
Collections skipped due to destination unreachable 44
<snip>
N9K-TELEMETRY-SW1#
Ce résultat identifie directement la raison pour laquelle les collections ont été ignorées :
Destination inaccessible = 44
La valeur correspond aux 44 collections ignorées signalées par le collecteur de données DME.
Cela permet à l'investigation de s'éloigner des chemins de détection eux-mêmes et de se diriger vers la destination télémétrique et le chemin de transport.
Inspecter les erreurs de transport
Utilisez l'ID de session indiqué par la commande show telemetry transport :
N9K-TELEMETRY-SW1# show telemetry transport 0 errors
Session Id: 0
Connection Errors
Connection Error Count: 0
Transmission Errors
Tx Error Count: 1
Last Tx Error: Thu Sep 17 21:22:16.008 UTC
Last Tx Return Code: UNAVAILABLE
N9K-TELEMETRY-SW1#
Les travaux pratiques ont rapporté :
Connection Error Count: 0
Tx Error Count: 1
Last Tx Error: Thu Sep 17 21:22:16.008 UTC
Last Tx Return Code: UNAVAILABLE
Le code de retour UNAVAILABLE enregistre un échec de transmission gRPC associé à la destination de télémétrie.
Au cours de ces travaux pratiques, le récepteur externe a été intentionnellement arrêté et redémarré alors que sa configuration était en cours de modification. Au cours de cet intervalle, NX-OS n'a pas pu atteindre la destination de télémétrie, ce qui correspond aux compteurs de collecte destination-inaccessible observés ci-dessus.
La corrélation importante est la suivante :
| Observation | Résultat |
|---|---|
| Collections ignorées | 44 |
| Destination inaccessible | 44 |
| Erreurs Tx de transport | 1 |
| Dernier code de retour Tx | NON DISPONIBLE |
| État de transport actuel | connected |
Les compteurs correspondants ignorés et destination inaccessible fournissent une preuve directe de la raison pour laquelle les collections ont été ignorées.
L’erreur de transport historique fournit des informations supplémentaires sur la défaillance de transport observée au cours de la même activité de TP.
Vérifier la récupération du transport
Une fois la connectivité au récepteur rétablie, utilisez :
N9K-TELEMETRY-SW1# show telemetry transport 0 stats
Session Id: 0
Connection Stats
Connection Count 3
Last Connected: Thu Sep 17 21:27:16.010 UTC
Disconnect Count 0
Last Disconnected: Never
Transmission Stats
Compression: disabled
Source Interface: not set()
Transmit Count: 603
Last TX time: Thu Sep 17 21:51:36.008 UTC
Min Tx Time: 1 ms
Max Tx Time: 414 ms
Avg Tx Time: 6 ms
Cur Tx Time: 1 ms
Flow Stats
Allowed Queued Msgs Size (bytes): 78643200
Current Queued Msgs Size (bytes): 0
Utilization (percent): 0
Max Queued Msgs Size (bytes): 3849
Total Queued Msgs Size (bytes): 865313
Current Msgs Held (# Msgs): 0
Total Msgs held (# Msgs): 604
Max Msgs Held (# Msgs): 5
Msgs Dropped (# Msgs): 0
Flow Control Apply Time (secs): 0
Flow Control Last Applied: Never
<snip>
N9K-TELEMETRY-SW1#
La vérification finale des travaux pratiques a révélé :
Connection Count: 3
Disconnect Count: 0
Transmit Count: 603
Average Transmission Time: 6 ms
Current Transmission Time: 1 ms
Current Queued Messages Size: 0
Transport Utilization: 0%
Messages Dropped: 0
Flow Control Last Applied: Never
Ces valeurs indiquent que la session de transport a récupéré et qu'elle transmettait activement des données de télémétrie sans messages mis en file d'attente ou abandonnés.
Les indicateurs de l'état actuel les plus importants étaient les suivants :
| Indicateur | Résultat |
|---|---|
| État du transport | connected |
| File actuelle | 0 |
| Messages abandonnés | 0 |
| Contrôle de flux | Jamais appliqué |
Cette distinction est importante lors du dépannage des compteurs de télémétrie : les erreurs historiques peuvent rester visibles même après la résolution de la condition sous-jacente.
Vérifier la configuration et les erreurs du collecteur d'événements
Des commandes supplémentaires peuvent être utilisées pour vérifier si NX-OS signale des problèmes de configuration ou de traitement des événements.
N9K-TELEMETRY-SW1# show telemetry config errors
--------------------------------------------------------------------------------
Row ID Path Sensor Group Error
--------------------------------------------------------------------------------
Transport Errors
--------------------------------------------------------------------------------
Destination group ID Source Interface Configured VRF Correct VRF
--------------------------------------------------------------------------------
N9K-TELEMETRY-SW1#
Pour la télémétrie basée sur les événements, utilisez :
N9K-TELEMETRY-SW1# show telemetry event collector errors
--------------------------------------------------------------------------------
Error Description Error Count
--------------------------------------------------------------------------------
Dme Event Subscription Init Failures - 0
Event Data Enqueue Failures - 0
Event Subscription Failures - 0
Pending Subscription List Create Failures - 0
Subscription Hash Table Create Failures - 0
Subscription Hash Table Destroy Failures - 0
Subscription Hash Table Insert Failures - 0
Subscription Hash Table Remove Failures - 0
N9K-TELEMETRY-SW1#
Tous les compteurs d'erreurs du collecteur d'événements étaient également nuls.
Ces résultats permettent d'éliminer les échecs de configuration et de collecteur d'événements lors de l'analyse des collectes périodiques ignorées.
Workflow de dépannage
Les commandes utilisées au cours de cette enquête peuvent être résumées comme suit :
| Commande | Objectif |
|---|---|
| show telemetry transport | Vérifiez l'état actuel de la session de transport. |
| show telemetry data collector brief | Identifiez les collectes réussies, ayant échoué, ignorées ou abandonnées. |
| show telemetry data collector details | Déterminez quels chemins de capteurs sont affectés. |
| show telemetry control stats | Déterminez pourquoi les collections ont été ignorées. |
| show telemetry transport <session-id> errors | Inspectez les pannes de transport. |
| show telemetry transport <id-session> stats | Examiner la récupération du transport, les files d'attente et les abandons. |
| show telemetry config errors | Identifiez les erreurs de configuration de télémétrie. |
| show telemetry event collector errors | Identifiez les erreurs du collecteur d'événements. |
Au cours de ces travaux pratiques, la séquence de dépannage a identifié une condition d’accessibilité de destination de télémétrie temporaire plutôt qu’un chemin de capteur DME ou une défaillance de configuration.
Une fois que le récepteur est à nouveau disponible, le transport de télémétrie est revenu à l'état Connecté, les collectes ont repris et aucune file d'attente ou condition de suppression de message n'a été observée.
Exemple d'application pratique : Surveiller les ressources système
La surveillance des ressources système est un exemple d'utilisation courant de la télémétrie en continu. Les informations relatives au processeur et à la mémoire peuvent être régulièrement exportées d'un commutateur Nexus vers une plate-forme de surveillance externe à des fins d'analyse historique, de tableaux de bord, de surveillance de la capacité et d'alerte.
Cisco NX-OS fournit des étiquettes de chemin de télémétrie prédéfinies pour les informations couramment surveillées. Dans cet exemple, l'étiquette du chemin d'accès aux ressources est utilisée pour collecter les informations relatives au processeur et à la mémoire du système.
Configurer la télémétrie des ressources système
Créez un nouveau groupe de capteurs à l'aide du libellé de chemin des ressources :
N9K-TELEMETRY-SW1(config)# telemetry
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 4
N9K-TELEMETRY-SW1(conf-tm-sensor)# path resources
Créez l'abonnement 4 et associez le groupe de capteurs 4 au groupe de destinations 1 :
N9K-TELEMETRY-SW1(config-telemetry)# subscription 4
N9K-TELEMETRY-SW1(conf-tm-sub)# dst-grp 1
N9K-TELEMETRY-SW1(conf-tm-sub)# snsr-grp 4 sample-interval 10000
Le groupe de capteurs 4 utilise le libellé de chemin de ressources prédéfini. L'abonnement 4 associe le groupe de capteurs à la destination télémétrique existante et configure la collecte périodique avec un intervalle d'échantillonnage non nul.
La configuration appropriée est la suivante :
telemetry
destination-group 1
ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB
use-vrf default
sensor-group 4
path resources
subscription 4
dst-grp 1
snsr-grp 4 sample-interval 10000
Consulter l'étiquette du chemin des ressources
Exécutez cette commande pour examiner les chemins DME représentés par l'étiquette de chemin de ressources :
N9K-TELEMETRY-SW1# show telemetry usability resources
1) label_name : resources
path_name : sys/proc
query_type : poll
<snip>
2) label_name : resources
path_name : sys/procsys
query_type : poll
<snip>
3) label_name : resources
path_name : sys/procsys/sysmem
query_type : event
query_condition : query-target-filter=and(updated(procSysMem.memstatus),ne(procSysMem.memstatus,"OK"))
Le résultat montre que l'étiquette de ressources représente plusieurs chemins DME sous-jacents.
Les chemins sys/proc et sys/procsys utilisent des requêtes d'interrogation et fournissent des informations sur les ressources système et les processus. Le chemin sys/procsys/system utilise une requête d'événement qui peut signaler une modification lorsque l'état de la mémoire surveillée est mis à jour et qu'il n'est plus OK.
Ceci démontre la différence entre la spécification directe d'un nom distinctif DME individuel et l'utilisation d'une étiquette de chemin de télémétrie prédéfinie.
Exemple :
Individual DME path:
path sys/intf/phys-[eth1/10]
Predefined path label:
path resources
Vérification de la télémétrie des ressources système
Utilisez show telemetry control database pour vérifier l'état du groupe de capteurs 4 et de l'abonnement 4.
La base de données Sensor Group signale :
Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions SubID ---------------------------------------------------------------------------------------------------- 4 Timer /DME 10000/Running 1 4
Le type Timer /DME et l'intervalle d'échantillonnage 10000/Running confirment que le groupe de capteurs 4 fonctionne comme une source de télémétrie DME périodique.
La base de données des chemins de capteurs affiche également les chemins sous-jacents associés au libellé des ressources.
Exemple :
resources:sys/procsys(4) GPB Encoded Data size in bytes (Cur/Min/Max): 20221/20221/20229 Subscription Id: 4 Message Stats: Sent = 14 Error = 0 Drops = 0
Le chemin lié au processus signale également la collecte de télémétrie active :
resources:sys/proc(4)
GPB Encoded Data size in bytes (Cur/Min/Max): 82284/81262/85098
Subscription Id: 4
Message Stats:
Sent = 14
Error = 0
Drops = 0
Ces compteurs confirment que les informations sur les ressources sont collectées, codées en tant que GPB et transmises sans erreurs ou abandons de message.
Comparer avec ressources système NX-OS
L'interface de ligne de commande NX-OS traditionnelle peut être utilisée pour afficher l'état actuel du processeur et de la mémoire du commutateur :
N9K-TELEMETRY-SW1# show system resources Load average: 1 minute: 0.57 5 minutes: 0.58 15 minutes: 0.63 Processes : 854 total, 2 running CPU states : 14.64% user, 3.50% kernel, 81.85% idle <snip> Memory usage: 24530808K total, 9315248K used, 15215560K free Kernel buffers: 22104K Used Kernel cached : 6255520K Used Current memory status: OK
L'interface de ligne de commande fournit une vue instantanée des ressources du système.
La télémétrie en continu permet d'exporter le même type d'informations de processeur et de mémoire vers un récepteur externe afin que plusieurs échantillons puissent être stockés et analysés au fil du temps.
L'utilisation du processeur peut changer rapidement. Par conséquent, les valeurs UC affichées par l'interface de ligne de commande et les valeurs reçues par télémétrie peuvent différer lorsque les échantillons sont collectés à des moments différents.
Vérification des données de ressource au niveau du récepteur
Le récepteur de télémétrie a décodé avec succès les informations de ressources système associées à l'abonnement 4.
Cet exemple montre les informations de CPU et de mémoire d'un exemple de télémétrie :
{
"timestamp": "2026-09-18T23:15:08Z",
"source": "N9K-TELEMETRY-SW1",
"cpu": {
"user": 11,
"kernel": 2,
"idle": 85,
"averageLast60Seconds": 7.099999904632568
},
"memory": {
"status": "OK",
"utilization": 38.18336486816406,
"usedKB": 9366688,
"freeKB": 15164120,
"totalKB": 24530808
}
}
La sortie du récepteur confirme que les informations de CPU et de mémoire de l'abonnement 4 sont correctement décodées et mises à disposition pour une surveillance externe.
À titre de comparaison, l'interface de ligne de commande de NX-OS a signalé environ 9,3 Go de mémoire utilisée sur environ 24,5 Go de mémoire totale et un état de mémoire actuel OK. L'échantillon de télémétrie indique la même valeur de mémoire totale, une utilisation de la mémoire d'environ 38 % et le même état de mémoire OK.
Les valeurs du processeur peuvent varier entre les échantillons de l'interface de ligne de commande et de télémétrie, car l'utilisation du processeur change de manière dynamique et les mesures ne sont pas nécessairement collectées au même instant.
Observer l'utilisation des ressources dans le temps
Plusieurs échantillons de télémétrie peuvent être utilisés pour observer l'évolution de l'utilisation des ressources système dans le temps.
Ces échantillons ont été reçus de l'abonnement 4 au cours du TP :
Utilisation moyenne du processeur - 60 dernières secondes
10% |
9% | ●
8% | ●
7% | ●
6% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
8.70% 8.50% 7.10%
Time
Utilisation de la mémoire
39% |
38% | ●-----------●-----------●
37% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
37.82% 38.06% 38.18%
Time
Ces exemples illustrent comment la télémétrie périodique peut fournir une vue temporelle du comportement du système au lieu d'une seule mesure instantanée. Dans un environnement de production, une plate-forme de surveillance ou d'observabilité peut stocker un plus grand nombre d'échantillons et les utiliser pour identifier les tendances, générer des alertes et créer des tableaux de bord historiques.
Conclusion
Cisco NX-OS Streaming Telemetry fournit un mécanisme structuré pour exporter des informations opérationnelles des commutateurs Cisco Nexus 9000 vers un récepteur de télémétrie externe.
Ce document présente les composants fondamentaux de la télémétrie en continu, notamment les chemins de capteur DME, le codage GPB, le transport gRPC, les groupes de destinations, les groupes de capteurs et les abonnements.
Dans l’environnement des travaux pratiques, la télémétrie périodique et la télémétrie événementielle ont été configurées et vérifiées. Des abonnements périodiques ont été utilisés pour collecter des statistiques et des informations opérationnelles sur Ethernet1/10, tandis qu'un abonnement basé sur des événements a été utilisé pour détecter des modifications contrôlées de l'objet géré Loopback100.
Un exemple pratique de surveillance des ressources système a également montré comment l'étiquette de chemin de ressources prédéfinies peut être utilisée pour exporter des informations de CPU et de mémoire vers un récepteur de télémétrie externe.
Les exemples de vérification et de dépannage ont montré comment les commandes de télémétrie NX-OS peuvent être utilisées pour valider la connectivité de transport, la collecte de données, le traitement des événements et les échecs de collecte d'historique.
Ces concepts constituent une base pour comprendre, mettre en oeuvre, vérifier et dépanner les déploiements de base de la télémétrie en continu sur Cisco Nexus 9000 NX-OS.
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
01-Oct-2026
|
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)