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, il protocollo RPC-TCP viene usato 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