Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Configurar

Diagrama de Rede

Configurações

Etapa 1. Preparar o Banco de Dados

Etapa 2. Preparar o Telegraf

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

Etapa 4. Ative NETCONF no controlador

Etapa 5. Configurar a assinatura de telemetria no controlador

Etapa 6. Configurar Fonte de Dados do Grafana

Passo 7. Criar um painel

Etapa 8. Adicionar uma Visualização ao Painel

Verificar

Configuração de execução da WLC

Configuração do Telegraf

Configuração do InfluxDB

Configuração do Grafana

Troubleshooting

Reflexo de One Stop-Shop da WLC

Confirmar acessibilidade da rede

Registro e depuração

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

Da CLI do InfluxDB

Do Telegraf

Referências

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.

Observação: é claro que essa estrutura é totalmente personalizável a partir das configurações Telegraf e InfluxDB. No entanto, isso vai além do escopo deste guia de configuração.

$ 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