Configureer geavanceerde gRPC Workflow met Telegraf, InfluxDB en Grafana op Catalyst 9800

Inleiding

Dit document beschrijft hoe de Telegraf-, InfluxDB- en Grafana (TIG)-stack moet worden geïmplementeerd en hoe deze met Catalyst 9800 moet worden verbonden.

Voorwaarden

Dit document toont de programmatische interfacemogelijkheden van Catalyst 9800 aan via een complexe integratie. Dit document is bedoeld om te laten zien hoe deze volledig aanpasbaar kunnen zijn op basis van elke behoefte en dagelijkse tijdsbesparende factoren zijn. De hier getoonde implementatie is afhankelijk van gRPC en presenteert telemetrieconfiguratie om draadloze gegevens van de Catalyst 9800 beschikbaar te maken in elke Telegraf, InfluxDB, Grafana (TIG) waarnemingsstack.

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Catalyst draadloze 9800 configuratiemodel. 
• Netwerkprogrammeerbaarheid en gegevensmodellen.
• TIG-stackbasis.
• 9800 WLC met Cisco IOS-XE 17.6 of een nieuwere release.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Catalyst 9800-CL (v. 17.12.03).
• Ubuntu (v. 22.04.03).
• InfluxDB (v. 1.06.07).
• Telegraf (v. 1.21.04).
• Grafana (v. 10.02.01).

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Configureren

Netwerkdiagram

Configuraties

In dit voorbeeld is telemetrie geconfigureerd op een 9800-CL met behulp van gRPC-uitbellen om informatie over een Telegraf-applicatie te drukken die ze opslaat in een InfluxDB-database. Hier werden twee apparaten gebruikt,

• Een Ubuntu-server die de hele TIG-stack host.
• Een Catalyst 9800-CL switch.

Deze configuratiegids richt zich niet op de gehele implementatie van deze apparaten, maar eerder op de configuraties die vereist zijn voor elke toepassing voor de 9800 informatie die moet worden verzonden, ontvangen en op de juiste manier gepresenteerd.

Stap 1. De database voorbereiden

Alvorens in het configuratiedeel te gaan, zorg ervoor dat uw instantie van de Influx behoorlijk loopt. Dit kan eenvoudig worden gedaan met de systemctl status opdracht, als u een Linux-distributie gebruikt.

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

In het voorbeeld om te werken, heeft Telegraf een database nodig om de metriek op te slaan en een gebruiker om verbinding te maken met deze. Deze kunnen gemakkelijk worden gemaakt van de InfluxDB CLI, met behulp van deze opdrachten:

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'

De database die nu gecreëerd is, Telegraf kan geconfigureerd worden om metriek er goed in op te slaan.

Stap 2. Bereid Telegraf voor

Slechts twee Telegraf configuraties zijn interessant voor dit voorbeeld om te werken. Deze kunnen (zoals gebruikelijk voor toepassingen die op Unix lopen) van het /etc/telegraf/telegraf.conf configuratiebestand worden gemaakt.

De eerste declareert de output die door Telegraf wordt gebruikt. Zoals eerder vermeld, wordt InfluxDB hier gebruikt en wordt als volgt geconfigureerd in het uitvoergedeelte van het telegraf.conf bestand:

###############################################################################
#                            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"

Dit instrueert het Telegraf proces om de gegevens op te slaan die het ontvangt in de InfluxDB die op dezelfde host op poort 8086 loopt en om de database genaamd "TELEGRAF" (evenals de referenties telegraf/YOU_PASSWORD om toegang te krijgen tot het) te gebruiken.

Als het eerste opgegeven ding het uitvoerformaat was, is het tweede natuurlijk de input. Om Telegraf te informeren dat de gegevens die het ontvangt, van een Cisco-apparaat komen via telemetrie, kunt u de inputmodule van cisco_telemetry_mdt" gebruiken. Om dit te configureren hoeft u alleen deze regels in het /etc/telegraf/telegraf.conf bestand toe te voegen:

###############################################################################
#                             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"

Hierdoor kan de Telegraf-toepassing op de host (op standaardpoort 57000) de ontvangen gegevens die uit de WLC komen, decoderen.

Nadat de configuratie is opgeslagen, moet u Telegraf opnieuw opstarten om het toe te passen op de service. Zorg ervoor dat de service opnieuw op de juiste manier wordt gestart:

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

Stap 3. Bepaal het telemetrieabonnement dat de gewenste metriek bevat

Zoals vermeld zijn op Cisco-apparaten, zoals op vele andere, statistieken georganiseerd volgens het YANG-model. De specifieke Cisco YANG-modellen voor elke versie van IOS XE (gebruikt op de 9800) kunnen hier worden gevonden, in het bijzonder de modellen voor IOS XE Dublin 17.12.03 die in dit voorbeeld worden gebruikt.

