Configurar o fluxo de trabalho gRPC avançado com Telegraf, InfluxDB e Grafana no Catalyst 9800

Introdução

Este documento descreve como implantar a pilha Telegraf, InfluxDB e Grafana (TIG) e interconectá-la com o Catalyst 9800.

Pré-requisitos

Este documento demonstra as capacidades de interfaces programáticas do Catalyst 9800 através de uma integração complexa. Este documento tem como objetivo mostrar como eles podem ser totalmente personalizáveis com base em qualquer necessidade e ser economizadores de tempo diários. A implantação mostrada aqui depende do gRPC e apresenta a configuração de telemetria para disponibilizar dados sem fio do Catalyst 9800 em qualquer pilha de observação Telegraf, InfluxDB, Grafana (TIG).

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Modelo de configuração Catalyst Wireless 9800. 
• Programabilidade de rede e modelos de dados.
• Conceitos básicos da pilha TIG.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de 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).

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Configurar

Diagrama de Rede

Configurações

Neste exemplo, a telemetria é configurada em um 9800-CL usando discagem gRPC para enviar informações em um aplicativo Telegraf armazenando-as em um banco de dados InfluxDB. Aqui, dois dispositivos foram usados,

• Um servidor Ubuntu que hospeda toda a pilha TIG.
• Um Catalyst 9800-CL.

Este guia de configuração não se concentra em toda a implantação desses dispositivos, mas nas configurações necessárias em cada aplicativo para que as informações do 9800 sejam enviadas, recebidas e apresentadas corretamente.

Etapa 1. Preparar o Banco de Dados

Antes de entrar na parte de configuração, verifique se a instância do Influx está sendo executada corretamente. Isso pode ser feito facilmente usando o systemctl status comando, se você estiver usando uma distribuição 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

Para que o exemplo funcione, o Telegraf precisa de um banco de dados para armazenar as métricas, bem como um usuário para se conectar a este. Eles podem ser facilmente criados a partir da CLI do InfluxDB, usando estes comandos:

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'

O banco de dados agora criado, o Telegraf, pode ser configurado para armazenar métricas nele corretamente.

Etapa 2. Preparar o Telegraf

Apenas duas configurações do Telegraf são interessantes para este exemplo funcionar. Isso pode ser feito (como de costume para aplicativos em execução no Unix) a partir do arquivo de /etc/telegraf/telegraf.conf configuração.

O primeiro declara a saída usada pelo Telegraf. Como dito anteriormente, o InfluxDB é usado aqui e configurado na seção de saída do telegraf.conf arquivo da seguinte maneira:

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

Isso instrui o processo Telegraf a armazenar os dados recebidos no InfluxDB sendo executado no mesmo host na porta 8086 e a usar o banco de dados chamado "TELEGRAF" (bem como as credenciais telegraf/YOUR_PASSWORD para acessá-lo).

Se a primeira coisa declarada foi o formato de saída, a segunda é, é claro, o de entrada. Para informar ao Telegraf que os dados recebidos vêm de um dispositivo Cisco que usa telemetria, você pode usar o módulo de entrada cisco_telemetry_mdt". Para configurar isso, basta adicionar estas linhas no /etc/telegraf/telegraf.conf arquivo:

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

Isso faz com que o aplicativo Telegraf em execução no host (na porta padrão 57000) possa decodificar os dados recebidos vindos da WLC.

Depois que a configuração for salva, certifique-se de reiniciar o Telegraf para aplicá-la ao serviço. Verifique também se o serviço foi reiniciado corretamente:

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

Etapa 3. Determine a inscrição de telemetria contendo a métrica desejada

Como dito, em dispositivos da Cisco como em muitos outros, as métricas são organizadas de acordo com o modelo YANG. Os modelos específicos do Cisco YANG para cada versão do IOS XE (usado no 9800) podem ser encontrados aqui, em particular o modelo para IOS XE Dublin 17.12.03 usado neste exemplo.

