Konfigurieren des erweiterten gRPC-Workflows mit Telegraf, InfluxDB und Grafana auf Catalyst 9800

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, können Sie dies auf einfache Weise mit dem systemctl status Befehl tun.

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 im Ausgabeteil der telegraf.conf Datei wie folgt 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 100^stel 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 ist gRPC-TCPwird verwendet, um eine Metrik an den Host 10.48.39.98 auf 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 der Catalyst Serie 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 auch sichergestellt werden, dass die konfigurierten Abonnements mit dem show telemetry ietf subscription all brief Befehl 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.

$ 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