Configurazione del flusso di lavoro RPC avanzato con Telegraf, InfluxDB e Grafana su Catalyst 9800

Introduzione

In questo documento viene descritto come implementare lo stack Telegraf, InfluxDB e Grafana (TIG) e interconnetterlo con Catalyst 9800.

Prerequisiti

Questo documento dimostra le capacità delle interfacce programmatiche di Catalyst 9800 tramite un'integrazione complessa. Questo documento ha lo scopo di mostrare come queste possano essere completamente personalizzabili in base alle esigenze e come risparmiatori di tempo quotidiani. L'implementazione qui presentata si basa su gRPC e presenta una configurazione di telemetria per rendere disponibili i dati wireless di Catalyst 9800 in qualsiasi stack di osservabilità Telegraf, InfluxDB, Grafana (TIG).

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Catalyst Wireless 9800 modello di configurazione. 
• Programmabilità della rete e modelli di dati.
• Nozioni di base sullo stack TIG.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• 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).

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Configurazione

Esempio di rete

Configurazioni

In questo esempio, la telemetria è configurata su un 9800-CL utilizzando la connessione remota gRPC per inviare informazioni su un'applicazione Telegraf memorizzandole in un database InfluxDB. In questo caso sono stati utilizzati due dispositivi,

• Server Ubuntu che ospita l'intero stack TIG.
• Catalyst 9800-CL.

Questa guida alla configurazione non si concentra sull'intera implementazione di questi dispositivi, ma piuttosto sulle configurazioni richieste su ciascuna applicazione per l'invio, la ricezione e la corretta presentazione delle informazioni relative allo switch 9800.

Passaggio 1. Preparare il database

Prima di passare alla parte di configurazione, verificare che l'istanza di Influx funzioni correttamente. A tale scopo, è possibile utilizzare il systemctl status comando, se si utilizza una distribuzione Linux.

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

Affinché l'esempio funzioni, Telegraf necessita di un database per memorizzare le metriche e di un utente per connettersi a questo database. Questi possono essere creati facilmente dalla CLI di InfluxDB, utilizzando i seguenti comandi:

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'

È ora possibile configurare Telegraf per archiviare correttamente le metriche nel database creato.

Passaggio 2. Prepara Telegraf

Solo due configurazioni Telegraf sono interessanti perché questo esempio funzioni. Queste possono essere eseguite (come di consueto per le applicazioni in esecuzione su Unix) dal file di /etc/telegraf/telegraf.conf configurazione.

Il primo dichiara l'output utilizzato da Telegraf. Come accennato in precedenza, InfluxDB viene utilizzato qui e configurato nella sezione di output del telegraf.conf file come segue:

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

In questo modo il processo Telegraf memorizza i dati ricevuti nel database InfluxDB in esecuzione sullo stesso host sulla porta 8086 e utilizza il database denominato "TELEGRAF" (nonché le credenziali telegraf/YOUR_PASSWORD per accedervi).

Se la prima cosa dichiarata era il formato di output, la seconda è, ovviamente, quella di input. Per informare Telegraf che i dati ricevuti provengono da un dispositivo Cisco tramite telemetria, è possibile utilizzare il modulo di input cisco_telemetry_mdt". Per configurare questa opzione, è sufficiente aggiungere le righe seguenti nel /etc/telegraf/telegraf.conf file:

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

In questo modo, l'applicazione Telegraf in esecuzione sull'host (sulla porta predefinita 5700) può decodificare i dati ricevuti dal WLC.

Una volta salvata la configurazione, riavviare Telegraf per applicarla al servizio. Verificare inoltre che il servizio sia stato riavviato correttamente:

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

Passaggio 3. Determinare la sottoscrizione di telemetria contenente la metrica desiderata

Come accennato, sui dispositivi Cisco come su molti altri, le metriche sono organizzate secondo il modello YANG. Qui sono riportati i modelli Cisco YANG specifici per ciascuna versione di IOS XE (utilizzata sul modello 9800), in particolare quello per IOS XE Dublino 17.12.03 utilizzato in questo esempio.

In questo esempio, l'attenzione è rivolta alla raccolta delle metriche di utilizzo della CPU dall'istanza 9800-CL utilizzata. Esaminando il modello YANG per Cisco IOS XE Dublin 17.12.03, è possibile determinare quale modulo contiene l'utilizzo della CPU del controller, in particolare per gli ultimi 5 secondi. Questi fanno parte del modulo Cisco-IOS-XE-process-cpu-oper, con il raggruppamento cpu-usage (cinque secondi foglia).