Neste exemplo, nos concentramos em coletar métricas de utilização da CPU da instância 9800-CL usada. Inspecionando o modelo YANG para o Cisco IOS XE Dublin 17.12.03, pode-se determinar qual módulo contém a utilização da CPU do controlador e, em particular, para os últimos 5 segundos. Eles fazem parte do módulo Cisco-IOS-XE-process-cpu-oper, no agrupamento de utilização de CPU (cinco segundos folha).

Etapa 4. Ative NETCONF no controlador

A estrutura de discagem gRPC depende do NETCONF para trabalhar da mesma forma. Portanto, esse recurso deve ser habilitado no 9800 e isso é obtido executando estes comandos:

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

Etapa 5. Configurar a assinatura de telemetria no controlador

Uma vez que os XPaths (também conhecido como, linguagem de caminhos XML) das métricas determinadas a partir do modelo YANG, uma assinatura de telemetria pode ser facilmente configurada a partir da CLI 9800 para começar a transmiti-los para a instância Telegraf configurada no Passo 2. Isso é feito com a execução destes comandos:

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

Neste bloco de código, primeiro é definida a assinatura de telemetria com o identificador 101. O Identificador de assinatura pode ser qualquer número entre <0-2147483647>, desde que não se sobreponha a outra assinatura. Para esta assinatura são configuradas, nesta ordem:

• O método de codificação usado, que deve ser kvGPB ao trabalhar com o protocolo de transporte gRPC.
• O filtro para as métricas enviadas pela assinatura, sendo o XPath que define a métrica que nos interessa (para saber, /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds).
• O endereço IP de origem usado pelo controlador para enviar as métricas.
• O tipo de fluxo usado para comunicar as métricas, neste caso, o padrão IETF YANG Push.
• A frequência usada pelo controlador para enviar dados ao assinante em 100^º de segundos. Nesse caso, ele foi configurado para enviar atualizações periodicamente a cada segundo.
• O endereço IP e o número de porta do receptor, bem como o protocolo usado para a comunicação entre o controlador e o assinante. Neste exemplo, gRPC-TCPé usado para enviar métrica ao host 10.48.39.98 na porta 57000.

Etapa 6. Configurar Fonte de Dados do Grafana

Agora que o controlador começa a enviar dados para o Telegraf e que eles estão armazenados no banco de dados TELEGRAF InfluxDB, é hora de configurar o Grafana para permitir que ele navegue por essas métricas.

Na GUI do Grafana, navegue até Home > Connections > Connect data e use a barra de pesquisa para localizar a fonte de dados do InfluxDB.

Selecione esse tipo de fonte de dados e use o botão "Create a InfluxDB data source" (Criar uma fonte de dados InfluxDB) para conectar o Grafana e o banco de dados TELEGRAPH criado na Etapa 1.

Preencha o formulário exibido na tela, especialmente forneça:

• Um nome para a fonte de dados.
• A URL da instância do InfluxDB usada.
• O nome do banco de dados usado (neste exemplo, "TELEGRAF").
• A credencial do usuário definida para acessá-la (neste exemplo, telegraf/YOUR_PASSWORD).

Passo 7. Criar um painel

As visualizações do Grafana são organizadas em Painéis. Para criar um painel contendo as visualizações de métricas do Catalyst 9800, navegue para Home > Dashboards e use o botão "Novo painel"

Isso abre o novo painel criado. Clique nos ícones de equipamento para acessar o parâmetro do painel e alterar seu nome. No exemplo, "Telemetria do Catalyst 9800" é usada. Depois que isso for feito, use o botão "Salvar painel" para salvar seu painel.

Etapa 8. Adicionar uma Visualização ao Painel

Agora que os dados são enviados, recebidos e armazenados corretamente e que o Grafana tem acesso a esse local de armazenamento, é hora de criar uma visualização para eles.

Em qualquer painel do Grafana, use o botão "Adicionar" e selecione "Visualização" no menu exibido para criar uma visualização de suas métricas.

 

Isso abre o painel Editar da visualização criada:

Nesse painel, selecione

