El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo implementar la pila Telegraf, InfluxDB y Grafana (TIG) e interconectarla con Catalyst 9800.
Este documento demuestra las capacidades de interfaces programáticas de Catalyst 9800 a través de una integración compleja. Este documento tiene como objetivo mostrar cómo estos pueden ser totalmente personalizables en función de cualquier necesidad y ser ahorradores de tiempo diarios. La implementación mostrada aquí se basa en gRPC y presenta la configuración de telemetría para hacer que los datos inalámbricos del Catalyst 9800 estén disponibles en cualquier pila de observabilidad de Telegraf, InfluxDB, Grafana (TIG).
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
En este ejemplo, la telemetría se configura en un 9800-CL usando el marcado de salida gRPC para enviar información en una aplicación Telegraph almacenándola en una base de datos InfluxDB. Aquí, se utilizaron dos dispositivos,
Esta guía de configuración no se centra en la implementación completa de estos dispositivos, sino en las configuraciones requeridas en cada aplicación para que la información del 9800 se envíe, reciba y presente correctamente.
Antes de entrar en la parte de configuración, asegúrese de que la instancia Influx se está ejecutando correctamente. Esto se puede hacer fácilmente usando el systemctl status
comando, si está usando una distribución 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 el ejemplo funcione, Telegraf necesita una base de datos para almacenar las métricas, así como un usuario para conectarse a esta. Estos se pueden crear fácilmente desde la CLI de InfluxDB, usando estos 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'
La base de datos ahora creada, Telegraf se puede configurar para almacenar métricas en ella correctamente.
Para que este ejemplo funcione, sólo son interesantes dos configuraciones de Telegrabado. Éstas se pueden realizar (como es habitual para las aplicaciones que se ejecutan en Unix) desde el archivo de /etc/telegraf/telegraf.conf
configuración.
El primero declara la salida utilizada por Telegraf. Como se indicó anteriormente, InfluxDB se utiliza aquí y se configura en la sección de salida del telegraf.conf
archivo de la siguiente manera:
###############################################################################
# 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"
Esto indica al proceso de Telegraf que almacene los datos que recibe en InfluxDB que se ejecuta en el mismo host en el puerto 8086 y que utilice la base de datos llamada "TELEGRAF" (así como las credenciales telegraf/YOUR_PASSWORD para acceder a ella).
Si lo primero declarado fue el formato de salida, el segundo es, por supuesto, el formato de entrada. Para informar a Telemraf que los datos que recibe provienen de un dispositivo Cisco que utiliza telemetría, puede utilizar el módulo de entrada cisco_telemetry_mdt". Para configurar esto, solo necesita agregar estas líneas en el /etc/telegraf/telegraf.conf
archivo:
###############################################################################
# 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"
Esto hace que la aplicación Telegraf que se ejecuta en el host (en el puerto predeterminado 57000) pueda decodificar los datos recibidos que provienen del WLC.
Una vez guardada la configuración, asegúrese de reiniciar Telegraf para aplicarlo al servicio. Asegúrese también de que el servicio se haya reiniciado correctamente:
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
Como se ha indicado, tanto en los dispositivos de Cisco como en muchos otros, las métricas se organizan según el modelo YANG. Los modelos específicos de Cisco YANG para cada versión de IOS XE (utilizados en el 9800) se pueden encontrar aquí, en particular el modelo para IOS XE Dublin 17.12.03 utilizado en este ejemplo.
En este ejemplo, nos centramos en recopilar las métricas de utilización de la CPU de la instancia 9800-CL utilizada. Al inspeccionar el modelo YANG para Cisco IOS XE Dublin 17.12.03, se puede determinar qué módulo contiene la utilización de la CPU del controlador y, en particular, durante los últimos 5 segundos. Estos son parte del módulo Cisco-IOS-XE-process-cpu-oper, bajo la agrupación cpu-utilization (cinco segundos de hoja).
El marco de marcado de salida gRPC depende de NETCONF para funcionar de la misma manera. Por lo tanto, esta función debe estar habilitada en el 9800 y esto se logra ejecutando estos comandos:
WLC(config)#netconf ssh
WLC(config)#netconf-yang
Una vez que XPath (alias, XML Paths Language) de las métricas determinadas a partir del modelo YANG, una suscripción de telemetría se puede configurar fácilmente desde la CLI 9800 para comenzar a transmitir estos a la instancia de Telegraf configurada en el Paso 2. Esto se realiza mediante la ejecución de estos 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
En este bloque de código, primero se define la suscripción de telemetría con el identificador 101. El identificador de suscripción puede ser cualquier número entre <0-2147483647>, siempre y cuando no se superponga con otra suscripción. Para esta suscripción se han configurado, en este orden:
/process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds
).Ahora que el controlador comienza a enviar datos a Telegraf y que estos se almacenan en la base de datos TELEGRAF InfluxDB, es hora de configurar Grafana para que pueda examinar estas métricas.
Desde la GUI de Grafana, navegue hasta Inicio > Conexiones > Conectar datos y utilice la barra de búsqueda para encontrar el origen de datos de InfluxDB.
Seleccione este tipo de origen de datos y utilice el botón "Crear un origen de datos InfluxDB" para conectar Grafana y la base de datos TELEGRAPH creada en el Paso 1.
Rellene el formulario que aparece en la pantalla, especialmente proporcione:
Las visualizaciones Grafana se organizan en Paneles. Para crear un panel que contenga las visualizaciones de métricas de Catalyst 9800, navegue hasta Inicio > Paneles y utilice el botón "Nuevo panel"
Se abrirá el nuevo panel creado. Pulse en los iconos de engranaje para acceder al parámetro del tablero de mandos y cambiar su nombre. En el ejemplo, se utiliza "Telemetría de Catalyst 9800". Una vez realizado este paso, utilice el botón "Guardar panel" para guardar el panel.
Ahora que los datos son enviados, recibidos y almacenados correctamente y que Grafana tiene acceso a esta ubicación de almacenamiento, es el momento de crear una visualización para ellos.
Desde cualquier panel de Grafana, utilice el botón "Agregar" y seleccione "Visualización" en el menú que aparece para crear una visualización de sus métricas.
Se abrirá el panel Editar de la visualización creada:
En este panel, seleccione
Una vez que se presiona el botón "Guardar/Aplicar" de la figura anterior, se agrega al panel la visualización que muestra el uso de la CPU del controlador Catalyst 9800 a lo largo del tiempo. Los cambios realizados en el panel se pueden guardar mediante el botón de icono de disquete.
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
# 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"
### 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"
#################################### Server ####################################
[server]
http_addr = 10.48.39.98
domain = 10.48.39.98
Desde el lado del WLC, lo primero que hay que verificar es que los procesos relacionados con las interfaces programáticas están funcionando.
#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 (utilizado por marcado de salida gRPC), estos comandos también pueden ayudar a verificar el estado del proceso.
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 vez que se verifica el estado del proceso, otra verificación importante es el estado de la conexión de telemetría entre el Catalyst 9800 y el receptor Telegraf. Se puede ver mediante el 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
Si la conexión de telemetría está activa entre el WLC y el receptor, también se puede asegurar que las suscripciones configuradas sean válidas usando el 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 versión detallada de este comando, show telemetry ietf subscription all detail
, proporciona más información sobre las suscripciones y puede ayudar a señalar un problema de su configuración.
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
El controlador Catalyst 9800 envía datos gRPC al puerto receptor configurado para cada suscripción de telemetría.
WLC#show run | include receiver ip address
receiver ip address 10.48.39.98 57000 protocol grpc-tcp
Para verificar la conectividad de red entre el WLC y el receptor en este puerto configurado, varias herramientas están disponibles.
Desde el WLC, se puede utilizar telnet en el puerto/IP del receptor configurado (aquí 10.48.39.98:57000) para verificar que éste esté abierto y accesible desde el controlador mismo. Si el tráfico no está siendo bloqueado, el puerto debe aparecer como abierto en la salida:
WLC#telnet 10.48.39.98 57000
Trying 10.48.39.98, 57000 ... Open <-------
Alternativamente, se puede utilizar Nmap desde cualquier host para asegurarse de que el receptor esté expuesto correctamente en el puerto configurado.
$ 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
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
[...]
Al igual que cualquier otro sistema de base de datos, InfluxDB viene con una CLI que se puede utilizar para verificar que las métricas son recibidas correctamente por Telegraf y almacenadas en la base de datos definida. InfluxDB organiza las métricas, llamadas puntos, en mediciones que se organizan como series. Algunos comandos básicos presentados aquí se pueden utilizar para verificar el esquema de datos en InfluxDB y asegurarse de que los datos lleguen a esta aplicación.
En primer lugar, puede comprobar que las series, las medidas y su estructura (claves) se generan correctamente. Telegraf e InfluxDB las generan automáticamente en función de la estructura del RPC utilizado.
Nota: Por supuesto, esta estructura es totalmente personalizable a partir de las configuraciones Telegraf e InfluxDB. Sin embargo, esto va más allá del alcance de esta guía de configuración.
$ 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 vez aclarada la estructura de datos (entero, cadena, booleano, ...), se puede obtener el número de puntos de datos que se almacenan en estas mediciones basadas en un campo determinado.
# 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
Si el número de puntos para un campo determinado y la marca de tiempo para la última aparición aumentan, es buena señal que la pila TIG recibe y almacena correctamente los datos enviados por el WLC.
Para verificar que el receptor de Telegraf realmente obtenga algunas métricas del controlador y verifique su formato, puede redirigir las métricas de Telegraf a un archivo de salida en el host. Esto puede ser muy útil cuando se trata de la resolución de problemas de interconexión de dispositivos. Para lograr esto, simplemente haga uso del plugin de salida "archivo" de Telegraf, configurable desde el /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"
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
10-Jun-2024 |
Versión inicial |