Recommandations pour les abonnements aux données de télémétrie sur gNMI
Cette section décrit les modes d’abonnement pris en charge par les connexions gNMI.
Le protocole gNMI définit le RPC pour l’abonnement Subscribe aux données de télémétrie. Le collecteur de télémétrie utilise ce RPC pour demander des mises à jour à l’équipement réseau concernant les données d’état et de configuration.
Les demandes de nouveaux abonnements sont encapsulées dans un SubscribeRequest message contenant un ou plusieurs chemins d’accès aux ressources. Les chemins d’accès abonnés se rapportent à des instances de données spécifiques sur l’équipement réseau cible. La requête peut contenir des chemins basés sur les schémas OpenConfig ou Junos® OS natifs.
La demande d’abonnement doit également inclure l’un des modes suivants :
-
ONCE- une demande unique de données. -
POLL- pour la récupération périodique et à la demande des données. -
STREAM- Un abonnement de longue durée qui diffuse des données en fonction de déclencheurs spécifiés.
Les abonnements en STREAM mode doivent spécifier l’un des sous-modes suivants :
-
ON_CHANGE- Les mises à jour des données ne sont envoyées qu’en cas de changement de la valeur de l’élément de données. -
SAMPLE- Les mises à jour des données sont envoyées une fois par intervalle d’échantillonnage en fonction d’une période d’intervalle spécifiée dans la demande d’abonnement. L’intervalle d’échantillonnage par défaut est de 30 secondes. -
TARGET_DEFINED- L’équipement réseau recevant la demande d’abonnement détermine le meilleur type de livraison des données pour chaque branche. Si le chemin d’accès spécifié dans le message fait référence à des données basées sur des événements, unON_CHANGEabonnement peut être créé. Pour les données qui représentent des valeurs de compteur, unSAMPLEabonnement peut être créé.Note:Les
TARGET_DEFINEDdemandes d’abonnement pour les chemins de configuration sont traitées commeON_CHANGEdes demandes uniquement.
Pour ONCEles abonnements et ON_CHANGE SAMPLE , le collecteur peut demander une mise à jour initiale contenant l’état actuel des chemins d’accès dans l’abonnement. Une mise à jour initiale de la synchronisation est utile pour les raisons suivantes :
-
Le collecteur dispose d’une vue complète de l’état actuel de chaque champ de l’appareil pour cette trajectoire de capteur.
-
Les données basées sur les événements (
ON_CHANGE) sont reçues par le collecteur au moins une fois avant que les suivantes ne se produisent, ce qui garantit que le collecteur reste informé de l’état des données au préalable. -
Les capteurs du moteur de transfert de paquets qui contiennent des valeurs de compteur zéro qui n’apparaissent normalement pas dans les données diffusées en continu en raison de la fonctionnalité de suppression zéro sont également envoyés. Cela permet de s’assurer que tous les champs de chaque fiche de ligne sont connus du collecteur.
L’équipement cible répond à la demande d’abonnement par un SubscribeResponse message. Si la demande d’abonnement nécessite une synchronisation initiale, la cible envoie les données suivies du message de réponse avec l’indicateur sync_response défini sur true. Après la synchronisation initiale, l’équipement cible procède à la mise à jour des chemins en fonction du mode d’abonnement.
Le SubscribeRequest message comprend un indicateur appelé updates_only. Lorsque cet indicateur est défini sur true, l’équipement cible n’envoie pas de synchronisation initiale, mais seulement les mises à jour ultérieures comme suit :
-
Pour
STREAMles abonnements enSAMPLEmode, la mise à jour est envoyée à l’intervalle d’échantillonnage suivant. -
Pour
STREAMles abonnements enON_CHANGEmode, la mise à jour est envoyée lors du prochain changement de valeur. -
Pour
ONCEles abonnements, seul le est envoyé avecsync_responselaSubscribeResponsevaleurfalse, et l’abonnement se ferme. -
TARGET_DEFINEDLes abonnements sont traités commeON_CHANGEpour les chemins de configuration et la mise à jour est envoyée au prochain changement de valeur.
Le contenu des messages et SubscribeResponse est défini dans le SubscribeRequest fichier gnmi.proto. Pour plus d’informations sur les modes d’abonnement RPC et d’abonnement, consultez la spécification gNMI à l’adresse suivante : Spécification gNMI : Abonnement aux mises à jour de télémétrie.
Les chemins de configuration présentent les limitations suivantes :
-
POLLLes abonnements ne sont pas pris en charge. -
Les chemins d’accès au préfixe ne sont pas inclus dans les messages de mise à jour.
-
La réponse gNMI n’est pas prise en charge pour les opérations de métadonnées spécifiques à Juniper, telles que
active/inactive,insert before/after,comment/annotate, etprotect/unprotect. Ceux-ci peuvent apparaître dans le message, mais ne sont pas valides. -
Paramètres non pris en charge dans les
SubscribeRequestfichiers includesuppress_redundant,heartbeat_level,allow_aggregation, etqos. -
L’encodage PROTO est le seul encodage pris en charge.
-
Les extensions dans
SubscribeRequestles messages ne sont pas prises en charge -
Le filtrage des chemins d’abonnement n’est pris en charge qu’au niveau de la clé.
Les variantes de commit suivantes ne sont pas prises en charge pour
ON_CHANGEles abonnements andTARGET_DEFINED:commit at,commit prepare/activate, et les validations par lots.Les commits ne sont pas pris en charge à partir de l’onglet
edit dynamicet les modes d’édition ouedit privatede configuration.-
Les messages de mise à jour ne sont pas envoyés pour les conteneurs de présence.
-
Les listes d’abonnement qui n’ont qu’une seule feuille configurée pour l’identificateur ou la clé peuvent ne pas générer de message de mise à jour.
Activation de la prise en charge des capteurs « ON CHANGE » via gNMI
Depuis Junos OS version 16.1, il est possible de diffuser régulièrement les états et compteurs opérationnels d’OpenConfig, afin d’exporter les données de télémétrie des équipements Juniper vers un collecteur externe. Bien qu’il soit utile pour collecter toutes les informations nécessaires et créer un « instantané » de référence, le streaming périodique est moins utile pour les missions urgentes. Configurez ON_CHANGE streaming pour qu’un collecteur externe reçoive des informations uniquement lorsque les états opérationnels changent.
Pour prendre en charge ON_CHANGE streaming, une nouvelle spécification appelée gRPC Network Management Interface (gNMI) a été implémentée pour la modification et la récupération des configurations à partir d’un élément réseau. En outre, la spécification gNMI peut être utilisée pour générer et contrôler des flux de télémétrie depuis un élément réseau vers un système de collecte de données. La nouvelle spécification gNMI permet à une définition de service gRPC de fournir une implémentation unique sur un élément réseau pour la configuration et la télémétrie. Il permet également à un système de gestion du réseau (NMS) d’interagir avec l’appareil par le biais de RPC de télémétrie et de configuration unifiés.
Le package de fichiers Junos (junos-telemetry-interface) inclut le fichier gnmi.proto et l’extension Juniper GnmiJuniperTelemetryHeader.proto pour la prise en charge de gNMI.
Des informations sur les RPC prenant en charge cette fonctionnalité se trouvent dans le fichier proto gNMI version 0.4.0 (la version prise en charge) et la spécification publiée
Le RPC subscribe de télémétrie du service gNMI prend en charge la diffusion ON_CHANGE en continu. RPC subscribe permet aux clients de demander à la cible d’envoyer des valeurs pour des chemins particuliers dans l’arborescence de données. Les valeurs peuvent être diffusées en continu (STREAM), envoyées une seule fois sur un canal à longue durée de vie (POLL) ou envoyées une seule fois en tant que récupération (ONCE).
Si vous vous abonnez à un conteneur de niveau supérieur avec une fréquence d’échantillonnage de 0, les sorties avec prise en charge ON_CHANGE sont diffusées en continu en fonction des événements. Les autres feuilles ne sont pas diffusées.
Pour permettre à un périphérique de déterminer quels nœuds sont diffusés en continu en tant que ON_CHANGE ou lesquels sont SAMPLE, le collecteur doit s’abonner à TARGET_DEFINED avec sample_interval.
Activation du mode d’abonnement « TARGET_DEFINED » via gNMI
Junos OS version 20.2R1 ajoute la prise en charge du mode d’abonnement TARGET_DEFINED avec les services gNMI (Network Management Interface) sur les routeurs MX5, MX10, MX40, MX80, MX104, MX150, MX204, MX240, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10008 et routeurs MX10016.
Un collecteur externe qui utilise un abonnement gNMI détermine la manière dont les données du capteur sont transmises :
-
Le mode STREAMING diffuse périodiquement les données du capteur à partir du DUT à un intervalle spécifié.
-
ON_CHANGE mode envoie des mises à jour pour les données du capteur à partir du DUT uniquement lorsque les valeurs de données changent.
-
Le nouveau mode TARGET_DEFINED (sous-mode 0) indique au DUT de sélectionner le mode approprié (STREAMING ou ON_CHANGE) pour transmettre chaque élément (feuille) des données du capteur au collecteur externe. Lorsque le collecteur externe envoie un abonnement pour un capteur avec le sous-mode 0 au DUT, le DUT répond, activant l’abonnement au capteur de sorte que la diffusion périodique n’inclut aucune des mises à jour du ON_CHANGE. Le DUT avertit le collecteur chaque fois que des événements ON_CHANGE éligibles se produisent.
Par défaut, les abonnements ont une fréquence de diffusion périodique de 30 secondes, sauf indication contraire du collecteur dans la demande d’abonnement.
Le fichier JavaScript Object Notation (JSON) ci-dessous montre un exemple d’abonnement gNMI. TARGET_DEFINED mode est défini à l'aide du chemin d' submode=0 accès à la ressource (capteur) /interfaces/interface[name='lo0']/state.
$ cat gnmi.json
{
"dut_list":[
{
"port":32767,
"rpc":["sub_request"],
"sub_request":{
"subscription":[
{
"path":"/interfaces/interface[name='lo0']/state",
"submode":0,
"sample_interval":30
}
],
"mode":0,
"encoding":2
}
}
]
$ python ./gnmi_subscribe_client_sample.py -c ./gnmi.json -d 10.53.32.102 -l client.log
Le package de fichiers Junos (junos-telemetry-interface) inclut le fichier gnmi.proto et l’extension Juniper GnmiJuniperTelemetryHeader.proto pour la prise en charge de gNMI.
Pour plus d’informations, consultez les spécifications gNMI et le fichier de protocole gNMI ici :
Activation du mode d’abonnement « INITIAL_SYNC » via gNMI
À partir de Junos OS version 20.2R1, il est possible de prendre en charge les statistiques de INITIAL_SYNC des capteurs moteur de transfert de paquets à l’aide des services gNMI. Cette fonctionnalité s’applique aux routeurs MX960, MX2008, MX2010, MX2020, PTX1000 et PTX5000. Le Juniper Networks® Gamme PTX10000 de routeurs, Juniper Networks® commutateur QFX5100 et Juniper Networks® commutateur QFX5200 offrent également cette prise en charge.
À partir de la version 20.4R1 de Junos OS Evolved, il est possible de prendre en charge les statistiques INITIAL_SYNC des capteurs moteur de transfert de paquets à l’aide des services gNMI. ® Juniper Networks commutateur QFX5130-32CD inclut cette prise en charge.
Lorsqu’un collecteur externe envoie une demande d’abonnement pour un capteur avec INITIAL_SYNC (gnmi-submode 2), l’hôte envoie au moins une fois toutes les feuilles (champs) cibles prises en charge sous ce chemin de ressource au collecteur avec la valeur actuelle. La collecte de ces statistiques est bénéfique pour les raisons suivantes :
-
Le collecteur dispose d’une vue complète de l’état actuel de chaque champ de l’appareil pour cette trajectoire de capteur.
-
Les données basées sur les événements (ON_CHANGE) arrivent au collecteur au moins une fois avant que l’événement suivant ne se produise. Cette approche permet au collecteur de connaître l’état des données avant que l’événement suivant ne se produise.
-
Les capteurs du moteur de transfert de paquets avec des valeurs de compteur zéro (supprimées du zéro) qui n’apparaissent normalement pas dans les données transmises en continu sont envoyés au moins une fois. Cette approche garantit au collecteur une visibilité sur tous les champs de chaque carte de ligne, souvent appelée source.
INITIAL_SYNC sous-mode exige que l’appareil envoie au moins une copie au collecteur, bien que l’envoi de plusieurs copies soit acceptable.
Les abonnements auront par défaut une fréquence de diffusion périodique de 30 secondes, sauf indication contraire du collecteur dans la demande d’abonnement.
Le fichier JavaScript Object Notation (JSON) ci-dessous montre un exemple d’abonnement gNMI. INITIAL_SYNC mode est défini à l’aide du chemin d’accès gnmi_submode 2 à la ressource (capteur) /interfaces/. L’attribut gnmi_mode est défini sur 0. L’encodage du protocole est défini sur 2 GBP.
{
"influx": {
"server": "server1",
"port": 8086,
"dbname": "gD40",
"measurement": "OC",
"user": "influx",
"password": "influxdb",
"recreate": true
},
"gnmi": {
"mode": 0, <---- STREAM
"encoding": 2, <--- PROTO encoding
"prefix": "/x/y/z"
},
"host": "10.10.130.73",
"port": 10162,
"user": "user1",
"password": "password1",
"cid": "cid-1jk",
"paths":[
{
"path": "/interfaces/",
"Freq": 10000000000,
"gnmi_submode": 2 <---- SAMPLE
}
]
}
Le package de fichiers Junos (junos-telemetry-interface) inclut le fichier gnmi.proto et l’extension Juniper GnmiJuniperTelemetryHeader.proto pour la prise en charge de gNMI.
Pour plus d’informations, consultez les spécifications gNMI et le fichier de protocole gNMI ici :
Spécification de télémétrie gNMI Définition du protocole gNMI
Exemples
Les exemples suivants montrent les demandes d’abonnement et les réponses effectuées par un client gNMI et un équipement cible au format protobuf.
Exemple : mode ONCE
L’exemple suivant montre une demande d’abonnement envoyée à partir d’un client gNMI au format protobuf. Le mode d’abonnement est ONCE et le chemin d’accès à la ressource OpenConfig est /system/aaa/authentication/users :
root@controller:~# /usr/local/bin/gnmic sub -a 10.225.0.0:32767 --mode once --path /system/aaa/authentication/users -u <username> -p <password> --format prototext
La cible répond par une mise à jour unique :
update: {
timestamp: 1676294840
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test2"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}
Exemple : ON_CHANGE
L’exemple suivant montre une demande d’abonnement en STREAM mode avec ON_CHANGE sous-mode. Le chemin d’accès à la ressource OpenConfig est /system/aaa/authentication/users/user[username="test1"] :
root@controller:~# /usr/local/bin/gnmic sub -a 10.225.0.0:32767 --mode stream --stream-mode on-change --path /system/aaa/authentication/users -u <username> -p <password> --format prototext
La configuration OpenConfig au moment de la demande d’abonnement :
user@root> show configuration openconfig-system:system aaa authentication | display set set openconfig-system:system aaa authentication users user test1 config password $ABC123 set openconfig-system:system aaa authentication users user test1 config role superuser
L’exemple de message de réponse montre les valeurs des chemins de configuration et l’indicateur sync_response défini sur true:
update: {
timestamp: 1676311979
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}
sync_response: true
Les modifications de configuration suivantes sont apportées aux chemins d’accès abonnés :
-
Ajouter un nom d’utilisateur pour
test1. -
Supprimer le mot de passe pour
test1.
L’équipement cible envoie la mise à jour suivante en réponse :
update: {
timestamp: 1676312428
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
delete: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
}
Exemple : SAMPLE
L’exemple suivant montre une demande d’abonnement en mode et SAMPLE en STREAM sous-mode. Le chemin d’accès à la ressource OpenConfig est /system/aaa/authentication/users/user[username="test1"] :
root@controller:~# /usr/local/bin/gnmic sub -a 10.225.0.0:32767 --mode stream --stream-mode sample --sample-interval 5s --path /system/aaa/authentication/users -u <username> -p <password> --format prototext
La configuration OpenConfig au moment de la demande d’abonnement :
user@root> show configuration openconfig-system:system aaa authentication | display set set openconfig-system:system aaa authentication users user test1 config username test1 set openconfig-system:system aaa authentication users user test1 config password "$ABC123" set openconfig-system:system aaa authentication users user test1 config role superuser
Les exemples de messages de réponse montrent une mise à jour initiale envoyée avec l’indicateur sync_response défini sur true et les mises à jour suivantes envoyées à des intervalles de 5 secondes :
update: {
timestamp: 1676295454
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}
sync_response: true
update: {
timestamp: 1676295459
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}
update: {
timestamp: 1676295464
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "username"
}
}
val: {
string_val: "test1"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "password"
}
}
val: {
string_val: "$ABC123"
}
}
update: {
path: {
elem: {
name: "system"
}
elem: {
name: "aaa"
}
elem: {
name: "authentication"
}
elem: {
name: "users"
}
elem: {
name: "user"
key: {
key: "username"
value: "test1"
}
}
elem: {
name: "config"
}
elem: {
name: "role"
}
}
val: {
string_val: "superuser"
}
}
}