• O nome da fonte de dados criada na Etapa 6, TELEGRAF neste exemplo.
• A medida (esquema) contendo os dados que você deseja visualizar, "Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-usage" neste exemplo.
• O campo do banco de dados que representa as métricas que você deseja visualizar, "cinco_segundos" neste exemplo.
• O título da visualização, "Utilização da CPU 9800-CL" neste exemplo.

Quando o botão "Save/Apply" (Salvar/Aplicar) da figura anterior for pressionado, a visualização que mostra o uso da CPU do controlador Catalyst 9800 ao longo do tempo será adicionada ao painel. As alterações feitas no painel podem ser salvas usando o botão do ícone de disquete.

Verificar

Configuração de execução da 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

Configuração do 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"

Configuração do 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"

Configuração do Grafana

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

Troubleshooting

Reflexo de One Stop-Shop da WLC

Do lado da WLC, a primeira coisa a ser verificada é que os processos relacionados às interfaces programáticas estão ativos e em execução.

#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 

Para NETCONF (usado por discagem gRPC), esses comandos também podem ajudar a verificar o status do 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

Uma vez verificado o status do processo, outra verificação importante é o status da conexão de telemetria entre o Catalyst 9800 e o receptor Telegraf. Ele pode ser exibido com o 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 a conexão de telemetria estiver ativa entre a WLC e o receptor, também é possível garantir que as assinaturas configuradas sejam válidas usando o show telemetry ietf subscription all brief comando.

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

A versão detalhada desse comando, show telemetry ietf subscription all detail, fornece mais informações sobre assinaturas e pode ajudar a apontar um problema de sua configuração.

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                                                                           

Confirmar acessibilidade da rede

O controlador Catalyst 9800 envia dados gRPC para a porta do receptor configurada para cada assinatura de telemetria.

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

Para verificar a conectividade de rede entre a WLC e o receptor nesta porta configurada, várias ferramentas estão disponíveis.

A partir da WLC, é possível usar o telnet no IP/porta do receptor configurado (aqui 10.48.39.98:57000) para verificar se este está aberto e acessível a partir do próprio controlador. Se o tráfego não estiver sendo bloqueado, a porta deve aparecer como aberta na saída:

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

Como alternativa, pode-se usar o Nmap de qualquer host para garantir que o receptor seja exposto corretamente na porta configurada.

$ 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

Registro e depuração

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

Certificando-se de que as métricas alcancem a pilha TIG

Da CLI do InfluxDB

Assim como qualquer outro sistema de banco de dados, o InfluxDB vem com uma CLI que pode ser usada para verificar se as métricas são recebidas corretamente pelo Telegraf e armazenadas no banco de dados definido. O InfluxDB organiza as métricas, os chamados pontos, em medidas que são organizadas como séries. Alguns comandos básicos apresentados aqui podem ser usados para verificar o esquema de dados no lado do InfluxDB e garantir que os dados alcancem esse aplicativo.

Primeiro, você pode verificar se as séries, as medidas e sua estrutura (chaves) foram geradas corretamente. Eles são gerados automaticamente pelo Telegraf e InfluxDB com base na estrutura do RPC usado.

$ 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

Uma vez esclarecida a estrutura de dados (inteiro, string, booleano, ...), pode-se obter o número de pontos de dados sendo armazenados nessas medidas com base em um campo específico.

# 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 o número de pontos para um determinado campo e o carimbo de data/hora para a última ocorrência aumentar, é bom sinal que a pilha TIG receba e armazene corretamente os dados enviados pela WLC.

Do Telegraf

Para verificar se o receptor Telegraf realmente recebe algumas métricas do controlador e verifica seu formato, você pode redirecionar as métricas Telegraf para um arquivo de saída no host. Isso pode ser muito útil quando se trata de solução de problemas de interconexão de dispositivos. Para conseguir isso, basta usar o plugin de saída "file" do Telegraf, configurável a partir do /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"

Referências

Diretrizes de dimensionamento de hardware

Requisitos Grafana