Configuración y verificación de la telemetría en la plataforma Nexus
Contenido
Introducción
Este documento describe cómo implementar y verificar la telemetría de streaming en los switches Cisco Nexus 9000 que ejecutan Cisco NX-OS.
Prerequisites
Requirements
Cisco recomienda tener conocimientos básicos sobre estos temas:
- CLI de Cisco NX-OS
- Conectividad IP básica de capa 3
- Conceptos básicos de supervisión de red
- Familiaridad básica con los conceptos de telemetría de red
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
| Componente | Plataforma/Software | Versión/Valor | Propósito |
|---|---|---|---|
| N9K-TELEMETRY-SW1 | N9K-C9348GC-FXP | 10.6(4) | fuente de telemetría |
| receptor de telemetría | Servidor Ubuntu | 22.04.5 | Receptor de telemetría externo |
| aplicación de telemetría | Telégrafo | 1.40.0 | Receptor de telemetría de Google Protocol Buffers (GPB) sobre gRPC |
| Puerto de escucha | TCP | 57000 | Puerto del receptor de telemetría |
| Formato de salida del receptor | JavaScript Object Notation (JSON) | — | Salida de telemetría legible por personas |
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Topología
El laboratorio utiliza un switch Cisco Nexus 9000 conectado directamente a un servidor Ubuntu que funciona como receptor de telemetría externo.
El switch Nexus y el receptor de telemetría están conectados directamente a través de Ethernet1/10 y ens192.
Conectividad de Nexus al receptor
Ethernet1/10 proporciona conectividad de capa 3 entre el switch Nexus y el receptor Ubuntu.
La configuración de la interfaz es:
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
Antecedentes
La supervisión y la visibilidad de la red son fundamentales para comprender el estado de la red, identificar comportamientos anómalos y solucionar problemas de red.
Cisco NX-OS proporciona varios mecanismos para recuperar o exportar información operativa desde un switch Nexus, incluidos la CLI, el protocolo simple de administración de red (SNMP) y Syslog. Los flujos de trabajo de supervisión tradicionales, como el sondeo SNMP y la recopilación basada en CLI, suelen basarse en un modelo de extracción, en el que un sistema de supervisión externo solicita información periódicamente al dispositivo de red.
La telemetría de transmisión introduce un modelo de inserción, en el que el dispositivo de red envía los datos operativos seleccionados hacia un receptor externo en función de las suscripciones configuradas. Esto proporciona un mecanismo estructurado para recopilar información de la red sin que sea necesario que el sistema de supervisión sondee continuamente el dispositivo.
Sondeo tradicional frente a telemetría de streaming
En un modelo de sondeo tradicional, el sistema de supervisión determina cuándo se recupera la información del dispositivo de red.
Por ejemplo, un sistema de administración de redes (NMS) puede solicitar estadísticas de interfaz cada 60 segundos. Esto proporciona instantáneas periódicas del estado del dispositivo; sin embargo, la visibilidad disponible para la aplicación de supervisión está directamente relacionada con el intervalo de sondeo configurado.
Con la telemetría de transmisión, el switch Nexus envía la información seleccionada hacia el receptor de telemetría de acuerdo con la suscripción configurada.
Las diferencias fundamentales pueden resumirse como sigue:
| Sondeo tradicional | Telemetría de transmisión |
|---|---|
| El cliente inicia la solicitud. | El dispositivo de red envía los datos. |
| Modelo Pull | Modelo Push |
| Los datos se recuperan según los intervalos de sondeo. | Los datos se envían según una suscripción de telemetría. |
| Suele proporcionar instantáneas periódicas. | Admite la recopilación periódica y basada en eventos. |
| El sistema de supervisión solicita información del dispositivo. | El dispositivo transmite la información seleccionada a un receptor. |
La telemetría de transmisión no sustituye necesariamente a los mecanismos de supervisión tradicionales. CLI, SNMP, Syslog y Telemetry pueden coexistir y servir para diferentes propósitos operativos.
La diferencia principal es el modelo de recopilación de datos.
Casos prácticos reales
En entornos de producción, la telemetría de transmisión se utiliza habitualmente para proporcionar una visibilidad continua del estado de la red y del sistema.
Entre los casos prácticos habituales se incluyen la supervisión de los contadores de interfaz y los cambios de estado, los recursos del sistema, como la utilización de la CPU y la memoria, y la información de fabric del Data Center, como los pares de LAN extensible virtual (VXLAN) y el estado de los pares de protocolo de gateway fronterizo (BGP). La telemetría basada en eventos también se puede utilizar para notificar los cambios de estado operativo a medida que se producen los cambios.
Los datos de telemetría exportados pueden ser utilizados por plataformas de supervisión y observación externas para paneles, alertas, análisis histórico y solución de problemas.
Descripción general del procesamiento de telemetría
En un nivel superior, la telemetría de streaming en NX-OS se puede entender como cuatro etapas principales:
+-----------------------+
| Data Collection |
+-----------+-----------+
|
v
+-----------------------+
| Data Encoding |
+-----------+-----------+
|
v
+-----------------------+
| Data Transport |
+-----------+-----------+
|
v
+-----------------------+
| Telemetry Receiver |
+-----------------------+
Estas etapas responden a cuatro preguntas básicas:
- Recolección de datos: ¿Qué información se recopila?
- Codificación de datos: ¿Cómo se representa la información?
- Transporte de datos: ¿Cómo se suministran los datos de telemetría?
- Receptor de telemetría: ¿Dónde se envían los datos de telemetría?
Terminología y arquitectura de telemetría
Recolección de datos
La primera etapa determina qué información debe recopilarse del switch.
Para los ejemplos de este documento, los datos de telemetría se recopilan del motor de gestión de datos (DME).
Motor de gestión de datos: DME
Data Management Engine mantiene una representación estructurada de la información de configuración y operativa de NX-OS.
En lugar de representar la información del dispositivo únicamente como texto CLI, DME organiza la información como objetos administrados a los que se puede acceder a través de rutas jerárquicas.
Por ejemplo:
sys/intf/phys-[eth1/10]
Identifica el objeto DME asociado a Ethernet1/10.
Otras rutas de DME utilizadas en este laboratorio incluyen:
sys/intf/phys-[eth1/10]/dbgIfIn
sys/intf/phys-[eth1/10]/dbgIfOut
sys/intf/phys-[eth1/10]/phys
sys/intf/lb-[lo100]
Cada ruta representa un objeto o parte diferente de la información disponible a través de DME. Son las mismas rutas que ya se han utilizado en toda la configuración del laboratorio.
Objetos gestionados y el árbol de información de gestión
La base de datos DME está compuesta por objetos gestionados (MO).
Un objeto gestionado representa una entidad dentro del modelo de gestión de NX-OS, como:
- Una interfaz física
- Una interfaz de loopback
- Estadísticas de entrada de interfaz
- Estadísticas de salida de interfaz
Los objetos administrados se organizan jerárquicamente en un árbol de información de administración (MIT).
Una representación simplificada de los objetos utilizados en este laboratorio es:
sys
|
+-- intf
|
+-- phys-[eth1/10]
| |
| +-- dbgIfIn
| +-- dbgIfOut
| +-- phys
|
+-- lb-[lo100]
Esta jerarquía resulta útil para comprender cómo las rutas de los sensores de telemetría identifican información específica dentro del DME.
Nombre distintivo: DN
Cada objeto administrado se puede identificar de forma exclusiva mediante un nombre distinguido (DN).
El DN representa la ruta jerárquica desde la raíz del árbol DME hasta el objeto de destino.
For example: sys/intf/lb-[lo100]
Identifica el objeto administrado Loopback100.
Del mismo modo:
sys/intf/phys-[eth1/10]/dbgIfIn
Identifica el objeto de estadísticas de entrada asociado a Ethernet1/10.
Una forma sencilla de entender un DN es considerarlo la dirección completa de un objeto dentro de la jerarquía de DME.
Ruta del sensor
Una ruta de sensor identifica la información que NX-OS debe supervisar para una suscripción de telemetría.
En los ejemplos de laboratorio iniciales, los nombres distintivos de DME se utilizan como rutas de sensor. En un ejemplo práctico posterior se muestra la etiqueta de ruta de acceso de recursos predefinida.
Por ejemplo:
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
Estas rutas proporcionan estadísticas de entrada, estadísticas de salida e información operativa para Ethernet1/10.
Codificación de datos
Después de que NX-OS recopile la información solicitada, los datos deben codificarse antes de poder transmitirse.
La codificación utilizada en este laboratorio es Google Protocol Buffers (GPB).
La configuración de destino especifica:
ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB
GPB define cómo se representa la información de telemetría recopilada en el mensaje.
La codificación y el transporte son funciones independientes: GPB define la representación de datos, mientras que el mecanismo de transporte determina cómo se entrega el mensaje.
Transporte de datos
El protocolo de transporte utilizado en este laboratorio es gRPC.
El switch Nexus envía los datos de telemetría codificados por GPB a:
192.168.100.10:57000
mediante gRPC.
Por lo tanto:
GPB define cómo se codifica la información de telemetría.
gRPC proporciona el mecanismo de transporte utilizado para entregar los mensajes de telemetría al receptor.
El transporte gRPC utilizado por la telemetría de transmisión no debe confundirse con el agente gRPC de NX-OS utilizado para servicios como la interfaz de administración de red (gNMI) de gRPC y la interfaz de operaciones de red (gNOI) de gRPC.
Receptor de telemetría
El receptor de telemetría es el sistema o aplicación externa que recibe y procesa el flujo de telemetría.
En este laboratorio, un servidor Ubuntu que ejecuta Telegraf se utiliza como receptor. El receptor escucha en el puerto TCP 57000 y acepta la secuencia de telemetría GPB sobre gRPC generada por el switch Nexus.
La implementación del receptor utilizada en el laboratorio se describe más adelante en la sección Preparación del receptor de telemetría.
Grupo de destino
El grupo de destino define dónde se deben enviar los datos de telemetría y cómo se deben transportar.
El laboratorio utiliza:
destination-group 1 ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB use-vrf default
Esto define la dirección del receptor, el puerto de destino, el protocolo de transporte, la codificación y la instancia de Virtual Routing and Forwarding (VRF) utilizada para la entrega de telemetría.
Grupo de sensores
El grupo de sensores define la información que se debe supervisar.
Por ejemplo:
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
En este ejemplo, el Grupo de sensores 2 monitorea las estadísticas de entrada Ethernet1/10, las estadísticas de salida y la información de la interfaz operativa. La ruta dbgIfIn proporciona estadísticas de interfaz de entrada, dbgIfOut proporciona estadísticas de interfaz de salida y phys proporciona información operativa para la interfaz.
Un grupo de sensores puede incluir varias rutas de sensor relacionadas y, por lo tanto, responde a la pregunta:
¿Qué datos se recopilan?
Suscripción
Una suscripción asocia un grupo de sensores a un grupo de destino y define el comportamiento de la recopilación.
Por ejemplo:
subscription 2 dst-grp 1 snsr-grp 2 sample-interval 60000
En este ejemplo:
- El Grupo de sensores 2 determina qué información se recopila.
- El intervalo de muestra determina el comportamiento de la colección.
- El Grupo de Destino 1 determina dónde y cómo se envía la información.
Por lo tanto, la suscripción conecta los principales elementos de configuración de telemetría:
Grupo de sensores + Comportamiento de la colección + Grupo de destino
Telemetría periódica y basada en eventos
Cisco NX-OS Streaming Telemetry admite la recopilación periódica y basada en eventos para suscripciones basadas en DME.
El comportamiento de la recopilación se controla mediante el intervalo de ejemplo asociado al grupo de sensores dentro de una suscripción.
Telemetría periódica
Con la telemetría periódica, NX-OS recopila y envía la información supervisada en un intervalo configurado.
El intervalo de muestreo se especifica en milisegundos.
For example: snsr-grp 2 sample-interval 60000
Configura un intervalo de recopilación de 60 segundos.
La telemetría periódica resulta útil para obtener información que cambia continuamente y que normalmente se analiza a lo largo del tiempo, como:
- Contadores de paquetes de interfaz
- Contadores de bytes
- Errores y descartes
- Estadísticas operativas
- Utilización de recursos
En este laboratorio, la suscripción 1 y la suscripción 2 utilizan la recopilación periódica.
La suscripción 1 recopila el objeto de interfaz Ethernet1/10 cada 10 segundos, mientras que la suscripción 2 recopila las estadísticas de la interfaz y la información operativa cada 60 segundos.
Telemetría basada en eventos
Con la telemetría basada en eventos, NX-OS no utiliza un temporizador de recopilación recurrente.
Para la telemetría basada en DME, el comportamiento basado en eventos se configura con:
sample-interval 0
Cuando cambia un objeto supervisado, la telemetría puede generar una actualización asociada a dicho cambio.
Este método de recopilación es útil para obtener información como:
- Cambios de configuración
- Cambios de estado administrativo
- Creación o eliminación de objetos
- Otros cambios en un objeto DME supervisado
En este laboratorio, la suscripción 3 supervisa el objeto DME Loopback100:
sys/intf/lb-[lo100]: snsr-grp 3 sample-interval 0
Por lo tanto, los cambios en el objeto Loopback100 supervisado se utilizan más adelante en este documento para demostrar la telemetría basada en eventos.
Comportamiento de la colección utilizado en el laboratorio
Las tres suscripciones utilizadas en la configuración inicial del laboratorio se pueden resumir de la siguiente manera:
| Suscripción | Información supervisada | Intervalo de muestra | Comportamiento de colección |
|---|---|---|---|
| 1 | Objeto de interfaz Ethernet1/10 | 10000 m | Periódico |
| 2 | Estadísticas Ethernet1/10 y estado operativo | 60000 m | Periódico |
| 3 | Loopback100 (objeto) | 0 | Basado en eventos |
La distinción principal es el disparador utilizado para generar datos de telemetría:
| Telemetría periódica | Telemetría basada en eventos |
|---|---|
| Utiliza un temporizador configurado. | No utiliza un temporizador periódico. |
| sample-interval > 0 | sample-interval 0 |
| Produce muestras repetidas. | Produce actualizaciones cuando cambian los objetos supervisados. |
| Se usa comúnmente para contadores y estadísticas. | Se suele utilizar para cambios de configuración o de estado. |
Las secciones de configuración y verificación muestran ambos comportamientos de recopilación mediante las suscripciones definidas anteriormente.
Preparación del receptor de telemetría
La telemetría de transmisión requiere un receptor externo capaz de aceptar y procesar los datos de telemetría enviados por el switch Nexus.
Para el transporte GPB sobre gRPC utilizado en este documento, el receptor debe ser capaz de:
- Recepción de conexiones gRPC
- Escuchando en el puerto de destino configurado
- Descodificación de mensajes de telemetría GPB
- Procesamiento o almacenamiento de los datos recibidos
La implementación del receptor de telemetría es independiente de la configuración de telemetría de NX-OS descrita en este documento.
Nota: La instalación, la configuración, el funcionamiento y la resolución de problemas del software receptor de telemetría de terceros quedan fuera del alcance de este documento. Consulte la documentación proporcionada por el proveedor del receptor para obtener información de configuración y soporte.
Receptor utilizado en este laboratorio
Para fines de demostración, el laboratorio utiliza un servidor externo de Ubuntu que ejecuta Telegraf como receptor de telemetría.
Los parámetros del receptor son:
| Parámetro | Valor |
|---|---|
| Dirección del receptor | 192.168.100.10 |
| Transporte | gRPC |
| Puerto de escucha | TCP/57000 |
| Codificación | GPB |
La configuración del software del lado del receptor no se trata en este documento.
Nota: Los ejemplos de resultados del receptor que se muestran en este documento se filtran para resaltar los campos relevantes para cada paso de verificación.
Antes de configurar la telemetría de transmisión en el switch Nexus, compruebe lo siguiente:
- Existe conectividad IP entre el switch Nexus y el receptor.
- La aplicación del receptor se está ejecutando.
- El puerto de destino configurado está escuchando.
- El receptor admite el protocolo de transporte configurado.
- El receptor admite la codificación de telemetría configurada.
Para este laboratorio, Ethernet1/10 en el switch Nexus utiliza 192.168.100.1/24 y el receptor de telemetría utiliza 192.168.100.10/24. Se debe confirmar la disponibilidad básica de la capa 3 antes de solucionar problemas de comportamiento específico de telemetría.
Una vez que el receptor esté accesible y listo para aceptar la telemetría GPB sobre gRPC en el puerto TCP 57000, se puede aplicar la configuración de telemetría de NX-OS.
Configuración de la telemetría de transmisión en NX-OS
La configuración utiliza tres componentes principales:
- Grupo de destino: Define dónde se envían los datos de telemetría y cómo se transportan.
- Grupo de sensores: Define la información que se recopila.
- Suscripción: Asocia un grupo de sensores a un grupo de destino y define el comportamiento de la recopilación.
El laboratorio utiliza este destino de telemetría:
| Parámetro | Valor |
|---|---|
| Destino | 192.168.100.10:57000 |
| Transporte | gRPC |
| Codificación | GPB |
| VRF | predeterminado |
La configuración inicial del laboratorio utiliza tres suscripciones:
| Suscripción | Sensor | Tipo de colección | Intervalo de muestra |
|---|---|---|---|
| 1 | Objeto de interfaz Ethernet1/10 | Periódico | 10000 m |
| 2 | Estadísticas Ethernet1/10 y estado operativo | Periódico | 60000 m |
| 3 | Loopback100 (objeto) | Basado en eventos | 0 |
Activar la función de telemetría
La telemetría de transmisión debe activarse primero de forma global.
N9K-TELEMETRY-SW1# configure terminal N9K-TELEMETRY-SW1(config)# feature telemetry
Ingresar al modo de configuración de telemetría:
N9K-TELEMETRY-SW1(config)# telemetry N9K-TELEMETRY-SW1(config-telemetry)#
La configuración de telemetría restante se realiza en este modo.
Configuración del grupo de destino
El grupo de destino identifica el receptor de telemetría externo y define el transporte y la codificación utilizados para enviar los datos de telemetría.
Configure
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
Esta configuración define:
- Dirección de destino: 192.168.100.10
- Puerto de destino: 57000
- Transporte: gRPC
- Codificación: GPB
- VRF: predeterminado
Se utiliza el VRF predeterminado porque el receptor de telemetría es accesible a través de Ethernet1/10 en el VRF predeterminado.
El VRF seleccionado para el transporte de telemetría debe proporcionar disponibilidad IP al receptor configurado.
Configuración del Grupo de sensores 1
El Grupo de sensores 1 supervisa el objeto de interfaz DME Ethernet1/10.
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 1 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]
La ruta del sensor identifica el objeto gestionado Ethernet1/10 en la jerarquía DME y proporciona información general de la interfaz asociada a dicho objeto.
Configurar suscripción 1
Asociar el Grupo de Sensores 1 con el Grupo de Destino 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
El intervalo de muestreo se especifica en milisegundos.
10000 ms = 10 segundos
Por lo tanto, la suscripción 1 recopila periódicamente el objeto DME Ethernet1/10 cada 10 segundos y envía los datos de telemetría al grupo de destino 1.
Configuración del Grupo de sensores 2
El Grupo de sensores 2 recopila estadísticas e información operativa para Ethernet1/10.
Configure
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
Las trayectorias de los sensores proporcionan:
| Ruta del sensor | Información |
|---|---|
| sys/intf/phys-[eth1/10]/dbgIfIn | Estadísticas de interfaz de entrada |
| sys/intf/phys-[eth1/10]/dbgIfOut | Estadísticas de interfaz de salida |
| sys/intf/phys-[eth1/10]/phys | Información de interfaz operativa |
Un grupo de sensores puede contener varias rutas de sensores relacionadas, lo que permite a la suscripción recopilar varias categorías de información desde la misma interfaz supervisada.
Configurar suscripción 2
Asociar el Grupo de Sensores 2 al Grupo de Destino 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
El intervalo de muestreo configurado es:
60000 ms = 60 segundos
Por lo tanto, la suscripción 2 recopila las estadísticas de Ethernet1/10 y la información operativa cada 60 segundos.
Esta suscripción se utiliza más adelante en el documento para comprobar el comportamiento periódico de la telemetría.
Configuración de la interfaz de loopback
Se utiliza una interfaz de loopback para demostrar la telemetría basada en eventos sin necesidad de una conexión física adicional.
Configure
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# ip address 10.255.255.100/32
El objeto DME correspondiente es:
sys/intf/lb-[lo100]
La interfaz de loopback proporciona una forma sencilla de generar cambios de estado administrativo y de configuración controlados durante la verificación de la telemetría basada en eventos.
Configuración del Grupo de sensores 3
Configuración de la ruta del sensor DME Loopback100:
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 3 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/lb-[lo100]
El Grupo de sensores 3 supervisa el objeto administrado Loopback100.
Configuración de la suscripción 3
Asocie el Grupo de Sensores 3 con el Grupo de Destino 1 y configure la recolección basada en eventos:
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
Para las suscripciones basadas en DME, un intervalo de muestra de cero configura el comportamiento basado en eventos.
Por lo tanto, los cambios realizados en el objeto Loopback100 supervisado pueden generar notificaciones de telemetría sin utilizar un temporizador de recopilación recurrente.
Esta suscripción se utiliza más adelante para demostrar los cambios de descripción y de estado administrativo.
Configuración de telemetría inicial completa
Una vez completada la configuración, compruébela con:
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
En este punto, el switch tiene el destino, los grupos de sensores y las suscripciones necesarias para comenzar a enviar datos de telemetría hacia el receptor configurado.
La siguiente sección verifica la sesión de transporte y la telemetría periódica generadas por las suscripciones Ethernet1/10.
Verificar telemetría periódica
Después de aplicar la configuración de telemetría, verifique que se haya establecido la sesión de transporte, que los grupos de sensores periódicos estén activos y que los datos de telemetría se recopilen y se envíen al receptor.
Verificar el transporte de telemetría
Ejecute este comando:
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#
El estado Conectado confirma que se ha establecido la sesión de transporte gRPC al receptor de telemetría configurado.
Los parámetros de transporte relevantes también coinciden con el grupo de destino configurado.
Verifique los grupos de sensores periódicos
Uso:
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 datos de grupos de sensores confirma que los grupos de sensores periódicos están activos:
| Grupo de sensores | Tipo | intervalo de muestra | Suscripción |
|---|---|---|---|
| 1 | Temporizador / DME | 10000 ms/en ejecución | 1 |
| 2 | Temporizador / DME | 60000 ms/en ejecución | 2 |
El Grupo de sensores 1 recopila el objeto de interfaz Ethernet1/10 cada 10 segundos.
El Grupo de sensores 2 recopila estadísticas de Ethernet1/10 e información operativa cada 60 segundos.
El mismo comando también muestra las trayectorias de sensor configuradas:
sys/intf/phys-[eth1/10] sys/intf/phys-[eth1/10]/dbgIfIn sys/intf/phys-[eth1/10]/dbgIfOut sys/intf/phys-[eth1/10]/phys
Para las trayectorias de sensor utilizadas en este laboratorio, los tiempos de recolección y codificación estaban típicamente entre 0 y 1 ms, y no se observaron caídas de mensajes de telemetría.
Verificar recopilación de datos
Uso:
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#
El laboratorio informó:
DME Successful Collections: 513 Payloads: 513 Failed: 0 Skipped: 44 Dropped: 0
Los contadores Satisfactorio y Carga útil confirman que se están recopilando datos de telemetría de DME y que se están generando cargas útiles de telemetría.
Las 44 colecciones omitidas son contadores históricos observados mientras que el destino de telemetría no estaba disponible temporalmente durante el laboratorio. Estos contadores se examinan más adelante en la sección Solución de problemas básicos.
Para obtener información adicional sobre la ruta por sensor, utilice:
N9K-TELEMETRY-SW1# show telemetry data collector details
Este comando puede identificar qué trayectorias de sensor configuradas contribuyeron a recolecciones exitosas, fallidas, omitidas o descartadas.
Verificar datos periódicos en el receptor
La suscripción 2 recopila estadísticas de Ethernet1/10 cada 60 segundos.
El receptor de telemetría informó estas estadísticas de entrada a las 21:44:45 hora universal coordinada (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
Un minuto después, se recibió otra muestra:
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
A continuación se resumen los cambios de contador entre ambas muestras:
| Contador | 21:44:45 | 21:45:45 |
|---|---|---|
| Paquetes unidifusión | 31,256 | 31,292 |
| Paquetes de multidifusión | 143,403 | 143,430 |
| Paquetes de difusión | 5,074 | 5,075 |
| Octetos | 12,870,535 | 12,875,428 |
| Errores | 0 | 0 |
| Descartes | 0 | 0 |
Las marcas de tiempo están separadas por aproximadamente 60 segundos, coincidiendo con el intervalo de muestreo configurado para la suscripción 2.
El aumento de los contadores de paquetes y bytes también confirma que las estadísticas actualizadas de la interfaz se recopilan y entregan al receptor.
Verificar información de salida y operativa
El trayecto del sensor dbgIfOut proporciona estadísticas de salida para Ethernet1/10.
Una muestra recolectada a las 21:45:45 UTC informó:
broadcastPkts: 8 discards: 0 errors: 0 multicastPkts: 4712 octets: 2444721 ucastPkts: 4092
La trayectoria del sensor phys proporciona atributos operativos para la misma interfaz.
El receptor informó:
adminSt: up operSt: up operSpeed: 1G operDuplex: full operMtu: 1500 operDescr: TELEMETRY-COLLECTOR
Estos ejemplos confirman que el Grupo de sensores 2 proporciona estadísticas de interfaz e información operativa a través de sus tres rutas de sensor DME configuradas.
Resumen de verificación de telemetría periódica
La verificación de telemetría periódica confirma:
| Verificación | Resultado |
|---|---|
| sesión de transporte gRPC | Conectado |
| codificación GPB | Confirmado |
| Grupo de sensores 1 | Ejecución a 10000 ms |
| Grupo de sensores 2 | Ejecución a 60000 ms |
| colecciones DME | Satisfactorio |
| Colecciones fallidas | 0 |
| Cargas descartadas | 0 |
| Muestras periódicas del receptor | Recibido |
| Contadores de interfaz | Actualización entre muestras |
Verificar telemetría basada en eventos
Después de verificar la telemetría periódica, utilice la suscripción 3 para validar la telemetría basada en eventos generando cambios controlados en el objeto administrado Loopback100.
Verificar la suscripción basada en eventos
Uso:
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 misma base de datos de telemetría confirma que la ruta del sensor está suscrita a través de la suscripción 3.
Generar actualizaciones basadas en eventos
Para verificar la generación de eventos, modifique la descripción de Loopback100:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# description TELEMETRY-EVENT-DEMO
El receptor de telemetría informó:
{
"timestamp": "2026-09-17T21:41:12Z",
"source": "N9K-TELEMETRY-SW1",
"subscription": "3",
"event": {
"descr": "TELEMETRY-EVENT-DEMO",
"dn": "sys/intf/lb-[lo100]",
"status": "modified"
}
}
El dn identifica el objeto DME supervisado y el atributo descr identifica la propiedad que ha cambiado.
A continuación, deshabilite y restaure administrativamente la interfaz:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# shutdown
Luego:
N9K-TELEMETRY-SW1(config-if)# no shutdown
El receptor detectó ambos cambios de estado.
| Grupo fecha/hora | Atributo cambiado | Valor |
|---|---|---|
| 21:41:12 | descr | TELEMETRY-EVENT-DEMO |
| 21:41:19 | adminSt | down (inactivo) |
| 21:41:24 | adminSt | en funcionamiento |
Cada actualización hacía referencia al mismo objeto supervisado:
sys/intf/lb-[lo100]
Informó del estado del objeto como modificado.
Estos resultados confirman que los cambios en los diferentes atributos del objeto administrado supervisado pueden generar actualizaciones de telemetría individuales.
Verificar la instantánea inicial y los mensajes de evento
Cuando se estableció la suscripción basada en eventos, NX-OS generó una instantánea inicial del objeto supervisado.
La base de datos Sender Path informó:
Estadísticas de instantánea:
Sent = 1 Error = 0 Drops = 0
Después de los tres cambios controlados, la misma trayectoria del sensor informó:
Estadísticas del mensaje:
Sent = 3 Error = 0 Drops = 0
Por consiguiente, los resultados pueden resumirse como sigue:
| Colección | Cuenta |
|---|---|
| Instantánea inicial | 1 |
| Modificación de descripción | 1 |
| Estado administrativo inactivo | 1 |
| Estado administrativo activado | 1 |
| Total | 4 |
La instantánea inicial representa el estado del objeto supervisado cuando la suscripción se activa, mientras que los mensajes subsiguientes corresponden a los cambios del objeto.
Verificar estadísticas de recolección de eventos
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#
El laboratorio informó:
Collection Count: 4
Latest Collection Time: Thu Sep 17 21:41:24.045 UTC
Sensor Path: sys/intf/lb-[lo100]
El recuento de recopilación coincide con la instantánea inicial y los tres cambios generados durante la prueba.
Verificar errores del recopilador de eventos
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#
No se observaron errores en el recopilador de eventos durante la prueba.
Resumen de verificación de telemetría basada en eventos
La verificación de telemetría basada en eventos confirma:
| Verificación | Resultado |
|---|---|
| Grupo de sensores | 3 |
| Ruta del sensor | sys/intf/lb-[lo100] |
| Tipo de colección | Evento/DME |
| intervalo de muestra | 0 / Sin temporizador |
| Instantánea inicial | Enviado |
| Cambio de descripción | Detectado |
| adminSt Down | Detectado |
| adminSt Up | Detectado |
| Total de cobros | 4 |
| Errores del recopilador de eventos | 0 |
La detección correcta de los cambios controlados de Loopback100 confirma que la suscripción 3 funciona según lo esperado.
En la siguiente sección se examinan los comandos principales de verificación y solución de problemas utilizados para evaluar el funcionamiento de la telemetría de transmisión.
Resolución de problemas básicos
Cuando los datos de telemetría no se reciben como se esperaba, comience la resolución de problemas determinando si el problema está relacionado con la sesión de transporte, la recopilación de datos, la configuración del sensor o el receptor externo.
Este flujo de trabajo utiliza un problema observado durante este laboratorio, en el que NX-OS notificó 44 recopilaciones omitidas y un error de transmisión gRPC histórico.
Verificar el estado actual del transporte
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#
Durante la verificación final, la sesión de telemetría informó:
Session ID: 0
Destination Group: 1
IP Address: 192.168.100.10
Port: 57000
Encoding: GPB
Transport: gRPC
Status: Connected
Un estado conectado confirma que la sesión de transporte está establecida actualmente.
Sin embargo, el estado de sesión actual no indica necesariamente si los problemas de conectividad ocurrieron antes. Por lo tanto, revise también los contadores de colección histórica y de transporte.
Revisar contadores de recopilación de datos
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#
El laboratorio informó:
DME Successful Collections: 513
Payloads: 513
Failed: 0
Skipped: 44
Dropped: 0
Los contadores Satisfactorio y Carga útil confirman que se han producido recopilaciones de telemetría de DME y generación de carga útil.
Sin embargo, el contador Omitido indica que no se realizaron 44 recopilaciones programadas.
Para identificar qué trayectorias de sensor se vieron afectadas, utilice:
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#
La salida detallada informó:
| Ruta del sensor | Omitido |
|---|---|
| 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 |
Las recopilaciones omitidas se distribuyeron por las rutas de los sensores periódicos, lo que indica que el problema no se aisló en un único objeto DME.
Nota: Los contadores de colecciones son acumulativos. Un contador histórico distinto de cero no indica necesariamente que la misma condición esté presente actualmente.
Determinar Por Qué Se Omiten Las Colecciones
N9K-TELEMETRY-SW1# show telemetry control stats
--------------------------------------------------------------------------------
Error Description Error Count
--------------------------------------------------------------------------------
<snip>
Collections skipped due to destination unreachable 44
<snip>
N9K-TELEMETRY-SW1#
Este resultado identifica directamente la razón de las recopilaciones omitidas:
Destino inalcanzable = 44
El valor coincide con las 44 recopilaciones omitidas notificadas por el recopilador de datos de DME.
Esto permite que la investigación se aleje de los trayectos del sensor en sí y se dirija hacia el destino de telemetría y el trayecto de transporte.
Inspeccionar errores de transporte
Utilice el ID de sesión informado por 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#
El laboratorio informó:
Connection Error Count: 0
Tx Error Count: 1
Last Tx Error: Thu Sep 17 21:22:16.008 UTC
Last Tx Return Code: UNAVAILABLE
El código de retorno UNAVAILABLE registra un error de transmisión gRPC asociado con el destino de telemetría.
En este laboratorio, el receptor externo se detuvo y reinició intencionalmente mientras se modificaba su configuración. Durante ese intervalo, NX-OS no pudo alcanzar el destino de telemetría, que se corresponde con los contadores de recopilación de destino inalcanzable observados anteriormente.
La correlación importante es:
| Observación | Resultado |
|---|---|
| Colecciones omitidas | 44 |
| Destino inalcanzable | 44 |
| Errores Tx de transporte | 1 |
| Último código de devolución de IVA | NO DISPONIBLE |
| Estado actual del transporte | Conectado |
Los contadores omitidos coincidentes y los contadores de destino inalcanzable proporcionan pruebas directas de por qué se omitieron las colecciones.
El error de transporte histórico proporciona información adicional sobre la falla de transporte observada durante la misma actividad de laboratorio.
Verificar recuperación de transporte
Una vez restaurada la conectividad con el receptor, utilice:
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 verificación de laboratorio final informó:
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
Estos valores muestran que la sesión de transporte se recuperó y transmitió activamente datos de telemetría sin mensajes en cola o descartados.
Los indicadores de estado actual más importantes fueron:
| Indicador | Resultado |
|---|---|
| Estado de transporte | Conectado |
| Cola actual | 0 |
| Mensajes descartados | 0 |
| Control de Flujo | Nunca se aplicó |
Esta distinción es importante cuando se solucionan problemas de contadores de telemetría: los errores históricos pueden permanecer visibles incluso después de que se haya resuelto la condición subyacente.
Comprobar errores de configuración y recopilador de eventos
Se pueden utilizar comandos adicionales para verificar si NX-OS informa de problemas de configuración o de procesamiento de eventos.
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#
Para la telemetría basada en eventos, utilice:
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#
Todos los contadores de errores del recopilador de eventos también eran cero.
Estos resultados ayudan a descartar los errores de configuración y del recopilador de eventos al investigar las recopilaciones periódicas omitidas.
Troubleshooting de Flujo
Los comandos utilizados durante esta investigación se pueden resumir de la siguiente manera:
| Comando | Propósito |
|---|---|
| show telemetry transport | Compruebe el estado actual de la sesión de transporte. |
| show telemetry data collector brief | Identifique colecciones correctas, fallidas, omitidas o eliminadas. |
| show telemetry data collector details | Determine qué trayectos del sensor se ven afectados. |
| show telemetry control stats | Determinar por qué se omitieron las colecciones. |
| show telemetry transport <session-id> errors | Inspeccione fallas de transporte. |
| show telemetry transport <session-id> stats | Revise la recuperación del transporte, las colas y las caídas. |
| show telemetry config errors | Identificar errores de configuración de telemetría. |
| show telemetry event collector errors | Identificar errores del recopilador de eventos. |
En este laboratorio, la secuencia de solución de problemas identificó una condición de disponibilidad de destino de telemetría temporal en lugar de una ruta de sensor DME o un fallo de configuración.
Después de que el receptor volviera a estar disponible, el transporte de telemetría volvió al estado Conectado, las recopilaciones se reanudaron y no se observó ninguna cola actual ni condición de mensaje descartado.
Ejemplo de aplicación práctica: Supervisar recursos del sistema
La supervisión de recursos del sistema es un caso práctico habitual de la telemetría de transmisión. La información sobre la memoria y la CPU se puede exportar periódicamente desde un switch Nexus a una plataforma de supervisión externa para realizar análisis históricos, paneles, supervisar la capacidad y emitir alertas.
Cisco NX-OS proporciona etiquetas de ruta de telemetría predefinidas para la información que se supervisa con frecuencia. En este ejemplo, la etiqueta de ruta de acceso de recursos se utiliza para recopilar información de memoria y CPU del sistema.
Configurar telemetría de recursos del sistema
Cree un nuevo grupo de sensores mediante la etiqueta de ruta de recursos:
N9K-TELEMETRY-SW1(config)# telemetry
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 4
N9K-TELEMETRY-SW1(conf-tm-sensor)# path resources
Cree la suscripción 4 y asocie el grupo de sensores 4 al grupo de destino 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
El Grupo de sensores 4 utiliza la etiqueta de ruta de recursos predefinida. La suscripción 4 asocia el grupo de sensores con el destino de telemetría existente y configura la recopilación periódica con un intervalo de muestreo distinto de cero.
La configuración relevante es:
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
Revise la etiqueta de ruta de recursos
Ejecute este comando para examinar las rutas de DME representadas por la etiqueta de ruta de recursos:
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"))
El resultado muestra que la etiqueta de recursos representa varias rutas de DME subyacentes.
Las rutas sys/proc y sys/procsys utilizan consultas de sondeo y proporcionan información de recursos del sistema y del proceso. La ruta sys/procsys/system utiliza una consulta de evento que puede informar de un cambio cuando el estado de la memoria supervisada se actualiza y ya no es correcto.
Esto demuestra la diferencia entre especificar un nombre distintivo de DME individual directamente y utilizar una etiqueta de ruta de telemetría predefinida.
Por ejemplo:
Individual DME path:
path sys/intf/phys-[eth1/10]
Predefined path label:
path resources
Verificar telemetría de recursos del sistema
Utilice show telemetry control database para verificar el estado del Grupo de sensores 4 y la Suscripción 4.
La base de datos de grupos de sensores informa:
Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions SubID ---------------------------------------------------------------------------------------------------- 4 Timer /DME 10000/Running 1 4
El tipo de temporizador/DME y el intervalo de muestreo 10000/en ejecución confirman que el Grupo de sensores 4 funciona como una fuente de telemetría DME periódica.
La base de datos Sender Path también muestra las rutas de acceso subyacentes asociadas a la etiqueta de recursos.
Por ejemplo:
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
La trayectoria relacionada con el proceso también informa sobre la recopilación de telemetría activa:
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
Estos contadores confirman que la información de recursos se recopila, se codifica como GPB y se transmite sin errores o caídas de mensajes.
Comparar con recursos del sistema NX-OS
La CLI de NX-OS tradicional se puede utilizar para mostrar el estado actual de la CPU y la memoria del switch:
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
La CLI proporciona una vista instantánea de los recursos del sistema.
La telemetría de transmisión permite exportar el mismo tipo de información de CPU y memoria a un receptor externo, de modo que se puedan almacenar y analizar varias muestras a lo largo del tiempo.
La utilización de la CPU puede cambiar rápidamente. Por lo tanto, los valores de CPU mostrados por la CLI y los valores recibidos a través de la telemetría pueden diferir cuando las muestras se recopilan en momentos diferentes.
Verificar datos de recursos en el receptor
El receptor de telemetría descodificó correctamente la información de recursos del sistema asociada con la suscripción 4.
Este ejemplo muestra información de CPU y memoria de un ejemplo de telemetría:
{
"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 salida del receptor confirma que la información de CPU y memoria de la Suscripción 4 se está descodificando con éxito y está disponible para monitoreo externo.
A modo de comparación, la CLI de NX-OS informó de aproximadamente 9,3 GB de memoria utilizada, de un total aproximado de 24,5 GB de memoria, con un estado de memoria actual de OK. El ejemplo de telemetría informa del mismo valor de memoria total, una utilización de memoria de aproximadamente el 38 por ciento y el mismo estado de memoria OK.
Los valores de la CPU pueden variar entre las muestras de CLI y de telemetría porque la utilización de la CPU cambia dinámicamente y las mediciones no se recopilan necesariamente en el mismo instante.
Observar La Utilización De Recursos A Lo Largo Del Tiempo
Se pueden utilizar varias muestras de telemetría para observar cómo cambia la utilización de los recursos del sistema con el tiempo.
Estas muestras se recibieron de la Suscripción 4 durante el laboratorio:
Utilización media de la CPU: últimos 60 segundos
10% |
9% | ●
8% | ●
7% | ●
6% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
8.70% 8.50% 7.10%
Time
Utilización de memoria
39% |
38% | ●-----------●-----------●
37% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
37.82% 38.06% 38.18%
Time
Estos ejemplos ilustran cómo la telemetría periódica puede proporcionar una vista basada en tiempo del comportamiento del sistema en lugar de una sola medición instantánea. En un entorno de producción, una plataforma de supervisión u observación puede almacenar un mayor número de muestras y utilizarlas para identificar tendencias, generar alertas y crear paneles históricos.
Conclusión
Cisco NX-OS Streaming Telemetry proporciona un mecanismo estructurado para exportar información operativa de los switches Cisco Nexus 9000 a un receptor de telemetría externo.
En este documento se muestran los componentes fundamentales de la telemetría de transmisión, incluidas las rutas de los sensores DME, la codificación GPB, el transporte gRPC, los grupos de destino, los grupos de sensores y las suscripciones.
Mediante el entorno de laboratorio, se configuró y verificó la telemetría periódica y basada en eventos. Las suscripciones periódicas se utilizaron para recopilar estadísticas de Ethernet1/10 e información operativa, mientras que una suscripción basada en eventos se utilizó para detectar cambios controlados en el objeto administrado Loopback100.
Un ejemplo práctico de monitoreo de recursos del sistema también demostró cómo la etiqueta de trayectoria de recursos predefinida se puede utilizar para exportar información de CPU y memoria hacia un receptor de telemetría externo.
Los ejemplos de solución de problemas y verificación demostraron cómo se pueden utilizar los comandos de telemetría de NX-OS para validar la conectividad de transporte, la recopilación de datos, el procesamiento de eventos y los fallos de recopilación histórica.
Estos conceptos proporcionan una base para comprender, implementar, verificar y solucionar problemas de implementaciones básicas de telemetría de transmisión en Cisco Nexus 9000 NX-OS.
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
01-Oct-2026
|
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)