Configurer le workflow gRPC avancé 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-TCP est 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