In dit voorbeeld richten we ons op het verzamelen van CPU-gebruiksgegevens van de gebruikte 9800-CL-instantie. Door het YANG-model voor Cisco IOS XE Dublin 17.12.03 te inspecteren, kan worden bepaald welke module het CPU-gebruik van de controller bevat, en met name voor de laatste 5 seconden. Deze maken deel uit van de Cisco-IOS-XE-process-cpu-oper module, onder de CPU-benuttingsgroep (blad vijf seconden).

Stap 4. Schakel NETCONF in op de controller

Het uitbel-framework van de gRPC is afhankelijk van NETCONF om hetzelfde te werken. Daarom moet deze optie worden ingeschakeld op de 9800. Dit wordt bereikt door deze opdrachten uit te voeren:

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

Stap 5. Configureer het telemetrieabonnement op de controller

Zodra de XPaths (ook bekend als XML Paths Language) van de maatstaven bepaald vanuit het YANG-model, kan een telemetrieabonnement eenvoudig geconfigureerd worden vanaf de 9800 CLI om te beginnen met het streamen van deze naar de Telegraf-instantie geconfigureerd in Stap 2. Dit gebeurt door deze opdrachten uit te voeren:

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 dit codeblok wordt eerst het telemetrieabonnement met identificatiecode 101 gedefinieerd. De abonnementsidentificator kan elk getal tussen <0-2147483647> zijn zolang het niet overlapt met een ander abonnement. Voor dit abonnement worden de volgende instellingen in deze volgorde uitgevoerd:

• De gebruikte coderingsmethode, die kvGPB moet zijn bij het werken met het gRPC transportprotocol.
• De filter voor de metriek die door het abonnement wordt verzonden, die XPath het metrische interessante ons (te weten, /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds) bepalen.
• Het IP-bronadres dat door de controller wordt gebruikt om de gegevens te verzenden.
• Het stroomtype dat wordt gebruikt om de metriek over te brengen, in dit geval YANG Push IETF-standaard.
• De frequentie die door de controller wordt gebruikt om gegevens naar de abonnee te verzenden in 100^e van seconden. In dit geval, werd het gevormd om update periodiek om de seconde te verzenden.
• Het IP-adres van de ontvanger, het poortnummer en het protocol dat wordt gebruikt voor de communicatie tussen de controller en de abonnee. In dit voorbeeld, gRPC-TCPwordt gebruikt om metriek naar host 10.48.39.98 op poort 57000 te verzenden.

Stap 6. Grafana-gegevensbron configureren

Nu de controller begint met het verzenden van gegevens naar Telegraf en dat deze worden opgeslagen in de Telegraf InfluxDB database, is het tijd om Grafana te configureren om deze gegevens te laten doorbladeren.

Ga vanuit uw Grafana GUI naar Home > Verbindingen > Verbind gegevens en gebruik de zoekbalk om de InfluxDB-gegevensbron te vinden.

Selecteer dit gegevensbrontype en gebruik de knop "Een InfluxDB-gegevensbron maken" om Grafana en de TELEGRAPH-database die bij Stap 1 is gemaakt, aan te sluiten.

Vul het formulier in dat op het scherm verschijnt en specificeer:

• Een naam voor de gegevensbron.
• De URL van de gebruikte InfluxDB-instantie.
• De gebruikte databasenaam (in dit voorbeeld "TELEGRAF").
• De referenties van de gebruiker gedefinieerd om toegang te krijgen (in dit voorbeeld telegraf/YOU_PASSWORD).

Stap 7. Een Dashboard maken

Grafana visualisaties zijn georganiseerd in Dashboards. Om een dashboard te maken met de Catalyst 9800 metriek visualisaties, navigeer naar Home > Dashboards en gebruik de "New dashboard" knop

Hierdoor wordt het nieuwe dashboard geopend. Klik op de versnellingspictogrammen om toegang te krijgen tot de dashboardparameter en de naam ervan te wijzigen. In het voorbeeld wordt "Catalyst 9800 Telemetry" gebruikt. Als dit is uitgevoerd, gebruikt u de knop "dashboard opslaan" om uw dashboard op te slaan.

Stap 8. Voeg een visualisatie toe aan het Dashboard

Nu gegevens op de juiste manier worden verzonden, ontvangen en opgeslagen en Grafana toegang heeft tot deze opslaglocatie, is het tijd om een visualisatie voor hen te maken.

Gebruik vanuit een Grafana-dashboard de knop "Toevoegen" en selecteer "Visualisatie" in het menu dat verschijnt om een visualisatie van uw parameters te creëren.

Dit opent het Bewerken paneel van de gemaakte visualisatie:

Selecteer vanuit dit paneel

