Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konfigurieren

Netzwerkdiagramm

Konfigurationen

Schritt 1: Datenbank vorbereiten

Schritt 2: Telegraf vorbereiten

Schritt 3: Telemetrie-Abonnement mit der gewünschten Metrik ermitteln

Schritt 4: Aktivieren von NETCONF auf dem Controller

Schritt 5: Konfigurieren des Telemetrie-Abonnements auf dem Controller

Schritt 6: Grafana-Datenquelle konfigurieren

Schritt 7. Dashboard erstellen

Schritt 8: Hinzufügen einer Visualisierung zum Dashboard

Überprüfung

Konfiguration des WLC wird ausgeführt

Telegraf-Konfiguration

InfluxDB-Konfiguration

Grafana-Konfiguration

Fehlerbehebung

WLC One Stopp Shop Reflex

Netzwerkerreichbarkeit bestätigen

Protokollierung und Debuggen

Erreichbarkeit der Kennzahlen am TIG-Stack

Von InfluxDB CLI

Von Telegraf

Referenzen

Einleitung

In diesem Dokument wird beschrieben, wie der Telegraf-, InfluxDB- und Grafana-Stack (TIG) bereitgestellt und mit dem Catalyst 9800 verbunden wird.

Voraussetzungen

In diesem Dokument werden die programmatischen Schnittstellenkapazitäten des Catalyst 9800 durch eine komplexe Integration beschrieben. Dieses Dokument soll zeigen, wie diese je nach Bedarf vollständig anpassbar sind und tägliche Zeitersparnisse ermöglichen. Die hier gezeigte Bereitstellung stützt sich auf gRPC und präsentiert eine Telemetriekonfiguration, um Wireless-Daten vom Catalyst 9800 in jedem Telegraf-, InfluxDB-, Grafana (TIG) Observability Stack verfügbar zu machen.

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

- Catalyst Wireless 9800-Konfigurationsmodell

- Netzwerkprogrammierbarkeit und Datenmodelle

- TIG-Stapel-Grundlagen.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

- Catalyst 9800-CL (Version 17.12.03)

- Ubuntu (Version 22.04.03)

- InfluxDB (V. 1.06.07).

- Telegraf (V. 1.21.04).

- Grafana (V. 10.2.01).

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.

Konfigurieren

Netzwerkdiagramm

Konfigurationen

In diesem Beispiel wird die Telemetrie auf einem 9800-CL mit gRPC-Dial-Out konfiguriert, um Informationen einer Telegraf-Anwendung, die sie speichert, in eine InfluxDB-Datenbank zu übertragen. Hier wurden zwei Geräte verwendet,

- Ein Ubuntu-Server, der den gesamten TIG-Stack hostet.

- Ein Catalyst 9800-CL

Der Schwerpunkt dieses Konfigurationsleitfadens liegt nicht auf der vollständigen Bereitstellung dieser Geräte, sondern auf den Konfigurationen, die für jede Anwendung erforderlich sind, damit die 9800-Informationen ordnungsgemäß gesendet, empfangen und dargestellt werden.

Schritt 1: Datenbank vorbereiten

Bevor Sie mit dem Konfigurationsteil beginnen, stellen Sie sicher, dass Ihre Influx-Instanz ordnungsgemäß ausgeführt wird. Wenn Sie eine Linux-Distribution verwenden, ist dies mit dem systemctl status Befehl ganz einfach möglich.

