Comprendre la télémétrie de Junos
Junos Telemetry est un framework développé par Juniper Networks qui permet d’exporter des données opérationnelles des équipements Junos vers des collecteurs externes. Ces données sont analysées pour la surveillance en temps réel des appareils. Cette rubrique décrit les concepts de télémétrie pilotée par modèle, les modes de télémétrie, les protocoles de transport, les capteurs de télémétrie, les chemins de capteur et les modèles de données utilisés par Junos Telemetry.
Télémétrie réseau
La télémétrie réseau est le processus de collecte, de transmission et d’analyse des données des équipements réseau. Ces données peuvent inclure des informations sur les schémas de trafic, l’état des appareils, les taux d’erreur et d’autres mesures qui fournissent des informations sur l’état et le comportement du réseau. Ces données vous permettent d’en tirer des informations utiles et de les appliquer pour surveiller et gérer efficacement les performances et la sécurité du réseau. Les administrateurs réseau peuvent utiliser les données de télémétrie pour résoudre les problèmes réseau, détecter les anomalies et optimiser l’utilisation des ressources sur l’ensemble du réseau. L’un des principaux avantages de la télémétrie réseau est sa capacité à fournir une visibilité en temps réel sur les opérations réseau.
La télémétrie du réseau joue également un rôle crucial dans le renforcement de la sécurité du réseau. En analysant les données de télémétrie, les équipes de sécurité peuvent identifier des schémas inhabituels pouvant indiquer une cyberattaque ou d’autres menaces de sécurité, permettant ainsi une détection et une réponse plus rapides aux incidents de sécurité potentiels et contribuant à protéger le réseau et ses données.
Télémétrie Junos
Junos Telemetry est la solution de télémétrie de Juniper, développée pour diffuser des données de télémétrie. Il est hautement évolutif et peut prendre en charge les dispositifs de surveillance à distance dans un réseau. Il permet également d’améliorer le dépannage, de gérer le réseau de manière proactive et de réduire les coûts opérationnels.
La télémétrie Junos peut être appliquée à divers scénarios de réseau :
- Surveillance des performances : Surveillez des indicateurs clés tels que l’utilisation de l’interface, la latence et la perte de paquets pour garantir des performances réseau optimales.
- Surveillance de la sécurité : Suivez les événements de sécurité, analysez les schémas de trafic et identifiez les menaces de sécurité potentielles.
- Gestion des performances applicatives : Obtenez des informations sur les performances des applications en corrélant les données réseau avec les données des applications.
- Planification de la capacité du réseau : Analysez les données historiques et en temps réel pour identifier les goulots d’étranglement potentiels et planifier les besoins futurs en capacité.
D'autres applications Juniper utilisent également la télémétrie Junos pour fournir des données en temps réel, ce qui permet de synchroniser l'état opérationnel entre les éléments du réseau et un contrôleur externe, tel que Mist de Juniper, Routing Director de Juniper et Apstra.
Télémétrie pilotée par des modèles
Junos Telemetry a adopté une architecture de télémétrie pilotée par des modèles (MDT). Un système de télémétrie réseau piloté par un modèle est une approche avancée de la surveillance du réseau qui exploite les modèles de données pour définir et collecter des données de télémétrie à partir des équipements réseau. Dans ce système, les modèles de données sont définis à l’aide d’un langage YANG (Yet Another Next Generation) pour spécifier la structure et les types de données à collecter ou à diffuser.
Juniper prend actuellement en charge deux modèles de données différents :
-
Modèle de données natif de Juniper
-
Modèle de données OpenConfig
Les deux modèles utilisent YANG pour spécifier la structure de données et les types de données à diffuser. Pour plus d’informations, consultez Modèles de données.
Le choix du bon modèle de données dépend des besoins spécifiques. Vous pouvez vous abonner simultanément aux capteurs des modèles OpenConfig et natifs. Les capteurs natifs prennent en charge des cas d’usage variés.
Suivez les étapes ci-dessous pour configurer une solution de télémétrie pilotée par un modèle :
Configurez l’appareil Juniper pour diffuser des données de télémétrie : Assurez-vous que l’équipement Juniper exécute une version compatible de Junos OS qui prend en charge la télémétrie Junos et que la connectivité réseau entre l’équipement Juniper et le collecteur est présente.
- Configurer le collecteur de données : Configurez le collecteur pour collecter et décoder les données. Pour plus d’informations, consultez Collecteur de données de télémétrie.
- Établir les protocoles de transport : Choisissez et configurez les protocoles de transport appropriés pour la transmission des données. Pour plus d’informations, consultez Protocoles de transport.
- Configurer le capteur : un profil de capteur définit les paramètres de la ressource système à surveiller et à diffuser. Vous pouvez activer une seule ressource système pour surveiller chaque profil de capteur ou configurer un profil de capteur différent pour chaque ressource système. Vous pouvez toutefois configurer plusieurs capteurs pour surveiller la même ressource système. Pour plus d’informations, voir Capteurs et chemins de capteurs.
- Créer des abonnements : configurez des abonnements pour les flux de données que vous devez surveiller. La session de télémétrie peut être établie en mode d’appel entrant ou sortant, selon que l’appareil ou le récepteur est configuré pour initier l’abonnement. Pour plus d’informations, consultez Modes de télémétrie.
Capteurs et chemins de capteurs
Les capteurs de télémétrie sont un composant important d’une solution de télémétrie. Ils mesurent divers paramètres physiques, environnementaux et de performance et les convertissent en données qui sont transmises au collecteur via des connexions TCP ou UDP pour surveillance et analyse à distance. Les capteurs de température, les capteurs d’interface, les capteurs de débit, etc. Le chemin d’un capteur de télémétrie est un itinéraire spécifique au sein d’un modèle de données, défini à l’aide de YANG, qui spécifie les données exactes à collecter et à diffuser à partir d’un équipement réseau. Juniper prend en charge les capteurs des modèles Openconfig et natifs. Les capteurs Openconfig suivent les mesures basées sur des compteurs ou sur l’état, tandis que les capteurs natifs suivent efficacement les mesures basées sur les événements, car ces capteurs ont accès à des données détaillées sur les appareils. Vous pouvez configurer les chemins des capteurs basés sur Openconfig pour récupérer les informations des capteurs dans un format indépendant du fournisseur ou configurer les chemins des capteurs natifs pour récupérer les informations propriétaires de Juniper dans un format natif. Pour plus d’informations, reportez-vous à la section Explorer les chemins des capteurs.
Collecteur de données de télémétrie
Le collecteur de télémétrie est un outil ou un logiciel spécialisé qui effectue la collecte, le traitement, la transmission et le stockage des données de télémétrie. Il sert d’intermédiaire entre les équipements Junos générant des données de télémétrie et les systèmes backend qui les stockent, les analysent et les visualisent.
Fonctions d’un collecteur de données :
- Collecte de données : le collecteur reçoit des données de télémétrie des appareils Juniper sur des connexions gRPC ou UDP.
- Traitement des données : le collecteur traite les données collectées en les agrégeant et en les normalisant pour filtrer les informations inutiles, agréger les mesures et effectuer une analyse initiale. Ce traitement permet de réduire le volume de données et de se concentrer sur les mesures les plus critiques.
- Transmission de données : Il garantit une transmission de données fiable et une faible latence.
- Stockage des données : les données traitées sont ensuite exportées vers divers systèmes backend pour une analyse, une visualisation et un stockage plus approfondis. Ils peuvent être stockés dans des lacs de données pour une analyse à long terme et une comparaison historique. Le collecteur prend en charge plusieurs formats et protocoles de données, ce qui le rend compatible avec différents outils de surveillance et d’analyse. Les données analysées peuvent être présentées par le biais de tableaux de bord et de rapports interactifs, fournissant des informations exploitables aux administrateurs réseau.
Modes de télémétrie
La télémétrie Junos prend en charge les sessions de télémétrie selon deux modes :
Les appareils Juniper peuvent fonctionner en mode d’appel entrant et sortant. Vous pouvez configurer l'appareil Juniper dans l'un ou l'autre mode en fonction de la topologie de votre réseau. Les deux modes utilisent les mêmes modèles de données et diffusent les mêmes données de télémétrie sur le réseau. La différence entre les deux modes dépend de la capacité du collecteur ou de l’appareil Juniper à initier et à maintenir la connexion.
Types d’abonnement
Junos Telemetry prend en charge différents modes d’abonnement, permettant une collecte de données personnalisée en fonction de besoins et de conditions spécifiques. Les modes d’abonnement sont configurés sur l’appareil à l’aide de commandes CLI ou font partie de la demande d’abonnement en fonction du type de télémétrie. Ces modes déterminent le comportement du flux de données. Les intervalles de diffusion déterminent la fréquence de transmission des données de télémétrie entre l’appareil et le collecteur. La collecte et la diffusion en continu des données sont déclenchées lorsque certaines conditions sont remplies ou que des événements se produisent qui déclenchent la collecte et la diffusion en continu des données de télémétrie. Ces déclencheurs garantissent que les données sont collectées lorsque des critères spécifiques sont remplis. Par exemple, des données de télémétrie peuvent être collectées et transmises en continu lorsqu’une perte de paquet est détectée. Les modes d’abonnement suivants sont pris en charge :
- Une fois : il s’agit d’une demande unique de données de télémétrie. Vous pouvez configurer ce type d’abonnement lorsqu’un instantané de l’état actuel des données abonnées est requis. L’appareil envoie les données de télémétrie une fois au collecteur et s’arrête.
- Poll : récupération périodique à la demande des données de télémétrie. Cette configuration est adaptée à la surveillance des capteurs à des intervalles spécifiques. Dans un scénario d’accès à distance, le collecteur s’abonne aux données de télémétrie via ce type d’abonnement, puis interroge les informations nécessaires.
- Stream : cet abonnement continu diffuse en continu des données lorsque des déclencheurs configurés se produisent.
Remarque : Tous les capteurs (OpenConfig ou natifs) ne prennent pas en charge tous les types d’abonnement.
Modes d’abonnement
Junos télémétrie prend en charge les modes d’abonnement suivants :
- ON_CHANGE : L’équipement envoie des mises à jour uniquement lorsque les données surveillées changent (par exemple, un compteur d’interface s’incrémente ou un état bascule). Ce mode convient aux mesures basées sur les événements plutôt que sur le temps.
- ÉCHANTILLON : Des mises à jour télémétriques sont diffusées en continu à intervalles réguliers en fonction de l’intervalle configuré. Ce mode convient à des mesures telles que le nombre de paquets ou les octets transférés, qui sont échantillonnés au fil du temps.
- TARGET_DEFINED : L’appareil décide du meilleur mode (SAMPLE ou ON_CHANGE) en fonction du capteur ou de la ressource surveillée. Juniper'implémentation peut utiliser SAMPLE par défaut, sauf si ON_CHANGE est explicitement pris en charge pour le capteur.
-
Remarque : Les demandes d’abonnement TARGET_DEFINED pour les chemins de configuration sont traitées uniquement comme des demandes ON_CHANGE.
-
Déterminez la configuration télémétrique appropriée pour votre réseau
La topologie de votre réseau et vos exigences en matière de données déterminent les capteurs, le type d’abonnement et le mode d’abonnement appropriés. Par exemple, utilisez des capteurs OpenConfig avec le mode d’abonnement SAMPLE pour un suivi périodique standardisé, par exemple pour la prise en charge des tableaux de bord multifournisseurs. Pour obtenir des informations spécifiques à Juniper ou basées sur des événements, telles que le dépannage matériel, utilisez des capteurs natifs avec le mode d’abonnement ON_CHANGE.
Protocoles de transport
Les protocoles de transport définissent comment les données de télémétrie sont transmises entre les équipements Junos et les collecteurs de télémétrie.
Les protocoles suivants sont pris en charge :
-
Protocole de contrôle de transmission (TCP)
-
Protocole UDP (User Datagram Protocol)
Protocole TCP
TCP est le protocole principal pris en charge par Junos Telemetry. Le protocole TCP est orienté connexion, dynamique et sécurisé (prise en charge de TLS), ce qui le rend fiable pour la livraison des données. TCP est pris en charge dans les modes de télémétrie d’appel entrant et sortant. Il constitue la couche de base des mécanismes de télémétrie tels que la pré-gNMI (propriétaire de Juniper) et la gNMI.
| Appel entrant | Appel sortant | |
|---|---|---|
| Transports | Protocole TCP | Protocole TCP |
| Séance | HTTP/2 | HTTP/2 |
| RPC Framework | gRPC | gRPC |
| API de télémétrie | gNMI | gNMI |
| Modèles de données |
|
|
Pour configurer télémétrie et décoder télémétrie messages, consultez Configurer les services gRPC, l’abonnement gNMI, les types de données pris en charge, Juniper référentiel GitHub et Protobuf Compact Message Format (Juniper propriétaire).
UDP
UDP est un protocole de transport léger et sans connexion pris en charge par la télémétrie Junos. UDP est pris en charge en mode de télémétrie d’appel sortant.
| Appel entrant | Appel sortant | |
|---|---|---|
| Transports | - | UDP |
| Séance | - | - |
| RPC Framework | - | gRPC |
| API de télémétrie | - | - |
| Modèles de données | - |
|
Dans la télémétrie UDP, les fichiers proto sont nécessaires pour décoder la structure du message de télémétrie. Pour configurer et décoder télémétrie messages, consultez Données de télémétrie en continu sur UDP, Format d’encapsulation des données de capteur, Types de données pris en charge, Juniper référentiel GitHub et Protobuf Compact Message Format (Juniper propriétaire).
Modèles de données
Les modèles de données de télémétrie Junos définissent la structure des données de télémétrie collectées à partir des équipements réseau à l’aide de YANG (Yet Another Next Generation). YANG est un langage de modélisation de données extensible basé sur des normes utilisé dans la télémétrie de Junos pour définir la configuration, les données d’état opérationnel et les appels de procédure à distance (RPC) pour les équipements réseau. Dans Junos Telemetry, les modèles YANG expriment la structure et les détails des modèles de données natifs ou OpenConfig qui contiennent les capteurs, tels que les statistiques d’interface. La norme YANG est définie dans les normes RFC 6020 et RFC 7950.
Juniper Networks publie des modules YANG pour les équipements Junos, qui peuvent être téléchargés à partir du référentiel GitHub de Juniper. À partir de la version 23.4, les modèles YANG de configuration et de télémétrie sont fusionnés et publiés dans le référentiel GitHub de Juniper. Il contient les définitions YANG pour la configuration, les RPC et les modèles de télémétrie.
Le groupe de travail OpenConfig définit le modèle de données OpenConfig. Il s’agit d’un modèle de données indépendant des fournisseurs pour configurer et gérer le réseau. Le modèle de données OpenConfig génère des données sous forme de messages Google Protocol Buffers (GPB) dans un format universel clé/valeur. Junos Telemetry vous permet d’exploiter les modèles OpenConfig pour obtenir une vue plus large et indépendante de tout fournisseur de votre réseau. Les chemins de capteur Openconfig sont utilisés pour récupérer des informations de capteur à partir de capteurs basés sur le modèle de données Openconfig. Pour une exploration détaillée du chemin des ressources Openconfig, reportez-vous à l’explorateur de modèles de données Junos YANG.
Le modèle de données natif de Juniper est un framework ouvert et extensible développé par Juniper. Ce modèle est utilisé pour diffuser des données de télémétrie sur les fonctionnalités uniques des appareils Juniper. Il s’agit notamment des statistiques d’interface, des informations de routage, des mesures de sécurité, etc. En outre, le modèle natif permet de définir des capteurs spécifiques à l’entreprise. Pour accéder aux informations provenant de capteurs Juniper ou spécifiques à une entreprise, abonnez-vous aux capteurs natifs de Juniper. Les chemins de capteur natifs sont utilisés pour récupérer des informations de capteur à partir de capteurs basés sur le modèle de données natif. Les modules YANG de Juniper pour les capteurs natifs sont disponibles dans le référentiel YANG de Juniper sur GitHub.
Explorer les chemins des capteurs
Le chemin d’un capteur de télémétrie décrit le chemin hiérarchique vers les points de données ou les mesures à surveiller. Il est utilisé pour identifier, activer et diffuser les données pertinentes. Junos Telemetry prend en charge les chemins de capteurs Openconfig et natifs :
-
Chemins des capteurs Openconfig
Pour configurer la collecte de données à partir de capteurs Openconfig, définissez les abonnements et les chemins des capteurs (par exemple,
/interfaces/interface/state/counters), configurez le collecteur de données et téléchargez les fichiers tampons du protocole de télémétrie Junos à partir de la page d’assistance de Juniper Networks. Capturez et décodez les données capturées sur le collecteur. -
Chemins de capteur natifs
Les chemins de capteur natifs sont spécifiques à Junos OS (par exemple,
/junos/system/line card/interface/) et offrent un accès granulaire, optimisé par Juniper, à des mesures spécifiques aux appareils.Les modes d’abonnement sont configurés sur l’appareil à l’aide de commandes CLI ou font partie de la demande d’abonnement en fonction du type de télémétrie. Utilisez les fichiers de la mémoire tampon de protocole pour décoder les données du capteur sur le collecteur.
Les deux types de chemins permettent de sortir des données de manière structurée dans des formats tels que JSON ou XML, ce qui assure la compatibilité avec les collecteurs externes pour une surveillance et une analyse efficaces.
- Explorateur de chemins de capteurs
- Sélection des chemins des capteurs de télémétrie
- Consignes importantes pour la sélection des chemins de capteur
- Exemple de chemin de capteur
Explorateur de chemins de capteurs
L’explorateur de modèles de données Junos YANG de Juniper Networks est un outil en ligne permettant d’afficher tous les chemins de ressources pris en charge, leurs feuilles de service correspondantes et les plates-formes d’appareils qui les prennent en charge. Il vous permet d’explorer ou de comparer divers attributs de modèles de données OpenConfig et natifs. Utilisez l’option de filtrage basée sur le numéro de version du logiciel ou du produit pour afficher la liste des chemins de ressources et des capteurs sur chaque plate-forme.
Sélection des chemins des capteurs de télémétrie
Dans un système de télémétrie basé sur un modèle, le chemin du capteur peut être configuré pour se terminer à n'importe quel niveau de la hiérarchie des conteneurs du modèle de données. En fonction des informations de télémétrie requises, vous pouvez configurer le chemin du capteur pour récupérer un vaste ensemble de données ou être très spécifique et récupérer des informations ciblées pour un capteur particulier. Par exemple, le chemin d’un capteur peut pointer vers un conteneur qui inclut toutes les statistiques d’interface sur un routeur, ou il peut être plus granulaire, en se concentrant sur une seule métrique comme la perte de paquets sur une interface spécifique.
Par exemple, pour recevoir des données de télémétrie sur les alarmes générées sur l’appareil (à l’aide du modèle de données OpenConfig), vous pouvez configurer l’un des chemins de ressources suivants en fonction de la granularité des données de capteur requise :
/system/alarms/alarm/id: Ce chemin récupère uniquement l’ID de l’alarme./system/alarms/alarm/config: Ce chemin récupère les informations détaillées de l’alarme.
La configuration des chemins de capteurs appropriés garantit un système de télémétrie efficace. Chaque chemin de ressource permet la diffusion de données en continu pour la ressource système à l’échelle mondiale, c’est-à-dire à l’échelle du système. Vous pouvez modifier chaque chemin d’accès à une ressource pour spécifier une interface logique ou physique. Le chemin d’accès aux ressources «/interfaces/interface/config » récupère la liste des éléments configurables au niveau de l’interface physique globale, tandis que le chemin d’accès «/interfaces/interface/config/name » spécifie le nom de l’interface, et l’appareil peut restreindre les valeurs autorisées pour cette branche en fonction du type d’interface.
Consignes importantes pour la sélection des chemins de capteur
Vous devez toujours indiquer le chemin complet et direct des ressources lors de la configuration des capteurs. La fourniture de chemins de ressources partiels, tels que «/components/component/ , entraîne des configurations incomplètes et des erreurs potentielles. De tels chemins de ressources peuvent imposer une charge importante à l’appareil, car il doit récupérer et afficher toutes les options disponibles dans cette hiérarchie. Pour éviter cela, vérifiez et utilisez toujours le chemin des ressources complètes pour garantir une configuration précise et efficace des capteurs.
Utilisez la convention hiérarchique de nommage des composants pour les composants système afin de vous aligner sur les normes OpenConfig. Cette convention permet d’identifier précisément les composants, en utilisant un chemin complet partant du nœud racine, comme CHASSIS0:REx pour les moteurs de routage et CHASSIS0:FPCx:PICy:NPUz les unités de traitement de réseau (NPU). Les scripts de conversion SLAX ont été mis à jour pour incorporer des caractères génériques et des expressions régulières, remplaçant les champs précédemment codés en dur.
Le tableau suivant présente des exemples de changement de nom de composant :
| Catégorie de composant |
Ancien nom |
Nouveau nom |
|---|---|---|
| Châssis |
|
|
| Le FPC |
|
|
| PIC (en anglais) |
|
|
| NPU |
|
|
| DP |
|
|
| Port |
|
|
| LE SIB |
|
|
| RE |
|
|
Un exemple de chemin complet, par fpc exemple, est /components/component[name="CHASSIS0:FPC0"]/state/parent : CHASSIS0.
Pour plus d’informations sur les conventions de dénomination des composants, consultez Vue d’ensemble des interfaces de périphérique
Exemple de chemin de capteur
| Chemin complet du capteur (recommandé) | Chemin partiel du capteur (non recommandé) |
|---|---|
/interfaces/interface/subinterfaces/subinterface/state/counters/out-pkts |
/interfaces/interface |
/interfaces/interface/ abonné produisant le chemin
/junos/system/linecard/interface/logical/ usage/ diffusé en continu signale les feuilles
parent_ae_name de nom de clé et
init_time (avec des traits de soulignement dans le nom de feuille). Le chemin
/interfaces/interface/state/ abonné produisant le chemin
/ junos/system/linecard/interface/queue/ diffusé en continu indique les feuilles
parent-ae-name du nom de clé et
init-time (avec des traits d’union dans le nom de la feuille).
Les performances des équipements Junos Evolved sont optimisées grâce à une architecture basée sur les services, dans laquelle certains processus ou démons sont activés en fonction de la configuration du service. Ces processus restent inactifs jusqu’à ce que le service soit configuré. Si un abonnement à la télémétrie cible un service inactif, aucune sortie de télémétrie n’est générée.
Format d’encapsulation des données du capteur
Le Junos télémétrie prend en charge deux méthodes d’exportation de données au format gpb (protocol buffers). Cette section décrit le format de données utilisé par les capteurs natifs lors de l’exportation de données de télémétrie sur UDP. Les données sont encapsulées dans un en-tête UDP, qui est ensuite encapsulé dans la charge utile IPv4. Ce modèle de télémétrie suit une architecture distribuée, où les données générées par les capteurs configurés sont exportées directement à partir du plan de données. En contournant le plan de contrôle, cette approche permet d’économiser les ressources du plan de contrôle pour d’autres fonctions critiques.
Un capteur natif exporte les données à proximité de la source à l’aide d’UDP. Vous pouvez exporter divers types de données de télémétrie, telles que les statistiques d’interface physique, les statistiques de compteurs de filtres de pare-feu ou les statistiques des chemins à commutation d’étiquettes (LSP). Un capteur commence à émettre des données dès qu’il est activé.
Les données du capteur sont représentées sous la forme d’un seul message de tampons de protocole structuré, nommé TelemetryStream. Le message, ou .proto fichier, illustré ci-dessous, comprend plusieurs attributs qui identifient la source de données, tels qu’une carte de ligne, un moteur de transfert de paquets ou un moteur de routage. Le nom du capteur configuré est également inclus. Pour plus d’informations sur la configuration des capteurs, voir Explorer les chemins des capteurs. Pour obtenir la liste des capteurs natifs pris en charge, reportez-vous à la section capteur (interface de télémétrie Junos).
Vous devez également télécharger les .proto fichiers de tous les capteurs pris en charge sur un serveur de streaming ou un collecteur. À partir d’un navigateur Web, accédez à l’URL de téléchargement du logiciel All Junos Platforms sur la page Juniper Networks : https://www.juniper.net/support/downloads/. Après avoir sélectionné le nom de la plate-forme Junos OS et le numéro de version, accédez à la section Outils et téléchargez le package Fichiers du modèle de données de l’interface de télémétrie Junos. Pour plus d’informations sur la configuration d’un serveur de streaming, reportez-vous à la section Serveur de streaming (interface de télémétrie Junos).
Format de message compact Protobuf (propriétaire de Juniper)
Les informations transmises au collecteur sont envoyées à l’aide de la structure de message de niveau supérieur de TelemetryStream (fichier télémétrie_top.proto). Le message contient les métadonnées des données du capteur en cours de diffusion (par exemple, le chemin du capteur, le système à partir duquel les données sont envoyées, le nœud à partir duquel les données sont envoyées, etc.). Les données réelles du capteur sont envoyées comme une extension du message de niveau supérieur. Un fichier proto séparé est envoyé pour les données du capteur. Le fichier telemetry_top.proto et le fichier sensor proto sont utilisés pour décoder les données du capteur au niveau du collecteur.
Structure du fichier télémétrie_top.proto
message TelemetryStream {
required string system_id = 1
[(telemetry_options).is_key = true];
optional uint32 component_id = 2
[(telemetry_options).is_key = true];
optional string sensor_name = 4
[(telemetry_options).is_key = true];
….
optional EnterpriseSensors enterprise = 101;
}
message EnterpriseSensors {
extensions 1 to max;
}
extend EnterpriseSensors {
// re-use IANA assigned numbers
optional JuniperNetworksSensors juniperNetworks = 2636;
}
message JuniperNetworksSensors {
extensions 1 to max; → ends with the extension message
}
Ce fichier se termine par le extension message.
Structure du fichier prototype du capteur
Ce fichier commence par le extension message.
extend JuniperNetworksSensors { → begins with the extension message
optional Port jnpr_interface_ext = 3;
}
message Port {
repeated InterfaceInfos interface_stats = 1;
}
message InterfaceInfos {
required string if_name = 1
[(telemetry_options).is_key = true];
optional uint64 init_time = 2;
…..
}
Le TelemetryStream message inclut également des structures imbriquées facultatives qui transportent différents types de données. Les structures imbriquées peuvent également contenir des données de capteur définies en privé, telles que Voir EnterpriseSensors. l’exemple ci-dessous :
//
// This file defines the top level message used for all Juniper
// Telemetry packets encoded to the protocol buffer format.
// The top level message is TelemetryStream.
//
import "google/protobuf/descriptor.proto";
extend google.protobuf.FieldOptions {
optional TelemetryFieldOptions telemetry_options = 1024;
}
message TelemetryFieldOptions {
optional bool is_key = 1;
optional bool is_timestamp = 2;
optional bool is_counter = 3;
optional bool is_gauge = 4;
}
message TelemetryStream {
// router name or export IP address
required string system_id = 1 [(telemetry_options).is_key = true];
// line card / RE (slot number)
optional uint32 component_id = 2 [(telemetry_options).is_key = true];
// PFE (if applicable)
optional uint32 sub_component_id = 3 [(telemetry_options).is_key = true];
// configured sensor name
optional string sensor_name = 4 [(telemetry_options).is_key = true];
// sequence number, monotonically increasesing for each
// system_id, component_id, sub_component_id + sensor_name.
optional uint32 sequence_number = 5;
// timestamp (milliseconds since 00:00:00 UTC 1/1/1970)
optional uint64 timestamp = 6 [(telemetry_options).is_timestamp = true];
// major version
optional uint32 version_major = 7;
// minor version
optional uint32 version_minor = 8;
optional IETFSensors ietf = 100;
optional EnterpriseSensors enterprise = 101;
}
message IETFSensors {
extensions 1 to max;
}
message EnterpriseSensors {
extensions 1 to max;
}
extend EnterpriseSensors {
// re-use IANA assigned numbers
optional JuniperNetworksSensors juniperNetworks = 2636;
}
message JuniperNetworksSensors {
extensions 1 to max;
}
Chaque entreprise, comme Juniper Networks, définit et gère les attributs générés par les capteurs d’entreprise. Chaque entreprise se voit attribuer un identifiant d’attribut unique. La convention actuelle consiste à utiliser des identificateurs de MIB d’entreprise attribués par l’IANA pour chaque attribut. Pour Juniper Networks, cet identifiant attribué est 2636.
Recommandé : Pour vérifier qu’un type de message particulier a été exporté et reçu, vérifiez les attributs sous TelemetryStream.enterprise.juniperNetworks dans le message gpb.
Voir le tableau 5 pour les descriptions de chaque élément collecté par les données des capteurs, y compris la sémantique et le schéma correspondant.
| Type d’élément |
Descriptif |
|---|---|
| Compteur |
Entier non signé qui augmente de façon monotone. Lorsqu’il atteint sa valeur maximale, il recommence à zéro. |
| Jauge |
Entier 32 bits ou 64 bits non signé dont la valeur peut augmenter ou diminuer. Un exemple de données représentées par cet élément est la valeur instantanée d’une ressource spécifique, telle que la profondeur de file d’attente ou la température. |
| Tarif |
Taux auquel une métrique de base change, telle qu’un compteur ou une jauge. Pour ce type d’élément, les unités de mesure sont définies explicitement (telles que les bits par seconde), ainsi que l’intervalle sur lequel le débit est collecté. |
| Moyenne |
Moyenne de plusieurs échantillons d’une métrique de base. Par exemple, un élément de données de profondeur de file d’attente moyenne serait calculé en faisant la moyenne de plusieurs éléments de la profondeur de file d’attente. Pour ce type d’élément, nous vous recommandons fortement de définir le nombre de mesures utilisées pour calculer la moyenne, ainsi que l’intervalle de temps entre les mesures. Sinon, vous devez définir explicitement le moyen par lequel cette valeur moyenne est calculée. |
| Pic |
Valeur maximale parmi plusieurs échantillons d’une métrique de base. Par exemple, un élément de profondeur de file d’attente maximale serait calculé en comparant plusieurs mesures de la profondeur de file d’attente et en sélectionnant la valeur maximale. Pour ce type d’élément de données, nous vous recommandons vivement de définir le nombre de mesures utilisées pour calculer la valeur maximale, ainsi que l’intervalle de temps entre les mesures. Sinon, définissez explicitement comment cette valeur maximale est définie. Vous devez également savoir si cette valeur n’est jamais effacée et représente donc la valeur maximale globale sur toute la durée. |
Chaque type d’élément de données comprend également des sous-ensembles d’éléments. Par exemple, les éléments Counter de données et Gauge incluraient des sous-ensembles pour rate, averageet peak des mesures.
Types de données pris en charge
Une GetRequest est envoyée lorsqu’un client collecteur initie un Get RPC pour recevoir des données de télémétrie. Les éléments de données avec lesquels la cible doit renvoyer des données au collecteur sont spécifiés, y compris le type de données. Le type de données est la variable qui spécifie la forme sous laquelle les données doivent être remises.
Le Tableau 6 répertorie les types de données pris en charge par la télémétrie Junos. Sauf indication contraire, le type de données est pris en charge pour l’exportation de données de télémétrie Junos à l’aide des services d’appel de procédure à distance (gRPC), des services gNMI (Network Management Interface) gRPC ou via UDP.
| Le type |
Valeur |
Descriptif |
|---|---|---|
| chaîne |
|
Valeur de chaîne. |
| int64 |
|
Valeur entière. |
| uint64 |
|
Valeur entière non signée. |
| bool |
|
Valeur bool. |
| flottant |
|
Valeur à virgule flottante.
Remarque :
Ce type de données est obsolète. À utiliser |
| double |
|
Une valeur double est une valeur à virgule flottante 64 bits. |
| Décimal64 |
|
Decimal64 valeur codée. Pris en charge uniquement avec les services gNMI. Utilisez decimal64 pour coder un nombre décimal de précision fixe. La valeur est exprimée sous la forme d’un ensemble de chiffres, la précision spécifiant le nombre de chiffres suivant la virgule décimale dans l’ensemble de chiffres. Par exemple : message Decimal64 {
int64 digits = 1; // Set of digits.
uint32 precision = 2; // Number of digits following the decimal point.
Remarque :
Ce type de données est obsolète. À utiliser |
| ScalarArray |
|
Valeur de tableau scalaire de type mixte. Tableau homogène des valeurs de types de données mixtes (chaîne, int64, uint64, booléen flottant ou décimal64). Pris en charge uniquement avec les services gNMI. |
| Le type | Valeur | Descriptif |
|---|---|---|
| IEEEFLOAT32 | Binaire, longueur = 4 | Un nombre à virgule flottante IEEE 32 bits. Il s’agit d’un type de données de modèle Open Config. Le format de ce numéro est celui de la forme : 1-bit sign
8-bit exponent
23-bit fraction
The floating point value is calculated using:
(-1)**S * 2**(Exponent-127) * (1+Fraction)";
Remarque : Le type de données gNMI équivalent au format binaire est « byte ». Dans une réponse gNMI, des données ont été reçues de manière incorrecte d’un périphérique au format float_val et une erreur de non-conformité a été affichée. Des modifications ont été apportées pour renvoyer les données au format bytes_val. Les quatre octets (qui représentent une valeur à virgule flottante) sont envoyés dans l’ordre des octets réseau. Assurez-vous de les réorganiser dans l’ordre des octets de l’hôte avant d’interpréter la valeur.
|
Pour plus d’informations sur les types de données, consultez github et http://www.openconfig.net/.
Surveillance des performances via la télémétrie Junos
L’une des fonctions principales de la télémétrie Junos est la surveillance des performances. Le transfert de données vers un système de gestion des performances permet aux administrateurs réseau de mesurer les tendances d’utilisation des liaisons et des nœuds, et de résoudre des problèmes tels que la congestion du réseau en temps réel.
Dans un déploiement classique, l’élément réseau, ou l’équipement, transmet des données dupliquées à deux serveurs de destination qui fonctionnent comme des collecteurs du système de gestion des performances. La transmission de données vers deux collecteurs assure la redondance. La figure 1 illustre comment les collecteurs du système de gestion des performances demandent des données et comment l’appareil transmet les données. L’équipement provisionne des capteurs pour collecter et exporter des données à l’aide d’une interface de ligne de commande (CLI), d’une configuration via NETCONF ou d’appels d’abonnement gRPC. Les collecteurs demandent des données en initiant un abonnement à la télémétrie. Les données ne sont demandées qu’une seule fois et sont diffusées périodiquement.
performances
La télémétrie Junos s’appuie également sur des données en temps réel pour faciliter la synchronisation de l’état opérationnel entre un élément du réseau et un contrôleur externe, tel que le contrôleur Northstar, qui automatise la création de chemins d’ingénierie du trafic sur le réseau. Le contrôleur NorthStar peut s’abonner aux données de télémétrie sur certains éléments du réseau, telles que les statistiques de chemin à commutation d’étiquettes (LSP).