• De naam van de gegevensbron die u in Stap 6 hebt gemaakt, TELEGRAF in dit voorbeeld.
• De meting (schema) die de gegevens bevat die u wilt visualiseren, "Cisco-IOS-XE-process-cpu-oper:cpu-use/cpu-use" in dit voorbeeld.
• Het veld uit de database die de waarden weergeeft die je wil visualiseren, "five_seconden" in dit voorbeeld.
• De titel van de visualisatie, "CPU Utilization 9800-CL" in dit voorbeeld.

Zodra de knop "Opslaan/Toepassen" van de vorige afbeelding is ingedrukt, wordt de visualisatie die het CPU-gebruik van de Catalyst 9800 controller in de loop der tijd weergeeft, aan het dashboard toegevoegd. De wijzigingen in het dashboard kunnen worden opgeslagen met behulp van de knop voor het diskette-pictogram.

Verifiëren

WLC-hardloopconfiguratie

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

Configuratie Telegraf

# 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"

Configuratie InfluxDB

### 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-configuratie

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

Problemen oplossen

WLC One Stop-Shop Reflex

Van de kant WLC, is het allereerste te verifiëren ding dat de processen met betrekking tot programmatische interfaces in gebruik zijn.

#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 

Voor NETCONF (gebruikt bij de gRPC-uitbellen) kunnen deze opdrachten ook helpen bij het controleren van de status van het proces.

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

Zodra de processtatus is gecontroleerd, is een andere belangrijke controle de status van de telemetrieverbinding tussen Catalyst 9800 en de Telegraf-ontvanger. Het kan worden bekeken met de opdracht "show telemetry connection all".

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       

Als de telemetrieverbinding tussen WLC en de ontvanger omhoog is, kan men ook verzekeren dat de gevormde abonnementen geldig zijn met behulp van het show telemetry ietf subscription all brief bevel.

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

De gedetailleerde versie van deze opdracht show telemetry ietf subscription all detail, biedt meer informatie over abonnementen en kan u helpen om een probleem te signaleren vanuit de configuratie.

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                                                                           

Netwerkbereikbaarheid bevestigen

De Catalyst 9800 controller verzendt gRPC-gegevens naar de ontvangerpoort die voor elk telemetrieabonnement is geconfigureerd.

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

Om de netwerkconnectiviteit tussen WLC en de ontvanger op deze gevormde haven te verifiëren, zijn verscheidene hulpmiddelen beschikbaar.

Van WLC, kan men telnet op de gevormde ontvanger IP/port (hier 10.48.39.98:57000) gebruiken om te verifiëren dat deze open en bereikbaar van het controlemechanisme zelf is. Als er geen verkeer wordt geblokkeerd, moet de poort als open worden weergegeven in de uitvoer:

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

U kunt ook Nmap van elke host gebruiken om er zeker van te zijn dat de ontvanger goed wordt blootgesteld aan de geconfigureerde poort.

$ 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

Vastlegging en foutopsporing

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
[...]

Zorg ervoor dat de TIG-stack binnen bereik is

Van InfluxDB CLI

Net als elk ander databasesysteem wordt InfluxDB geleverd met een CLI die kan worden gebruikt om te controleren of de metriek correct door Telegraf worden ontvangen en in de gedefinieerde database worden opgeslagen. InfluxDB organiseert metriek, zogenaamde punten, in metingen die zelf als serie worden georganiseerd. Sommige basiscommando's die hier gepresenteerd worden kunnen gebruikt worden om het dataschema aan InfluxDB kant te verifiëren en ervoor te zorgen dat gegevens deze toepassing bereiken.

Eerst kunt u controleren of de serie, metingen en hun structuur (toetsen) correct worden gegenereerd. Deze worden automatisch gegenereerd door Telegraf en InfluxDB op basis van de structuur van de gebruikte RPC.

Opmerking: Uiteraard is deze structuur volledig aanpasbaar vanuit de Telegraf en InfluxDB configuraties. Echter, dit gaat achter het bereik van deze configuratie gids.

$ 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

Zodra de datastructuur is opgehelderd (integer, string, boolean, ...), kan men het aantal datapunten dat is opgeslagen op basis van deze metingen krijgen voor een bepaald veld.

# 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

Als het aantal punten voor een bepaald veld en de tijdstempel voor de laatste keer dat er iets gebeurt, toeneemt, is het een goed teken dat de TIG-stack de door de WLC verzonden gegevens op de juiste manier ontvangt en opslaat.

Van Telegraf

Om te verifiëren dat de Telegraf-ontvanger daadwerkelijk enkele metriek van de controller krijgt en hun formaat controleert, kunt u de Telegraf-metriek omleiden naar een uitvoerbestand op de host. Dit kan zeer handig zijn wanneer het gaat om het oplossen van problemen met de onderlinge verbinding van apparaten. Om dit te bereiken, maak gebruik van de "bestand" uitvoer plugin van Telegraf, configureerbaar vanuit de /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"

Referenties

Richtlijnen voor hardwaregrootte

Grafana requirements