Konfiguration und Überprüfung der Telemetrie auf der Nexus-Plattform
Inhalt
Einleitung
Dieses Dokument beschreibt die Implementierung und Verifizierung von Streaming-Telemetrie auf Cisco Nexus 9000-Switches mit Cisco NX-OS.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Grundkenntnisse in diesen Themen verfügen:
- Cisco NX-OS-CLI
- Grundlegende Layer-3-IP-Konnektivität
- Grundlegende Netzwerküberwachungskonzepte
- Grundlegende Kenntnisse der Telemetriekonzepte für Netzwerke
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
| Komponente | Plattform/Software | Version/Wert | Zweck |
|---|---|---|---|
| N9K-TELEMETRIE-SW1 | N9K-C9348GC-FXP | 10.6(4) | Telemetriequelle |
| Telemetrieempfänger | Ubuntu-Server | 22.04.5 | Externer Telemetrieempfänger |
| Telemetrie-Anwendung | Telegraf | 1.40.0 | Google Protocol Buffers (GPB)-over-gRPC-Telemetrieempfänger |
| Listening-Port | TCP | 57000 | Telemetrie-Empfangsport |
| Ausgabeformat des Empfängers | JavaScript Object Notation (JSON) | — | Vom Menschen lesbare Telemetrieleistung |
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Topologie
Bei der Übung wurde ein Cisco Nexus 9000-Switch verwendet, der direkt mit einem Ubuntu-Server verbunden ist, der als externer Telemetrie-Empfänger fungiert.
Der Nexus Switch und der Telemetrie-Empfänger sind über Ethernet1/10 und ens192 direkt verbunden.
Nexus-Receiver-Verbindungen
Ethernet1/10 stellt Layer-3-Verbindungen zwischen dem Nexus-Switch und dem Ubuntu-Receiver bereit.
Die Schnittstellenkonfiguration lautet wie folgt:
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
Hintergrundinformationen
Netzwerküberwachung und -transparenz sind von grundlegender Bedeutung, um den Netzwerkzustand zu verstehen, ungewöhnliches Verhalten zu identifizieren und Netzwerkprobleme zu beheben.
Cisco NX-OS bietet verschiedene Mechanismen zum Abrufen oder Exportieren von Betriebsinformationen von einem Nexus-Switch, einschließlich CLI, Simple Network Management Protocol (SNMP) und Syslog. Herkömmliche Überwachungs-Workflows wie SNMP Polling und CLI-basierte Erfassung basieren in der Regel auf einem Pull-Modell, bei dem ein externes Überwachungssystem regelmäßig Informationen vom Netzwerkgerät anfordert.
Streaming-Telemetrie führt ein Push-Modell ein, bei dem das Netzwerkgerät auf Basis konfigurierter Abonnements ausgewählte Betriebsdaten an einen externen Empfänger sendet. Dadurch wird ein strukturierter Mechanismus zur Erfassung von Netzwerkinformationen geschaffen, ohne dass das Überwachungssystem das Gerät kontinuierlich abfragen muss.
Telemetriedaten: Traditionelle Umfragen oder Streaming
In einem herkömmlichen Abfragemodell bestimmt das Überwachungssystem, wann Informationen vom Netzwerkgerät abgerufen werden.
So kann beispielsweise ein Netzwerkmanagementsystem (NMS) alle 60 Sekunden Schnittstellenstatistiken anfordern. Dies ermöglicht regelmäßige Snapshots des Gerätestatus. Die für die Überwachungsanwendung verfügbare Transparenz hängt jedoch direkt vom konfigurierten Abfrageintervall ab.
Bei Streaming-Telemetrie sendet der Nexus-Switch gemäß konfiguriertem Abonnement ausgewählte Informationen an den Telemetrie-Empfänger.
Die grundlegenden Unterschiede lassen sich wie folgt zusammenfassen:
| Traditionelles Polling | Streaming-Telemetrie |
|---|---|
| Der Client initiiert die Anforderung. | Das Netzwerkgerät sendet die Daten. |
| Pull-Modell | Druckmodell |
| Die Daten werden entsprechend den Polling-Intervallen abgerufen. | Die Daten werden gemäß eines Telemetrie-Abonnements gesendet. |
| Stellt in der Regel regelmäßige Snapshots bereit. | Unterstützt die regelmäßige und ereignisbasierte Erfassung. |
| Das Überwachungssystem fordert Informationen vom Gerät an. | Das Gerät streamt ausgewählte Informationen an einen Empfänger. |
Streaming-Telemetrie ersetzt nicht notwendigerweise die herkömmlichen Überwachungsmechanismen. CLI, SNMP, Syslog und Telemetrie können gleichzeitig verwendet werden und dienen unterschiedlichen Betriebszwecken.
Der Hauptunterschied besteht im Datenerfassungsmodell.
Einsatzmöglichkeiten in der Praxis
In Produktionsumgebungen wird Streaming-Telemetrie häufig verwendet, um einen kontinuierlichen Überblick über den Netzwerk- und Systemstatus zu erhalten.
Typische Anwendungsfälle sind die Überwachung von Schnittstellenzählern und Statusänderungen, Systemressourcen wie CPU- und Speichernutzung sowie Informationen zur Data Center Fabric wie Virtual Extensible LAN (VXLAN)-Peers und Border Gateway Protocol (BGP)-Peer-Status. Ereignisbasierte Telemetrie kann auch verwendet werden, um Änderungen des Betriebsstatus zu melden, sobald diese auftreten.
Die exportierten Telemetriedaten können dann von externen Überwachungs- und Überwachungsplattformen für Dashboards, Warnmeldungen, Verlaufsanalysen und Fehlerbehebung verwendet werden.
Telemetrieverarbeitung - Überblick
Die Streaming-Telemetrie auf NX-OS kann im Wesentlichen in vier Phasen unterteilt werden:
+-----------------------+
| Data Collection |
+-----------+-----------+
|
v
+-----------------------+
| Data Encoding |
+-----------+-----------+
|
v
+-----------------------+
| Data Transport |
+-----------+-----------+
|
v
+-----------------------+
| Telemetry Receiver |
+-----------------------+
In diesen Phasen werden vier grundlegende Fragen beantwortet:
- Datensammlung: Welche Informationen werden gesammelt?
- Datenkodierung: Wie werden die Informationen dargestellt?
- Datentransport: Wie werden die Telemetriedaten übertragen?
- Telemetrie-Empfänger: Wohin werden die Telemetriedaten gesendet?
Telemetrie-Architektur und -Terminologie
Datensammlung
In der ersten Phase wird festgelegt, welche Informationen vom Switch erfasst werden müssen.
Für die Beispiele in diesem Dokument werden Telemetriedaten von der Data Management Engine (DME) erfasst.
Datenmanagement-Engine - DME
Die Data Management Engine verwaltet eine strukturierte Darstellung der Konfigurations- und Betriebsinformationen in NX-OS.
Anstatt Geräteinformationen nur als CLI-Text darzustellen, organisiert DME Informationen als verwaltete Objekte, auf die über hierarchische Pfade zugegriffen werden kann.
Beispiele:
sys/intf/phys-[eth1/10]
Identifiziert das mit Ethernet1/10 verknüpfte DME-Objekt.
Weitere in dieser Übung verwendete DME-Pfade sind:
sys/intf/phys-[eth1/10]/dbgIfIn
sys/intf/phys-[eth1/10]/dbgIfOut
sys/intf/phys-[eth1/10]/phys
sys/intf/lb-[lo100]
Jeder Pfad stellt ein anderes Objekt oder einen anderen Teil der über DME verfügbaren Informationen dar. Hierbei handelt es sich um die gleichen Pfade, die bereits in der gesamten Lab-Konfiguration verwendet wurden.
Verwaltete Objekte und der Verwaltungsinformationsbaum
Die DME-Datenbank besteht aus verwalteten Objekten (MOs).
Ein verwaltetes Objekt stellt eine Entität innerhalb des NX-OS-Verwaltungsmodells dar, z. B.:
- Eine physische Schnittstelle
- Loopback-Schnittstelle
- Schnittstellen-Eingabestatistiken
- Schnittstellen-Ausgabestatistiken
Verwaltete Objekte werden hierarchisch in einem Management Information Tree (MIT) organisiert.
Eine vereinfachte Darstellung der in dieser Übung verwendeten Objekte ist wie folgt:
sys
|
+-- intf
|
+-- phys-[eth1/10]
| |
| +-- dbgIfIn
| +-- dbgIfOut
| +-- phys
|
+-- lb-[lo100]
Diese Hierarchie ist nützlich, um zu verstehen, wie Telemetriesensor-Pfade spezifische Informationen in DME identifizieren.
Distinguished Name - DN
Jedes verwaltete Objekt kann eindeutig durch einen DN (Distinguished Name) identifiziert werden.
Der DN stellt den hierarchischen Pfad vom Stamm der DME-Struktur zum Zielobjekt dar.
For example: sys/intf/lb-[lo100]
Identifiziert das verwaltete Loopback100-Objekt.
Ähnlich:
sys/intf/phys-[eth1/10]/dbgIfIn
Identifiziert das mit Ethernet1/10 verknüpfte Eingabestatistikobjekt.
Ein einfacher Weg, einen DN zu verstehen, besteht darin, ihn als die vollständige Adresse eines Objekts innerhalb der DME-Hierarchie zu betrachten.
Sensorpfad
Ein Sensorpfad identifiziert die Informationen, die NX-OS für ein Telemetrie-Abonnement überwachen muss.
In den Beispielen der ersten Übung werden DME Distinguished Names als Sensorpfade verwendet. In einem späteren praktischen Beispiel wird die vordefinierte Ressourcenpfadbezeichnung veranschaulicht.
Beispiele:
sensor-group 2 path sys/intf/phys-[eth1/10]/dbgIfIn path sys/intf/phys-[eth1/10]/dbgIfOut path sys/intf/phys-[eth1/10]/phys
Diese Pfade bieten Eingangsstatistiken, Ausgangsstatistiken und Betriebsinformationen für Ethernet1/10.
Datenkodierung
Nachdem NX-OS die angeforderten Informationen erfasst hat, müssen die Daten codiert werden, bevor sie übertragen werden können.
Die in dieser Übung verwendete Kodierung ist Google Protocol Buffers (GPB).
Die Zielkonfiguration legt Folgendes fest:
ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB
GPB definiert, wie die gesammelten Telemetrieinformationen in der Nachricht dargestellt werden.
Kodierung und Transport sind separate Funktionen: GPB definiert die Datendarstellung, während der Transportmechanismus bestimmt, wie die Nachricht zugestellt wird.
Datentransport
Das in dieser Übung verwendete Transportprotokoll ist gRPC.
Der Nexus-Switch sendet GPB-kodierte Telemetriedaten an:
192.168.100.10:57000
mit gRPC.
Daher:
GPB definiert, wie die Telemetrieinformationen codiert werden.
gRPC stellt den Transportmechanismus für die Übertragung der Telemetriemeldungen an den Empfänger bereit.
Der von Streaming Telemetry verwendete gRPC-Transport darf nicht mit dem NX-OS gRPC-Agenten verwechselt werden, der für Dienste wie gRPC Network Management Interface (gNMI) und gRPC Network Operations Interface (gNOI) verwendet wird.
Telemetrie-Empfänger
Der Telemetrie-Empfänger ist das externe System oder die Anwendung, das bzw. die den Telemetrie-Stream empfängt und verarbeitet.
In dieser Übung wird ein Ubuntu-Server mit Telegraf als Empfänger verwendet. Der Empfänger hört den TCP-Port 57000 ab und akzeptiert den vom Nexus-Switch generierten GPB-over-gRPC-Telemetrie-Stream.
Die im Labor verwendete Empfängerimplementierung wird später im Abschnitt "Vorbereitung des Telemetrie-Empfängers" beschrieben.
Zielgruppe
Die Zielgruppe definiert, wohin Telemetriedaten gesendet und wie sie übertragen werden müssen.
Die Übung verwendet Folgendes:
destination-group 1 ip address 192.168.100.10 port 57000 protocol gRPC encoding GPB use-vrf default
Diese Eigenschaft definiert die Empfängeradresse, den Zielport, das Transportprotokoll, die Kodierung und die VRF-Instanz (Virtual Routing and Forwarding), die für die Telemetrielieferung verwendet werden.
Sensorgruppe
Die Sensorgruppe legt fest, welche Informationen überwacht werden müssen.
Beispiele:
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 diesem Beispiel überwacht die Sensorgruppe 2 die Ethernet1/10-Eingabestatistiken, Ausgabestatistiken und Informationen zu den Betriebsschnittstellen. Der dbgIfIn-Pfad stellt Statistiken zur Eingabeschnittstelle, dbgIfOut Statistiken zur Ausgabeschnittstelle und phys Betriebsinformationen für die Schnittstelle bereit.
Eine Sensorgruppe kann mehrere verwandte Sensorpfade enthalten und beantwortet daher folgende Frage:
Welche Daten werden gesammelt?
Abonnement
Ein Abonnement verknüpft eine Sensorgruppe mit einer Zielgruppe und definiert das Auflistungsverhalten.
Beispiele:
subscription 2 dst-grp 1 snsr-grp 2 sample-interval 60000
In diesem Beispiel:
- Sensorgruppe 2 bestimmt, welche Informationen gesammelt werden.
- Das Samplingintervall bestimmt das Auflistungsverhalten.
- Die Zielgruppe 1 bestimmt, wohin und wie die Informationen gesendet werden.
Das Abonnement verbindet daher die wichtigsten Telemetriekonfigurationselemente:
Sensorgruppe + Erfassungsverhalten + Zielgruppe
Periodische und ereignisbasierte Telemetrie
Cisco NX-OS Streaming-Telemetrie unterstützt die regelmäßige und ereignisbasierte Erfassung DME-basierter Abonnements.
Das Erfassungsverhalten wird durch das Abtastintervall gesteuert, das der Sensorgruppe innerhalb eines Abonnements zugeordnet ist.
Periodische Telemetrie
NX-OS erfasst und sendet die überwachten Informationen in konfigurierten Intervallen, wobei regelmäßige Telemetriedaten zur Verfügung stehen.
Das Abtastintervall wird in Millisekunden angegeben.
For example: snsr-grp 2 sample-interval 60000
Konfiguriert ein 60-Sekunden-Erfassungsintervall.
Periodische Telemetrie ist nützlich für Informationen, die sich kontinuierlich ändern und in der Regel im Laufe der Zeit analysiert werden, wie z. B.:
- Zähler für Schnittstellenpakete
- Byte-Zähler
- Fehler und Rückwürfe
- Betriebsstatistiken
- Ressourcennutzung
In dieser Übung werden für Abonnement 1 und für Abonnement 2 periodische Sammlungen verwendet.
Subscription 1 erfasst alle 10 Sekunden das Ethernet1/10-Schnittstellenobjekt, Subscription 2 hingegen alle 60 Sekunden Schnittstellenstatistiken und Betriebsinformationen.
Ereignisbasierte Telemetrie
Bei der ereignisbasierten Telemetrie verwendet NX-OS keinen Timer für die regelmäßige Erfassung.
Für die DME-basierte Telemetrie wird das ereignisbasierte Verhalten wie folgt konfiguriert:
sample-interval 0
Wenn sich ein überwachtes Objekt ändert, kann die Telemetrie ein Update generieren, das mit dieser Änderung verknüpft ist.
Diese Auflistungsmethode ist für folgende Informationen nützlich:
- Konfigurationsänderungen
- Administrative Statusänderungen
- Erstellen oder Löschen von Objekten
- Weitere Änderungen unter einem überwachten DME-Objekt
In dieser Übung überwacht Subscription 3 das Loopback100-DME-Objekt:
sys/intf/lb-[lo100]: snsr-grp 3 sample-interval 0
Änderungen am überwachten Loopback100-Objekt werden daher später in diesem Dokument verwendet, um die ereignisbasierte Telemetrie zu veranschaulichen.
In der Übung verwendetes Auflistungsverhalten
Die drei in der anfänglichen Laborkonfiguration verwendeten Abonnements können wie folgt zusammengefasst werden:
| Abonnement | Überwachte Informationen | Beispielintervall | Auflistungsverhalten |
|---|---|---|---|
| 1 | Ethernet1/10-Schnittstellenobjekt | 10000 ms | Periodisch |
| 2 | Ethernet1/10-Statistiken und Betriebsstatus | 60000 ms | Periodisch |
| 3 | Loopback100-Objekt | 0 | ereignisbasiert |
Der Hauptunterschied besteht darin, dass Telemetriedaten durch Trigger generiert werden:
| Periodische Telemetrie | Ereignisbasierte Telemetrie |
|---|---|
| Verwendet einen konfigurierten Timer. | Es wird kein periodischer Zeitgeber verwendet. |
| Abtastintervall > 0 | Abtastintervall 0 |
| Produziert wiederholte Proben. | Erstellt Updates, wenn überwachte Objekte sich ändern. |
| Wird häufig für Zähler und Statistiken verwendet. | Wird häufig für Konfigurations- oder Statusänderungen verwendet. |
In den Abschnitten "Configuration" und "Verification" werden beide Erfassungsverhalten unter Verwendung der oben definierten Abonnements veranschaulicht.
Telemetrie-Empfänger vorbereiten
Für Streaming-Telemetrie ist ein externer Empfänger erforderlich, der die vom Nexus-Switch gesendeten Telemetriedaten empfangen und verarbeiten kann.
Für den in diesem Dokument verwendeten GPB-over-gRPC-Transport muss der Empfänger in der Lage sein:
- Empfangen von gRPC-Verbindungen
- Überwacht den konfigurierten Ziel-Port
- Dekodieren von GPB-Telemetriemeldungen
- Verarbeitung oder Speicherung der empfangenen Daten
Die Implementierung des Telemetrie-Empfängers ist unabhängig von der in diesem Dokument beschriebenen NX-OS-Telemetriekonfiguration.
Anmerkung: Installation, Konfiguration, Betrieb und Fehlerbehebung von Telemetrie-Receiver-Software von Drittanbietern werden in diesem Dokument nicht behandelt. Informationen zur Konfiguration und zum Support erhalten Sie in der Dokumentation des jeweiligen Empfängerherstellers.
In dieser Übung verwendeter Empfänger
Zu Demonstrationszwecken wird in der Übung ein externer Ubuntu-Server mit Telegraf als Telemetriempfänger verwendet.
Die Empfangsparameter sind:
| Parameter | Wert |
|---|---|
| Empfängeradresse | 192.168.100.10 |
| Verkehr | gRPC |
| Listening-Port | TCP/57000 |
| Kodierung | GPB |
Die empfängerseitige Softwarekonfiguration wird in diesem Dokument nicht behandelt.
Anmerkung: Die in diesem Dokument gezeigten Beispiele für Empfängerausgaben werden gefiltert, um die für die einzelnen Überprüfungsschritte relevanten Felder hervorzuheben.
Überprüfen Sie vor der Konfiguration von Streaming Telemetrie auf dem Nexus-Switch Folgendes:
- Zwischen dem Nexus-Switch und dem Empfänger besteht eine IP-Verbindung.
- Die Empfängeranwendung wird ausgeführt.
- Der konfigurierte Zielport lauscht.
- Der Empfänger unterstützt das konfigurierte Transportprotokoll.
- Der Empfänger unterstützt die konfigurierte Telemetriecodierung.
Bei dieser Übung wird für Ethernet1/10 auf dem Nexus-Switch 192.168.100.1/24 und für den Telemetrie-Empfänger 192.168.100.10/24 verwendet. Die grundlegende Layer-3-Erreichbarkeit muss bestätigt werden, bevor ein telemetriespezifisches Verhalten behoben werden kann.
Sobald der Empfänger erreichbar ist und GPB-over-gRPC-Telemetrie über den TCP-Port 57000 akzeptieren kann, kann die NX-OS-Telemetriekonfiguration angewendet werden.
Konfigurieren von Streaming-Telemetrie auf NX-OS
Die Konfiguration besteht aus drei Hauptkomponenten:
- Zielgruppe: Definiert, wohin die Telemetriedaten gesendet und wie sie übertragen werden.
- Sensorgruppe: Definiert, welche Informationen gesammelt werden.
- Abonnement: Ordnet einer Zielgruppe eine Sensorgruppe zu und definiert das Auflistungsverhalten.
Die Übung verwendet folgende Telemetriebasis:
| Parameter | Wert |
|---|---|
| Ziel | 192.168.100.10:57000 |
| Verkehr | gRPC |
| Kodierung | GPB |
| VRF | standard |
In der anfänglichen Laborkonfiguration werden drei Abonnements verwendet:
| Abonnement | Sensor | Sammlungstyp | Beispielintervall |
|---|---|---|---|
| 1 | Ethernet1/10-Schnittstellenobjekt | Periodisch | 10000 ms |
| 2 | Ethernet1/10-Statistiken und Betriebsstatus | Periodisch | 60000 ms |
| 3 | Loopback100-Objekt | ereignisbasiert | 0 |
Telemetrie-Funktion aktivieren
Streaming-Telemetrie muss zunächst global aktiviert werden.
N9K-TELEMETRY-SW1# configure terminal N9K-TELEMETRY-SW1(config)# feature telemetry
Telemetriekonfigurationsmodus:
N9K-TELEMETRY-SW1(config)# telemetry N9K-TELEMETRY-SW1(config-telemetry)#
Die verbleibende Telemetriekonfiguration wird in diesem Modus durchgeführt.
Konfigurieren der Zielgruppe
Die Zielgruppe identifiziert den externen Telemetrie-Empfänger und definiert den Transport und die Codierung, die zum Senden von Telemetriedaten verwendet werden.
Konfiguration:
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
Diese Konfiguration definiert Folgendes:
- Zieladresse: 192.168.100.10
- Ziel-Port: 57000
- Verkehr: gRPC
- Kodierung: GPB
- VRF: standard
Das Standard-VRF wird verwendet, da der Telemetrie-Empfänger über Ethernet1/10 im Standard-VRF erreichbar ist.
Die für den Telemetrietransport ausgewählte VRF-Instanz muss für die IP-Erreichbarkeit des konfigurierten Empfängers sorgen.
Sensorgruppe 1 konfigurieren
Sensorgruppe 1 überwacht das Ethernet1/10 DME-Schnittstellenobjekt.
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 1 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/phys-[eth1/10]
Der Sensorpfad identifiziert das verwaltete Ethernet1/10-Objekt in der DME-Hierarchie und stellt allgemeine Schnittstelleninformationen bereit, die mit diesem Objekt verknüpft sind.
Abonnement 1 konfigurieren
Sensorgruppe 1 mit Zielgruppe 1 verknüpfen:
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
Das Abtastintervall wird in Millisekunden angegeben.
10000 ms = 10 Sekunden
Das Abonnement 1 erfasst daher periodisch alle 10 Sekunden das Ethernet1/10 DME-Objekt und sendet die Telemetriedaten an die Zielgruppe 1.
Sensorgruppe 2 konfigurieren
Sensorgruppe 2 erfasst Statistiken und Betriebsinformationen für Ethernet 1/10.
Konfiguration:
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
Die Sensorpfade bieten folgende Vorteile:
| Sensorpfad | Informationen |
|---|---|
| sys/intf/phys-[eth1/10]/dbgIfIn | Statistiken der Eingangsschnittstelle |
| sys/intf/phys-[eth1/10]/dbgIfOut | Statistiken der Ausgangsschnittstelle |
| sys/intf/phys-[eth1/10]/phys | Informationen zur Betriebsschnittstelle |
Eine Sensorgruppe kann mehrere verwandte Sensorpfade enthalten, sodass das Abonnement mehrere Kategorien von Informationen von derselben überwachten Schnittstelle sammeln kann.
Konfigurieren von Abonnement 2
Sensorgruppe 2 mit Zielgruppe 1 verknüpfen:
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
Das konfigurierte Abtastintervall ist:
60000 ms = 60 Sekunden
Abonnement 2 erfasst daher alle 60 Sekunden die Ethernet1/10-Statistiken und -Betriebsinformationen.
Dieses Abonnement wird später in diesem Dokument verwendet, um das regelmäßige Telemetrieverhalten zu überprüfen.
Konfigurieren der Loopback-Schnittstelle
Eine Loopback-Schnittstelle dient zur Demonstration ereignisbasierter Telemetrie, ohne dass eine zusätzliche physische Verbindung erforderlich ist.
Konfiguration:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# ip address 10.255.255.100/32
Das entsprechende DME-Objekt ist:
sys/intf/lb-[lo100]
Die Loopback-Schnittstelle bietet eine einfache Möglichkeit, während der ereignisbasierten Telemetrieprüfung kontrollierte Änderungen der Konfiguration und des Verwaltungsstatus zu generieren.
Sensorgruppe 3 konfigurieren
Konfigurieren Sie den Loopback100 DME-Sensorpfad:
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 3 N9K-TELEMETRY-SW1(conf-tm-sensor)# path sys/intf/lb-[lo100]
Sensorgruppe 3 überwacht das verwaltete Loopback100-Objekt.
Konfigurieren von Abonnement 3
Zuordnen von Sensorgruppe 3 zu Zielgruppe 1 und Konfigurieren der ereignisbasierten Erfassung:
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
Bei DME-basierten Abonnements wird das ereignisbasierte Verhalten durch ein Sampleintervall von Null konfiguriert.
Änderungen unter dem überwachten Loopback100-Objekt können daher Telemetrie-Benachrichtigungen generieren, ohne einen wiederkehrenden Auflistungs-Timer zu verwenden.
Dieses Abonnement wird später verwendet, um Änderungen der Beschreibung und des Verwaltungsstatus zu veranschaulichen.
Vollständige erste Telemetriekonfiguration
Wenn die Konfiguration abgeschlossen ist, überprüfen Sie sie mit:
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
Zu diesem Zeitpunkt verfügt der Switch über das Ziel, die Sensorgruppen und die erforderlichen Abonnements, um Telemetriedaten an den konfigurierten Empfänger zu senden.
Im nächsten Abschnitt werden die Transportsitzung und die periodische Telemetrie überprüft, die von den Ethernet1/10-Abonnements generiert werden.
Periodische Telemetrie überprüfen
Nachdem die Telemetriekonfiguration angewendet wurde, überprüfen Sie, ob die Transportsitzung eingerichtet ist, ob die periodischen Sensorgruppen aktiv sind und ob Telemetriedaten gesammelt und an den Empfänger übertragen werden.
Überprüfen des Telemetrietransports
Führen Sie diesen Befehl aus:
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#
Der Status "Connected" (Verbunden) bestätigt, dass die gRPC-Transportsitzung zum konfigurierten Telemetrie-Empfänger eingerichtet ist.
Die relevanten Transportparameter stimmen auch mit der konfigurierten Zielgruppe überein.
Überprüfen der periodischen Sensorgruppen
Nutzung:
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
Die Sensorgruppen-Datenbank bestätigt, dass die periodischen Sensorgruppen aktiv sind:
| Sensorgruppe | Typ | Abtastintervall | Abonnement |
|---|---|---|---|
| 1 | Timer/DME | 10000 ms / Wird ausgeführt | 1 |
| 2 | Timer/DME | 60000 ms / Wird ausgeführt | 2 |
Sensorgruppe 1 erfasst das Ethernet1/10-Schnittstellenobjekt alle 10 Sekunden.
Sensorgruppe 2 erfasst alle 60 Sekunden Ethernet1/10-Statistiken und Betriebsinformationen.
Mit dem gleichen Befehl werden auch die konfigurierten Sensorpfade angezeigt:
sys/intf/phys-[eth1/10] sys/intf/phys-[eth1/10]/dbgIfIn sys/intf/phys-[eth1/10]/dbgIfOut sys/intf/phys-[eth1/10]/phys
Für die in dieser Übung verwendeten Sensorpfade lagen die Erfassungs- und Codierzeiten in der Regel zwischen 0 und 1 ms, und es wurden keine Verwerfungen von Telemetrienachrichten beobachtet.
Überprüfen der Datensammlung
Nutzung:
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#
Das Labor berichtete:
DME Successful Collections: 513 Payloads: 513 Failed: 0 Skipped: 44 Dropped: 0
Die Zähler für erfolgreiche Telemetriedaten und Payloads bestätigen, dass DME-Telemetriedaten gesammelt und Telemetriedaten generiert werden.
Die 44 übersprungenen Sammlungen sind historische Zähler, die beobachtet wurden, während das Telemetrie-Ziel während der Übung vorübergehend nicht verfügbar war. Diese Zähler werden später im Abschnitt Grundlegende Fehlerbehebung näher erläutert.
Weitere Informationen pro Sensorpfad finden Sie unter:
N9K-TELEMETRY-SW1# show telemetry data collector details
Mit diesem Befehl kann ermittelt werden, welche konfigurierten Sensorpfade zu erfolgreichen, fehlgeschlagenen, übersprungenen oder verworfenen Sammlungen beigetragen haben.
Überprüfen Sie die periodischen Daten am Empfänger.
Abonnement 2 erfasst alle 60 Sekunden Ethernet1/10-Statistiken.
Der Telemetrie-Empfänger meldete diese Eingabestatistiken um 21:44:45 Uhr Coordinated Universal Time (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
Eine Minute später wurde eine weitere Probe empfangen:
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
Die Leistungsindikatoränderungen zwischen den beiden Stichproben werden im Folgenden zusammengefasst:
| Zähler | 21:44:45 | 21:45:45 |
|---|---|---|
| Unicast-Pakete | 31,256 | 31,292 |
| Multicast-Pakete | 143,403 | 143,430 |
| Broadcast-Pakete | 5,074 | 5,075 |
| Oktette | 12,870,535 | 12,875,428 |
| Fehler | 0 | 0 |
| Rückwürfe | 0 | 0 |
Die Zeitstempel werden durch ca. 60 Sekunden voneinander getrennt und entsprechen dem für Abonnement 2 konfigurierten Abtastintervall.
Die zunehmenden Paket- und Byte-Zähler bestätigen außerdem, dass aktualisierte Schnittstellenstatistiken gesammelt und an den Empfänger übermittelt werden.
Überprüfen der Ausgabe- und Betriebsinformationen
Der dbgIfOut-Sensorpfad liefert Ausgabestatistiken für Ethernet1/10.
Eine um 21:45:45 UTC entnommene Probe ergab Folgendes:
broadcastPkts: 8 discards: 0 errors: 0 multicastPkts: 4712 octets: 2444721 ucastPkts: 4092
Der phys-Sensorpfad stellt Betriebsattribute für dieselbe Schnittstelle bereit.
Der Empfänger berichtete:
adminSt: up operSt: up operSpeed: 1G operDuplex: full operMtu: 1500 operDescr: TELEMETRY-COLLECTOR
Diese Beispiele bestätigen, dass Sensorgruppe 2 über die drei konfigurierten DME-Sensorpfade sowohl Schnittstellenstatistiken als auch Betriebsinformationen bereitstellt.
Zusammenfassung der periodischen Telemetrie-Verifizierung
Die regelmäßige Telemetrie bestätigt Folgendes:
| Verifizierung | Ergebnis |
|---|---|
| gRPC-Transportsitzung | Verbunden |
| GPB-Kodierung | Bestätigt |
| Sensorgruppe 1 | Laufzeit: 10000 ms |
| Sensorgruppe 2 | Laufzeit: 60000 ms |
| DME-Sammlungen | Erfolgreich |
| Fehlgeschlagene Sammlungen | 0 |
| Verworfene Payloads | 0 |
| Periodische Empfängerproben | Empfangen |
| Schnittstellen-Zähler | Aktualisierung zwischen Stichproben |
Überprüfung der ereignisbasierten Telemetrie
Verwenden Sie nach der Überprüfung der regelmäßigen Telemetrie Subscription 3, um die ereignisbasierte Telemetrie zu validieren, indem Sie kontrollierte Änderungen am Loopback100 Managed Object generieren.
Überprüfen des ereignisbasierten Abonnements
Nutzung:
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]
Dieselbe Telemetriedatenbank bestätigt, dass der Sensorpfad über Abonnement 3 registriert wird.
Ereignisbasierte Updates generieren
Ändern Sie zur Überprüfung der Ereignisgenerierung die Loopback100-Beschreibung:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# description TELEMETRY-EVENT-DEMO
Der Telemetrieempfänger meldete:
{
"timestamp": "2026-09-17T21:41:12Z",
"source": "N9K-TELEMETRY-SW1",
"subscription": "3",
"event": {
"descr": "TELEMETRY-EVENT-DEMO",
"dn": "sys/intf/lb-[lo100]",
"status": "modified"
}
}
Der dn identifiziert das überwachte DME-Objekt, und das descr-Attribut identifiziert die geänderte Eigenschaft.
Deaktivieren und stellen Sie anschließend die Schnittstelle wieder her:
N9K-TELEMETRY-SW1(config)# interface loopback100 N9K-TELEMETRY-SW1(config-if)# shutdown
Dann:
N9K-TELEMETRY-SW1(config-if)# no shutdown
Der Empfänger hat beide Zustandsänderungen erkannt.
| Zeitstempel | Geändertes Attribut | Wert |
|---|---|---|
| 21:41:12 | entschlüsseln | TELEMETRIEVERANSTALTUNG - DEMO |
| 21:41:19 | AdminSt | hinuntergehen |
| 21:41:24 | AdminSt | aufstehen |
Jede Aktualisierung verwies auf dasselbe überwachte Objekt:
sys/intf/lb-[lo100]
Der Objektstatus wurde als geändert gemeldet.
Diese Ergebnisse bestätigen, dass Änderungen an verschiedenen Attributen des überwachten verwalteten Objekts individuelle Telemetrie-Updates generieren können.
Überprüfen des ersten Snapshots und der Ereignismeldungen
Bei Einrichtung des ereignisbasierten Abonnements generierte NX-OS einen ersten Snapshot des überwachten Objekts.
Die Sensorpfaddatenbank hat Folgendes gemeldet:
Snapshot-Statistiken:
Sent = 1 Error = 0 Drops = 0
Nach den drei kontrollierten Änderungen meldete derselbe Sensorpfad:
Nachrichtenstatistiken:
Sent = 3 Error = 0 Drops = 0
Die Ergebnisse lassen sich daher wie folgt zusammenfassen:
| Sammlung | Anzahl |
|---|---|
| Anfänglicher Snapshot | 1 |
| Beschreibung geändert | 1 |
| Verwaltungsstatus "Down" | 1 |
| Verwaltungsstatus aktiv | 1 |
| Gesamt | 4 |
Der ursprüngliche Snapshot stellt den Zustand des überwachten Objekts dar, wenn das Abonnement aktiv wird, während die nachfolgenden Meldungen Objektänderungen entsprechen.
Ereigniserfassungsstatistik überprüfen
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#
Das Labor berichtete:
Collection Count: 4
Latest Collection Time: Thu Sep 17 21:41:24.045 UTC
Sensor Path: sys/intf/lb-[lo100]
Die Sammlungsanzahl entspricht dem ersten Snapshot und den drei während des Tests generierten Änderungen.
Überprüfen von Ereignissammlerfehlern
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#
Während des Tests wurden keine Fehler in der Ereigniserfassung festgestellt.
Ereignisbasierte Telemetrie - Zusammenfassung
Die ereignisbasierte Telemetrie-Verifizierung bestätigt Folgendes:
| Verifizierung | Ergebnis |
|---|---|
| Sensorgruppe | 3 |
| Sensorpfad | sys/intf/lb-[lo100] |
| Sammlungstyp | Veranstaltung/DME |
| Abtastintervall | 0 / Kein Timer |
| Anfänglicher Snapshot | Gesendet |
| Beschreibung ändern | Erkannt |
| adminHerunterfahren | Erkannt |
| AdminEinrichten | Erkannt |
| Sammlungen gesamt | 4 |
| Fehler der Ereignissammlung | 0 |
Die erfolgreiche Erkennung der gesteuerten Loopback100-Änderungen bestätigt, dass Abonnement 3 erwartungsgemäß funktioniert.
Im nächsten Abschnitt werden die primären Befehle zur Verifizierung und Fehlerbehebung für die Auswertung der Streaming-Telemetrie beschrieben.
Grundlegende Fehlerbehebung
Wenn Telemetriedaten nicht wie erwartet empfangen werden, beginnen Sie mit der Fehlerbehebung, indem Sie ermitteln, ob das Problem mit der Transportsitzung, der Datensammlung, der Sensorkonfiguration oder dem externen Empfänger zusammenhängt.
In diesem Workflow wird ein Problem verwendet, das in dieser Übung beobachtet wurde, in der NX-OS 44 übersprungene Sammlungen und einen historischen gRPC-Übertragungsfehler meldete.
Überprüfen des aktuellen Transportstatus
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#
Bei der abschließenden Überprüfung ergab die Telemetriesession Folgendes:
Session ID: 0
Destination Group: 1
IP Address: 192.168.100.10
Port: 57000
Encoding: GPB
Transport: gRPC
Status: Connected
Der Status Verbunden bestätigt, dass die Transportsitzung derzeit eingerichtet ist.
Der aktuelle Sitzungszustand gibt jedoch nicht unbedingt an, ob zuvor Verbindungsprobleme aufgetreten sind. Überprüfen Sie daher auch die historischen Sammel- und Transportzähler.
Zähler für Datenerfassung überprüfen
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#
Das Labor berichtete:
DME Successful Collections: 513
Payloads: 513
Failed: 0
Skipped: 44
Dropped: 0
Die Zähler "Successful" (Erfolg) und "Payload" (Nutzlast) bestätigen, dass die DME-Telemetrie erfasst und die Nutzlast generiert wurde.
Der Zähler Übersprungen zeigt jedoch an, dass 44 geplante Auflistungen nicht ausgeführt wurden.
Um festzustellen, welche Sensorpfade betroffen waren, verwenden Sie:
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#
Die detaillierten Ergebnisse:
| Sensorpfad | Übersprungen |
|---|---|
| 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 |
| Gesamt | 44 |
Die übersprungenen Auflistungen wurden über die periodischen Sensorpfade verteilt, was darauf hinweist, dass das Problem nicht auf ein einzelnes DME-Objekt isoliert wurde.
Anmerkung: Sammlungszähler sind kumulativ. Ein Verlaufszähler ungleich null bedeutet nicht notwendigerweise, dass die gleiche Bedingung gegenwärtig vorhanden ist.
Ermitteln, warum Sammlungen übersprungen wurden
N9K-TELEMETRY-SW1# show telemetry control stats
--------------------------------------------------------------------------------
Error Description Error Count
--------------------------------------------------------------------------------
<snip>
Collections skipped due to destination unreachable 44
<snip>
N9K-TELEMETRY-SW1#
Diese Ausgabe identifiziert direkt den Grund für die übersprungenen Auflistungen:
Ziel nicht erreichbar = 44
Der Wert entspricht den 44 übersprungenen Auflistungen, die vom DME-Datensammler gemeldet wurden.
Dadurch kann die Untersuchung von den Sensorpfaden selbst weg und zum Telemetrieziel und Transportpfad geführt werden.
Transportfehler überprüfen
Verwenden Sie die vom Telemetrietransport anzeigen gemeldete Sitzungs-ID:
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#
Das Labor berichtete:
Connection Error Count: 0
Tx Error Count: 1
Last Tx Error: Thu Sep 17 21:22:16.008 UTC
Last Tx Return Code: UNAVAILABLE
Der UNAVAILABLE-Rückgabecode zeichnet einen gRPC-Übertragungsfehler auf, der mit dem Telemetrieziel verknüpft ist.
In dieser Übung wurde der externe Empfänger absichtlich angehalten und neu gestartet, während seine Konfiguration geändert wurde. Während dieses Intervalls konnte NX-OS das Telemetrieziel nicht erreichen, das den oben beobachteten Zählern für nicht erreichbare Ziele entspricht.
Die wichtige Korrelation ist:
| Beobachtung | Ergebnis |
|---|---|
| Übersprungene Sammlungen | 44 |
| Ziel nicht erreichbar | 44 |
| Transportsteuerfehler | 1 |
| Letzter Tx-Rückgabecode | NICHT VERFÜGBAR |
| Aktueller Transportzustand | Verbunden |
Die Zähler für übersprungene und für nicht erreichbare Ziele liefern einen direkten Beweis dafür, warum die Auflistungen übersprungen wurden.
Der historische Transportfehler liefert zusätzliche Informationen über den Transportfehler, der während derselben Laboraktivität beobachtet wurde.
Überprüfung der Transportwiederherstellung
Verwenden Sie nach der Wiederherstellung der Verbindung zum Empfänger Folgendes:
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#
Die abschließende Laborprüfung ergab Folgendes:
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
Diese Werte zeigen, dass die Transportsitzung wiederhergestellt wurde und aktiv Telemetriedaten ohne Nachrichten in der Warteschlange oder verworfene Nachrichten übertragen hat.
Die wichtigsten aktuellen Indikatoren waren:
| Anzeige | Ergebnis |
|---|---|
| Transportstatus | Verbunden |
| Aktuelle Warteschlange | 0 |
| Verworfene Nachrichten | 0 |
| Flusssteuerung | Nie angewendet |
Diese Unterscheidung ist wichtig bei der Fehlerbehebung von Telemetriekonten: Verlaufsfehler können auch nach der Behebung der zugrunde liegenden Bedingung sichtbar bleiben.
Überprüfen von Konfigurations- und Ereigniserfassungsfehlern
Mithilfe zusätzlicher Befehle kann überprüft werden, ob NX-OS Probleme bei der Konfiguration oder Ereignisverarbeitung meldet.
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#
Für ereignisbasierte Telemetrie verwenden Sie:
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 Ereigniskollektorfehlerzähler wiesen ebenfalls den Wert 0 auf.
Diese Ergebnisse helfen beim Untersuchen der ausgelassenen periodischen Auflistungen, Konfigurations- und Ereignissammlungsfehler auszuschließen.
Fehlerbehebung-Workflow
Die bei dieser Untersuchung verwendeten Befehle lassen sich wie folgt zusammenfassen:
| Command | Zweck |
|---|---|
| Telemetrietransport anzeigen | Überprüfen des aktuellen Status der Transportsitzung |
| Telemetriedatensammlerbrief anzeigen | Identifizierung erfolgreicher, fehlgeschlagener, übersprungener oder gelöschter Auflistungen. |
| Telemetriedatensammlerdetails anzeigen | Bestimmen Sie, welche Sensorpfade betroffen sind. |
| Telemetriestatistiken anzeigen | Ermitteln, warum Sammlungen übersprungen wurden |
| show telemetry transport <Sitzungs-ID> errors | Überprüfen Sie Transportfehler. |
| show telemetry transport <Sitzungs-ID> stats | Überprüfen der Transportwiederherstellung, Warteschlangen und Verwerfungen |
| Telemetriekonfigurationsfehler anzeigen | Identifizieren von Telemetrie-Konfigurationsfehlern. |
| Anzeige von Fehlern im Telemetrieereignissammler | Identifizieren von Ereignissammlungsfehlern. |
Bei dieser Übung wurde in der Fehlerbehebungssequenz statt eines DME-Sensorpfads oder eines Konfigurationsfehlers eine temporäre Erreichbarkeitsbedingung für das Telemetriebasis identifiziert.
Nachdem der Empfänger wieder verfügbar war, kehrte der Telemetrietransport in den Status Verbunden zurück, die Erfassung wurde wieder aufgenommen, und es wurde keine aktuelle Warteschlange oder kein Nachrichtenverlust beobachtet.
Anwendungsbeispiel: Systemressourcen überwachen
Die Systemressourcenüberwachung ist ein gängiger Anwendungsfall für Streaming-Telemetrie. CPU- und Speicherinformationen können regelmäßig von einem Nexus-Switch zu einer externen Überwachungsplattform exportiert werden, um Verlaufsanalysen, Dashboards, Kapazitätsüberwachung und Warnungen durchzuführen.
Cisco NX-OS bietet vordefinierte Telemetriepfad-Labels für häufig überwachte Informationen. In diesem Beispiel wird die Ressourcenpfad-Bezeichnung verwendet, um CPU- und Speicherinformationen des Systems zu erfassen.
Systemressourcen-Telemetrie konfigurieren
Erstellen Sie eine neue Sensorgruppe mit der Ressourcenpfadbezeichnung:
N9K-TELEMETRY-SW1(config)# telemetry
N9K-TELEMETRY-SW1(config-telemetry)# sensor-group 4
N9K-TELEMETRY-SW1(conf-tm-sensor)# path resources
Erstellen Sie Abonnement 4, und ordnen Sie Sensorgruppe 4 der Zielgruppe 1 zu:
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
Sensorgruppe 4 verwendet die vordefinierte Ressourcenpfadbezeichnung. Abonnement 4 verknüpft die Sensorgruppe mit dem vorhandenen Telemetrieziel und konfiguriert die periodische Erfassung mit einem Abtastintervall ungleich null.
Die relevante Konfiguration ist:
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
Überprüfen der Bezeichnung "Ressourcenpfad"
Führen Sie diesen Befehl aus, um die DME-Pfade zu untersuchen, die durch die Ressourcenpfadbezeichnung dargestellt werden:
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"))
Die Ausgabe zeigt, dass die Ressourcenbezeichnung mehrere zugrunde liegende DME-Pfade darstellt.
Die Pfade sys/proc und sys/procsys verwenden Polling-Abfragen und stellen Informationen zu Prozessen und Systemressourcen bereit. Der Pfad sys/procsys/system verwendet eine Ereignisabfrage, die eine Änderung melden kann, wenn der überwachte Speicherstatus aktualisiert wird und nicht mehr OK ist.
Dies veranschaulicht den Unterschied zwischen der direkten Angabe eines einzelnen DME Distinguished Name und der Verwendung eines vordefinierten Telemetriepfadens.
Beispiele:
Individual DME path:
path sys/intf/phys-[eth1/10]
Predefined path label:
path resources
Systemressourcen-Telemetrie überprüfen
Verwenden Sie show telemetry control database, um den Status von Sensorgruppe 4 und Abonnement 4 zu überprüfen.
Die Sensorgruppen-Datenbank enthält folgende Berichte:
Sensor Group ID Sensor Group type Sampling interval(ms) Linked subscriptions SubID ---------------------------------------------------------------------------------------------------- 4 Timer /DME 10000/Running 1 4
Der Timer-/DME-Typ und das Samplingintervall 10000/Running bestätigen, dass die Sensorgruppe 4 als periodische DME-Telemetriequelle arbeitet.
Die Sensorpfaddatenbank zeigt auch die zugrunde liegenden Pfade an, die der Ressourcenbezeichnung zugeordnet sind.
Beispiele:
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
Über den prozessbezogenen Pfad wird auch eine aktive Telemetriesammlung gemeldet:
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
Diese Leistungsindikatoren bestätigen, dass Ressourceninformationen gesammelt, als GPB codiert und ohne Nachrichtenfehler oder Auslassungen übertragen werden.
Vergleich mit NX-OS-Systemressourcen
Die herkömmliche Kommandozeile von NX-OS kann verwendet werden, um den aktuellen CPU- und Speicherstatus des Switches anzuzeigen:
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
Die CLI bietet eine sofortige Ansicht der Systemressourcen.
Streaming-Telemetrie ermöglicht den Export derselben CPU- und Speicherdaten an einen externen Empfänger, sodass mehrere Stichproben gespeichert und analysiert werden können.
Die CPU-Auslastung kann sich schnell ändern. Aus diesem Grund können die von der CLI angezeigten CPU-Werte und die über Telemetrie empfangenen Werte sich unterscheiden, wenn die Stichproben zu unterschiedlichen Zeiten gesammelt werden.
Ressourcendaten am Empfänger überprüfen
Der Telemetrieempfänger hat die Systemressourceninformationen für Abonnement 4 erfolgreich decodiert.
Dieses Beispiel zeigt CPU- und Speicherinformationen aus einem Telemetriesample:
{
"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
}
}
Die Empfängerausgabe bestätigt, dass CPU- und Speicherinformationen von Subscription 4 erfolgreich decodiert und für externe Überwachung zur Verfügung gestellt werden.
Zum Vergleich: Die CLI von NX-OS meldete ca. 9,3 GB verwendeten Speicher aus ca. 24,5 GB Gesamtspeicher und den aktuellen Speicherstatus "OK". Das Telemetrie-Beispiel zeigt den gleichen Gesamtspeicherwert, eine Speichernutzung von ca. 38 % und den gleichen OK-Speicherstatus an.
Die CPU-Werte können zwischen den CLI- und Telemetriebeispielen variieren, da sich die CPU-Auslastung dynamisch ändert und die Messwerte nicht notwendigerweise zum gleichen Zeitpunkt erfasst werden.
Beobachtung der Ressourcennutzung im Laufe der Zeit
Mithilfe mehrerer Telemetriesampeln kann beobachtet werden, wie sich die Auslastung der Systemressourcen im Laufe der Zeit verändert.
Diese Beispiele wurden während der Übung von Abonnement 4 empfangen:
Durchschnittliche CPU-Auslastung - letzte 60 Sekunden
10% |
9% | ●
8% | ●
7% | ●
6% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
8.70% 8.50% 7.10%
Time
Speichernutzung
39% |
38% | ●-----------●-----------●
37% |
+-------------------------------------
23:14:08 23:14:38 23:15:08
37.82% 38.06% 38.18%
Time
Diese Beispiele veranschaulichen, wie die periodische Telemetrie eine zeitbasierte Ansicht des Systemverhaltens anstelle einer einzigen Momentanmessung liefern kann. In einer Produktionsumgebung kann eine Überwachungs- oder Überwachungsplattform eine größere Anzahl von Stichproben speichern und diese verwenden, um Trends zu identifizieren, Warnungen zu generieren und historische Dashboards zu erstellen.
Schlussfolgerung
Die Cisco NX-OS Streaming-Telemetrie bietet einen strukturierten Mechanismus zum Exportieren von Betriebsinformationen von Cisco Nexus 9000-Switches an einen externen Telemetrie-Empfänger.
In diesem Dokument werden die grundlegenden Komponenten der Streaming-Telemetrie vorgestellt, darunter DME-Sensorpfade, GPB-Codierung, gRPC-Transport, Zielgruppen, Sensorgruppen und Abonnements.
In der Laborumgebung wurden regelmäßige und ereignisbasierte Telemetriedaten konfiguriert und verifiziert. Regelmäßige Abonnements wurden verwendet, um Ethernet1/10-Statistiken und betriebliche Informationen zu erfassen, während ein ereignisbasiertes Abonnement verwendet wurde, um kontrollierte Änderungen an dem Loopback100 Managed Object zu erkennen.
Ein praktisches Beispiel für die Systemressourcenüberwachung zeigte auch, wie die vordefinierte Ressourcenpfadbezeichnung verwendet werden kann, um CPU- und Speicherinformationen in einen externen Telemetrie-Empfänger zu exportieren.
Die Beispiele für Verifizierung und Fehlerbehebung zeigten, wie NX-OS-Telemetriebefehle verwendet werden können, um Transportverbindungen, Datenerfassung, Ereignisverarbeitung und Verlaufserfassungsfehler zu validieren.
Diese Konzepte bilden die Grundlage für das Verständnis, die Implementierung, die Verifizierung und die Fehlerbehebung bei grundlegenden Streaming-Telemetrie-Bereitstellungen auf Cisco Nexus 9000 NX-OS-Geräten.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
01-Oct-2026
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)