Configurazione e verifica della telemetria sulla piattaforma Nexus
Sommario
Introduzione
In questo documento viene descritto come implementare e verificare la telemetria di streaming sugli switch Cisco Nexus 9000 con Cisco NX-OS.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza di base dei seguenti argomenti:
- Cisco NX-OS CLI
- Connettività IP Layer 3 di base
- Nozioni base sul monitoraggio della rete
- Conoscenza di base dei concetti di telemetria di rete
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
| Componente | Piattaforma/Software | Versione/Valore | Scopo |
|---|---|---|---|
| N9K-TELEMETRY-SW1 | N9K-C9348GC-FXP | 10.6(4) | Origine telemetria |
| Ricevitore telemetrico | Server Ubuntu | 22.04.5 | Ricevitore telemetrico esterno |
| Applicazione di telemetria | Telegraf | 1.40.0 | Ricevitore di telemetria Google Protocol Buffer (GPB) over RPC |
| Porta di ascolto | TCP | 57000 | Porta ricevitore telemetria |
| Formato di uscita ricevitore | JSON (JavaScript Object Notation) | — | Uscita di telemetria leggibile |
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Topologia
Il laboratorio utilizza uno switch Cisco Nexus 9000 collegato direttamente a un server Ubuntu che funziona come ricevitore di telemetria esterno.
Lo switch Nexus e il ricevitore telemetrico sono collegati direttamente tramite Ethernet1/10 e ens192.
Connettività Nexus-to-Receiver
Ethernet1/10 fornisce la connettività di layer 3 tra lo switch Nexus e il ricevitore Ubuntu.
La configurazione dell'interfaccia è:
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
Premesse
Il monitoraggio e la visibilità della rete sono fondamentali per comprendere lo stato della rete, identificare comportamenti anomali e risolvere problemi di rete.
Cisco NX-OS fornisce diversi meccanismi per recuperare o esportare informazioni operative da uno switch Nexus, tra cui CLI, SNMP (Simple Network Management Protocol) e Syslog. I flussi di lavoro di monitoraggio tradizionali, come il polling SNMP e la raccolta basata sulla CLI, si basano in genere su un modello pull, in cui un sistema di monitoraggio esterno richiede periodicamente le informazioni dal dispositivo di rete.
La telemetria di streaming introduce un modello push, in cui il dispositivo di rete invia dati operativi selezionati verso un ricevitore esterno in base alle sottoscrizioni configurate. Questo fornisce un meccanismo strutturato per la raccolta delle informazioni di rete senza richiedere al sistema di monitoraggio di eseguire continuamente il polling del dispositivo.
Confronto tra polling tradizionale e telemetria in streaming
In un modello di polling tradizionale, il sistema di monitoraggio determina quando le informazioni vengono recuperate dal dispositivo di rete.
Ad esempio, un sistema di gestione della rete (NMS, Network Management System) può richiedere statistiche di interfaccia ogni 60 secondi. In questo modo è possibile eseguire periodicamente istantanee dello stato del dispositivo. tuttavia, la visibilità disponibile per l'applicazione di monitoraggio è direttamente correlata all'intervallo di polling configurato.
Con la telemetria di streaming, lo switch Nexus invia le informazioni selezionate verso il ricevitore di telemetria in base alla sottoscrizione configurata.
Le differenze fondamentali possono essere riassunte come segue:
| Sondaggio tradizionale | Telemetria in streaming |
|---|---|
| Il client avvia la richiesta. | Il dispositivo di rete invia i dati. |
| Modello pull | Modello push |
| I dati vengono recuperati in base agli intervalli di polling. | I dati vengono inviati in base a un abbonamento di telemetria. |
| In genere fornisce istantanee periodiche. | Supporta la raccolta periodica e basata su eventi. |
| Il sistema di monitoraggio richiede informazioni al dispositivo. | Il dispositivo trasmette le informazioni selezionate a un ricevitore. |
La telemetria in streaming non sostituisce necessariamente i meccanismi di monitoraggio tradizionali. CLI, SNMP, Syslog e Telemetria possono coesistere e servire a diversi scopi operativi.
La differenza principale è rappresentata dal modello di raccolta dei dati.
Casi di utilizzo reali
Negli ambienti di produzione, la telemetria di streaming viene comunemente utilizzata per fornire una visibilità continua dello stato della rete e del sistema.
I casi di utilizzo tipici includono il monitoraggio dei contatori di interfaccia e delle modifiche di stato, delle risorse di sistema come l'utilizzo di CPU e memoria e delle informazioni sulla struttura del centro dati, come peer VXLAN (Virtual Extensible LAN) e stato peer BGP (Border Gateway Protocol). La telemetria basata su eventi può inoltre essere utilizzata per segnalare le modifiche allo stato operativo man mano che si verificano.
I dati di telemetria esportati possono quindi essere utilizzati da piattaforme esterne di monitoraggio e osservazione per dashboard, avvisi, analisi cronologiche e risoluzione dei problemi.
Panoramica sull'elaborazione telemetrica
A un livello elevato, la telemetria di streaming su NX-OS può essere intesa come quattro fasi principali:
+-----------------------+
| Data Collection |
+-----------+-----------+
|
v
+-----------------------+
| Data Encoding |
+-----------+-----------+
|
v
+-----------------------+
| Data Transport |
+-----------+-----------+
|
v
+-----------------------+
| Telemetry Receiver |
+-----------------------+
Queste fasi rispondono a quattro domande fondamentali:
- Raccolta dati: Quali informazioni vengono raccolte?
- Codifica dati: In che modo vengono rappresentate le informazioni?
- Trasporto dati: Come vengono forniti i dati di telemetria?
- Ricevitore telemetrico: Dove vengono inviati i dati di telemetria?
Architettura e terminologia di telemetria
Raccolta dati
Nella prima fase vengono stabilite le informazioni che devono essere raccolte dallo switch.
Per gli esempi riportati in questo documento, i dati di telemetria vengono raccolti dal DME (Data Management Engine).
Data Management Engine - DME
Il motore di gestione dei dati gestisce una rappresentazione strutturata delle informazioni di configurazione e operative all'interno di NX-OS.
Anziché rappresentare le informazioni sui dispositivi solo come testo CLI, DME organizza le informazioni come oggetti gestiti a cui è possibile accedere tramite percorsi gerarchici.
Ad esempio:
sys/intf/phys-[eth1/10]
Identifica l'oggetto DME associato a Ethernet1/10.
Altri percorsi DME utilizzati in questa esercitazione sono:
sys/intf/phys-[eth1/10]/dbgIfIn
sys/intf/phys-[eth1/10]/dbgIfOut
sys/intf/phys-[eth1/10]/phys
sys/intf/lb-[lo100]
Ogni percorso rappresenta un oggetto o una parte diversa delle informazioni disponibili tramite DME. Si tratta degli stessi percorsi già utilizzati nella configurazione lab.
Oggetti gestiti e struttura delle informazioni di gestione
Il database DME è composto da oggetti gestiti (MO).
Un oggetto gestito rappresenta un'entità all'interno del modello di gestione NX-OS, ad esempio:
- Un'interfaccia fisica
- Interfaccia loopback
- Statistiche input interfaccia
- Statistiche output interfaccia
Gli oggetti gestiti sono organizzati gerarchicamente in una struttura di informazioni di gestione (MIT, Management Information Tree).
Di seguito è riportata una rappresentazione semplificata degli oggetti utilizzati in questa esercitazione.
sys
|
+-- intf
|
+-- phys-[eth1/10]
| |
| +-- dbgIfIn
| +-- dbgIfOut
| +-- phys
|
+-- lb-[lo100]
Questa gerarchia è utile per comprendere come i percorsi dei sensori di telemetria identificano informazioni specifiche all'interno di DME.
Nome distinto — DN
Ogni oggetto gestito può essere identificato in modo univoco da un nome distinto (DN).
Il DN rappresenta il percorso gerarchico dalla radice dell'albero DME all'oggetto di destinazione.
For example: sys/intf/lb-[lo100]
Identifica l'oggetto gestito Loopback100.
Analogamente:
sys/intf/phys-[eth1/10]/dbgIfIn
Identifica l'oggetto statistiche di input associato a Ethernet1/10.
Un modo semplice per comprendere un DN consiste nel considerarlo come l'indirizzo completo di un oggetto all'interno della gerarchia DME.
Percorso sensore
Un percorso del sensore identifica le informazioni che NX-OS deve monitorare per una sottoscrizione di telemetria.
Negli esempi di laboratorio iniziali, i nomi distinti DME vengono utilizzati come percorsi dei sensori. In un esempio pratico successivo viene illustrata l'etichetta del percorso delle risorse predefinito.
Ad esempio:
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
Questi percorsi forniscono statistiche di input, statistiche di output e informazioni operative per Ethernet1/10.
Codifica dei dati
Dopo che NX-OS ha raccolto le informazioni richieste, è necessario codificare i dati prima di poterli trasmettere.
La codifica utilizzata in questa esercitazione è Google Protocol Buffers (GPB).
La configurazione di destinazione specifica:
ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB
GPB definisce la modalità di rappresentazione nel messaggio delle informazioni di telemetria raccolte.
La codifica e il trasporto sono funzioni separate: GPB definisce la rappresentazione dei dati, mentre il meccanismo di trasporto determina la modalità di recapito del messaggio.
Trasporto dati
Il protocollo di trasporto utilizzato in questa esercitazione è gRPC.
Lo switch Nexus invia i dati di telemetria con codifica GPB a:
192.168.100.10:57000
mediante gRPC.
Pertanto:
GPB definisce il modo in cui le informazioni di telemetria vengono codificate.
gRPC fornisce il meccanismo di trasporto utilizzato per consegnare i messaggi di telemetria al destinatario.
Il trasporto gRPC utilizzato dalla telemetria di streaming non deve essere confuso con l'agente gRPC di NX-OS utilizzato per servizi quali gRPC Network Management Interface (gNMI) e gRPC Network Operations Interface (gNOI).
Ricevitore telemetrico
Il ricevitore di telemetria è il sistema o l'applicazione esterna che riceve ed elabora il flusso di telemetria.
In questa esercitazione viene usato come ricevitore un server Ubuntu su cui è in esecuzione Telegraf. Il ricevitore resta in ascolto sulla porta TCP 5700 e accetta il flusso di telemetria GPB-over-RPC generato dallo switch Nexus.
L'implementazione del ricevitore usata nel laboratorio è descritta più avanti nella sezione Preparazione del ricevitore di telemetria.
Gruppo di destinazione
Il gruppo di destinazione definisce dove inviare i dati di telemetria e come trasportarli.
Il laboratorio utilizza:
destination-group 1 ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB use-vrf default
Definisce l'indirizzo del ricevitore, la porta di destinazione, il protocollo di trasporto, la codifica e l'istanza VRF (Virtual Routing and Forwarding) utilizzata per la consegna telemetrica.
Gruppo di sensori
Il gruppo di sensori definisce le informazioni da monitorare.
Ad esempio:
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
In questo esempio, il gruppo di sensori 2 controlla le statistiche di ingresso Ethernet 1/10, le statistiche di uscita e le informazioni sull'interfaccia operativa. Il percorso dbgIfIn fornisce le statistiche dell'interfaccia di input, dbgIfOut fornisce le statistiche dell'interfaccia di output e phys fornisce le informazioni operative per l'interfaccia.
Un gruppo di sensori può includere più percorsi di sensori correlati e pertanto risponde alla domanda:
Quali dati vengono raccolti?
Abbonamento
Una sottoscrizione associa un gruppo di sensori a un gruppo di destinazione e definisce il comportamento della raccolta.
Ad esempio:
subscription 2 dst-grp 1 snsr-grp 2 sample-interval 60000
In questo esempio:
- Il gruppo di sensori 2 determina quali informazioni vengono raccolte.
- L'intervallo di esempio determina il comportamento della raccolta.
- Il gruppo di destinazione 1 determina dove e come vengono inviate le informazioni.
La sottoscrizione connette quindi i principali elementi di configurazione della telemetria:
Gruppo di sensori + Comportamento della raccolta + Gruppo di destinazione
Telemetria periodica e basata sugli eventi
La telemetria di streaming di Cisco NX-OS supporta la raccolta periodica e basata su eventi per le sottoscrizioni basate su DME.
Il comportamento della raccolta è controllato dall'intervallo di campionamento associato al gruppo di sensori all'interno di una sottoscrizione.
Telemetria periodica
Grazie alla telemetria periodica, NX-OS raccoglie e invia le informazioni monitorate a intervalli configurati.
L'intervallo di campionamento è specificato in millisecondi.
For example: snsr-grp 2 sample-interval 60000
Configura un intervallo di raccolta di 60 secondi.
La telemetria periodica è utile per le informazioni che cambiano continuamente e che vengono in genere analizzate nel tempo, ad esempio:
- Contatori pacchetti di interfaccia
- Contatori byte
- Errori e scarti
- Statistiche operative
- Utilizzo delle risorse
In questa esercitazione, la sottoscrizione 1 e la sottoscrizione 2 utilizzano la raccolta periodica.
La sottoscrizione 1 raccoglie l'oggetto interfaccia Ethernet1/10 ogni 10 secondi, mentre la sottoscrizione 2 raccoglie le statistiche sull'interfaccia e le informazioni operative ogni 60 secondi.
Telemetria basata su eventi
Con la telemetria basata su eventi, NX-OS non utilizza un timer di raccolta ricorrente.
Per la telemetria basata su DME, il comportamento basato su eventi è configurato con:
sample-interval 0
Quando un oggetto controllato viene modificato, la telemetria può generare un aggiornamento associato a tale modifica.
Questo metodo di raccolta è utile per informazioni quali:
- Modifiche alla configurazione
- Modifiche dello stato amministrativo
- Creazione o eliminazione di oggetti
- Altre modifiche in un oggetto DME monitorato
In questa esercitazione, Subscription 3 esegue il monitoraggio dell'oggetto DME Loopback100:
sys/intf/lb-[lo100]: snsr-grp 3 sample-interval 0
Le modifiche apportate all'oggetto Loopback100 monitorato vengono quindi utilizzate più avanti in questo documento per dimostrare la telemetria basata su eventi.
Comportamento della raccolta utilizzato nel laboratorio
Le tre sottoscrizioni utilizzate nella configurazione lab iniziale possono essere riepilogate come segue:
| Abbonamento | Informazioni monitorate | Intervallo di campionamento | Comportamento della raccolta |
|---|---|---|---|
| 1 | oggetto interfaccia Ethernet1/10 | 10000 ms | Periodico |
| 2 | Statistiche e stato operativo di Ethernet1/10 | 60000 ms | Periodico |
| 3 | Oggetto Loopback100 | 0 | Basato su eventi |
La distinzione principale è il trigger utilizzato per generare i dati di telemetria:
| Telemetria periodica | Telemetria basata su eventi |
|---|---|
| Utilizza un timer configurato. | Non utilizza un timer periodico. |
| intervallo di campionamento > 0 | intervallo di campionamento 0 |
| Produce campioni ripetuti. | Genera aggiornamenti quando gli oggetti monitorati vengono modificati. |
| Comunemente utilizzato per i contatori e le statistiche. | Generalmente utilizzato per le modifiche alla configurazione o allo stato. |
Nelle sezioni relative alla configurazione e alla verifica vengono illustrati entrambi i comportamenti di raccolta mediante le sottoscrizioni definite in precedenza.
Preparare il ricevitore di telemetria
La telemetria di streaming richiede un ricevitore esterno in grado di accettare ed elaborare i dati di telemetria inviati dallo switch Nexus.
Per il trasporto GPB-over-RPC utilizzato in questo documento, il ricevitore deve essere in grado di:
- Ricezione connessioni gRPC
- In ascolto sulla porta di destinazione configurata
- Decodifica dei messaggi di telemetria GPB
- Elaborazione o memorizzazione dei dati ricevuti
L'implementazione del ricevitore di telemetria è indipendente dalla configurazione di telemetria NX-OS descritta in questo documento.
Nota: L'installazione, la configurazione, il funzionamento e la risoluzione dei problemi del software di ricezione telemetrica di terze parti esulano dall'ambito di questo documento. Per informazioni sulla configurazione e sul supporto, consultare la documentazione del fornitore del ricevitore.
Ricevitore utilizzato in questo laboratorio
A scopo dimostrativo, il laboratorio utilizza un server Ubuntu esterno che esegue Telegraf come ricevitore di telemetria.
I parametri del ricevitore sono:
| Parametro | Valore |
|---|---|
| Indirizzo destinatario | 192.168.100.10 |
| Trasporto | RPC |
| Porta di attesa | TCP/5700 |
| Codifica | GPB |
La configurazione del software del ricevitore non è illustrata nel presente documento.
Nota: Gli esempi di output dei ricevitori mostrati in questo documento vengono filtrati per evidenziare i campi relativi a ciascuna fase di verifica.
Prima di configurare la telemetria di streaming sullo switch Nexus, verificare che:
- Esiste una connettività IP tra lo switch Nexus e il ricevitore.
- L'applicazione di ricezione è in esecuzione.
- La porta di destinazione configurata è in ascolto.
- Il ricevitore supporta il protocollo di trasporto configurato.
- Il ricevitore supporta la codifica di telemetria configurata.
In questa esercitazione, Ethernet1/10 sullo switch Nexus utilizza 192.168.100.1/24, mentre il ricevitore di telemetria utilizza 192.168.100.10/24. Prima di risolvere i problemi relativi al comportamento specifico della telemetria, è necessario verificare la raggiungibilità di base di layer 3.
Quando il ricevitore è raggiungibile e pronto ad accettare la telemetria GPB-over-RPC sulla porta TCP 5700, è possibile applicare la configurazione della telemetria di NX-OS.
Configurazione della telemetria di streaming su NX-OS
La configurazione utilizza tre componenti principali:
- Gruppo di destinazione: Definisce dove vengono inviati i dati di telemetria e come vengono trasportati.
- Gruppo sensori: Definisce quali informazioni vengono raccolte.
- Sottoscrizione: Associa un gruppo di sensori a un gruppo di destinazione e definisce il comportamento della raccolta.
La lab utilizza questa destinazione di telemetria:
| Parametro | Valore |
|---|---|
| Destinazione | 192.168.100.10:57000 |
| Trasporto | RPC |
| Codifica | GPB |
| VRF | predefinito |
La configurazione lab iniziale utilizza tre sottoscrizioni:
| Abbonamento | Sensore | Tipo di insieme | Intervallo di campionamento |
|---|---|---|---|
| 1 | oggetto interfaccia Ethernet1/10 | Periodico | 10000 ms |
| 2 | Statistiche e stato operativo di Ethernet1/10 | Periodico | 60000 ms |
| 3 | Oggetto Loopback100 | Basato su eventi | 0 |
Abilita la funzionalità di telemetria
La telemetria di streaming deve prima essere attivata a livello globale.
N9K-TELEMETRY-SW1# configure terminal N9K-TELEMETRY-SW1(config)# feature telemetry
Accedere alla modalità di configurazione della telemetria:
N9K-TELEMETRY-SW1(config)# telemetry N9K-TELEMETRY-SW1(config-telemetry)#
La configurazione di telemetria rimanente viene eseguita in questa modalità.
Configurare il gruppo di destinazione
Il gruppo di destinazione identifica il ricevitore di telemetria esterno e definisce il trasporto e la codifica utilizzati per inviare i dati di telemetria.
Configurazione:
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
Questa configurazione definisce:
- Indirizzo di destinazione: 192.168.100.10
- Porta di destinazione: 57000
- Trasporto: RPC
- Codifica GPB
- VRF: predefinito
Il VRF predefinito è utilizzato perché il ricevitore di telemetria è raggiungibile tramite Ethernet 1/10 nel VRF predefinito.
Il VRF selezionato per il trasporto di telemetria deve fornire la raggiungibilità IP al ricevitore configurato.
Configura gruppo sensori 1
Il gruppo di sensori 1 controlla l'oggetto dell'interfaccia DME Ethernet1/10.
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 1 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]
Il percorso del sensore identifica l'oggetto gestito Ethernet1/10 nella gerarchia DME e fornisce informazioni generali sull'interfaccia associate a tale oggetto.
Configura sottoscrizione 1
Associare il gruppo di sensori 1 al gruppo di destinazione 1:
N9K-TELEMETRY-SW1(config-telemetry)# subscription 1 N9K-TELEMETRY-SW1(conf-tm-sub)# dst-grp 1 N9K-TELEMETRY-SW1(conf-tm-sub)# snsr-grp 1 sample-interval 10000
L'intervallo di campionamento è specificato in millisecondi.
10000 ms = 10 secondi
La sottoscrizione 1 raccoglie quindi periodicamente l'oggetto DME Ethernet1/10 ogni 10 secondi e invia i dati di telemetria al gruppo di destinazione 1.
Configura gruppo sensori 2
Il gruppo di sensori 2 raccoglie statistiche e informazioni operative per Ethernet1/10.
Configurazione:
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
I percorsi dei sensori forniscono:
| Percorso sensore | Informazioni |
|---|---|
| sys/intf/phys-[eth1/10]/dbgIfIn | Statistiche interfaccia di input |
| sys/intf/phys-[eth1/10]/dbgIfOut | Statistiche interfaccia di output |
| sys/intf/phys-[eth1/10]/phys | Informazioni sull'interfaccia operativa |
Un gruppo di sensori può contenere più percorsi di sensori correlati, consentendo alla sottoscrizione di raccogliere diverse categorie di informazioni dalla stessa interfaccia monitorata.
Configura sottoscrizione 2
Associare il gruppo di sensori 2 al gruppo di destinazione 1:
N9K-TELEMETRY-SW1(config-telemetry)# subscription 2 N9K-TELEMETRY-SW1(conf-tm-sub)# dst-grp 1 N9K-TELEMETRY-SW1(conf-tm-sub)# snsr-grp 2 sample-interval 60000
L'intervallo di campionamento configurato è:
60000 ms = 60 secondi
La sottoscrizione 2 raccoglie pertanto le statistiche e le informazioni operative di Ethernet1/10 ogni 60 secondi.
Questa sottoscrizione viene utilizzata più avanti nel documento per verificare il comportamento della telemetria periodica.
Configurazione dell'interfaccia di loopback
Un'interfaccia di loopback viene utilizzata per dimostrare la telemetria basata su eventi senza richiedere un'ulteriore connessione fisica.
Configurazione:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# ip address 10.255.255.100/32
L'oggetto DME corrispondente è:
sys/intf/lb-[lo100]
L'interfaccia di loopback fornisce un modo semplice per generare modifiche controllate della configurazione e dello stato amministrativo durante la verifica della telemetria basata su eventi.
Configura gruppo sensori 3
Configurare il percorso del sensore DME Loopback100:
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 3 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/lb-[lo100]
Il gruppo di sensori 3 controlla l'oggetto gestito Loopback100.
Configura sottoscrizione 3
Associare il gruppo di sensori 3 al gruppo di destinazione 1 e configurare la raccolta basata sugli eventi:
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
Per le sottoscrizioni basate su DME, un intervallo di esempio pari a zero configura il comportamento basato sugli eventi.
Le modifiche apportate all'oggetto Loopback100 monitorato possono pertanto generare notifiche di telemetria senza utilizzare un timer di raccolta ricorrente.
Questa sottoscrizione viene utilizzata in seguito per illustrare le modifiche alla descrizione e allo stato amministrativo.
Completa configurazione di telemetria iniziale
Dopo aver completato la configurazione, verificarla 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
A questo punto, lo switch ha la destinazione, i gruppi di sensori e le sottoscrizioni necessarie per iniziare a inviare i dati di telemetria al ricevitore configurato.
La sezione successiva verifica la sessione di trasporto e la telemetria periodica generata dalle sottoscrizioni Ethernet1/10.
Verifica telemetria periodica
Dopo aver applicato la configurazione di telemetria, verificare che la sessione di trasporto sia stata stabilita, che i gruppi di sensori periodici siano attivi e che i dati di telemetria vengano raccolti e consegnati al destinatario.
Verifica il trasporto di telemetria
Eseguire questo 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#
Lo stato Connected conferma che la sessione di trasporto gRPC al ricevitore di telemetria configurato è stabilita.
I parametri di trasporto rilevanti corrispondono anche al gruppo di destinazione configurato.
Verifica dei gruppi di sensori periodici
Utilizzo:
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
Il database dei gruppi di sensori conferma che i gruppi di sensori periodici sono attivi:
| Gruppo di sensori | Tipo | Intervallo di campionamento | Abbonamento |
|---|---|---|---|
| 1 | Timer/DME | 10000 ms / in esecuzione | 1 |
| 2 | Timer/DME | 60000 ms / in esecuzione | 2 |
Il gruppo di sensori 1 raccoglie l'oggetto interfaccia Ethernet1/10 ogni 10 secondi.
Il gruppo di sensori 2 raccoglie le statistiche Ethernet 1/10 e le informazioni operative ogni 60 secondi.
Lo stesso comando visualizza anche i percorsi dei sensori configurati:
sys/intf/phys-[eth1/10] sys/intf/phys-[eth1/10]/dbgIfIn sys/intf/phys-[eth1/10]/dbgIfOut sys/intf/phys-[eth1/10]/phys
Per i percorsi dei sensori utilizzati in questa esercitazione, i tempi di raccolta e codifica erano in genere compresi tra 0 e 1 ms e non sono state osservate cadute di messaggi di telemetria.
Verifica raccolta dati
Utilizzo:
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#
Il laboratorio ha riportato:
DME Successful Collections: 513 Payloads: 513 Failed: 0 Skipped: 44 Dropped: 0
I contatori Riuscito e Payload confermano che è in corso la raccolta dei dati di telemetria DME e la generazione dei payload di telemetria.
I 44 insiemi saltati sono contatori cronologici osservati mentre la destinazione di telemetria non era temporaneamente disponibile durante il lab. Questi contatori vengono esaminati più avanti nella sezione Risoluzione dei problemi di base.
Per ulteriori informazioni sul percorso per sensore, utilizzare:
N9K-TELEMETRY-SW1# show telemetry data collector details
Questo comando può identificare i percorsi dei sensori configurati che hanno contribuito a raccolte riuscite, non riuscite, ignorate o eliminate.
Verifica dei dati periodici presso il ricevitore
La sottoscrizione 2 raccoglie le statistiche Ethernet1/10 ogni 60 secondi.
Il ricevitore di telemetria ha segnalato queste statistiche alle 21:44:45 UTC (Coordinated Universal Time):
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 più tardi, è stato ricevuto un altro esempio:
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
Le variazioni dei contatori tra i due campioni sono riepilogate di seguito:
| Contatore | 21:44:45 | 21:45:45 |
|---|---|---|
| Pacchetti unicast | 31,256 | 31,292 |
| Pacchetti multicast | 143,403 | 143,430 |
| Pacchetti broadcast | 5,074 | 5,075 |
| Ottetti | 12,870,535 | 12,875,428 |
| Errori | 0 | 0 |
| Ignora | 0 | 0 |
I timestamp sono separati da circa 60 secondi, corrispondenti all'intervallo di campionamento configurato per la sottoscrizione 2.
L'aumento dei contatori di pacchetti e byte conferma anche che sono in corso la raccolta e la consegna al destinatario delle statistiche aggiornate sull'interfaccia.
Verifica dell'output e delle informazioni operative
Il percorso del sensore dbgIfOut fornisce le statistiche di output per Ethernet1/10.
Un campione raccolto alle 21:45:45 UTC riporta:
broadcastPkts: 8 discards: 0 errors: 0 multicastPkts: 4712 octets: 2444721 ucastPkts: 4092
Il percorso del sensore phys fornisce attributi operativi per la stessa interfaccia.
Il destinatario ha segnalato:
adminSt: up operSt: up operSpeed: 1G operDuplex: full operMtu: 1500 operDescr: TELEMETRY-COLLECTOR
Questi esempi confermano che il gruppo di sensori 2 fornisce sia statistiche di interfaccia che informazioni operative tramite i suoi tre percorsi di sensori DME configurati.
Riepilogo periodico verifica telemetria
La verifica periodica della telemetria conferma:
| Verifica | Risultato |
|---|---|
| sessione di trasporto RPC | Connesso |
| Codifica GPB | Confermato |
| Gruppo sensori 1 | A 10.000 ms |
| Gruppo sensori 2 | A 60.000 ms |
| Raccolte DME | Operazione riuscita |
| Raccolte non riuscite | 0 |
| Payload eliminati | 0 |
| Campioni ricevitore periodici | Ricevuto |
| Contatori interfaccia | Aggiornamento tra campioni |
Verifica della telemetria basata sugli eventi
Dopo la verifica della telemetria periodica, utilizzare la sottoscrizione 3 per convalidare la telemetria basata su eventi generando modifiche controllate all'oggetto gestito Loopback100.
Verifica della sottoscrizione basata su eventi
Utilizzo:
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]
Lo stesso database di telemetria conferma che il percorso del sensore è sottoscritto tramite la sottoscrizione 3.
Genera aggiornamenti basati sugli eventi
Per verificare la generazione degli eventi, modificare la descrizione di Loopback100:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# description TELEMETRY-EVENT-DEMO
Il ricevitore di telemetria ha riportato:
{
"timestamp": "2026-09-17T21:41:12Z",
"source": "N9K-TELEMETRY-SW1",
"subscription": "3",
"event": {
"descr": "TELEMETRY-EVENT-DEMO",
"dn": "sys/intf/lb-[lo100]",
"status": "modified"
}
}
Il dn identifica l'oggetto DME monitorato e l'attributo descr identifica la proprietà modificata.
Quindi, disabilitare e ripristinare l'interfaccia a livello amministrativo:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# shutdown
Quindi:
N9K-TELEMETRY-SW1(config-if)# no shutdown
Il ricevitore ha rilevato entrambi i cambiamenti di stato.
| Timestamp | Attributo modificato | Valore |
|---|---|---|
| 21:41:12 | descr | TELEMETRIA-EVENTO-DEMO |
| 21:41:19 | adminSet | inattivo |
| 21:41:24 | adminSet | attivo |
Ogni aggiornamento fa riferimento allo stesso oggetto monitorato:
sys/intf/lb-[lo100]
Lo stato dell'oggetto è modificato.
Questi risultati confermano che le modifiche ai diversi attributi dell'oggetto gestito monitorato possono generare singoli aggiornamenti di telemetria.
Verifica dei messaggi iniziali relativi a snapshot ed eventi
Quando è stata stabilita la sottoscrizione basata su eventi, NX-OS ha generato uno snapshot iniziale dell'oggetto monitorato.
Il database dei percorsi dei sensori riporta:
Statistiche snapshot:
Sent = 1 Error = 0 Drops = 0
Dopo le tre modifiche controllate, lo stesso percorso del sensore segnala:
Statistiche messaggi:
Sent = 3 Error = 0 Drops = 0
I risultati possono pertanto essere riassunti come segue:
| Raccolta | Conteggio |
|---|---|
| Snapshot iniziale | 1 |
| Modifica della descrizione | 1 |
| Stato amministrativo inattivo | 1 |
| Stato amministrativo attivo | 1 |
| Totale | 4 |
Lo snapshot iniziale rappresenta lo stato dell'oggetto monitorato quando la sottoscrizione diventa attiva, mentre i messaggi successivi corrispondono alle modifiche dell'oggetto.
Verifica statistiche raccolta eventi
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#
Il laboratorio ha riportato:
Collection Count: 4
Latest Collection Time: Thu Sep 17 21:41:24.045 UTC
Sensor Path: sys/intf/lb-[lo100]
Il conteggio delle raccolte corrisponde allo snapshot iniziale e alle tre modifiche generate durante il test.
Verifica errori agente di raccolta eventi
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#
Nessun errore dell'agente di raccolta eventi rilevato durante il test.
Riepilogo verifica telemetria basata su eventi
La verifica della telemetria basata sugli eventi conferma:
| Verifica | Risultato |
|---|---|
| Gruppo di sensori | 3 |
| Percorso sensore | sys/intf/lb-[lo100] |
| Tipo di insieme | Evento / DME |
| Intervallo di campionamento | 0 / Nessun timer |
| Snapshot iniziale | Inviato |
| Modifica della descrizione | Rilevato |
| adminStInattivo | Rilevato |
| adminSetup | Rilevato |
| Raccolte totali | 4 |
| Errori agente di raccolta eventi | 0 |
Il rilevamento delle modifiche di Loopback100 controllate conferma che la sottoscrizione 3 funziona come previsto.
Nella sezione successiva vengono esaminati i comandi di verifica principale e di risoluzione dei problemi utilizzati per valutare l'operazione di telemetria di streaming.
Risoluzione dei problemi di base
Quando i dati di telemetria non vengono ricevuti come previsto, iniziare la risoluzione del problema determinando se il problema è correlato alla sessione di trasporto, alla raccolta dei dati, alla configurazione del sensore o al ricevitore esterno.
Questo flusso di lavoro utilizza un problema osservato durante questa esercitazione, in cui NX-OS ha segnalato 44 raccolte ignorate e un errore di trasmissione gRPC cronologico.
Verifica lo stato di trasporto corrente
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 verifica finale, la sessione di telemetria ha riportato:
Session ID: 0
Destination Group: 1
IP Address: 192.168.100.10
Port: 57000
Encoding: GPB
Transport: gRPC
Status: Connected
Lo stato Connesso conferma che la sessione di trasporto è attualmente stabilita.
Tuttavia, lo stato corrente della sessione non indica necessariamente se i problemi di connettività si sono verificati in precedenza. Pertanto, rivedere anche i contatori di raccolta e trasporto storici.
Verifica contatori raccolta dati
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#
Il laboratorio ha riportato:
DME Successful Collections: 513
Payloads: 513
Failed: 0
Skipped: 44
Dropped: 0
I contatori Riuscito e Payload confermano che si sono verificate raccolte di telemetria DME e generazione di payload.
Tuttavia, il contatore Ignorato indica che non sono state eseguite 44 raccolte pianificate.
Per identificare i percorsi dei sensori interessati, utilizzare:
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#
L'output dettagliato riporta:
| Percorso sensore | Ignorato |
|---|---|
| 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 |
| Totale | 44 |
Gli insiemi ignorati sono stati distribuiti tra i percorsi periodici dei sensori, indicando che il problema non era isolato in un singolo oggetto DME.
Nota: I contatori di raccolta sono cumulativi. Un contatore cronologico diverso da zero non indica necessariamente che è presente la stessa condizione.
Determina Perché Le Raccolte Sono State Ignorate
N9K-TELEMETRY-SW1# show telemetry control stats
--------------------------------------------------------------------------------
Error Description Error Count
--------------------------------------------------------------------------------
<snip>
Collections skipped due to destination unreachable 44
<snip>
N9K-TELEMETRY-SW1#
Questo output identifica direttamente il motivo per le raccolte ignorate:
Destinazione non raggiungibile = 44
Il valore corrisponde alle 44 raccolte ignorate riportate dall'agente di raccolta dati DME.
Questo permette all'indagine di allontanarsi dai percorsi dei sensori stessi e verso la destinazione della telemetria e il percorso di trasporto.
Controlla errori di trasporto
Usa l'ID sessione segnalato da 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#
Il laboratorio ha riportato:
Connection Error Count: 0
Tx Error Count: 1
Last Tx Error: Thu Sep 17 21:22:16.008 UTC
Last Tx Return Code: UNAVAILABLE
Il codice restituito UNAVAILABLE registra un errore di trasmissione gRPC associato alla destinazione di telemetria.
In questa esercitazione, il ricevitore esterno è stato intenzionalmente arrestato e riavviato durante la modifica della configurazione. Durante tale intervallo, NX-OS non è stato in grado di raggiungere la destinazione di telemetria, che corrisponde ai contatori di raccolta destinazione irraggiungibile osservati in precedenza.
La correlazione importante è:
| Osservazione | Risultato |
|---|---|
| Raccolte ignorate | 44 |
| Destinazione non raggiungibile | 44 |
| Errori Tx Trasporto | 1 |
| Codice restituito ultima imposta | NON DISPONIBILE |
| Stato di trasporto corrente | Connesso |
I contatori corrispondenti ignorati e destinazione non raggiungibile forniscono una prova diretta del motivo per cui le raccolte sono state ignorate.
L'errore di trasporto storico fornisce ulteriori informazioni sull'errore di trasporto osservato durante la stessa attività di laboratorio.
Verifica ripristino trasporto
Una volta ripristinata la connettività al ricevitore, utilizzare:
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 verifica finale in laboratorio ha riportato:
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
Questi valori mostrano che la sessione di trasporto è stata ripristinata e stava trasmettendo attivamente dati di telemetria senza messaggi in coda o eliminati.
I più importanti indicatori dello stato attuale sono stati:
| Indicatore | Risultato |
|---|---|
| Stato trasporto | Connesso |
| Coda corrente | 0 |
| Messaggi non elaborati | 0 |
| Controllo flusso | Mai applicato |
Questa distinzione è importante per la risoluzione dei problemi relativi ai contatori di telemetria: gli errori cronologici possono rimanere visibili anche dopo la risoluzione della condizione sottostante.
Controlla errori di Raccolta eventi e configurazione
È possibile utilizzare comandi aggiuntivi per verificare se NX-OS segnala problemi di configurazione o di elaborazione degli eventi.
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#
Per la telemetria basata su eventi, utilizzare:
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#
Anche tutti i contatori degli errori dell'agente di raccolta eventi erano zero.
Questi risultati consentono di escludere errori di configurazione e dell'agente di raccolta eventi durante l'analisi delle raccolte periodiche ignorate.
Flusso di lavoro di risoluzione dei problemi
I comandi utilizzati durante questa indagine possono essere riassunti come segue:
| Comando | Scopo |
|---|---|
| mostra trasporto di telemetria | Controllare lo stato corrente della sessione di trasporto. |
| show telemetry data collector brief | Identificare le raccolte riuscite, non riuscite, ignorate o eliminate. |
| mostra dettagli agente di raccolta dati di telemetria | Determinare i percorsi dei sensori interessati. |
| mostra statistiche controllo telemetria | Determina il motivo per cui le raccolte sono state ignorate. |
| show telemetry transport <id-sessione> errors | Esaminare gli errori di trasporto. |
| show telemetry transport <id-sessione> statistiche | Esaminare il ripristino del trasporto, le code e le interruzioni. |
| mostra errori di configurazione telemetria | Identificare gli errori di configurazione della telemetria. |
| mostra errori agente di raccolta eventi di telemetria | Identificare gli errori dell'agente di raccolta eventi. |
In questa esercitazione, la sequenza di risoluzione dei problemi ha identificato una condizione di raggiungibilità della destinazione di telemetria temporanea piuttosto che un percorso del sensore DME o un errore di configurazione.
Dopo che il ricevitore è diventato nuovamente disponibile, il trasporto di telemetria è tornato allo stato Connesso, le raccolte sono riprese e non è stata osservata alcuna condizione corrente di coda o di perdita del messaggio.
Esempio pratico di applicazione: Monitoraggio delle risorse di sistema
Il monitoraggio delle risorse di sistema è un caso di utilizzo comune per la telemetria di streaming. Le informazioni sulla CPU e sulla memoria possono essere periodicamente esportate da uno switch Nexus a una piattaforma di monitoraggio esterna per analisi cronologiche, dashboard, monitoraggio della capacità e avvisi.
Cisco NX-OS fornisce etichette di percorso di telemetria predefinite per le informazioni monitorate con maggiore frequenza. In questo esempio, l'etichetta del percorso delle risorse viene utilizzata per raccogliere informazioni sulla CPU e sulla memoria del sistema.
Configura telemetria risorse di sistema
Creare un nuovo gruppo di sensori utilizzando l'etichetta percorso risorse:
N9K-TELEMETRY-SW1(config)# telemetry
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 4
N9K-TELEMETRY-SW1(conf-tm-sensor)# path resources
Creare la sottoscrizione 4 e associare il gruppo di sensori 4 al gruppo di destinazione 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
Il gruppo di sensori 4 utilizza l'etichetta del percorso delle risorse predefinite. La sottoscrizione 4 associa il gruppo di sensori alla destinazione di telemetria esistente e configura la raccolta periodica con un intervallo di campionamento diverso da zero.
La configurazione rilevante è:
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
Etichetta Percorso risorse
Eseguire questo comando per esaminare i percorsi DME rappresentati dall'etichetta percorso risorse:
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"))
L'output mostra che l'etichetta delle risorse rappresenta più percorsi DME sottostanti.
I percorsi sys/proc e sys/procsys utilizzano query di polling e forniscono informazioni sulle risorse di sistema e di processo. Il percorso sys/procsys/sysmem utilizza una query di evento in grado di segnalare una modifica quando lo stato della memoria monitorata viene aggiornato e non è più corretto.
Questo comando mostra la differenza tra la specifica diretta di un singolo nome distinto DME e l'utilizzo di un'etichetta di percorso di telemetria predefinita.
Ad esempio:
Individual DME path:
path sys/intf/phys-[eth1/10]
Predefined path label:
path resources
Verifica telemetria risorse di sistema
Utilizzare show telemetry control database per verificare lo stato del gruppo di sensori 4 e della sottoscrizione 4.
Il database del gruppo di sensori riporta:
Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions SubID ---------------------------------------------------------------------------------------------------- 4 Timer /DME 10000/Running 1 4
Il tipo Timer /DME e l'intervallo di campionamento 10000/Running confermano che il gruppo di sensori 4 funziona come una sorgente di telemetria DME periodica.
Il database dei percorsi dei sensori mostra anche i percorsi sottostanti associati all'etichetta delle risorse.
Ad esempio:
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
Il percorso relativo al processo segnala inoltre la raccolta di telemetria attiva:
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
Questi contatori confermano che le informazioni sulle risorse vengono raccolte, codificate come GPB e trasmesse senza errori o perdite di messaggi.
Confronto con le risorse di sistema NX-OS
La CLI tradizionale di NX-OS può essere utilizzata per visualizzare lo stato corrente della CPU e della memoria dello 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 fornisce una vista istantanea delle risorse di sistema.
La telemetria di streaming consente di esportare lo stesso tipo di informazioni della CPU e della memoria verso un ricevitore esterno, in modo che nel tempo sia possibile archiviare e analizzare più campioni.
L'utilizzo della CPU può cambiare rapidamente. Pertanto, i valori della CPU visualizzati dalla CLI e i valori ricevuti tramite telemetria possono differire quando gli esempi vengono raccolti in momenti diversi.
Verifica dei dati delle risorse presso il ricevitore
Il ricevitore di telemetria ha decodificato le informazioni sulle risorse di sistema associate alla sottoscrizione 4.
In questo esempio vengono mostrate le informazioni sulla CPU e sulla memoria di un esempio di 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
}
}
L'output del ricevitore conferma che le informazioni sulla CPU e sulla memoria della sottoscrizione 4 vengono decodificate e rese disponibili per il monitoraggio esterno.
A scopo di confronto, la CLI di NX-OS ha riportato circa 9,3 GB di memoria utilizzata su circa 24,5 GB totali e lo stato corrente della memoria è OK. L'esempio di telemetria riporta lo stesso valore di memoria totale, un utilizzo di memoria di circa il 38% e lo stesso stato di memoria OK.
I valori della CPU possono variare tra gli esempi della CLI e quelli di telemetria perché l'utilizzo della CPU cambia in modo dinamico e le misurazioni non vengono necessariamente raccolte nello stesso istante.
Osserva utilizzo risorse nel tempo
È possibile utilizzare più esempi di telemetria per osservare i cambiamenti dell'utilizzo delle risorse di sistema nel tempo.
Questi campioni sono stati ricevuti dalla sottoscrizione 4 durante il laboratorio:
Utilizzo medio CPU - Ultimi 60 secondi
10% |
9% | ●
8% | ●
7% | ●
6% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
8.70% 8.50% 7.10%
Time
Utilizzo della memoria
39% |
38% | ●-----------●-----------●
37% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
37.82% 38.06% 38.18%
Time
Questi esempi mostrano come la telemetria periodica possa fornire una vista basata sul tempo del comportamento del sistema invece di una singola misurazione istantanea. In un ambiente di produzione, una piattaforma di monitoraggio o osservabilità è in grado di archiviare un numero maggiore di campioni e utilizzarli per identificare le tendenze, generare avvisi e creare dashboard cronologici.
Conclusioni
La telemetria di streaming di Cisco NX-OS fornisce un meccanismo strutturato per esportare informazioni operative dagli switch Cisco Nexus 9000 a un ricevitore di telemetria esterno.
In questo documento vengono illustrati i componenti fondamentali della telemetria di streaming, inclusi i percorsi dei sensori DME, la codifica GPB, il trasporto gRPC, i gruppi di destinazione, i gruppi di sensori e le sottoscrizioni.
Utilizzando l'ambiente lab, la telemetria periodica e basata su eventi sono state configurate e verificate. Le sottoscrizioni periodiche sono state utilizzate per raccogliere le statistiche Ethernet1/10 e le informazioni operative, mentre una sottoscrizione basata su eventi è stata utilizzata per rilevare le modifiche controllate all'oggetto gestito Loopback100.
Un esempio pratico di monitoraggio delle risorse di sistema ha inoltre dimostrato come l'etichetta del percorso delle risorse predefinite può essere utilizzata per esportare le informazioni della CPU e della memoria verso un ricevitore di telemetria esterno.
Gli esempi di verifica e risoluzione dei problemi hanno dimostrato come i comandi di telemetria NX-OS possono essere utilizzati per convalidare la connettività del trasporto, la raccolta dei dati, l'elaborazione degli eventi e gli errori di raccolta cronologica.
Questi concetti forniscono una base per la comprensione, l'implementazione, la verifica e la risoluzione dei problemi relativi alle installazioni di telemetria di streaming di base su Cisco Nexus 9000 NX-OS.
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
01-Oct-2026
|
Versione iniziale |
Feedback