Configuration du workflow avancé gRPC avec Telegraf, InfluxDB et Grafana sur Catalyst 9800

Introduction

Ce document décrit comment déployer la pile Telegraf, InfluxDB et Grafana (TIG) et l'interconnecter avec le Catalyst 9800.

Conditions préalables

Ce document présente les capacités des interfaces programmatiques du Catalyst 9800 grâce à une intégration complexe. Ce document vise à montrer comment ceux-ci peuvent être entièrement personnalisables en fonction de n'importe quel besoin et être des gains de temps quotidiens. Le déploiement présenté ici repose sur gRPC et présente une configuration de télémétrie pour rendre les données sans fil du Catalyst 9800 disponibles dans n'importe quelle pile d'observabilité Telegraf, InfluxDB, Grafana (TIG).

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Modèle de configuration Catalyst Wireless 9800. 
• Programmabilité réseau et modèles de données.
• Notions de base sur les piles TIG

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Configurer

Diagramme du réseau

Configurations

Dans cet exemple, la télémétrie est configurée sur un 9800-CL à l'aide de la numérotation gRPC pour transmettre des informations sur une application Telegraf les stockant dans une base de données InfluxDB. Ici, deux appareils ont été utilisés,

• Un serveur Ubuntu hébergeant toute la pile TIG.
• Un commutateur Catalyst 9800-CL.

Ce guide de configuration ne se concentre pas sur le déploiement complet de ces périphériques, mais plutôt sur les configurations requises sur chaque application pour que les informations du 9800 soient envoyées, reçues et présentées correctement.

Étape 1. Préparation de la base de données

Avant d'accéder à la partie configuration, assurez-vous que votre instance Influx s'exécute correctement. Cela peut être fait facilement à l'aide de la systemctl status commande, si vous utilisez une distribution 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

Pour que l'exemple fonctionne, Telegraf a besoin d'une base de données pour stocker les métriques, ainsi que d'un utilisateur pour se connecter à celle-ci. Ces commandes peuvent être facilement créées à partir de l'interface de ligne de commande InfluxDB, en utilisant les commandes suivantes :

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 données maintenant créée, Telegraf peut être configurée pour stocker des mesures correctement.

Étape 2. Préparer Telegraf

