In dit document wordt beschreven hoe u Streaming Telemetry kunt implementeren en verifiëren op Cisco Nexus 9000-switches met Cisco NX-OS.
Cisco raadt u aan om basiskennis te hebben van deze onderwerpen:
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
| component | Platform/software | Versie / waarde | Doel |
|---|---|---|---|
| N9K-TELEMETRIE-SW1 | N9K-C9348GC-FXP | 10.6(4) | telemetriebron |
| telemetrie-ontvanger | Ubuntu-server | 22.04.5 | Externe telemetrie-ontvanger |
| Telemetrie-toepassing | telegraaf | 1.40.0 | Google Protocol Buffers (GPB)-over-gRPC-telemetrieontvanger |
| Luisterpoort | TCP | 57000 | Telemetrie-ontvangerpoort |
| uitvoerformaat van de ontvanger | JavaScript Object Notation (JSON) | — | Door de mens leesbare telemetrie-uitgang |
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Het lab maakt gebruik van een Cisco Nexus 9000-switch die rechtstreeks is aangesloten op een Ubuntu-server die werkt als de externe telemetrieontvanger.

De Nexus switch en telemetrie ontvanger zijn direct verbonden via Ethernet1/10 en ens192.
Ethernet1/10 biedt Layer 3-connectiviteit tussen de Nexus-switch en de Ubuntu-ontvanger.
De interface configuratie is:
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
Netwerkmonitoring en zichtbaarheid zijn van fundamenteel belang voor het begrijpen van de netwerkgezondheid, het identificeren van abnormaal gedrag en het oplossen van netwerkproblemen.
Cisco NX-OS biedt verschillende mogelijkheden om bedrijfsinformatie van een Nexus-switch op te halen of te exporteren, waaronder de CLI, Simple Network Management Protocol (SNMP) en Syslog. Traditionele monitoringworkflows zoals SNMP polling en CLI-gebaseerde verzameling vertrouwen vaak op een pull-model, waarbij een extern monitoringsysteem periodiek informatie opvraagt van het netwerkapparaat.
Streaming Telemetry introduceert een push-model, waarbij het netwerkapparaat geselecteerde operationele gegevens naar een externe ontvanger stuurt op basis van geconfigureerde abonnementen. Dit biedt een gestructureerd mechanisme voor het verzamelen van netwerkinformatie zonder dat het monitoringsysteem het apparaat continu moet pollen.
In een traditioneel peilmodel bepaalt het monitoringsysteem wanneer informatie wordt opgehaald van het netwerkapparaat.
Een netwerkbeheersysteem (NMS) kan bijvoorbeeld elke 60 seconden interfacestatistieken aanvragen. Dit biedt periodieke momentopnamen van de apparaatstatus; de zichtbaarheid die beschikbaar is voor de monitoringtoepassing is echter rechtstreeks gerelateerd aan het geconfigureerde pollinginterval.
Met Streaming Telemetry verzendt de Nexus-switch bepaalde informatie naar de telemetrieontvanger volgens het geconfigureerde abonnement.
De fundamentele verschillen kunnen als volgt worden samengevat:
| traditioneel stemmen | streaming telemetrie |
|---|---|
| De klant initieert het verzoek. | Het netwerkapparaat verzendt de gegevens. |
| Trekmodel | Push-model |
| De gegevens worden opgehaald op basis van de polling intervallen. | Gegevens worden verzonden volgens een telemetrie-abonnement. |
| Gewoonlijk worden er periodieke snapshots gemaakt. | Ondersteunt periodieke en event-based collectie. |
| Het bewakingssysteem vraagt informatie op van het apparaat. | Apparaat streamt geselecteerde informatie naar een ontvanger. |
Streaming Telemetrie vervangt niet noodzakelijkerwijs traditionele monitoringmechanismen. CLI, SNMP, Syslog en Telemetry kunnen naast elkaar bestaan en verschillende operationele doeleinden dienen.
Het belangrijkste verschil is het gegevensverzamelingsmodel.
In productieomgevingen wordt streaming telemetrie vaak gebruikt om continu zicht te bieden op de netwerk- en systeemgezondheid.
Typische use cases zijn onder andere monitoring interface counters en statuswijzigingen, systeembronnen zoals CPU en geheugengebruik, en datacenter fabric informatie zoals Virtual Extensible LAN (VXLAN) peers en Border Gateway Protocol (BGP) peer state. Gebeurtenisgebaseerde telemetrie kan ook worden gebruikt om wijzigingen in de operationele status te rapporteren wanneer de wijzigingen zich voordoen.
De geëxporteerde telemetriegegevens kunnen vervolgens worden verbruikt door externe monitoring- en observatieplatforms voor dashboards, waarschuwingen, historische analyse en probleemoplossing.
Op een hoog niveau kan Streaming Telemetry op NX-OS worden opgevat als vier hoofdfasen:
+-----------------------+
| Data Collection |
+-----------+-----------+
|
v
+-----------------------+
| Data Encoding |
+-----------+-----------+
|
v
+-----------------------+
| Data Transport |
+-----------+-----------+
|
v
+-----------------------+
| Telemetry Receiver |
+-----------------------+
Deze fasen beantwoorden vier basisvragen:
De eerste fase bepaalt welke informatie van de switch moet worden verzameld.
Voor de voorbeelden in dit document worden telemetriegegevens verzameld uit de Data Management Engine (DME).
De Data Management Engine onderhoudt een gestructureerde weergave van configuratie- en operationele informatie binnen NX-OS.
In plaats van apparaatinformatie alleen als CLI-tekst weer te geven, organiseert DME informatie als beheerde objecten die via hiërarchische paden kunnen worden geopend.
Voorbeeld:
sys/intf/phys-[eth1/10]
Identificeert het DME-object dat is gekoppeld aan Ethernet1/10.
Andere DME-paden die in dit lab worden gebruikt, zijn:
sys/intf/phys-[eth1/10]/dbgIfIn
sys/intf/phys-[eth1/10]/dbgIfOut
sys/intf/phys-[eth1/10]/phys
sys/intf/lb-[lo100]
Elk pad vertegenwoordigt een ander object of deel van de informatie die beschikbaar is via DME. Dit zijn dezelfde paden die al in de laboratoriumconfiguratie worden gebruikt.
De DME-database bestaat uit Managed Objects (MO's).
Een beheerd object vertegenwoordigt een entiteit binnen het NX-OS-beheermodel, zoals:
Beheerde objecten worden hiërarchisch georganiseerd in een Management Information Tree (MIT).
Een vereenvoudigde weergave van de objecten die in dit lab worden gebruikt, is:
sys
|
+-- intf
|
+-- phys-[eth1/10]
| |
| +-- dbgIfIn
| +-- dbgIfOut
| +-- phys
|
+-- lb-[lo100]
Deze hiërarchie is nuttig om te begrijpen hoe telemetrie-sensorpaden specifieke informatie binnen DME identificeren.
Elk beheerd object kan op unieke wijze worden geïdentificeerd met een Distinguished Name (DN).
De DN vertegenwoordigt het hiërarchische pad van de wortel van de DME-structuur naar het doelobject.
For example: sys/intf/lb-[lo100]
Hiermee wordt het beheerde object Loopback100 geïdentificeerd.
Zo ook:
sys/intf/phys-[eth1/10]/dbgIfIn
Hiermee wordt het invoerstatistiekobject geïdentificeerd dat is gekoppeld aan Ethernet1/10.
Een eenvoudige manier om een DN te begrijpen is om het te zien als het volledige adres van een object binnen de DME-hiërarchie.
Een sensorpad identificeert de informatie die NX-OS moet bewaken voor een telemetrieabonnement.
In de eerste laboratoriumvoorbeelden worden DME Distinguished Names gebruikt als sensorpaden. Een later praktisch voorbeeld toont het vooraf gedefinieerde padlabel voor resources.
Voorbeeld:
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
Deze paden bieden inputstatistieken, outputstatistieken en operationele informatie voor Ethernet1/10.
Nadat NX-OS de gevraagde informatie verzamelt, moeten de gegevens worden gecodeerd voordat ze kunnen worden verzonden.
De codering die in dit lab wordt gebruikt, is Google Protocol Buffers (GPB).
De bestemmingsconfiguratie specificeert:
ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB
GPB definieert hoe de verzamelde telemetrie-informatie wordt weergegeven in het bericht.
Codering en transport zijn afzonderlijke functies: GPB definieert de gegevensrepresentatie, terwijl het transportmechanisme bepaalt hoe het bericht wordt afgeleverd.
Het transportprotocol dat in dit lab wordt gebruikt, is gRPC.
De Nexus-switch stuurt de GPB-gecodeerde telemetriegegevens naar:
192.168.100.10:57000
gRPC gebruiken.
Daarom:
GPB definieert hoe de telemetrie-informatie wordt gecodeerd.
gRPC biedt het transportmechanisme dat wordt gebruikt om de telemetrieberichten aan de ontvanger af te leveren.
Het gRPC-transport dat door Streaming Telemetry wordt gebruikt, mag niet worden verward met de NX-OS gRPC Agent die wordt gebruikt voor services zoals gRPC Network Management Interface (gNMI) en gRPC Network Operations Interface (gNOI).
De telemetrieontvanger is het externe systeem of de toepassing die de telemetriestroom ontvangt en verwerkt.
In dit lab wordt een Ubuntu-server met Telegraaf gebruikt als ontvanger. De ontvanger luistert naar TCP-poort 57000 en accepteert de GPB-over-gRPC-telemetriestroom die door de Nexus-switch wordt gegenereerd.
De implementatie van de ontvanger die in het lab wordt gebruikt, wordt later beschreven in het gedeelte De telemetrieontvanger voorbereiden.
De doelgroep bepaalt waar telemetriegegevens moeten worden verzonden en hoe deze moeten worden vervoerd.
Het lab gebruikt:
destination-group 1 ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB use-vrf default
Dit definieert het ontvangeradres, de bestemmingspoort, het transportprotocol, de codering en de Virtual Routing and Forwarding (VRF)-instantie die wordt gebruikt voor telemetrielevering.
De sensorgroep bepaalt welke informatie moet worden gemonitord.
Voorbeeld:
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 dit voorbeeld bewaakt Sensor Group 2 Ethernet1/10-invoerstatistieken, uitvoerstatistieken en operationele interfacegegevens. Het dbgIfIn-pad biedt statistieken over de invoerinterface, dbgIfOut biedt statistieken over de uitvoerinterface en phys biedt operationele informatie voor de interface.
Een sensorgroep kan meerdere gerelateerde sensorpaden bevatten en beantwoordt daarom de vraag:
Welke gegevens worden verzameld?
Een abonnement koppelt een sensorgroep aan een doelgroep en definieert het verzamelgedrag.
Voorbeeld:
subscription 2 dst-grp 1 snsr-grp 2 sample-interval 60000
In dit voorbeeld:
Het abonnement verbindt daarom de belangrijkste elementen van de telemetrieconfiguratie:
Sensorgroep + verzamelgedrag + bestemmingsgroep
Cisco NX-OS Streaming Telemetry ondersteunt periodieke en op gebeurtenissen gebaseerde verzameling voor DME-gebaseerde abonnementen.
Het verzamelgedrag wordt bepaald door het sample-interval dat is gekoppeld aan de sensorgroep binnen een abonnement.
Met periodieke telemetrie verzamelt en verzendt NX-OS de bewaakte informatie met een geconfigureerd interval.
Het bemonsteringsinterval wordt gespecificeerd in milliseconden.
For example: snsr-grp 2 sample-interval 60000
Configureert een verzamelinterval van 60 seconden.
Periodieke telemetrie is nuttig voor informatie die voortdurend verandert en meestal in de loop van de tijd wordt geanalyseerd, zoals:
In dit lab maken Abonnement 1 en Abonnement 2 gebruik van periodieke verzameling.
Abonnement 1 verzamelt het Ethernet1/10-interfaceobject elke 10 seconden, terwijl Abonnement 2 elke 60 seconden interfacestatistieken en operationele informatie verzamelt.
Met gebeurtenisgebaseerde telemetrie gebruikt NX-OS geen terugkerende verzamelingstimer.
Voor DME-gebaseerde telemetrie wordt gebeurtenisgebaseerd gedrag geconfigureerd met:
sample-interval 0
Wanneer een bewaakt object verandert, kan telemetrie een update genereren die aan die verandering is gekoppeld.
Deze verzamelmethode is nuttig voor informatie zoals:
In dit lab bewaakt Subscription 3 het Loopback100 DME-object:
sys/intf/lb-[lo100]: snsr-grp 3 sample-interval 0
Wijzigingen in het gemonitorde Loopback100-object worden daarom later in dit document gebruikt om op gebeurtenissen gebaseerde telemetrie aan te tonen.
De drie abonnementen die in de oorspronkelijke laboratoriumconfiguratie worden gebruikt, kunnen als volgt worden samengevat:
| Abonnement | bewaakte informatie | steekproefinterval | collectiegedrag |
|---|---|---|---|
| 1 | Ethernet1/10-interfaceobject | 10000 ms | periodiek |
| 2 | Ethernet1/10-statistieken en operationele status | 60000 ms | periodiek |
| 3 | Loopback100-object | 0 | Gebeurtenisgebaseerd |
Het belangrijkste onderscheid is de trigger die wordt gebruikt om telemetriegegevens te genereren:
| periodieke telemetrie | op gebeurtenissen gebaseerde telemetrie |
|---|---|
| Gebruikt een geconfigureerde timer. | Gebruik geen periodieke timer. |
| Monsterinterval > 0 | steekproefinterval 0 |
| Produceert herhaalde monsters. | Produceert updates wanneer bewaakte objecten veranderen. |
| Wordt vaak gebruikt voor tellers en statistieken. | Wordt vaak gebruikt voor configuratie- of statuswijzigingen. |
De secties Configuratie en verificatie tonen beide verzamelingsgedrag met behulp van de hierboven gedefinieerde abonnementen.
Streaming Telemetry vereist een externe ontvanger die in staat is om de telemetriegegevens die door de Nexus-switch zijn verzonden te accepteren en te verwerken.
Voor het GPB-over-gRPC-transport dat in dit document wordt gebruikt, moet de ontvanger in staat zijn:
De implementatie van de telemetrieontvanger is onafhankelijk van de NX-OS-telemetrieconfiguratie die in dit document wordt beschreven.
Opmerking: Installatie, configuratie, werking en probleemoplossing van telemetrie-ontvangersoftware van derden vallen buiten het bereik van dit document. Raadpleeg de documentatie van de leverancier van de ontvanger voor informatie over configuratie en ondersteuning.
Voor demonstratiedoeleinden gebruikt het lab een externe Ubuntu-server waarop Telegraaf wordt uitgevoerd als de telemetrie-ontvanger.
De ontvanger parameters zijn:
| Parameter | Waarde |
|---|---|
| ontvangeradres | 192.168.100.10 |
| vervoer | gRPC |
| Luisterpoort | TCP/57000 |
| codering | GPB |
De configuratie van de software aan de ontvangerzijde wordt in dit document niet behandeld.
Opmerking: De uitvoervoorbeelden van ontvangers in dit document worden gefilterd om de velden te markeren die relevant zijn voor elke verificatiestap.
Controleer voordat u Streaming Telemetry configureert op de Nexus-switch of:
Voor dit lab gebruikt Ethernet1/10 op de Nexus-switch 192.168.100.1/24 en de telemetrieontvanger 192.168.100.10/24. De bereikbaarheid van Basic Layer 3 moet worden bevestigd voordat er problemen met telemetrie-specifiek gedrag worden opgelost.
Zodra de ontvanger bereikbaar is en klaar is om GPB-over-gRPC-telemetrie op TCP-poort 57000 te accepteren, kan de NX-OS-telemetrieconfiguratie worden toegepast.
De configuratie maakt gebruik van drie primaire componenten:
Het lab gebruikt deze telemetriebestemming:
| Parameter | Waarde |
|---|---|
| Bestemming | 192.168.100.10:57000 |
| vervoer | gRPC |
| codering | GPB |
| VRF | standaard |
De initiële labconfiguratie gebruikt drie abonnementen:
| Abonnement | sensor | Type verzameling | steekproefinterval |
|---|---|---|---|
| 1 | Ethernet1/10-interfaceobject | periodiek | 10000 ms |
| 2 | Ethernet1/10-statistieken en operationele status | periodiek | 60000 ms |
| 3 | Loopback100-object | Gebeurtenisgebaseerd | 0 |
Streaming Telemetrie moet eerst wereldwijd worden ingeschakeld.
N9K-TELEMETRY-SW1# configure terminal N9K-TELEMETRY-SW1(config)# feature telemetry
Voer de configuratiemodus voor telemetrie in:
N9K-TELEMETRY-SW1(config)# telemetry N9K-TELEMETRY-SW1(config-telemetry)#
De resterende telemetrieconfiguratie wordt uitgevoerd in deze modus.
De doelgroep identificeert de externe telemetrieontvanger en definieert het transport en de codering die worden gebruikt om telemetriegegevens te verzenden.
Configureren:
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
Deze configuratie definieert:
De standaard VRF wordt gebruikt omdat de telemetrie-ontvanger bereikbaar is via Ethernet1/10 in de standaard VRF.
De VRF die is geselecteerd voor telemetrietransport moet IP-bereikbaarheid bieden aan de geconfigureerde ontvanger.
Sensor Group 1 bewaakt het Ethernet1/10 DME-interfaceobject.
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 1 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]
Het sensorpad identificeert het beheerde Ethernet1/10-object in de DME-hiërarchie en biedt algemene interfaceinformatie die aan dat object is gekoppeld.
Sensorgroep 1 koppelen aan bestemmingsgroep 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
Het bemonsteringsinterval wordt gespecificeerd in milliseconden.
10000 ms = 10 seconden
Abonnement 1 verzamelt daarom periodiek het Ethernet1/10 DME-object om de 10 seconden en stuurt de telemetriegegevens naar Bestemmingsgroep 1.
Sensor Group 2 verzamelt statistieken en operationele informatie voor Ethernet 1/10.
Configureren:
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
De sensorpaden bieden:
| sensorpad | informatie |
|---|---|
| sys/intf/phys-[eth1/10]/dbgIfIn | Invoerinterfacestatistieken |
| sys/intf/phys-[eth1/10]/dbgIfOut | Statistieken uitvoerinterface |
| SYS/INTF/PHYS-[ETH1/10]/PHYS | Operationele interface-informatie |
Een sensorgroep kan meerdere gerelateerde sensorpaden bevatten, waardoor het abonnement verschillende categorieën informatie van dezelfde bewaakte interface kan verzamelen.
Sensorgroep 2 koppelen aan bestemmingsgroep 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
Het geconfigureerde bemonsteringsinterval is:
60000 ms = 60 seconden
Abonnement 2 verzamelt daarom elke 60 seconden de Ethernet1/10 statistieken en operationele informatie.
Dit abonnement wordt later in het document gebruikt om periodiek telemetriegedrag te verifiëren.
Een loopback-interface wordt gebruikt om op gebeurtenissen gebaseerde telemetrie te demonstreren zonder dat er een extra fysieke verbinding nodig is.
Configureren:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# ip address 10.255.255.100/32
Het corresponderende DME-object is:
sys/intf/lb-[lo100]
De loopback-interface biedt een eenvoudige manier om gecontroleerde configuratie- en beheerstatuswijzigingen te genereren tijdens de gebeurtenisgebaseerde telemetrieverificatie.
Configureer het Loopback100 DME-sensorpad:
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 3 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/lb-[lo100]
Sensor Group 3 bewaakt het Loopback100 Managed Object.
Sensorgroep 3 koppelen aan bestemmingsgroep 1 en gebeurtenisgebaseerde verzameling configureren:
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
Voor DME-gebaseerde abonnementen configureert een voorbeeldinterval van nul gebeurtenisgebaseerd gedrag.
Wijzigingen onder het bewaakte Loopback100-object kunnen daarom telemetriemeldingen genereren zonder een terugkerende verzamelingstimer te gebruiken.
Dit abonnement wordt later gebruikt om wijzigingen in de beschrijving en de administratieve status aan te tonen.
Nadat de configuratie is voltooid, controleert u deze met:
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
Op dit punt heeft de switch de bestemming, sensorgroepen en abonnementen die nodig zijn om telemetriegegevens naar de geconfigureerde ontvanger te verzenden.
In het volgende gedeelte worden de transportsessie en de periodieke telemetrie gecontroleerd die door de Ethernet1/10-abonnementen worden gegenereerd.
Nadat de telemetrieconfiguratie is toegepast, controleert u of de transportsessie is ingesteld, de periodieke sensorgroepen actief zijn en telemetriegegevens worden verzameld en aan de ontvanger worden geleverd.
Voer deze opdracht uit:
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#
De status Verbonden bevestigt dat de gRPC-transportsessie naar de geconfigureerde telemetrieontvanger is ingesteld.
De relevante transportparameters komen ook overeen met de geconfigureerde bestemmingsgroep.
Gebruik:
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
De Sensor Group Database bevestigt dat de periodieke sensorgroepen actief zijn:
| sensorgroep | Type | bemonsteringsinterval | Abonnement |
|---|---|---|---|
| 1 | Timer / DME | 10000 ms / Werkend | 1 |
| 2 | Timer / DME | 60000 ms / Lopen | 2 |
Sensor Group 1 verzamelt het Ethernet1/10-interfaceobject elke 10 seconden.
Sensor Group 2 verzamelt elke 60 seconden Ethernet1/10-statistieken en operationele informatie.
In dezelfde opdracht worden ook de geconfigureerde sensorpaden weergegeven:
sys/intf/phys-[eth1/10] sys/intf/phys-[eth1/10]/dbgIfIn sys/intf/phys-[eth1/10]/dbgIfOut sys/intf/phys-[eth1/10]/phys
Voor de sensorpaden die in dit lab werden gebruikt, lagen de verzamel- en coderingstijden meestal tussen 0 en 1 ms, en er werden geen telemetrieberichtdruppels waargenomen.
Gebruik:
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#
Het lab meldde:
DME Successful Collections: 513 Payloads: 513 Failed: 0 Skipped: 44 Dropped: 0
De Succesvolle en Payload tellers bevestigen dat DME telemetrie gegevens worden verzameld en telemetrie payloads worden gegenereerd.
De 44 overgeslagen collecties zijn historische tellers die werden waargenomen terwijl de telemetriebestemming tijdelijk niet beschikbaar was tijdens het lab. Deze tellers worden later onderzocht in de sectie Basisproblemen oplossen.
Voor aanvullende informatie per sensor-pad gebruikt u:
N9K-TELEMETRY-SW1# show telemetry data collector details
Met deze opdracht kunt u bepalen welke geconfigureerde sensorpaden hebben bijgedragen aan succesvolle, mislukte, overgeslagen of gedropte verzamelingen.
Abonnement 2 verzamelt elke 60 seconden Ethernet1/10-statistieken.
De telemetrie-ontvanger rapporteerde deze invoerstatistieken om 21:44:45 Gecoördineerde Universele Tijd (UTC):
timestamp: 2026-09-17T21:44:45Z source: N9K-TELEMETRY-SW1 subscription: 2 path: sys/intf/phys-[eth1/10]/dbgIfIn broadcastPkts: 5074 discards: 0 errors: 0 multicastPkts: 143403 octets: 12870535 ucastPkts: 31256
Een minuut later werd er weer een sample ontvangen:
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
De tegenveranderingen tussen beide monsters worden hieronder samengevat:
| Teller | 21:44:45 | 21:45:45 |
|---|---|---|
| Unicast-pakketten | 31,256 | 31,292 |
| Multicast-pakketten | 143,403 | 143,430 |
| Uitzendpakketten | 5,074 | 5,075 |
| octetten | 12,870,535 | 12,875,428 |
| Fouten | 0 | 0 |
| teruggooi | 0 | 0 |
De tijdstempels worden ongeveer 60 seconden van elkaar gescheiden, overeenkomend met het bemonsteringsinterval dat is geconfigureerd voor Abonnement 2.
De toenemende pakkettellers en bytetellers bevestigen ook dat bijgewerkte interfacestatistieken worden verzameld en aan de ontvanger worden geleverd.
Het pad van de dbgIfOut-sensor biedt uitvoerstatistieken voor Ethernet1/10.
Een monster verzameld om 21:45:45 UTC meldde:
broadcastPkts: 8 discards: 0 errors: 0 multicastPkts: 4712 octets: 2444721 ucastPkts: 4092
Het pad van de phys-sensor biedt operationele kenmerken voor dezelfde interface.
De ontvanger meldde:
adminSt: up operSt: up operSpeed: 1G operDuplex: full operMtu: 1500 operDescr: TELEMETRY-COLLECTOR
Deze monsters bevestigen dat Sensor Group 2 zowel interfacestatistieken als operationele informatie biedt via de drie geconfigureerde DME-sensorpaden.
De periodieke telemetrieverificatie bevestigt:
| Verificatie | resultaat |
|---|---|
| gRPC-transportsessie | verbonden |
| GPB-codering | bevestigd |
| Sensorgroep 1 | Rijden op 10000 ms |
| Sensorgroep 2 | Rijden op 60000 ms |
| DME-collecties | Geslaagd |
| Mislukte verzamelingen | 0 |
| Gevallen payloads | 0 |
| Periodieke ontvangermonsters | ontvangen |
| Interfacetellers | Bijwerken tussen monsters |
Na verificatie van periodieke telemetrie, gebruikt u Abonnement 3 om gebeurtenisgebaseerde telemetrie te valideren door gecontroleerde wijzigingen in het beheerde object Loopback100 te genereren.
Gebruik:
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]
Dezelfde telemetriedatabase bevestigt dat het sensorpad is geabonneerd via Abonnement 3.
Wijzig de beschrijving van Loopback100 om het genereren van gebeurtenissen te controleren:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# description TELEMETRY-EVENT-DEMO
De telemetrie-ontvanger meldde:
{
"timestamp": "2026-09-17T21:41:12Z",
"source": "N9K-TELEMETRY-SW1",
"subscription": "3",
"event": {
"descr": "TELEMETRY-EVENT-DEMO",
"dn": "sys/intf/lb-[lo100]",
"status": "modified"
}
}
De dn identificeert het bewaakte DME-object en het attribuut descr identificeert de eigenschap die is gewijzigd.
Schakel vervolgens de interface administratief uit en herstel deze:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# shutdown
Vervolgens:
N9K-TELEMETRY-SW1(config-if)# no shutdown
De ontvanger detecteerde beide toestandswijzigingen.
| tijdstempel | Gewijzigd attribuut | Waarde |
|---|---|---|
| 21:41:12 | beschimpen | TELEMETRIE-GEBEURTENIS-DEMO |
| 21:41:19 | beheerder | neerwaarts |
| 21:41:24 | beheerder | omhoog |
Elke update verwijst naar hetzelfde bewaakte object:
sys/intf/lb-[lo100]
Het rapporteerde de objectstatus als gewijzigd.
Deze resultaten bevestigen dat wijzigingen in verschillende kenmerken van het bewaakte beheerde object individuele telemetrie-updates kunnen genereren.
Toen het gebeurtenisgebaseerde abonnement werd ingesteld, genereerde NX-OS een eerste momentopname van het gemonitorde object.
De Sensor Path Database rapporteerde:
Statistieken momentopname:
Sent = 1 Error = 0 Drops = 0
Na de drie gecontroleerde veranderingen rapporteerde hetzelfde sensorpad:
Berichtstatussen:
Sent = 3 Error = 0 Drops = 0
De resultaten kunnen daarom worden samengevat als:
| inzameling | tellen |
|---|---|
| Eerste momentopname | 1 |
| Wijziging van beschrijving | 1 |
| Administratieve status verlaagd | 1 |
| Administratieve toestand verhoogd | 1 |
| totaal | 4 |
De eerste momentopname geeft de status van het gemonitorde object weer wanneer het abonnement actief wordt, terwijl de volgende berichten overeenkomen met objectwijzigingen.
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#
Het lab meldde:
Collection Count: 4
Latest Collection Time: Thu Sep 17 21:41:24.045 UTC
Sensor Path: sys/intf/lb-[lo100]
Het aantal verzamelingen komt overeen met de eerste momentopname en de drie wijzigingen die tijdens de test zijn gegenereerd.
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#
Tijdens de test werden geen voorvalverzamelaarsfouten waargenomen.
De op gebeurtenissen gebaseerde telemetrieverificatie bevestigt:
| Verificatie | resultaat |
|---|---|
| sensorgroep | 3 |
| sensorpad | SYS/INTF/LB-[LO100] |
| Type verzameling | Evenement / DME |
| bemonsteringsinterval | 0 / Geen timer |
| Eerste momentopname | verzonden |
| Beschrijving Wijzigen | gedetecteerd |
| AdminSt Down | gedetecteerd |
| adminSt Up | gedetecteerd |
| Totaal aantal verzamelingen | 4 |
| Fouten bij gebeurtenisverzamelaar | 0 |
De succesvolle detectie van de gecontroleerde Loopback100-wijzigingen bevestigt dat Abonnement 3 werkt zoals verwacht.
In het volgende gedeelte worden de primaire verificatie- en probleemoplossingsopdrachten onderzocht die worden gebruikt om de werking van Streaming Telemetry te evalueren.
Wanneer telemetriegegevens niet worden ontvangen zoals verwacht, begint u met het oplossen van problemen door te bepalen of het probleem verband houdt met de transportsessie, gegevensverzameling, sensorconfiguratie of de externe ontvanger.
Deze workflow maakt gebruik van een probleem dat is waargenomen tijdens dit lab, waarbij NX-OS 44 overgeslagen verzamelingen en één historische gRPC-transmissiefout rapporteerde.
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#
Tijdens de laatste verificatie rapporteerde de telemetriesessie:
Session ID: 0
Destination Group: 1
IP Address: 192.168.100.10
Port: 57000
Encoding: GPB
Transport: gRPC
Status: Connected
Een Connected state bevestigt dat de transportsessie momenteel is ingesteld.
De huidige sessiestatus geeft echter niet noodzakelijkerwijs aan of er eerder connectiviteitsproblemen zijn opgetreden. Bekijk daarom ook de historische inzamelings- en transportbalies.
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#
Het lab meldde:
DME Successful Collections: 513
Payloads: 513
Failed: 0
Skipped: 44
Dropped: 0
De Succesvolle en Payload tellers bevestigen dat DME telemetrie collecties en payload generatie hebben plaatsgevonden.
De balie Overgeslagen geeft echter aan dat 44 geplande collecties niet zijn uitgevoerd.
Om te bepalen welke sensorpaden zijn aangetast, gebruikt u:
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#
De gerapporteerde gedetailleerde output:
| sensorpad | overgeslagen |
|---|---|
| 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 |
| totaal | 44 |
De overgeslagen collecties werden verspreid over de periodieke sensorpaden, wat aangeeft dat het probleem niet geïsoleerd was tot een enkel DME-object.
Opmerking: de incassobalies zijn cumulatief. Een historische teller zonder nul betekent niet noodzakelijk dat dezelfde toestand momenteel aanwezig is.
N9K-TELEMETRY-SW1# show telemetry control stats
--------------------------------------------------------------------------------
Error Description Error Count
--------------------------------------------------------------------------------
<snip>
Collections skipped due to destination unreachable 44
<snip>
N9K-TELEMETRY-SW1#
Deze output identificeert direct de reden voor de overgeslagen collecties:
Bestemming onbereikbaar = 44
De waarde komt overeen met de 44 overgeslagen verzamelingen die door de DME-gegevensverzamelaar zijn gerapporteerd.
Dit stelt het onderzoek in staat om weg te gaan van de sensorpaden zelf en naar de telemetriebestemming en het transportpad.
Gebruik de sessie-ID die wordt gerapporteerd door 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#
Het lab meldde:
Connection Error Count: 0
Tx Error Count: 1
Last Tx Error: Thu Sep 17 21:22:16.008 UTC
Last Tx Return Code: UNAVAILABLE
De NIET-BESCHIKBARE retourcode registreert een gRPC-transmissiefout die is gekoppeld aan de bestemming van de telemetrie.
In dit lab werd de externe ontvanger opzettelijk gestopt en opnieuw opgestart terwijl de configuratie werd gewijzigd. Tijdens dat interval kon NX-OS de telemetriebestemming niet bereiken, wat overeenkomt met de hierboven waargenomen niet-bereikbare verzameltellers.
De belangrijke correlatie is:
| waarneming | resultaat |
|---|---|
| Overgeslagen collecties | 44 |
| Bestemming onbereikbaar | 44 |
| Transport Tx-fouten | 1 |
| Laatste Tx retourcode | UNAVAILABLE |
| Huidige transporttoestand | verbonden |
De matching overgeslagen en bestemming-onbereikbare tellers bieden direct bewijs voor de reden waarom de collecties werden overgeslagen.
De historische transportfout geeft aanvullende informatie over de transportfout die tijdens dezelfde laboratoriumactiviteit is waargenomen.
Nadat de verbinding met de ontvanger is hersteld, gebruikt u:
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#
De laatste laboratoriumverificatie meldde:
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
Deze waarden tonen aan dat de transportsessie herstelde en actief telemetriegegevens verstuurde zonder wachtrij of gedropte berichten.
De belangrijkste indicatoren van de huidige toestand waren:
| aanwijzer | resultaat |
|---|---|
| Vervoersstatus | verbonden |
| Huidige wachtrij | 0 |
| Berichten laten vallen | 0 |
| Flow Control | Nooit toegepast |
Dit onderscheid is belangrijk bij het oplossen van telemetrietellers: historische fouten kunnen zichtbaar blijven, zelfs nadat de onderliggende aandoening is opgelost.
Extra opdrachten kunnen worden gebruikt om te controleren of NX-OS configuratie- of gebeurtenisverwerkingsproblemen meldt.
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#
Gebruik voor op gebeurtenissen gebaseerde telemetrie:
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#
Alle fouttellers voor gebeurtenisverzamelaars waren ook nul.
Deze resultaten helpen configuratie- en gebeurtenisverzamelaarfouten uit te sluiten bij het onderzoeken van de overgeslagen periodieke collecties.
De commando's die tijdens dit onderzoek zijn gebruikt, kunnen als volgt worden samengevat:
| Opdracht | Doel |
|---|---|
| telemetrievervoer tonen | Controleer de huidige status van de transportsessie. |
| Telemetrie-gegevensverzamelaarssamenvatting weergeven | Identificeer succesvolle, mislukte, overgeslagen of gedropte collecties. |
| Gegevens van gegevensverzamelaar voor telemetrie weergeven | Bepaal welke sensorpaden worden beïnvloed. |
| Statistieken voor telemetriecontrole weergeven | Bepaal waarom collecties zijn overgeslagen. |
| Fouten bij telemetrietransport <session-id> weergeven | Inspecteer transportstoringen. |
| Statistieken voor telemetrietransport <session-id> weergeven | Herstel van transport, wachtrijen en drops controleren. |
| Fouten in telemetrieconfiguratie weergeven | Identificeer fouten in de telemetrieconfiguratie. |
| Fouten bij het verzamelen van telemetrie-gebeurtenissen weergeven | Identificeer fouten van gebeurtenisverzamelaar. |
In dit lab identificeerde de reeks probleemoplossing een tijdelijke bereikbaarheidsvoorwaarde voor telemetriebestemming in plaats van een DME-sensorpad of configuratiefout.
Nadat de ontvanger weer beschikbaar kwam, keerde het telemetrietransport terug naar de Connected State, werden de collecties hervat en werd er geen huidige wachtrij of berichtdropconditie waargenomen.
Systeemresource monitoring is een veel voorkomende use case voor streaming telemetrie. CPU- en geheugeninformatie kan periodiek worden geëxporteerd van een Nexus-switch naar een extern monitoringplatform voor historische analyse, dashboards, capaciteitsbewaking en alarmering.
Cisco NX-OS biedt vooraf gedefinieerde telemetriepadlabels voor algemeen bewaakte informatie. In dit voorbeeld wordt het label Bronnenpad gebruikt om gegevens over de CPU en het geheugen van het systeem te verzamelen.
Maak een nieuwe sensorgroep met het label resource path:
N9K-TELEMETRY-SW1(config)# telemetry
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 4
N9K-TELEMETRY-SW1(conf-tm-sensor)# path resources
Abonnement 4 maken en Sensorgroep 4 koppelen aan Bestemmingsgroep 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
Sensor Group 4 gebruikt het vooraf gedefinieerde padlabel voor resources. Abonnement 4 koppelt de sensorgroep aan de bestaande telemetriebestemming en configureert periodieke verzameling met een niet-nul bemonsteringsinterval.
De relevante configuratie is:
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
Voer deze opdracht uit om de DME-paden te onderzoeken die worden weergegeven door het label resource path:
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"))
De uitvoer laat zien dat het resourcelabel meerdere onderliggende DME-paden vertegenwoordigt.
De sys/proc- en sys/procsys-paden maken gebruik van polling-query's en bieden proces- en systeembroninformatie. Het sys/procsys/systeempad maakt gebruik van een gebeurtenisquery die een wijziging kan melden wanneer de status van het gemonitorde geheugen wordt bijgewerkt en niet meer in orde is.
Dit toont het verschil aan tussen het rechtstreeks opgeven van een afzonderlijke DME-naam en het gebruik van een vooraf gedefinieerd telemetriepadlabel.
Voorbeeld:
Individual DME path:
path sys/intf/phys-[eth1/10]
Predefined path label:
path resources
Gebruik de controledatabase voor telemetrie weergeven om de status van Sensorgroep 4 en Abonnement 4 te verifiëren.
De Sensor Group Database rapporteert:
Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions SubID ---------------------------------------------------------------------------------------------------- 4 Timer /DME 10000/Running 1 4
Het Timer/DME-type en 10000/Running sampling interval bevestigen dat Sensor Group 4 werkt als een periodieke DME telemetrie bron.
De Sensor Path Database toont ook de onderliggende paden die zijn gekoppeld aan het bronnenlabel.
Voorbeeld:
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
Het procesgerelateerde pad rapporteert ook actieve telemetriecollectie:
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
Deze tellers bevestigen dat broninformatie wordt verzameld, gecodeerd als GPB en verzonden zonder berichtfouten of -druppels.
De traditionele NX-OS CLI kan worden gebruikt om de huidige CPU en geheugenstatus van de switch weer te geven:
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
De CLI biedt een direct overzicht van de systeembronnen.
Streaming Telemetry maakt het mogelijk om hetzelfde type CPU- en geheugeninformatie naar een externe ontvanger te exporteren, zodat meerdere monsters in de loop van de tijd kunnen worden opgeslagen en geanalyseerd.
Het CPU-gebruik kan snel veranderen. Daarom kunnen CPU-waarden die door de CLI worden weergegeven en waarden die via telemetrie worden ontvangen, verschillen wanneer de monsters op verschillende tijdstippen worden verzameld.
De telemetrie-ontvanger heeft de systeembroninformatie die is gekoppeld aan Abonnement 4 met succes gedecodeerd.
Dit voorbeeld toont CPU- en geheugeninformatie van één telemetriemonster:
{
"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
}
}
De uitvoer van de ontvanger bevestigt dat CPU- en geheugeninformatie van Abonnement 4 met succes wordt gedecodeerd en beschikbaar wordt gesteld voor externe bewaking.
Ter vergelijking, de NX-OS CLI rapporteerde ongeveer 9,3 GB gebruikt geheugen van ongeveer 24,5 GB totaal geheugen en een huidige geheugenstatus van OK. Het telemetriemonster rapporteert dezelfde totale geheugenwaarde, een geheugengebruik van ongeveer 38 procent en dezelfde OK-geheugenstatus.
De CPU-waarden kunnen variëren tussen de CLI- en telemetriemonsters omdat het CPU-gebruik dynamisch verandert en de metingen niet noodzakelijkerwijs op hetzelfde moment worden verzameld.
Meerdere telemetrievoorbeelden kunnen worden gebruikt om te observeren hoe het gebruik van systeembronnen in de loop van de tijd verandert.
Deze monsters werden ontvangen van Abonnement 4 tijdens het lab:
CPU gemiddeld gebruik - laatste 60 seconden
10% |
9% | ●
8% | ●
7% | ●
6% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
8.70% 8.50% 7.10%
Time
geheugengebruik
39% |
38% | ●-----------●-----------●
37% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
37.82% 38.06% 38.18%
Time
Deze voorbeelden illustreren hoe periodieke telemetrie een tijdgebaseerde weergave van systeemgedrag kan bieden in plaats van een enkele momentane meting. In een productieomgeving kan een monitoring- of observatieplatform grotere aantallen monsters opslaan en de monsters gebruiken om trends te identificeren, waarschuwingen te genereren en historische dashboards te bouwen.
Cisco NX-OS Streaming Telemetry biedt een gestructureerd systeem voor het exporteren van bedrijfsinformatie van Cisco Nexus 9000-switches naar een externe telemetrieontvanger.
Dit document toonde de fundamentele componenten van Streaming Telemetry, waaronder DME-sensorpaden, GPB-codering, gRPC-transport, doelgroepen, sensorgroepen en abonnementen.
Met behulp van de laboratoriumomgeving werden zowel periodieke als op gebeurtenissen gebaseerde telemetrie geconfigureerd en geverifieerd. Periodieke abonnementen werden gebruikt om Ethernet1/10-statistieken en operationele informatie te verzamelen, terwijl een op gebeurtenissen gebaseerd abonnement werd gebruikt om gecontroleerde wijzigingen in het Loopback100 Managed Object te detecteren.
Een praktijkvoorbeeld van het monitoren van systeembronnen toonde ook aan hoe het vooraf gedefinieerde padlabel voor resources kan worden gebruikt om CPU- en geheugeninformatie naar een externe telemetrieontvanger te exporteren.
De verificatie- en probleemoplossingsvoorbeelden toonden aan hoe NX-OS-telemetriecommando's kunnen worden gebruikt om transportconnectiviteit, gegevensverzameling, gebeurtenisverwerking en historische verzamelingsfouten te valideren.
Deze concepten bieden een basis voor het begrijpen, implementeren, verifiëren en oplossen van elementaire Streaming Telemetry-implementaties op Cisco Nexus 9000 NX-OS.
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
01-Oct-2026
|
Eerste vrijgave |