Configurar e verificar a telemetria na plataforma Nexus
Contents
Introdução
Este documento descreve como implementar e verificar a telemetria de transmissão nos switches Cisco Nexus 9000 que executam o Cisco NX-OS.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento básico destes tópicos:
- CLI do Cisco NX-OS
- Conectividade IP básica de camada 3
- Conceitos básicos de monitoramento de rede
- Familiaridade básica com conceitos de telemetria de rede
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
| Componente | Plataforma/software | Versão/valor | Propósito |
|---|---|---|---|
| N9K-TELEMETRIA-SW1 | N9K-C9348GC-FXP | 10.6(4) | Fonte de telemetria |
| Receptor de telemetria | Servidor Ubuntu | 22.04.5 | Receptor de telemetria externo |
| Aplicativo de telemetria | Telérafe | 1.40.0 | Receptor de telemetria GPB-over-gRPC |
| Porta de escuta | TCP | 57000 | Porta do receptor de telemetria |
| Formato de saída do receptor | Notação de Objeto JavaScript (JSON - JavaScript Object Notation) | — | Saída de telemetria legível por humanos |
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Topologia
O laboratório usa um switch Cisco Nexus 9000 conectado diretamente a um servidor Ubuntu que opera como o receptor de telemetria externo.
O switch Nexus e o receptor de telemetria são conectados diretamente através de Ethernet1/10 e ens192.
Conectividade do Nexus com o receptor
A Ethernet1/10 fornece conectividade de Camada 3 entre o switch Nexus e o receptor Ubuntu.
A configuração da interface é:
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
Informações de Apoio
O monitoramento e a visibilidade da rede são fundamentais para entender a integridade da rede, identificar o comportamento anormal e solucionar problemas da rede.
O Cisco NX-OS fornece vários mecanismos para recuperar ou exportar informações operacionais de um switch Nexus, incluindo o CLI, o SNMP (Simple Network Management Protocol) e o Syslog. Fluxos de trabalho de monitoramento tradicionais, como interrogação de SNMP e coleta baseada em CLI, normalmente dependem de um modelo de recebimento, no qual um sistema de monitoramento externo solicita periodicamente informações do dispositivo de rede.
A telemetria de fluxo apresenta um modelo push, em que o dispositivo de rede envia os dados operacionais selecionados para um receptor externo com base nas assinaturas configuradas. Isso fornece um mecanismo estruturado para coletar informações da rede sem exigir que o sistema de monitoramento faça o poll contínuo do dispositivo.
Telemetria de pesquisa tradicional versus transmissão contínua
Em um modelo de pesquisa tradicional, o sistema de monitoramento determina quando as informações são recuperadas do dispositivo de rede.
Por exemplo, um sistema de gerenciamento de rede (NMS) pode solicitar estatísticas de interface a cada 60 segundos. Isso fornece instantâneos periódicos do estado do dispositivo; no entanto, a visibilidade disponível para o aplicativo de monitoramento está diretamente relacionada ao intervalo de polling configurado.
Com a telemetria de fluxo contínuo, o switch Nexus envia as informações selecionadas para o receptor de telemetria de acordo com a assinatura configurada.
As diferenças fundamentais podem ser resumidas da seguinte forma:
| Pesquisa tradicional | Telemetria de streaming |
|---|---|
| O cliente inicia a solicitação. | O dispositivo de rede envia os dados. |
| Modelo de recebimento | Modelo Push |
| Os dados são recuperados de acordo com os intervalos de polling. | Os dados são enviados de acordo com uma assinatura de telemetria. |
| Normalmente fornece snapshots periódicos. | Oferece suporte à coleta periódica e baseada em eventos. |
| O sistema de monitoramento solicita informações do dispositivo. | O dispositivo transmite as informações selecionadas para um receptor. |
A telemetria de fluxo não substitui necessariamente os mecanismos de monitoramento tradicionais. CLI, SNMP, Syslog e Telemetria podem coexistir e servir a diferentes propósitos operacionais.
A principal diferença é o modelo de coleta de dados.
Casos de uso reais
Em ambientes de produção, a telemetria de fluxo é normalmente usada para fornecer visibilidade contínua da integridade da rede e do sistema.
Os casos de uso típicos incluem o monitoramento de contadores de interface e alterações de status, recursos do sistema, como utilização de CPU e memória, e informações de malha do data center, como pares de LAN extensível virtual (VXLAN) e o estado do par do protocolo de gateway de borda (BGP). A telemetria baseada em eventos também pode ser usada para relatar alterações de estado operacional à medida que elas ocorrem.
Os dados de telemetria exportados podem ser consumidos por plataformas externas de monitoramento e observação para painéis, alertas, análise histórica e solução de problemas.
Visão geral do processamento de telemetria
Em um alto nível, a telemetria de transmissão no NX-OS pode ser entendida como quatro etapas principais:
+-----------------------+
| Data Collection |
+-----------+-----------+
|
v
+-----------------------+
| Data Encoding |
+-----------+-----------+
|
v
+-----------------------+
| Data Transport |
+-----------+-----------+
|
v
+-----------------------+
| Telemetry Receiver |
+-----------------------+
Essas etapas respondem a quatro perguntas básicas:
- Levantamento de dados: Quais informações são coletadas?
- Codificação de dados: Como as informações são representadas?
- Transporte de dados: Como os dados de telemetria são fornecidos?
- Receptor de telemetria: Para onde são enviados os dados de telemetria?
Arquitetura e terminologia de telemetria
Levantamento de dados
O primeiro estágio determina quais informações devem ser coletadas do switch.
Para os exemplos deste documento, os dados de telemetria são coletados do Mecanismo de Gerenciamento de Dados (DME).
Mecanismo de gerenciamento de dados — DME
O mecanismo de gerenciamento de dados mantém uma representação estruturada de informações operacionais e de configuração no NX-OS.
Em vez de representar as informações do dispositivo apenas como texto CLI, o DME organiza as informações como objetos gerenciados que podem ser acessados por meio de caminhos hierárquicos.
Por exemplo:
sys/intf/phys-[eth1/10]
Identifica o objeto DME associado à Ethernet1/10.
Outros caminhos DME usados neste laboratório incluem:
sys/intf/phys-[eth1/10]/dbgIfIn
sys/intf/phys-[eth1/10]/dbgIfOut
sys/intf/phys-[eth1/10]/phys
sys/intf/lb-[lo100]
Cada caminho representa um objeto diferente ou parte das informações disponíveis através do DME. Esses são os mesmos caminhos já usados na configuração do laboratório.
Objetos Gerenciados e a Árvore de Informações de Gerenciamento
O banco de dados DME é composto de MOs (Managed Objects, objetos gerenciados).
Um objeto gerenciado representa uma entidade dentro do modelo de gerenciamento do NX-OS, como:
- Uma interface física
- Uma interface de loopback
- Estatísticas de entrada de interface
- Estatísticas de saída da interface
Os objetos gerenciados são organizados hierarquicamente em uma MIT (Management Information Tree, árvore de informações de gerenciamento).
Uma representação simplificada dos objetos usados neste laboratório é:
sys
|
+-- intf
|
+-- phys-[eth1/10]
| |
| +-- dbgIfIn
| +-- dbgIfOut
| +-- phys
|
+-- lb-[lo100]
Essa hierarquia é útil para entender como os caminhos do sensor de telemetria identificam informações específicas no DME.
Nome distinto — DN
Cada Objeto Gerenciado pode ser identificado exclusivamente por um DN (Distinguished Name - Nome Distinto).
O DN representa o caminho hierárquico da raiz da árvore DME até o objeto de destino.
For example: sys/intf/lb-[lo100]
Identifica o Objeto Gerenciado Loopback100.
Da mesma forma:
sys/intf/phys-[eth1/10]/dbgIfIn
Identifica o objeto de estatísticas de entrada associado à Ethernet1/10.
Uma maneira simples de entender um DN é considerá-lo como o endereço completo de um objeto dentro da hierarquia DME.
Caminho do sensor
Um caminho de sensor identifica as informações que o NX-OS deve monitorar para uma assinatura de telemetria.
Nos exemplos iniciais de laboratório, os nomes distintos DME são usados como caminhos de sensor. Um exemplo prático posterior demonstra o rótulo do caminho de recursos predefinido.
Por exemplo:
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
Esses caminhos fornecem estatísticas de entrada, estatísticas de saída e informações operacionais para Ethernet1/10.
Codificação de dados
Depois que o NX-OS coleta as informações solicitadas, os dados devem ser codificados para que possam ser transmitidos.
A codificação usada neste laboratório é Google Protocol Buffers (GPB).
A configuração de destino especifica:
ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB
O GPB define como as informações de telemetria coletadas são representadas na mensagem.
A codificação e o transporte são funções separadas: O GPB define a representação de dados, enquanto o mecanismo de transporte determina como a mensagem é entregue.
Transporte de dados
O protocolo de transporte usado neste laboratório é o gRPC.
O switch Nexus envia os dados de telemetria codificados em GPB para:
192.168.100.10:57000
usando gRPC.
Portanto:
O GPB define como as informações de telemetria são codificadas.
O gRPC fornece o mecanismo de transporte usado para entregar as mensagens de telemetria ao receptor.
O transporte gRPC usado pela telemetria de fluxo não deve ser confundido com o agente gRPC do NX-OS usado para serviços como gNMI (gRPC Network Management Interface, Interface de gerenciamento de rede gRPC) e gNOI (gRPC Network Operations Interface, Interface de operações de rede gRPC).
Receptor de telemetria
O receptor de telemetria é o sistema externo ou aplicativo que recebe e processa o fluxo de telemetria.
Neste laboratório, um servidor Ubuntu executando o Telegraf é usado como o receptor. O receptor escuta a porta TCP 57000 e aceita o fluxo de telemetria GPB-over-gRPC gerado pelo switch Nexus.
A implementação do receptor usada no laboratório é descrita mais adiante na seção Prepare o Receptor de Telemetria.
Grupo de Destino
O grupo de destino define para onde os dados de telemetria devem ser enviados e como devem ser transportados.
O laboratório usa:
destination-group 1 ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB use-vrf default
Isso define o endereço do receptor, a porta de destino, o protocolo de transporte, a codificação e a instância de Virtual Routing and Forwarding (VRF) usada para a entrega de telemetria.
Grupo de sensores
O grupo de sensores define quais informações devem ser monitoradas.
Por exemplo:
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
Neste exemplo, o Sensor Group 2 monitora estatísticas de entrada Ethernet1/10, estatísticas de saída e informações de interface operacional. O caminho dbgIfIn fornece estatísticas de interface de entrada, dbgIfOut fornece estatísticas de interface de saída e phys fornece informações operacionais para a interface.
Um grupo de sensores pode incluir vários caminhos de sensores relacionados e, portanto, responde à pergunta:
Quais dados são coletados?
Assinatura
Uma assinatura associa um grupo de sensores a um grupo de destino e define o comportamento de coleta.
Por exemplo:
subscription 2 dst-grp 1 snsr-grp 2 sample-interval 60000
Neste exemplo:
- O Grupo de sensores 2 determina quais informações são coletadas.
- O intervalo de amostra determina o comportamento de coleta.
- O grupo de destino 1 determina para onde e como as informações são enviadas.
Portanto, a assinatura conecta os principais elementos de configuração de telemetria:
Grupo de sensores + comportamento de coleta + grupo de destino
Telemetria periódica e baseada em eventos
A telemetria de streaming do Cisco NX-OS oferece suporte à coleta periódica e baseada em eventos para assinaturas baseadas em DME.
O comportamento da coleta é controlado pelo intervalo de amostra associado ao grupo de sensores dentro de uma assinatura.
Telemetria periódica
Com a telemetria periódica, o NX-OS coleta e envia as informações monitoradas em um intervalo configurado.
O intervalo de amostragem é especificado em milissegundos.
For example: snsr-grp 2 sample-interval 60000
Configura um intervalo de coleta de 60 segundos.
A telemetria periódica é útil para informações que mudam continuamente e normalmente são analisadas ao longo do tempo, como:
- Contadores de pacotes de interface
- Contadores de bytes
- Erros e descartes
- Estatísticas operacionais
- Utilização de recursos
Neste laboratório, as assinaturas 1 e 2 usam a coleta periódica.
A Assinatura 1 coleta o objeto de interface Ethernet1/10 a cada 10 segundos, enquanto a Assinatura 2 coleta estatísticas de interface e informações operacionais a cada 60 segundos.
Telemetria baseada em eventos
Com a telemetria baseada em eventos, o NX-OS não usa um temporizador de coleta recorrente.
Para telemetria baseada em DME, o comportamento baseado em eventos é configurado com:
sample-interval 0
Quando um objeto monitorado é alterado, a telemetria pode gerar uma atualização associada a essa alteração.
Este método de coleta é útil para informações como:
- Alterações de configuração
- Alterações de estado administrativo
- Criação ou exclusão de objeto
- Outras alterações em um objeto DME monitorado
Neste laboratório, a Subscrição 3 monitora o objeto DME Loopback100:
sys/intf/lb-[lo100]: snsr-grp 3 sample-interval 0
As alterações no objeto Loopback100 monitorado são, portanto, usadas posteriormente neste documento para demonstrar a telemetria baseada em eventos.
Comportamento de Coleta Usado no Laboratório
As três assinaturas usadas na configuração inicial do laboratório podem ser resumidas da seguinte forma:
| Assinatura | Informações monitoradas | Intervalo de Amostra | Comportamento da Coleção |
|---|---|---|---|
| 1 | objeto de interface Ethernet1/10 | 10000 ms | Periódico |
| 2 | Estatísticas e estado operacional da Ethernet1/10 | 60000 ms | Periódico |
| 3 | Objeto Loopback100 | 0 | Baseado em evento |
A principal distinção é o acionador usado para gerar dados de telemetria:
| Telemetria periódica | Telemetria baseada em eventos |
|---|---|
| Usa um temporizador configurado. | Não usa um temporizador periódico. |
| sample-interval > 0 | sample-interval 0 |
| Produz amostras repetidas. | Produz atualizações quando objetos monitorados são alterados. |
| Comumente usado para contadores e estatísticas. | Geralmente usado para alterações de configuração ou estado. |
As seções de configuração e verificação demonstram ambos os comportamentos de coleta usando as assinaturas definidas acima.
Preparar o receptor de telemetria
A telemetria de fluxo requer um receptor externo capaz de aceitar e processar os dados de telemetria enviados pelo switch Nexus.
Para o transporte GPB-over-gRPC usado neste documento, o receptor deve ser capaz de:
- Recebendo conexões gRPC
- Escutando na porta de destino configurada
- Decodificação de mensagens de telemetria GPB
- Processamento ou armazenamento dos dados recebidos
A implementação do receptor de telemetria é independente da configuração de telemetria do NX-OS descrita neste documento.
Note: A instalação, a configuração, a operação e a solução de problemas do software receptor de telemetria de terceiros estão fora do escopo deste documento. Consulte a documentação fornecida pelo fornecedor do receptor para obter informações sobre configuração e suporte.
Receptor usado neste laboratório
Para fins de demonstração, o laboratório usa um servidor Ubuntu externo que executa o Telegraf como o receptor de telemetria.
Os parâmetros do receptor são:
| Parâmetro | Valor |
|---|---|
| Endereço do receptor | 192.168.100.10 |
| Transporte | gRPC |
| Porta de escuta | TCP/57000 |
| Codificação | GPB |
A configuração do software do lado do receptor não é abordada neste documento.
Note: Os exemplos de saída do receptor mostrados neste documento são filtrados para destacar os campos relevantes para cada etapa de verificação.
Antes de configurar a telemetria de fluxo contínuo no switch Nexus, verifique se:
- A conectividade IP existe entre o switch Nexus e o receptor.
- O aplicativo receptor está em execução.
- A porta de destino configurada está escutando.
- O receptor suporta o protocolo de transporte configurado.
- O receptor suporta a codificação de telemetria configurada.
Para este laboratório, a Ethernet1/10 no switch Nexus usa 192.168.100.1/24 e o receptor de telemetria usa 192.168.100.10/24. A acessibilidade básica da Camada 3 deve ser confirmada antes da solução de problemas de comportamento específico da telemetria.
Quando o receptor estiver acessível e pronto para aceitar a telemetria GPB-over-gRPC na porta TCP 57000, a configuração de telemetria do NX-OS poderá ser aplicada.
Configurar telemetria de streaming no NX-OS
A configuração usa três componentes principais:
- Grupo de Destino: Define para onde os dados de telemetria são enviados e como eles são transportados.
- Grupo de sensores: Define quais informações são coletadas.
- Assinatura: Associa um grupo de sensores a um grupo de destinos e define o comportamento de coleta.
O laboratório usa este destino de telemetria:
| Parâmetro | Valor |
|---|---|
| Destino | 192.168.100.10:57000 |
| Transporte | gRPC |
| Codificação | GPB |
| VRF | padrão |
A configuração inicial do laboratório usa três assinaturas:
| Assinatura | Sensor | Tipo de Coleção | Intervalo de Amostra |
|---|---|---|---|
| 1 | objeto de interface Ethernet1/10 | Periódico | 10000 ms |
| 2 | Estatísticas e estado operacional da Ethernet1/10 | Periódico | 60000 ms |
| 3 | Objeto Loopback100 | Baseado em evento | 0 |
Ativar o recurso de telemetria
A telemetria de streaming deve ser habilitada globalmente primeiro.
N9K-TELEMETRY-SW1# configure terminal N9K-TELEMETRY-SW1(config)# feature telemetry
Entre no modo de configuração de telemetria:
N9K-TELEMETRY-SW1(config)# telemetry N9K-TELEMETRY-SW1(config-telemetry)#
A configuração de telemetria restante é executada nesse modo.
Configurar o grupo de destino
O grupo de destino identifica o receptor de telemetria externo e define o transporte e a codificação usados para enviar dados de telemetria.
Configurar:
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
Essa configuração define:
- Endereço de destino: 192.168.100.10
- Porta de Destino: 57000
- Transporte: gRPC
- Codificação: GPB
- VRF: padrão
O VRF padrão é usado porque o receptor de telemetria pode ser acessado por meio de Ethernet1/10 no VRF padrão.
O VRF selecionado para transporte de telemetria deve fornecer acessibilidade IP ao receptor configurado.
Configurar o grupo de sensores 1
O grupo de sensores 1 monitora o objeto de interface Ethernet1/10 DME.
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 1 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]
O caminho do sensor identifica o objeto gerenciado Ethernet1/10 na hierarquia DME e fornece informações gerais de interface associadas a esse objeto.
Configurar assinatura 1
Associe o grupo de sensores 1 ao grupo de destinos 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
O intervalo de amostragem é especificado em milissegundos.
10000 ms = 10 segundos
Portanto, a Assinatura 1 coleta periodicamente o objeto DME Ethernet1/10 a cada 10 segundos e envia os dados de telemetria para o Grupo de Destino 1.
Configurar o grupo de sensores 2
O Sensor Group 2 coleta estatísticas e informações operacionais para Ethernet1/10.
Configurar:
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
Os caminhos do sensor oferecem:
| Caminho do sensor | Informações |
|---|---|
| sys/intf/phys-[eth1/10]/dbgIfIn | Estatísticas de interface de entrada |
| sys/intf/phys-[eth1/10]/dbgIfOut | Estatísticas de interface de saída |
| sys/intf/phys-[eth1/10]/phys | Informações da interface operacional |
Um grupo de sensores pode conter vários caminhos de sensores relacionados, permitindo que a assinatura colete várias categorias de informações da mesma interface monitorada.
Configurar Assinatura 2
Associe o grupo de sensores 2 ao grupo de destinos 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
O intervalo de amostragem configurado é:
60000 ms = 60 segundos
Portanto, a Assinatura 2 coleta as estatísticas e informações operacionais da Ethernet1/10 a cada 60 segundos.
Esta assinatura é usada posteriormente no documento para verificar o comportamento de telemetria periódica.
Configurar a interface de loopback
Uma interface de loopback é usada para demonstrar a telemetria baseada em eventos sem exigir uma conexão física adicional.
Configurar:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# ip address 10.255.255.100/32
O objeto DME correspondente é:
sys/intf/lb-[lo100]
A interface de loopback oferece uma maneira simples de gerar alterações controladas de configuração e de estado administrativo durante a verificação de telemetria baseada em eventos.
Configurar o grupo de sensores 3
Configure o caminho do sensor DME Loopback100:
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 3 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/lb-[lo100]
O Sensor Group 3 monitora o Objeto Gerenciado Loopback100.
Configurar Assinatura 3
Associe o Sensor Group 3 ao Destination Group 1 e configure a coleta baseada em 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 assinaturas baseadas em DME, um intervalo de amostra de zero configura o comportamento baseado em eventos.
As alterações no objeto Loopback100 monitorado podem, portanto, gerar notificações de telemetria sem usar um temporizador de coleta recorrente.
Esta assinatura é usada posteriormente para demonstrar alterações de descrição e estado administrativo.
Concluir a configuração inicial de telemetria
Após concluir a configuração, verifique-a com:
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
Nesse ponto, o switch tem o destino, os grupos de sensores e as assinaturas necessárias para começar a enviar dados de telemetria para o receptor configurado.
A próxima seção verifica a sessão de transporte e a telemetria periódica gerada pelas assinaturas Ethernet1/10.
Verificar Telemetria Periódica
Depois que a configuração de telemetria for aplicada, verifique se a sessão de transporte está estabelecida, se os grupos de sensores periódicos estão ativos e se os dados de telemetria estão sendo coletados e entregues ao receptor.
Verifique o transporte da telemetria
Execute 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#
O estado Conectado confirma que a sessão de transporte gRPC para o receptor de telemetria configurado foi estabelecida.
Os parâmetros de transporte relevantes também correspondem ao grupo de destino configurado.
Verifique os 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
O banco de dados do grupo de sensores confirma que os grupos de sensores periódicos estão ativos:
| Grupo de sensores | Tipo | intervalo de amostragem | Assinatura |
|---|---|---|---|
| 1 | Temporizador / DME | 10000 ms/em execução | 1 |
| 2 | Temporizador / DME | 60000 ms/em execução | 2 |
O Sensor Group 1 coleta o objeto de interface Ethernet1/10 a cada 10 segundos.
O Sensor Group 2 coleta estatísticas e informações operacionais da Ethernet1/10 a cada 60 segundos.
O mesmo comando também exibe os caminhos configurados do sensor:
sys/intf/phys-[eth1/10] sys/intf/phys-[eth1/10]/dbgIfIn sys/intf/phys-[eth1/10]/dbgIfOut sys/intf/phys-[eth1/10]/phys
Para os caminhos de sensor usados neste laboratório, os tempos de coleta e codificação eram geralmente entre 0 e 1 ms, e nenhuma queda de mensagem de telemetria foi observada.
Verificar Coleta de Dados
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#
O laboratório relatou:
DME Successful Collections: 513 Payloads: 513 Failed: 0 Skipped: 44 Dropped: 0
Os contadores de carga útil e de êxito confirmam que os dados de telemetria do DME estão sendo coletados e as cargas úteis de telemetria estão sendo geradas.
As 44 coletas ignoradas são contadores históricos observados enquanto o destino da telemetria estava temporariamente indisponível durante o laboratório. Esses contadores são examinados posteriormente na seção Troubleshooting Básico.
Para obter informações adicionais por caminho do sensor, use:
N9K-TELEMETRY-SW1# show telemetry data collector details
Esse comando pode identificar quais caminhos de sensor configurados contribuíram para coleções bem-sucedidas, com falha, ignoradas ou eliminadas.
Verificar dados periódicos no receptor
A Assinatura 2 coleta estatísticas de Ethernet1/10 a cada 60 segundos.
O receptor de telemetria relatou estas estatísticas de entrada às 21:44:45, UTC (Tempo Universal Coordenado):
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
Um minuto depois, outra amostra foi recebida:
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
As alterações do contador entre as duas amostras estão resumidas a seguir:
| Contador | 21:44:45 | 21:45:45 |
|---|---|---|
| Pacotes unicast | 31,256 | 31,292 |
| Pacotes multicast | 143,403 | 143,430 |
| Pacotes de broadcast | 5,074 | 5,075 |
| Octetos | 12,870,535 | 12,875,428 |
| Erros | 0 | 0 |
| Discards | 0 | 0 |
Os timestamps são separados por aproximadamente 60 segundos, correspondendo ao intervalo de amostragem configurado para a Assinatura 2.
Os contadores de pacotes e bytes cada vez maiores também confirmam que as estatísticas atualizadas de interface estão sendo coletadas e entregues ao receptor.
Verificar informações operacionais e de saída
O caminho do sensor dbgIfOut fornece estatísticas de saída para Ethernet1/10.
Uma amostra colhida às 21:45:45 UTC indicou:
broadcastPkts: 8 discards: 0 errors: 0 multicastPkts: 4712 octets: 2444721 ucastPkts: 4092
O caminho do sensor phys fornece atributos operacionais para a mesma interface.
O receptor informou:
adminSt: up operSt: up operSpeed: 1G operDuplex: full operMtu: 1500 operDescr: TELEMETRY-COLLECTOR
Esses exemplos confirmam que o Sensor Group 2 fornece estatísticas de interface e informações operacionais através de seus três caminhos configurados do sensor DME.
Resumo da verificação periódica de telemetria
A verificação de telemetria periódica confirma:
| Verificação | Resultado |
|---|---|
| sessão de transporte gRPC | Conectado |
| codificação GPB | Confirmado |
| Grupo de sensores 1 | Execução a 10000 ms |
| Grupo de sensores 2 | Execução a 60000 ms |
| coleções de DME | Bem-sucedido |
| Coleções com falha | 0 |
| Cargas descartadas | 0 |
| Amostras periódicas do receptor | Recebido |
| Contadores de interface | Atualizando entre amostras |
Verificar a telemetria baseada em eventos
Após verificar a telemetria periódica, use a Assinatura 3 para validar a telemetria baseada em eventos gerando alterações controladas no Objeto Gerenciado Loopback100.
Verifique a assinatura baseada em evento
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]
O mesmo banco de dados de telemetria confirma que o caminho do sensor está inscrito por meio da Assinatura 3.
Gerar Atualizações Baseadas em Evento
Para verificar a geração de eventos, modifique a descrição de Loopback100:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# description TELEMETRY-EVENT-DEMO
O receptor de telemetria relatou:
{
"timestamp": "2026-09-17T21:41:12Z",
"source": "N9K-TELEMETRY-SW1",
"subscription": "3",
"event": {
"descr": "TELEMETRY-EVENT-DEMO",
"dn": "sys/intf/lb-[lo100]",
"status": "modified"
}
}
O dn identifica o objeto DME monitorado e o atributo descr identifica a propriedade que foi alterada.
Em seguida, desative e restaure administrativamente a interface:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# shutdown
Em seguida:
N9K-TELEMETRY-SW1(config-if)# no shutdown
O receptor detectou as duas alterações de estado.
| Carimbo de data/hora | Atributo Alterado | Valor |
|---|---|---|
| 21:41:12 | descr | TELEMETRIA-EVENT-DEMO |
| 21:41:19 | adminSt | down |
| 21:41:24 | adminSt | up |
Cada atualização fez referência ao mesmo objeto monitorado:
sys/intf/lb-[lo100]
Ele relatou o status do objeto como modificado.
Esses resultados confirmam que as alterações em diferentes atributos do Objeto gerenciado monitorado podem gerar atualizações de telemetria individuais.
Verifique o instantâneo inicial e as mensagens de evento
Quando a assinatura baseada em evento foi estabelecida, o NX-OS gerou um instantâneo inicial do objeto monitorado.
O banco de dados de caminho do sensor informou:
Estatísticas do instantâneo:
Sent = 1 Error = 0 Drops = 0
Após as três alterações controladas, o mesmo caminho do sensor informado:
Estatísticas da mensagem:
Sent = 3 Error = 0 Drops = 0
Os resultados podem, por conseguinte, ser resumidos do seguinte modo:
| Coleção | Contagem |
|---|---|
| Instantâneo inicial | 1 |
| Modificação de descrição | 1 |
| Estado administrativo inativo | 1 |
| Estado administrativo ativo | 1 |
| Total | 4 |
O instantâneo inicial representa o estado do objeto monitorado quando a assinatura se torna ativa, enquanto as mensagens subsequentes correspondem às alterações do objeto.
Verificar Estatísticas de Coleta 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#
O laboratório relatou:
Collection Count: 4
Latest Collection Time: Thu Sep 17 21:41:24.045 UTC
Sensor Path: sys/intf/lb-[lo100]
A contagem de coleta corresponde a um instantâneo inicial e às três alterações geradas durante o teste.
Verificar erros do coletor 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#
Nenhum erro de coletor de eventos foi observado durante o teste.
Resumo da verificação de telemetria baseada em eventos
A verificação de telemetria baseada em eventos confirma:
| Verificação | Resultado |
|---|---|
| Grupo de sensores | 3 |
| Caminho do sensor | sys/intf/lb-[lo100] |
| Tipo de Coleção | Evento/DME |
| intervalo de amostragem | 0 / Sem Temporizador |
| Instantâneo inicial | Enviado |
| Alteração de Descrição | Detectado |
| adminSt Inativo | Detectado |
| adminConfigurar | Detectado |
| Total de Coleções | 4 |
| Erros do coletor de eventos | 0 |
A detecção bem-sucedida das alterações controladas de Loopback100 confirma que a Assinatura 3 está operando conforme esperado.
A próxima seção examina os comandos principais de verificação e solução de problemas usados para avaliar a operação da telemetria de fluxo.
Troubleshooting Básico
Quando os dados de telemetria não forem recebidos como esperado, comece a solução de problemas determinando se o problema está relacionado à sessão de transporte, coleta de dados, configuração do sensor ou ao receptor externo.
Este fluxo de trabalho usa um problema observado durante este laboratório, em que o NX-OS relatou 44 coletas ignoradas e um erro de transmissão gRPC histórico.
Verifique o estado de transporte atual
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 a verificação final, a sessão de telemetria relatou:
Session ID: 0
Destination Group: 1
IP Address: 192.168.100.10
Port: 57000
Encoding: GPB
Transport: gRPC
Status: Connected
Um estado Conectado confirma que a sessão de transporte está estabelecida no momento.
No entanto, o estado da sessão atual não indica necessariamente se os problemas de conectividade ocorreram anteriormente. Portanto, revise também os contadores de coleta e transporte históricos.
Revisar Contadores de Coleta de Dados
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#
O laboratório relatou:
DME Successful Collections: 513
Payloads: 513
Failed: 0
Skipped: 44
Dropped: 0
Os contadores Bem-sucedidos e de Carga confirmam que ocorreram coletas de telemetria DME e geração de carga.
No entanto, o contador Ignorado indica que 44 coletas agendadas não foram executadas.
Para identificar quais caminhos do sensor foram afetados, use:
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#
A saída detalhada relatada:
| Caminho do sensor | Ignorado |
|---|---|
| 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 |
As coleções ignoradas foram distribuídas pelos caminhos periódicos do sensor, indicando que o problema não foi isolado a um único objeto DME.
Note: Os contadores de coleção são cumulativos. Um contador histórico diferente de zero não indica necessariamente que a mesma condição está presente no momento.
Determine por que as coleções foram ignoradas
N9K-TELEMETRY-SW1# show telemetry control stats
--------------------------------------------------------------------------------
Error Description Error Count
--------------------------------------------------------------------------------
<snip>
Collections skipped due to destination unreachable 44
<snip>
N9K-TELEMETRY-SW1#
Esta saída identifica diretamente o motivo para as coletas ignoradas:
Destino inalcançável = 44
O valor corresponde às 44 coletas ignoradas relatadas pelo coletor de dados DME.
Isso permite que a investigação se afaste dos próprios caminhos do sensor e vá em direção ao destino da telemetria e ao caminho de transporte.
Inspecionar erros de transporte
Use a ID de sessão relatada pelo comando 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#
O laboratório relatou:
Connection Error Count: 0
Tx Error Count: 1
Last Tx Error: Thu Sep 17 21:22:16.008 UTC
Last Tx Return Code: UNAVAILABLE
O código de retorno NÃO DISPONÍVEL registra uma falha de transmissão gRPC associada ao destino de telemetria.
Neste laboratório, o receptor externo foi intencionalmente parado e reiniciado enquanto sua configuração estava sendo modificada. Durante esse intervalo, o NX-OS não pôde alcançar o destino de telemetria, que corresponde aos contadores de coleta de destino inalcançável observados acima.
A correlação importante é:
| Observação | Resultado |
|---|---|
| Coleções ignoradas | 44 |
| Destino inalcançável | 44 |
| Erros de transmissão de transporte | 1 |
| Último código de retorno de Tx | INDISPONÍVEL |
| Estado de transporte atual | Conectado |
Os contadores correspondentes ignorados e de destino inalcançável fornecem evidência direta do motivo pelo qual as coletas foram ignoradas.
O erro de transporte histórico fornece informações adicionais sobre a falha de transporte observada durante a mesma atividade de laboratório.
Verificar a recuperação do transporte
Depois que a conectividade com o receptor for restaurada, use:
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#
A verificação final do laboratório relatou:
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
Esses valores mostram que a sessão de transporte se recuperou e estava transmitindo dados de telemetria ativamente sem mensagens em fila ou descartadas.
Os indicadores mais importantes do estado atual foram:
| Indicador | Resultado |
|---|---|
| Status do transporte | Conectado |
| Fila atual | 0 |
| Mensagens Ignoradas | 0 |
| controle de fluxo | Nunca aplicado |
Esta distinção é importante ao Troubleshoot contadores de telemetria: os erros históricos podem permanecer visíveis mesmo após a condição subjacente ter sido resolvida.
Verificar erros de configuração e do coletor de eventos
Comandos adicionais podem ser usados para verificar se o NX-OS relata problemas de configuração ou de processamento 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 telemetria baseada em eventos, use:
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 os contadores de erro do coletor de eventos também foram zero.
Esses resultados ajudam a eliminar falhas de configuração e do coletor de eventos ao investigar as coletas periódicas ignoradas.
Troubleshooting de Fluxo de Trabalho
Os comandos usados durante esta investigação podem ser resumidos da seguinte forma:
| Comando | Propósito |
|---|---|
| show telemetry transport | Verifique o estado da sessão de transporte atual. |
| mostrar resumo do coletor de dados de telemetria | Identifique coleções bem-sucedidas, com falha, ignoradas ou eliminadas. |
| mostrar detalhes do coletor de dados de telemetria | Determine quais caminhos do sensor são afetados. |
| show telemetry control stats | Determine por que as coleções foram ignoradas. |
| show telemetry transport <session-id> errors | Inspecione as falhas de transporte. |
| show telemetry transport <session-id> stats | Revisar a recuperação de transporte, filas e descartes. |
| show telemetry config errors | Identificar erros de configuração de telemetria. |
| mostrar erros do coletor de eventos de telemetria | Identificar erros do coletor de eventos. |
Neste laboratório, a sequência de solução de problemas identificou uma condição temporária de acessibilidade do destino de telemetria em vez de uma falha de configuração ou de caminho do sensor DME.
Depois que o receptor se tornou disponível novamente, o transporte de telemetria retornou ao estado Conectado, as coletas foram retomadas e nenhuma condição atual de fila ou de queda de mensagem foi observada.
Exemplo de aplicação prática: Monitorar recursos do sistema
O monitoramento de recursos do sistema é um caso de uso comum da telemetria de fluxo. As informações de CPU e memória podem ser exportadas periodicamente de um switch Nexus para uma plataforma de monitoramento externa para análise histórica, painéis, monitoramento de capacidade e alertas.
O Cisco NX-OS fornece rótulos de caminho de telemetria predefinidos para informações comumente monitoradas. Neste exemplo, o rótulo do caminho de recursos é usado para coletar informações da CPU e da memória do sistema.
Configurar Telemetria de Recursos do Sistema
Crie um novo grupo de sensores usando o rótulo do caminho de recursos:
N9K-TELEMETRY-SW1(config)# telemetry
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 4
N9K-TELEMETRY-SW1(conf-tm-sensor)# path resources
Crie a assinatura 4 e associe o grupo de sensores 4 ao 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
O Sensor Group 4 usa o rótulo de caminho de recursos predefinidos. A Inscrição 4 associa o grupo de sensores ao destino de telemetria existente e configura a coleta periódica com um intervalo de amostragem diferente de zero.
A configuração relevante é:
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
Revisar o rótulo de caminho de recursos
Execute este comando para examinar os caminhos DME representados pelo rótulo do caminho 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"))
A saída mostra que o rótulo de recursos representa vários caminhos DME subjacentes.
Os caminhos sys/proc e sys/procsys usam consultas de sondagem e fornecem informações sobre processos e recursos do sistema. O caminho sys/procsys/sysmem usa uma consulta de eventos que pode relatar uma alteração quando o status da memória monitorada é atualizado e não está mais OK.
Isso demonstra a diferença entre especificar um nome distinto DME individual diretamente e usar um rótulo de caminho de telemetria predefinido.
Por exemplo:
Individual DME path:
path sys/intf/phys-[eth1/10]
Predefined path label:
path resources
Verificar Telemetria de Recursos do Sistema
Use show telemetry control database para verificar o estado do Sensor Group 4 e da Subscrição 4.
O Banco de Dados do Grupo de Sensor relata:
Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions SubID ---------------------------------------------------------------------------------------------------- 4 Timer /DME 10000/Running 1 4
O tipo Temporizador/DME e o intervalo de amostragem 10000/Em execução confirmam que o Grupo de sensores 4 está operando como uma fonte de telemetria DME periódica.
O Banco de Dados de Caminho do Sensor também mostra os caminhos subjacentes associados ao rótulo de recursos.
Por exemplo:
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
O caminho relacionado ao processo também relata a coleta de telemetria ativa:
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
Esses contadores confirmam que as informações do recurso estão sendo coletadas, codificadas como GPB e transmitidas sem erros de mensagem ou descartes.
Compare com recursos do sistema NX-OS
A CLI do NX-OS tradicional pode ser usada para exibir o estado atual da CPU e da memória do 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
A CLI fornece uma visualização instantânea dos recursos do sistema.
A telemetria de fluxo permite que o mesmo tipo de informações de CPU e memória seja exportado para um receptor externo, de modo que várias amostras possam ser armazenadas e analisadas ao longo do tempo.
A utilização da CPU pode mudar rapidamente. Portanto, os valores de CPU exibidos pelo CLI e os valores recebidos por telemetria podem diferir quando as amostras são coletadas em momentos diferentes.
Verificar dados do recurso no receptor
O receptor de telemetria decodificou com êxito as informações de recursos do sistema associadas à Assinatura 4.
Este exemplo mostra informações de CPU e memória de um exemplo de telemetria:
{
"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
}
}
A saída do receptor confirma que as informações de CPU e memória da Assinatura 4 estão sendo decodificadas com êxito e disponibilizadas para monitoramento externo.
Para comparação, o NX-OS CLI relatou aproximadamente 9,3 GB de memória usada de aproximadamente 24,5 GB de memória total e um status de memória atual de OK. O exemplo de telemetria relata o mesmo valor total de memória, uma utilização de memória de aproximadamente 38% e o mesmo estado de memória OK.
Os valores da CPU podem variar entre o CLI e as amostras de telemetria, pois a utilização da CPU muda dinamicamente e as medições não são necessariamente coletadas no mesmo instante.
Observar a utilização de recursos ao longo do tempo
Várias amostras de telemetria podem ser usadas para observar como a utilização de recursos do sistema muda com o tempo.
Estes exemplos foram recebidos da Assinatura 4 durante o laboratório:
Utilização Média da 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
Utilização de memória
39% |
38% | ●-----------●-----------●
37% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
37.82% 38.06% 38.18%
Time
Esses exemplos ilustram como a telemetria periódica pode fornecer uma visão baseada em tempo do comportamento do sistema, em vez de uma única medição instantânea. Em um ambiente de produção, uma plataforma de monitoramento ou observação pode armazenar um número maior de amostras e usar as amostras para identificar tendências, gerar alertas e criar painéis de histórico.
Conclusão
A telemetria de transmissão contínua do Cisco NX-OS fornece um mecanismo estruturado para exportar informações operacionais dos switches Cisco Nexus 9000 para um receptor de telemetria externo.
Este documento demonstrou os componentes fundamentais da Telemetria de Streaming, incluindo caminhos do sensor DME, codificação GPB, transporte gRPC, grupos de destinos, grupos de sensores e assinaturas.
Usando o ambiente de laboratório, a telemetria periódica e baseada em eventos foi configurada e verificada. As assinaturas periódicas foram usadas para coletar estatísticas e informações operacionais da Ethernet1/10, enquanto uma assinatura baseada em eventos foi usada para detectar alterações controladas no Objeto Gerenciado Loopback100.
Um exemplo prático de monitoramento de recursos do sistema também demonstrou como o rótulo de caminho de recursos predefinidos pode ser usado para exportar informações de CPU e memória para um receptor de telemetria externo.
Os exemplos de verificação e solução de problemas demonstraram como os comandos de telemetria do NX-OS podem ser usados para validar a conectividade de transporte, coleta de dados, processamento de eventos e falhas de coleta de histórico.
Esses conceitos fornecem uma base para entender, implementar, verificar e solucionar problemas de implantações básicas de telemetria de transmissão no Cisco Nexus 9000 NX-OS.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
01-Oct-2026
|
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)