admin@tig:~$ systemctl status influxd ● influxdb.service - InfluxDB is an open-source, distributed, time series database Loaded: loaded (/lib/systemd/system/influxdb.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2023-06-14 13:06:18 UTC; 2 weeks 5 days ago Docs: https://docs.influxdata.com/influxdb/ Main PID: 733 (influxd) Tasks: 15 (limit: 19180) Memory: 4.2G CPU: 1h 28min 47.366s CGroup: /system.slice/influxdb.service └─733 /usr/bin/influxd -config /etc/influxdb/influxdb.conf

Damit das Beispiel funktioniert, benötigt Telegraf eine Datenbank, in der die Kennzahlen gespeichert werden, sowie einen Benutzer, der sich mit dieser Datenbank verbindet. Diese können mithilfe der folgenden Befehle auf einfache Weise über die InfluxDB-CLI erstellt werden:

admin@tig:~$ influx Connected to http://localhost:8086 version 1.8.10 InfluxDB shell version: 1.8.10 > create database TELEGRAF > create user telegraf with password 'YOUR_PASSWORD'

Die Datenbank ist nun erstellt, Telegraf kann so konfiguriert werden, dass Metriken darin richtig gespeichert werden.

Schritt 2: Telegraf vorbereiten

Für dieses Beispiel sind nur zwei Telegraf-Konfigurationen interessant. Diese können (wie üblich für unter Unix laufende Anwendungen) aus der /etc/telegraf/telegraf.conf Konfigurationsdatei erstellt werden.

Die erste deklariert die von Telegraf verwendete Ausgabe. Wie bereits erwähnt, wird hier InfluxDB verwendet und wie folgt im Ausgabeabschnitt der telegraf.conf Datei konfiguriert:

############################################################################### # OUTPUT PLUGINS # ############################################################################### # Output Plugin InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. # ## # ## Multiple URLs can be specified for a single cluster, only ONE of the # ## urls will be written to each interval. urls = [ "http://127.0.0.1:8086" ] # ## The target database for metrics; will be created as needed. # ## For UDP url endpoint database needs to be configured on server side. database = "TELEGRAF" # ## HTTP Basic Auth username = "telegraf" password = "YOUR_PASSWORD"

Dies weist den Telegraf-Prozess an, die empfangenen Daten in der InfluxDB zu speichern, die auf demselben Host auf Port 8086 ausgeführt wird, und die Datenbank "TELEGRAF" zu verwenden (sowie die Zugangsdaten telegraf/YOUR_PASSWORD, um darauf zuzugreifen).

Wenn das erste deklarierte Format das Ausgabeformat war, ist das zweite natürlich das Eingabeformat. Um Telegraf mitzuteilen, dass die empfangenen Daten von einem Cisco Gerät stammen, das Telemetrie verwendet, können Sie das Eingabemodul "cisco_telemetry_mdt" verwenden. Um dies zu konfigurieren, müssen Sie der /etc/telegraf/telegraf.conf Datei nur die folgenden Zeilen hinzufügen:

############################################################################### # INPUT PLUGINS # ############################################################################### # # Cisco model-driven telemetry (MDT) input plugin for IOS XR, IOS XE and NX-OS platforms [[inputs.cisco_telemetry_mdt]] # ## Telemetry transport can be "tcp" or "grpc". TLS is only supported when # ## using the grpc transport. transport = "grpc" # # ## Address and port to host telemetry listener service_address = ":57000" # ## Define aliases to map telemetry encoding paths to simple measurement names [inputs.cisco_telemetry_mdt.aliases] ifstats = "ietf-interfaces:interfaces-state/interface/statistics"

Dadurch kann die Telegraf-Anwendung, die auf dem Host (auf dem Standardport 57000) läuft, die vom WLC empfangenen Daten decodieren.

Nachdem Sie die Konfiguration gespeichert haben, starten Sie Telegraf neu, um es auf den Dienst anzuwenden. Stellen Sie außerdem sicher, dass der Dienst ordnungsgemäß neu gestartet wurde:

admin@tig:~$ sudo systemctl restart telegraf admin@tig:~$ systemctl status telegraf.service ● telegraf.service - Telegraf Loaded: loaded (/lib/systemd/system/telegraf.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2023-07-03 17:12:49 UTC; 2min 18s ago Docs: https://github.com/influxdata/telegraf Main PID: 110182 (telegraf) Tasks: 10 (limit: 19180) Memory: 47.6M CPU: 614ms CGroup: /system.slice/telegraf.service └─110182 /usr/bin/telegraf -config /etc/telegraf/telegraf.conf -config-directory /etc/telegraf/telegraf.d

Schritt 3: Telemetrie-Abonnement mit der gewünschten Metrik ermitteln

Wie bereits erwähnt, sind die Kennzahlen auf Cisco Geräten wie auf vielen anderen nach dem YANG-Modell organisiert. Die jeweiligen Cisco YANG-Modelle für jede Version von IOS XE (auf dem 9800 verwendet) finden Sie hier, insbesondere die für IOS XE Dublin 17.12.03 in diesem Beispiel.

In diesem Beispiel konzentrieren wir uns auf die Erfassung von CPU-Nutzungsmetriken der verwendeten 9800-CL-Instanz. Durch die Überprüfung des YANG-Modells für Cisco IOS XE Dublin 17.12.03 kann festgestellt werden, welches Modul die CPU-Auslastung des Controllers enthält, insbesondere für die letzten 5 Sekunden. Diese sind Teil des Moduls Cisco-IOS-XE-process-cpu-oper unter der CPU-Nutzungsgruppierung (Leaf fünf Sekunden).

Schritt 4: Aktivieren von NETCONF auf dem Controller

Das gRPC-Dial-Out-Framework basiert auf NETCONF, um dasselbe zu erreichen. Daher muss diese Funktion auf dem 9800 aktiviert werden. Dies wird durch die folgenden Befehle erreicht:

WLC(config)#netconf ssh WLC(config)#netconf-yang

Schritt 5: Konfigurieren des Telemetrie-Abonnements auf dem Controller

Sobald die XPaths (auch bekannt als XML Paths Language) der Metriken aus dem YANG-Modell ermittelt wurden, kann ein Telemetrie-Abonnement über die 9800-CLI konfiguriert werden, um diese zu der in Schritt 2 konfigurierten Telegraf-Instanz zu streamen. Dazu führen Sie die folgenden Befehle aus:

WLC(config)#telemetry ietf subscription 101 WLC(config-mdt-subs)#encoding encode-kvgpb WLC(config-mdt-subs)#filter xpath /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds WLC(config-mdt-subs)#source-address 10.48.39.130 WLC(config-mdt-subs)#stream yang-push WLC(config-mdt-subs)#update-policy periodic 100 WLC(config-mdt-subs)#receiver ip address 10.48.39.98 57000 protocol grpc-tcp

In diesem Codeblock wird zunächst die Telemetrie-Subskription mit der Kennung 101 definiert. Die Abonnement-ID kann eine beliebige Zahl zwischen <0-2147483647> sein, solange sie sich nicht mit einem anderen Abonnement überschneidet. Für dieses Abonnement werden in der folgenden Reihenfolge konfiguriert:

- Die verwendete Kodierungsmethode, die beim Arbeiten mit dem gRPC-Transportprotokoll kvGPB sein muss.

- Der Filter für die Metriken, die vom Abonnement gesendet werden, ist der XPath, der die Metrik definiert, die uns interessiert (zu wissen, /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds).

- Die Quell-IP-Adresse, die vom Controller zum Senden der Kennzahlen verwendet wird.

- Der Stream-Typ, der zur Kommunikation der Metriken verwendet wird, in diesem Fall YANG Push IETF-Standard.

- Die Frequenz, mit der der Controller Daten in 100stel Sekunden an den Teilnehmer sendet. In diesem Fall wurde sie so konfiguriert, dass sie Updates regelmäßig jede Sekunde sendet.

- Die IP-Adresse und die Port-Nummer des Empfängers sowie das Protokoll, das für die Kommunikation zwischen Controller und Teilnehmer verwendet wird. In diesem Beispiel wird gRPC-TCP verwendet, um eine Metrik an den Host 10.48.39.98 an Port 57000 zu senden.

Schritt 6: Grafana-Datenquelle konfigurieren

Nun, da der Controller beginnt, Daten an Telegraf zu senden und diese in der TELEGRAF InfluxDB-Datenbank gespeichert werden, ist es an der Zeit, Grafana so zu konfigurieren, dass es diese Metriken durchsucht.

Navigieren Sie in der Grafana-GUI zu Home > Connections > Connect data und suchen Sie mithilfe der Suchleiste nach der Datenquelle InfluxDB.

Wählen Sie diesen Datenquellentyp aus und verwenden Sie die Schaltfläche "Eine InfluxDB-Datenquelle erstellen", um Grafana mit der in Schritt 1 erstellten TELEGRAPH-Datenbank zu verbinden.

Füllen Sie das Formular aus, das auf dem Bildschirm angezeigt wird, und stellen Sie insbesondere Folgendes bereit:

- Ein Name für die Datenquelle.

- Die URL der verwendeten InfluxDB-Instanz.

- Der verwendete Datenbankname (in diesem Beispiel TELEGRAF).

- Die Anmeldeinformationen des Benutzers, der für den Zugriff darauf definiert wurde (in diesem Beispiel telegraf/YOUR_PASSWORD).

Schritt 7. Dashboard erstellen

Grafana-Visualisierungen sind in Dashboards organisiert. Um ein Dashboard mit den Metriken des Catalyst 9800 zu erstellen, navigieren Sie zu Home > Dashboards, und drücken Sie auf "New Dashboard" (Neues Dashboard).

Dadurch wird das neu erstellte Dashboard geöffnet. Klicken Sie auf die Zahnradsymbole, um auf den Dashboard-Parameter zuzugreifen und dessen Namen zu ändern. Im Beispiel wird "Catalyst 9800 Telemetrie" verwendet. Anschließend können Sie Ihr Dashboard mit der Schaltfläche "Dashboard speichern" speichern.

Schritt 8: Hinzufügen einer Visualisierung zum Dashboard

Jetzt, da die Daten korrekt gesendet, empfangen und gespeichert werden und Grafana Zugriff auf diesen Speicherort hat, ist es an der Zeit, eine Visualisierung für sie zu erstellen.

Verwenden Sie in jedem Grafana Dashboard die Schaltfläche "Hinzufügen", und wählen Sie im angezeigten Menü "Visualisierung" aus, um eine Visualisierung Ihrer Metriken zu erstellen.

Daraufhin wird der Bearbeitungsbereich der erstellten Visualisierung geöffnet:

Wählen Sie in diesem Bereich

- Der Name der Datenquelle, die Sie in Schritt 6 erstellt haben, in diesem Beispiel TELEGRAF.

- Die Messung (Schema), die die Daten enthält, die Sie visualisieren möchten, "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-usage" in diesem Beispiel.

- Das Feld aus der Datenbank, das die Metriken darstellt, die Sie visualisieren möchten, in diesem Beispiel "five_seconds".

- Der Titel der Visualisierung, "CPU Utilization 9800-CL" in diesem Beispiel.

Sobald Sie die Schaltfläche "Save/Apply" (Speichern/Anwenden) aus der vorherigen Abbildung gedrückt haben, wird die Visualisierung der CPU-Nutzung des Catalyst 9800 Controllers im Laufe der Zeit zum Dashboard hinzugefügt. Die am Dashboard vorgenommenen Änderungen können mithilfe der Diskette gespeichert werden.

Überprüfung

Konfiguration des WLC wird ausgeführt

Building configuration... Current configuration : 112215 bytes ! ! Last configuration change at 14:28:36 UTC Thu May 23 2024 by admin ! NVRAM config last updated at 14:28:23 UTC Thu May 23 2024 by admin ! version 17.12 [...] aaa new-model ! ! aaa authentication login default local aaa authentication login local-auth local aaa authentication dot1x default group radius aaa authorization exec default local aaa authorization network default group radius [...] vlan internal allocation policy ascending ! vlan 39 ! vlan 1413 name VLAN_1413 ! ! interface GigabitEthernet1 switchport access vlan 1413 negotiation auto no mop enabled no mop sysid ! interface GigabitEthernet2 switchport trunk allowed vlan 39,1413 switchport mode trunk negotiation auto no mop enabled no mop sysid ! interface Vlan1 no ip address no ip proxy-arp no mop enabled no mop sysid ! interface Vlan39 ip address 10.48.39.130 255.255.255.0 no ip proxy-arp no mop enabled no mop sysid [...] telemetry ietf subscription 101 encoding encode-kvgpb filter xpath /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization source-address 10.48.39.130 stream yang-push update-policy periodic 1000 receiver ip address 10.48.39.98 57000 protocol grpc-tcp [...] netconf-yang

Telegraf-Konfiguration

# Configuration for telegraf agent [agent] metric_buffer_limit = 10000 collection_jitter = "0s" debug = true quiet = false flush_jitter = "0s" hostname = "" omit_hostname = false ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] urls = ["http://127.0.0.1:8086"] database = "TELEGRAF" username = "telegraf" password = "Wireless123#" ############################################################################### # INPUT PLUGINS # ############################################################################### ############################################################################### # SERVICE INPUT PLUGINS # ############################################################################### # # Cisco model-driven telemetry (MDT) input plugin for IOS XR, IOS XE and NX-OS platforms [[inputs.cisco_telemetry_mdt]] transport = "grpc" service_address = "10.48.39.98:57000" [inputs.cisco_telemetry_mdt.aliases] ifstats = "ietf-interfaces:interfaces-state/interface/statistics"

InfluxDB-Konfiguration

### Welcome to the InfluxDB configuration file. reporting-enabled = false [meta] dir = "/var/lib/influxdb/meta" [data] dir = "/var/lib/influxdb/data" wal-dir = "/var/lib/influxdb/wal" [retention] enabled = true check-interval = "30m"

Grafana-Konfiguration

#################################### Server #################################### [server] http_addr = 10.48.39.98 domain = 10.48.39.98

Fehlerbehebung

WLC One Stopp Shop Reflex

Was den WLC angeht, ist das erste, was überprüft werden muss, dass die mit den Programmierschnittstellen verbundenen Prozesse in Gang sind.

#show platform software yang-management process confd : Running nesd : Running syncfd : Running ncsshd : Running <-- NETCONF / gRPC Dial-Out dmiauthd : Running <-- For all of them, Device Managment Interface needs to be up. nginx : Running <-- RESTCONF ndbmand : Running pubd : Running gnmib : Running <-- gNMI

Bei NETCONF (für gRPC-Dial-Out) kann dieser Befehl auch dabei helfen, den Status des Prozesses zu überprüfen.

WLC#show netconf-yang status netconf-yang: enabled netconf-yang candidate-datastore: disabled netconf-yang side-effect-sync: enabled netconf-yang ssh port: 830 netconf-yang turbocli: disabled netconf-yang ssh hostkey algorithms: rsa-sha2-256,rsa-sha2-512,ssh-rsa netconf-yang ssh encryption algorithms: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes256-cbc netconf-yang ssh MAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1 netconf-yang ssh KEX algorithms: diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group16-sha512

Eine weitere wichtige Prüfung nach Überprüfung des Prozessstatus ist der Status der Telemetrie-Verbindung zwischen dem Catalyst 9800 und dem Telegraf-Empfänger. Sie kann mit dem Befehl "show telemetry connection all" (Telemetriedaten anzeigen) angezeigt werden.

WLC#show telemetry connection all Telemetry connections Index Peer Address Port VRF Source Address State State Description ----- -------------------------- ----- --- -------------------------- ---------- -------------------- 28851 10.48.39.98 57000 0 10.48.39.130 Active Connection up

Wenn die Telemetrieverbindung zwischen dem WLC und dem Empfänger besteht, kann mithilfe des show telemetry ietf subscription all brief Befehls auch sichergestellt werden, dass die konfigurierten Abonnements gültig sind.

WLC#show telemetry ietf subscription all brief ID Type State State Description 101 Configured Valid Subscription validated

Die detaillierte Version dieses Befehls enthält show telemetry ietf subscription all detailweitere Informationen zu Abonnements und kann beim Hinweisen auf ein Problem in der Konfiguration helfen.

WLC#show telemetry ietf subscription all detail Telemetry subscription detail: Subscription ID: 101 Type: Configured State: Valid Stream: yang-push Filter: Filter type: xpath XPath: /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization Update policy: Update Trigger: periodic Period: 1000 Encoding: encode-kvgpb Source VRF: Source Address: 10.48.39.130 Notes: Subscription validated Named Receivers: Name Last State Change State Explanation ------------------------------------------------------------------------------------------------------------------------------------------------------- grpc-tcp://10.48.39.98:57000 05/23/24 08:00:25 Connected

Netzwerkerreichbarkeit bestätigen

Der Catalyst 9800-Controller sendet gRPC-Daten an den für jedes Telemetrie-Abonnement konfigurierten Empfängerport.

WLC#show run | include receiver ip address receiver ip address 10.48.39.98 57000 protocol grpc-tcp

Zur Überprüfung der Netzwerkverbindung zwischen dem WLC und dem Empfänger an diesem konfigurierten Port stehen verschiedene Tools zur Verfügung.

Vom WLC aus kann über Telnet auf dem konfigurierten IP/Port des Empfängers (hier 10.48.39.98:57000) überprüft werden, ob dieser offen ist und vom Controller selbst erreicht werden kann. Wenn der Datenverkehr nicht blockiert wird, muss der Port in der Ausgabe als offen angezeigt werden:

WLC#telnet 10.48.39.98 57000 Trying 10.48.39.98, 57000 ... Open <-------

Alternativ kann Nmap von einem beliebigen Host verwendet werden, um sicherzustellen, dass der Empfänger am konfigurierten Port richtig angezeigt wird.

$ sudo nmap -sU -p 57000 10.48.39.98 Starting Nmap 7.95 ( https://nmap.org ) at 2024-05-17 13:12 CEST Nmap scan report for air-1852e-i-1.cisco.com (10.48.39.98) Host is up (0.020s latency). PORT STATE SERVICE 57000/udp open|filtered unknown Nmap done: 1 IP address (1 host up) scanned in 0.35 seconds

Protokollierung und Debuggen

2024/05/23 14:40:36.566486156 {pubd_R0-0}{2}: [mdt-ctrl] [30214]: (note): **** Event Entry: Configured legacy receiver creation/modification of subscription 101 receiver 'grpc-tcp://10.48.39.98:57000' 2024/05/23 14:40:36.566598609 {pubd_R0-0}{2}: [mdt-ctrl] [30214]: (note): Use count for named receiver 'grpc-tcp://10.48.39.98:57000' set to 46. 2024/05/23 14:40:36.566600301 {pubd_R0-0}{2}: [mdt-ctrl] [30214]: (note): {subscription receiver event='configuration created'} received for subscription 101 receiver 'grpc-tcp://10.48.39.98:57000' [...] 2024/05/23 14:40:36.572402901 {pubd_R0-0}{2}: [pubd] [30214]: (info): Collated data collector filters for subscription 101. 2024/05/23 14:40:36.572405081 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Creating periodic sensor for subscription 101. 2024/05/23 14:40:36.572670046 {pubd_R0-0}{2}: [pubd] [30214]: (info): Creating data collector type 'ei_do periodic' for subscription 101 using filter '/process-cpu-ios-xe-oper:cpu-usage/cpu-utilization'. 2024/05/23 14:40:36.572670761 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Creating crimson data collector for filter '/process-cpu-ios-xe-oper:cpu-usage/cpu-utilization' (1 subfilters) with cap 0x0001. 2024/05/23 14:40:36.572671763 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Need new data collector instance 0 for subfilter '/process-cpu-ios-xe-oper:cpu-usage/cpu-utilization'. 2024/05/23 14:40:36.572675434 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Creating CRIMSON periodic data collector for filter '/process-cpu-ios-xe-oper:cpu-usage/cpu-utilization'. 2024/05/23 14:40:36.572688399 {pubd_R0-0}{2}: [pubd] [30214]: (debug): tree rooted at cpu-usage 2024/05/23 14:40:36.572715384 {pubd_R0-0}{2}: [pubd] [30214]: (debug): last container/list node 0 2024/05/23 14:40:36.572740734 {pubd_R0-0}{2}: [pubd] [30214]: (debug): 1 non leaf children to render from cpu-usage down 2024/05/23 14:40:36.573135594 {pubd_R0-0}{2}: [pubd] [30214]: (debug): URI:/cpu_usage;singleton_id=0 SINGLETON 2024/05/23 14:40:36.573147953 {pubd_R0-0}{2}: [pubd] [30214]: (debug): 0 non leaf children to render from cpu-utilization down 2024/05/23 14:40:36.573159482 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Timer created for subscription 101, sensor 0x62551136f0e8 2024/05/23 14:40:36.573166451 {pubd_R0-0}{2}: [mdt-ctrl] [30214]: (note): {subscription receiver event='receiver connected'} received with peer (10.48.39.98:57000) for subscription 101 receiver 'grpc-tcp://10.48.39.98:57000' 2024/05/23 14:40:36.573197750 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Starting batch from periodic collector 'ei_do periodic'. 2024/05/23 14:40:36.573198408 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Building from the template 2024/05/23 14:40:36.575467870 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Created dbal batch:133, for crimson subscription 2024/05/23 14:40:36.575470867 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Done building from the template 2024/05/23 14:40:36.575481078 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Executing batch:133 for periodic subscription 2024/05/23 14:40:36.575539723 {pubd_R0-0}{2}: [mdt-ctrl] [30214]: (note): {subscription id=101 receiver name='grpc-tcp://10.48.39.98:57000', state='connecting'} handling 'receiver connected' event with result 'e_mdt_rc_ok' 2024/05/23 14:40:36.575558274 {pubd_R0-0}{2}: [mdt-ctrl] [30214]: (note): {subscription receiver event='receiver connected'} subscription 101 receiver 'grpc-tcp://10.48.39.98:57000' changed 2024/05/23 14:40:36.577274757 {ndbmand_R0-0}{2}: [ndbmand] [30690]: (info): get__next_table reached the end of table for /services;serviceName=ewlc_oper/capwap_data@23 2024/05/23 14:40:36.577279206 {ndbmand_R0-0}{2}: [ndbmand] [30690]: (debug): Cleanup table for /services;serviceName=ewlc_oper/capwap_data cursor=0x57672da538b0 2024/05/23 14:40:36.577314397 {ndbmand_R0-0}{2}: [ndbmand] [30690]: (info): get__next_object cp=ewlc-oper-db exit return CONFD_OK 2024/05/23 14:40:36.577326609 {ndbmand_R0-0}{2}: [ndbmand] [30690]: (debug): yield ewlc-oper-db 2024/05/23 14:40:36.579099782 {iosrp_R0-0}{1}: [parser_cmd] [26295]: (note): id= A.B.C.D@vty0:user= cmd: 'receiver ip address 10.48.39.98 57000 protocol grpc-tcp' SUCCESS 2024/05/23 14:40:36.578 UTC 2024/05/23 14:40:36.580979429 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Batch response received for crimson sensor, batch:133 2024/05/23 14:40:36.580988867 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Green response: Result rc 0, Length: 360, num_records 1 2024/05/23 14:40:36.581175013 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Green Resp cursor len 63 2024/05/23 14:40:36.581176173 {pubd_R0-0}{2}: [pubd] [30214]: (debug): There is no more data left to be retrieved from batch 133. 2024/05/23 14:40:36.581504331 {iosrp_R0-0}{2}: [parser_cmd] [24367]: (note): id= 10.227.65.133@vty1:user=admin cmd: 'receiver ip address 10.48.39.98 57000 protocol grpc-tcp' SUCCESS 2024/05/23 14:40:36.553 UTC [...] 2024/05/23 14:40:37.173223406 {pubd_R0-0}{2}: [pubd] [30214]: (info): Added queue (wq: tc_inst 60293411, 101) to be monitored (mqid: 470) 2024/05/23 14:40:37.173226005 {pubd_R0-0}{2}: [pubd] [30214]: (debug): New subscription (subscription 101) monitoring object stored at id 19 2024/05/23 14:40:37.173226315 {pubd_R0-0}{2}: [pubd] [30214]: (note): Added subscription for monitoring (subscription 101, msid 19) 2024/05/23 14:40:37.173230769 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Stats updated for Q (wq: tc_inst 60293411, 101), total_enqueue: 1 2024/05/23 14:40:37.173235969 {pubd_R0-0}{2}: [pubd] [30214]: (debug): (grpc::events) Processing event Q 2024/05/23 14:40:37.173241290 {pubd_R0-0}{2}: [pubd] [30214]: (debug): GRPC telemetry connector update data for subscription 101, period 1 (first: true) 2024/05/23 14:40:37.173257944 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Encoding path is Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization 2024/05/23 14:40:37.173289128 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Creating kvgpb encoder 2024/05/23 14:40:37.173307771 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Creating combined parser 2024/05/23 14:40:37.173310050 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Beginning MDT yang container walk for record 0 2024/05/23 14:40:37.173329761 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Dispatching new container [data_node: name=Cisco-IOS-XE-process-cpu-oper:cpu-usage, type=container, parent=n/a, key=false] 2024/05/23 14:40:37.173334681 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Container 'Cisco-IOS-XE-process-cpu-oper:cpu-usage' started successfully 2024/05/23 14:40:37.173340313 {pubd_R0-0}{2}: [pubd] [30214]: (debug): add data in progress 2024/05/23 14:40:37.173343079 {pubd_R0-0}{2}: [pubd] [30214]: (debug): GRPC telemetry connector continue data for subscription 101, period 1 (first: true) 2024/05/23 14:40:37.173345689 {pubd_R0-0}{2}: [pubd] [30214]: (debug): (grpc::events) Processing event Q 2024/05/23 14:40:37.173350431 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Dispatching new container [data_node: name=cpu-utilization, type=container, parent=Cisco-IOS-XE-process-cpu-oper:cpu-usage, key=false] 2024/05/23 14:40:37.173353194 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Deferred container cpu-utilization 2024/05/23 14:40:37.173355275 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Container 'cpu-utilization' started successfully 2024/05/23 14:40:37.173380121 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Dispatching new leaf [name=five-seconds, value=3, parent=cpu-utilization, key=false] 2024/05/23 14:40:37.173390655 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Leaf 'five-seconds' added successfully 2024/05/23 14:40:37.173393529 {pubd_R0-0}{2}: [pubd] [30214]: (debug): add data in progress 2024/05/23 14:40:37.173395693 {pubd_R0-0}{2}: [pubd] [30214]: (debug): GRPC telemetry connector continue data for subscription 101, period 1 (first: true) 2024/05/23 14:40:37.173397974 {pubd_R0-0}{2}: [pubd] [30214]: (debug): (grpc::events) Processing event Q 2024/05/23 14:40:37.173406311 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Dispatching new leaf [name=five-seconds-intr, value=0, parent=cpu-utilization, key=false] 2024/05/23 14:40:37.173408937 {pubd_R0-0}{2}: [pubd] [30214]: (debug): Leaf 'five-seconds-intr' added successfully 2024/05/23 14:40:37.173411575 {pubd_R0-0}{2}: [pubd] [30214]: (debug): add data in progress [...]

Erreichbarkeit der Kennzahlen am TIG-Stack

Von InfluxDB CLI

Wie jedes andere Datenbanksystem verfügt auch InfluxDB über eine Kommandozeile, mit der sich überprüfen lässt, ob Metriken von Telegraf korrekt empfangen und in der definierten Datenbank gespeichert werden. InfluxDB organisiert Metriken, so genannte Punkte, in Messungen, die selbst als Serie organisiert sind. Einige der hier vorgestellten Grundbefehle können verwendet werden, um das Datenschema auf InfluxDB-Seite zu überprüfen und sicherzustellen, dass die Daten diese Anwendung erreichen.

Zunächst können Sie überprüfen, ob die Reihen, Messungen und ihre Struktur (Schlüssel) korrekt generiert werden. Diese werden automatisch von Telegraf und InfluxDB generiert, basierend auf der Struktur des verwendeten RPC.

Hinweis: Diese Struktur kann natürlich vollständig über die Konfigurationen Telegraf und InfluxDB angepasst werden. Dies geht jedoch über den Rahmen dieses Konfigurationsleitfadens hinaus.

$ influx Connected to http://localhost:8086 version 1.6.7~rc0 InfluxDB shell version: 1.6.7~rc0 > USE TELEGRAF Using database TELEGRAF > SHOW SERIES key --- Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization,host=ubuntu-virtual-machine,path=Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization,source=WLC,subscription=101 > SHOW MEASUREMENTS name: measurements name ---- Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization > SHOW FIELD KEYS FROM "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization" name: Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization fieldKey fieldType -------- --------- cpu_usage_processes/cpu_usage_process/avg_run_time integer cpu_usage_processes/cpu_usage_process/five_minutes float cpu_usage_processes/cpu_usage_process/five_seconds float cpu_usage_processes/cpu_usage_process/invocation_count integer cpu_usage_processes/cpu_usage_process/name string cpu_usage_processes/cpu_usage_process/one_minute float cpu_usage_processes/cpu_usage_process/pid integer cpu_usage_processes/cpu_usage_process/total_run_time integer cpu_usage_processes/cpu_usage_process/tty integer five_minutes integer five_seconds integer five_seconds_intr integer one_minute integer

Sobald die Datenstruktur geklärt ist (Integer, String, boolean, ...), kann man die Anzahl der Datenpunkte, die auf diesen Messungen gespeichert werden, basierend auf einem bestimmten Feld abrufen.

# Get the number of points from "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization" for the field "five_seconds". > SELECT COUNT(five_seconds) FROM "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization" name: Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization time count ---- ----- 0 1170 > SELECT COUNT(five_seconds) FROM "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization" name: Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization time count ---- ----- 0 1171 # Fix timestamp display > precision rfc3339 # Get the last point stored in "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization" for the field "five_seconds". > SELECT LAST(five_seconds) FROM "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization" name: Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization time last ---- ---- 2024-05-23T13:18:53.51Z 0 > SELECT LAST(five_seconds) FROM "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization" name: Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-utilization time last ---- ---- 2024-05-23T13:19:03.589Z 2

Wenn die Anzahl der Punkte für ein bestimmtes Feld und der Zeitstempel für den letzten Vorfall ansteigen, ist es ein gutes Zeichen, dass der TIG-Stapel die vom WLC gesendeten Daten korrekt empfängt und speichert.

Von Telegraf

Um zu überprüfen, ob der Telegraf-Empfänger tatsächlich Metriken vom Controller erhält und deren Format überprüft, können Sie die Telegraf-Metriken in eine Ausgabedatei auf dem Host umleiten. Dies kann sehr praktisch sein, wenn es um die Fehlerbehebung bei Geräteverbindungen geht. Um dies zu erreichen, benutzen Sie einfach das "Datei"-Ausgabemodul von Telegraf, konfigurierbar von der /etc/telegraf/telegraf.conf.

# Send telegraf metrics to file(s) [[outputs.file]] # ## Files to write to, "stdout" is a specially handled file. files = ["stdout", "/tmp/metrics.out", "other/path/to/the/file"] # # ## Use batch serialization format instead of line based delimiting. The # ## batch format allows for the production of non line based output formats and # ## may more efficiently encode metric groups. # # use_batch_format = false # # ## The file will be rotated after the time interval specified. When set # ## to 0 no time based rotation is performed. # # rotation_interval = "0d" # # ## The logfile will be rotated when it becomes larger than the specified # ## size. When set to 0 no size based rotation is performed. # # rotation_max_size = "0MB" # # ## Maximum number of rotated archives to keep, any older logs are deleted. # ## If set to -1, no archives are removed. # # rotation_max_archives = 5 # # ## Data format to output. # ## Each data format has its own unique set of configuration options, read # ## more about them here: # ## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_OUTPUT.md data_format = "influx"

Referenzen

Richtlinien zur Hardware-Bedarfsbestimmung

Grafana-Anforderungen