Seules deux configurations Telegraf sont intéressantes pour que cet exemple fonctionne. Elles peuvent être effectuées (comme d'habitude pour les applications exécutées sous Unix) à partir du fichier de /etc/telegraf/telegraf.conf configuration.

Le premier déclare la sortie utilisée par Telegraf. Comme indiqué précédemment, InfluxDB est utilisé ici et est configuré dans la section de sortie du telegraf.conf fichier comme suit :

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

Ceci demande au processus Telegraf de stocker les données qu'il reçoit dans InfluxDB exécuté sur le même hôte sur le port 8086 et d'utiliser la base de données appelée « TELEGRAF » (ainsi que les identifiants telegraf/YOUR_PASSWORD pour y accéder).

Si la première chose déclarée était le format de sortie, la seconde est, bien sûr, le format d'entrée. Pour informer Telegraf que les données qu'il reçoit proviennent d'un périphérique Cisco utilisant la télémétrie, vous pouvez utiliser le module d'entrée « cisco_telemetry_mdt ». Pour configurer cela, il vous suffit d'ajouter ces lignes dans le /etc/telegraf/telegraf.conf fichier :

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

Cela permet à l'application Telegraf s'exécutant sur l'hôte (sur le port par défaut 57000) de décoder les données reçues provenant du WLC.

Une fois la configuration enregistrée, veillez à redémarrer Telegraf pour l'appliquer au service. Assurez-vous également que le service a redémarré correctement :

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

Étape 3. Déterminer l'abonnement de télémétrie contenant la métrique souhaitée

Comme indiqué, sur les périphériques Cisco comme sur de nombreux autres, les métriques sont organisées selon le modèle YANG. Les modèles Cisco YANG spécifiques à chaque version d'IOS XE (utilisée sur le 9800) sont disponibles ici, en particulier celui d'IOS XE Dublin 17.12.03 utilisé dans cet exemple.

Dans cet exemple, nous nous concentrons sur la collecte des mesures d'utilisation du CPU à partir de l'instance 9800-CL utilisée. En examinant le modèle YANG pour Cisco IOS XE Dublin 17.12.03, on peut déterminer quel module contient l'utilisation CPU du contrôleur, et en particulier pour les 5 dernières secondes. Elles font partie du module Cisco-IOS-XE-process-cpu-oper, sous le regroupement cpu-usage (leaf 5 secondes).

Étape 4. Activer NETCONF sur le contrôleur

Le cadre de numérotation gRPC repose sur NETCONF pour fonctionner de la même manière. Par conséquent, cette fonctionnalité doit être activée sur le 9800 et ceci est réalisé en exécutant ces commandes :

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

Étape 5. Configurer l'abonnement de télémétrie sur le contrôleur

Une fois les XPaths (a.k.a, XML Paths Language) des métriques déterminées à partir du modèle YANG, un abonnement de télémétrie peut être facilement configuré à partir de l'interface de ligne de commande 9800 afin de commencer à diffuser ces métriques vers l'instance Telegraf configurée à l'étape 2. Pour ce faire, exécutez les commandes suivantes :

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

Dans ce bloc de code, on définit d'abord l'abonnement télémétrique avec l'identifiant 101. L'identificateur d'abonnement peut être n'importe quel nombre compris entre <0 et 2147483647>, à condition qu'il ne chevauche pas un autre abonnement. Pour cet abonnement sont configurés, dans cet ordre :

• Méthode de codage utilisée, qui doit être kvGPB lors de l'utilisation du protocole de transport gRPC.
• Filtre des métriques envoyées par l'abonnement, c'est-à-dire le XPath définissant la métrique qui nous intéresse (à savoir, /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds).
• Adresse IP source utilisée par le contrôleur pour envoyer les métriques.
• Type de flux utilisé pour communiquer les métriques, dans ce cas la norme IETF YANG Push.
• Fréquence utilisée par le contrôleur pour envoyer des données à l'abonné en 100^ème de secondes. Dans ce cas, il a été configuré pour envoyer des mises à jour régulièrement chaque seconde.
• L'adresse IP et le numéro de port du récepteur, ainsi que le protocole utilisé pour la communication entre le contrôleur et l'abonné. Dans cet exemple, gRPC-TCPest utilisé pour envoyer la métrique à l’hôte 10.48.39.98 sur le port 57000.

Étape 6. Configurer la source de données Grafana

Maintenant que le contrôleur commence à envoyer des données à Telegraf et que celles-ci sont stockées dans la base de données InfluxDB de TELEGRAF, il est temps de configurer Grafana pour lui permettre de parcourir ces métriques.

Dans l'interface graphique de Grafana, accédez à Home > Connections > Connect data et utilisez la barre de recherche pour trouver la source de données InfluxDB.

Sélectionnez ce type de source de données et utilisez le bouton "Créer une source de données InfluxDB" pour connecter Grafana et la base de données TELEGRAPH créée à l'étape 1.

Remplissez le formulaire qui s'affiche à l'écran, en fournissant notamment :

• Nom de la source de données.
• URL de l'instance InfluxDB utilisée.
• Nom de base de données utilisé (dans cet exemple, « TELEGRAF »).
• Informations d'identification de l'utilisateur défini pour y accéder (dans cet exemple, telegraf/YOUR_PASSWORD).

Étape 7. Créer un tableau de bord

Les visualisations Grafana sont organisées en tableaux de bord. Pour créer un tableau de bord contenant les visualisations de mesures Catalyst 9800, accédez à Accueil > Tableaux de bord et utilisez le bouton « Nouveau tableau de bord »

Le nouveau tableau de bord créé s'ouvre. Cliquez sur les icônes d'engrenage pour accéder au paramètre du tableau de bord et modifier son nom. Dans l'exemple, « Télémétrie Catalyst 9800 » est utilisé. Une fois cette opération effectuée, utilisez le bouton « Enregistrer le tableau de bord » pour enregistrer votre tableau de bord.

Étape 8. Ajouter une visualisation au tableau de bord

Maintenant que les données sont envoyées, reçues et stockées correctement et que Grafana a accès à cet emplacement de stockage, il est temps de créer une visualisation pour eux.

Depuis n'importe quel tableau de bord Grafana, utilisez le bouton « Ajouter » et sélectionnez « Visualisation » dans le menu qui apparaît pour créer une visualisation de vos métriques.

 

Le panneau Modifier de la visualisation créée s'ouvre :

Dans ce panneau, sélectionnez

• Nom de la source de données créée à l'étape 6, TELEGRAF dans cet exemple.
• Mesure (schéma) contenant les données que vous souhaitez visualiser, « Cisco-IOS-XE-process-cpu-oper:cpu-usage/cpu-usage » dans cet exemple.
• Champ de la base de données représentant les mesures à visualiser, « five_seconds » dans cet exemple.
• Titre de la visualisation, « CPU Utilization 9800-CL » dans cet exemple.

Une fois le bouton « Save/Apply » de la figure précédente enfoncé, la visualisation montrant l'utilisation CPU du contrôleur Catalyst 9800 au fil du temps est ajoutée au tableau de bord. Les modifications apportées au tableau de bord peuvent être enregistrées à l'aide du bouton de l'icône de disquette.

Vérifier

Configuration en cours du 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

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

Configuration de 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"

Configuration de Grafana

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

Dépannage

WLC One Stop-Shop Reflex

Du côté du WLC, la toute première chose à vérifier est que les processus liés aux interfaces de programmation sont opérationnels.

#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 

Pour NETCONF (utilisé par la numérotation gRPC), ces commandes peuvent également aider à vérifier l'état du processus.

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

Une fois l'état du processus vérifié, une autre vérification importante est l'état de la connexion de télémétrie entre le Catalyst 9800 et le récepteur Telegraf. Il peut être affiché à l'aide de la commande « 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 connexion de télémétrie est établie entre le WLC et le récepteur, on peut également s'assurer que les abonnements configurés sont valides à l'aide de la show telemetry ietf subscription all brief commande.

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

La version détaillée de cette commande, show telemetry ietf subscription all detail, fournit plus d'informations sur les abonnements et peut aider à signaler un problème à partir de sa configuration.

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                                                                           

Confirmer l'accessibilité du réseau

Le contrôleur Catalyst 9800 envoie des données gRPC au port de réception configuré pour chaque abonnement de télémétrie.

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

Pour vérifier la connectivité réseau entre le WLC et le récepteur sur ce port configuré, plusieurs outils sont disponibles.

À partir du WLC, on peut utiliser telnet sur le récepteur IP/port configuré (ici 10.48.39.98:57000) pour vérifier que celui-ci est ouvert et accessible à partir du contrôleur lui-même. Si le trafic n'est pas bloqué, le port doit apparaître comme ouvert dans le résultat :

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

Vous pouvez également utiliser Nmap à partir de n'importe quel hôte pour vous assurer que le récepteur est exposé correctement sur le port configuré.

$ 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

Journalisation et débogage

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

S'assurer que les indicateurs atteignent la pile TIG

À partir de InfluxDB CLI

Comme tout autre système de base de données, InfluxDB est livré avec une CLI qui peut être utilisée pour vérifier les métriques sont reçues correctement par Telegraf et stockées dans la base de données définie. InfluxDB organise les métriques, appelées points, en mesures elles-mêmes organisées en séries. Certaines commandes de base présentées ici peuvent être utilisées pour vérifier le schéma de données côté InfluxDB et s'assurer que les données atteignent cette application.

Tout d'abord, vous pouvez vérifier que les séries, les mesures et leur structure (clés) sont correctement générées. Ceux-ci sont automatiquement générés par Telegraf et InfluxDB en fonction de la structure du RPC utilisé.

$ 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

Une fois la structure de données clarifiée (entier, chaîne, booléen, ...), on peut obtenir le nombre de points de données stockés sur ces mesures en fonction d'un champ particulier.

# 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 le nombre de points pour un champ particulier et l'horodatage pour la dernière occurrence augmentent, il est bon signe que la pile TIG reçoit et stocke correctement les données envoyées par le WLC.

De Telegraf

Pour vérifier que le récepteur Telegraf obtient réellement certaines métriques du contrôleur et vérifie leur format, vous pouvez rediriger les métriques Telegraf vers un fichier de sortie sur l'hôte. Cela peut s'avérer très pratique lorsqu'il s'agit de dépanner des interconnexions de périphériques. Pour ce faire, il vous suffit d'utiliser le plug-in de sortie « file » de Telegraf, configurable à partir du /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"

Références

Recommandations de dimensionnement du matériel

exigences de Grafana