Passaggio 4. Abilitare NETCONF sul controller

Il funzionamento del framework di chiamata in uscita gRPC è garantito da NETCONF. Pertanto, questa funzione deve essere abilitata sul modello 9800 e ciò si ottiene eseguendo i seguenti comandi:

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

Passaggio 5. Configurare la sottoscrizione di telemetria nel controller

Una volta che gli XPath (a.k.a, XML Paths Language) delle metriche sono stati determinati dal modello YANG, è possibile configurare facilmente una sottoscrizione di telemetria dalla CLI 9800 per avviare lo streaming di queste metriche sull'istanza Telegraf configurata nel passo 2. A tale scopo, eseguire i comandi seguenti:

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 questo blocco di codice viene innanzitutto definita la sottoscrizione di telemetria con identificatore 101. L'identificatore della sottoscrizione può essere un numero qualsiasi compreso tra <0-2147483647> a condizione che non si sovrapponga a un'altra sottoscrizione. Per questa sottoscrizione sono configurati nell'ordine seguente:

• Metodo di codifica utilizzato, che deve essere kvGPB quando si utilizza il protocollo di trasporto gRPC.
• Il filtro per le metriche inviate dalla sottoscrizione, ovvero l'espressione XPath che definisce la metrica che ci interessa (per conoscere, /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds).
• Indirizzo IP di origine utilizzato dal controller per inviare le metriche.
• Il tipo di flusso utilizzato per comunicare le metriche, in questo caso YANG Push IETF standard.
• Frequenza utilizzata dal controller per inviare dati al sottoscrittore in 100^esimo di secondi. In questo caso, è stato configurato per l'invio periodico di aggiornamenti ogni secondo.
• L'indirizzo IP e il numero di porta del ricevitore, nonché il protocollo utilizzato per la comunicazione tra il controller e il sottoscrittore. Nell'esempio, gRPC-TCPviene utilizzato per inviare la metrica all'host 10.48.39.98 sulla porta 5700.

Passaggio 6. Configura origine dati Grafana

Ora che il controller inizia a inviare i dati a Telegraf e che questi sono memorizzati nel database TELEGRAF InfluxDB, è necessario configurare Grafana in modo che visualizzi queste metriche.

Dalla GUI di Grafana, selezionare Home > Connessioni > Connetti dati e utilizzare la barra di ricerca per trovare l'origine dati InfluxDB.

Selezionare questo tipo di origine dati e utilizzare il pulsante "Create a InfluxDB data source" (Crea origine dati InfluxDB) per collegare Grafana e il database TELEGRAPH creato al punto 1.

Compilare il modulo visualizzato sullo schermo, in particolare fornire:

• Nome dell'origine dati.
• URL dell'istanza InfluxDB utilizzata.
• Il nome del database utilizzato (in questo esempio, "TELEGRAF").
• Credenziale dell'utente definito per l'accesso (in questo esempio, telegraf/YOUR_PASSWORD).

Passaggio 7. Creare un dashboard

Le visualizzazioni Grafana sono organizzate in dashboard. Per creare un dashboard contenente le visualizzazioni delle metriche di Catalyst 9800, passare a Home > Dashboard e utilizzare il pulsante "Nuovo dashboard"

Verrà aperto il nuovo dashboard creato. Fate clic sulle icone degli ingranaggi per accedere al parametro del quadro comandi e modificarne il nome. Nell'esempio, viene usato "Catalyst 9800 Telemetry". Una volta eseguita questa operazione, utilizzare il pulsante "Salva dashboard" per salvare il dashboard.

Passaggio 8. Aggiungere un effetto grafico al dashboard

Ora che i dati sono inviati, ricevuti e memorizzati correttamente e che Grafana ha accesso a questo percorso di archiviazione, è il momento di creare una visualizzazione per loro.

Da qualsiasi dashboard Grafana, utilizzare il pulsante "Aggiungi" e selezionare "Visualizzazione" dal menu visualizzato per creare una visualizzazione delle metriche.

 

Verrà aperto il pannello Modifica della visualizzazione creata:

Da questo pannello, selezionare

• Il nome dell'origine dati creata nel passaggio 6, TELEGRAF in questo esempio.
• La misura (schema) contenente i dati che si desidera visualizzare, "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-usage" in questo esempio.
• Il campo del database che rappresenta le metriche che si desidera visualizzare, "five_seconds" in questo esempio.
• Il titolo della visualizzazione, "Utilizzo CPU 9800-CL" in questo esempio.

Dopo aver premuto il pulsante "Save/Apply" (Salva/Applica) nella figura precedente, al dashboard viene aggiunta la visualizzazione che mostra l'utilizzo della CPU del controller Catalyst 9800 nel tempo. Le modifiche apportate al dashboard possono essere salvate utilizzando il pulsante dell'icona del disco floppy.

Verifica

Configurazione in esecuzione WLC

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

Configurazione di 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"

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

Configurazione di Grafana

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

Risoluzione dei problemi

WLC One Stop-Shop Reflex

Dal lato WLC, la prima cosa da verificare è che i processi relativi alle interfacce programmatiche siano attivi e in esecuzione.

#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 

Per NETCONF (utilizzato dalla chiamata in uscita gRPC), questi comandi consentono anche di controllare lo stato del processo.

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

Una volta verificato lo stato del processo, un altro controllo importante è lo stato della connessione telemetrica tra Catalyst 9800 e il ricevitore Telegraf. Può essere visualizzato con il comando "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       

Se la connessione di telemetria è attiva tra il WLC e il destinatario, è possibile anche verificare che le sottoscrizioni configurate siano valide utilizzando il show telemetry ietf subscription all brief comando.

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

La versione dettagliata di questo comando, show telemetry ietf subscription all detail, fornisce ulteriori informazioni sulle sottoscrizioni e può aiutare a segnalare un problema dalla sua configurazione.

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                                                                           

Conferma raggiungibilità della rete

Il controller Catalyst 9800 invia i dati gRPC alla porta ricevitore configurata per ciascuna sottoscrizione di telemetria.

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

Per verificare la connettività di rete tra il WLC e il ricevitore su questa porta configurata, sono disponibili diversi strumenti.

Dal WLC, è possibile usare telnet sulla porta IP/porta del ricevitore configurata (qui 10.48.39.98:57000) per verificare che questa sia aperta e raggiungibile dal controller stesso. Se il traffico non viene bloccato, la porta deve apparire come aperta nell'output:

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

In alternativa, è possibile usare Nmap da qualsiasi host per assicurarsi che il ricevitore sia esposto correttamente sulla porta configurata.

$ 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

Registrazione e debug

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

Verifica del raggiungimento dello stack TIG da parte delle metriche

Dalla CLI di InfluxDB

Come qualsiasi altro sistema di database, InfluxDB è dotato di una CLI che può essere utilizzata per verificare che le metriche siano ricevute correttamente da Telegraf e memorizzate nel database definito. InfluxDB organizza le metriche, dette punti, in misure organizzate a loro volta in serie. Alcuni comandi di base qui presentati possono essere utilizzati per verificare lo schema di dati sul lato InfluxDB e assicurarsi che i dati raggiungano questa applicazione.

Innanzitutto, è possibile verificare che le serie, le misure e la relativa struttura (chiavi) siano generate correttamente. Questi vengono generati automaticamente da Telegraf e InfluxDB in base alla struttura della RPC utilizzata.

$ 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

Una volta chiarita la struttura dei dati (integer, string, boolean, ...), è possibile ottenere il numero di coordinate memorizzate in queste misurazioni in base a un campo specifico.

# 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

Se il numero di punti per un particolare campo e il timestamp per l'ultima occorrenza aumentano, è buona norma che lo stack TIG riceva e memorizzi correttamente i dati inviati dal WLC.

Da Telegraf

Per verificare che il ricevitore Telegraf riceva effettivamente alcune metriche dal controller e ne controlli il formato, è possibile reindirizzare le metriche Telegraf a un file di output sull'host. Questa funzionalità è molto utile quando si tratta di risolvere problemi di interconnessione dei dispositivi. Per ottenere questo, è sufficiente utilizzare il plug-in di output "file" da Telegraf, configurabile da /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"

Riferimenti

Linee guida per il dimensionamento dell'hardware

Requisiti Grafana