Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Présentation de l’agrégation intégrée

Les appareils Juniper prennent en charge l’agrégation intégrée. Les compteurs d’interface, CoS, MPLS, AF et AE sont agrégés par l’appareil, qui transmet ensuite les données de télémétrie à un collecteur. Par rapport à l’agrégation hors boîte, où les compteurs sont diffusés en continu vers le collecteur et agrégés là-bas, l’agrégation sur la boîte fournit des données de télémétrie plus précises. L’agrégation intégrée reconnaît également les événements systémiques, tels que les réinitialisations de carte de ligne ou les changements d’appartenance aux LAG. L’agrégation sur carton réduit les erreurs de production au niveau du collecteur. Il réduit également considérablement l’utilisation globale de la bande passante des données de télémétrie dans certains environnements cloud où les données sont mesurées.

Logique d’agrégation

L’agrégation de données est la simple addition de valeurs de compteur données à partir de toutes les instances du moteur de transfert de paquets reçues sous forme de messages Google protobuf dans les processus du module d’agrégation. Le module d’agrégation met en cache les statistiques de plusieurs moteurs de transfert de paquets en fonction de la demande d’abonnement reçue. La mise en cache se fait par abonnement reçu.

Les points suivants s’appliquent à l’agrégation des données :

  • Si les données statistiques sont de type jauge, les valeurs de champ sont Average, Max ou Min, et le module d’agrégation commande l’agrégation en fonction de la valeur du champ de type de jauge.

  • L’agrégation est effectuée pour les types de données de compteur et de jauge annotés dans le fichier YANG.

  • À tout moment, une seule source de données est disponible dans le cache pour un moteur de transfert de paquets donné. Les nouvelles entrées écrasent le cache existant.

  • Aucun minuteur distinct n’agrège ou ne diffuse les données. Chaque fois que des exemples de données sont reçus d’un moteur de transfert de paquets, le temps d’agrégation et de diffusion est vérifié à l’aide de l’horodatage agrégé précédemment envoyé. Par exemple:

  • Horodatage actuel : horodatage précédemment agrégé > reporting_interval

  • L’horodatage d’exportation comporte un horodatage médian pour les données agrégées.

  • La mise en cache des enregistrements dans le démon na-grpcd n’est disponible que lorsque l’abonnement est valide (actif). Lorsqu’un abonnement est inactif, les données de télémétrie agrégées exportées peuvent ne pas correspondre aux statistiques de l’interface de ligne de commande du moteur de routage. Les déclencheurs suivants peuvent créer cette incompatibilité :

    • Redémarrage d’un ou plusieurs FPC dans lesquels les membres enfants font partie de l’interface agrégée.

    • Suppression d’un maximum de n-1 membres enfants (au moins un lien enfant est actif) d’une interface d’agrégation.

  • Enfin, si l’abonnement est supprimé, le cache associé est également supprimé.

Dans un flux gNMI ou gRPC, le premier échantillon peut ne pas contenir de valeurs de compteur de statistiques agrégées, car le premier intervalle du moteur de routage peut n’avoir reçu qu’un seul échantillon de plusieurs FPC. Cependant, à partir du deuxième intervalle, le flux contiendra les valeurs agrégées des compteurs reçus de tous les FPC.

L’agrégation des échantillons est déclenchée en fonction de l’un des échantillons entrants. La figure 1 montre que l’échantillon S2 est retardé. En raison de ce délai, l’agrégation A2 utilise l’ancien échantillon t0 avec un horodatage médian des échantillons. Ceci est étiqueté t1' (bien qu'en réalité il s'agisse de t1).

Figure 1 : Agrégation des intervalles Graph showing data aggregation over time with a dashed blue line and diamond markers. Orange line labeled Aggregated Stream connects points A1, A2, and A3. d’échantillonnage

Exportation de données du moteur de transfert de paquets

La fonctionnalité d’agrégation s’appuie sur l’interface de télémétrie fondamentale basée sur le protobuf pour exporter les données du moteur de transfert de paquets. Un flux de télémétrie basé sur le protobuf encapsule les données à exporter dans une enveloppe commune de niveau supérieur appelée TelemetryStream (illustrée ci-dessous).

Cette enveloppe de niveau supérieur fournit les informations nécessaires pour construire le cache de statistiques du moteur de transfert de paquets dans une opération appelée combinateur. Le combinateur effectue une jointure logique sur plusieurs instances de données ayant un ID d’interface et un ID de file d’attente communs, et produit des statistiques de file d’attente de sortie agrégées à l’échelle du système. Chaque protobuf entrant est organisé dans le cache à l’aide d’un capteur, d’un composant et d’un champ d’emplacement du moteur de transfert de paquets dans le protobuf TelemetryStream . Le combinateur garde une trace des données d’instance par moteur de transfert de paquets en mettant en cache la dernière exportation de protobuf à partir du moteur de transfert de paquets pour un capteur spécifique. L’utilisation de protobuf binaire comme unité d’agrégation garantit une surcharge minimale de mise en cache et de comptabilité pour chaque collection de compteurs contenus dans le protobuf.

Un horodatage sur les données de télémétrie exportées à partir du moteur de transfert de paquets déclenche le calcul des données agrégées. Si le temps écoulé depuis l’exportation précédente des données agrégées dépasse l’intervalle d’actualisation du capteur, une nouvelle valeur agrégée est exportée. Cette nouvelle valeur utilise l’horodatage du dernier exemple du moteur de transfert de paquets qui a déclenché l’exportation de la valeur agrégée. Cette méthode élimine le besoin d’exécuter une minuterie par capteur à l’intérieur du combinateur pour récolter des données agrégées. De plus, la mise en cache de la dernière exportation de données reçues à partir du moteur de transfert de paquets réduit la « dérive » dans les données agrégées exportées. Ceci est particulièrement utile dans des cas tels que l’exportation retardée du moteur de transfert de paquets, ainsi que pour les modifications opérationnelles qui peuvent potentiellement empêcher toute exportation ultérieure à partir du moteur de transfert de paquets.

Identification d’échantillons de données agrégées

Vous pouvez identifier les échantillons agrégés par le composant du champ d’en-tête avec la valeur na-grpcd. Le démon na-grpcd produit les données agrégées.

Conseils d’utilisation

Gardez à l’esprit les considérations suivantes lorsque vous utilisez l’agrégation intégrée :

  • Le calcul des débits de paquets et d’octets est basé sur le message d’horodatage des statistiques agrégées. Étant donné que le message d’horodatage est synthétisé sur un moteur de routage, mais qu’il est basé sur des données mises en cache provenant de plusieurs FPC, les paquets et le débit d’octets peuvent ne pas être exacts. La précision est plus élevée lorsque la configuration de l’intervalle de rapport est raisonnable (conformément aux directives relatives aux meilleures pratiques).

  • Si les moteurs de transfert de paquets n’exportent pas les messages statistiques (par exemple, si l’état de fonctionnement est inactif), les statistiques d’agrégation ne sont pas exportées vers le collecteur.

  • Attendez-vous à ce que les statistiques de télémétrie MPLS LSP avec un bundle AE présentent un écart de 5 % dans les débits de paquets et d’octets.

Chemins d’accès aux ressources pris en charge

Les agrégations intégrées prennent en charge les chemins d’accès aux ressources suivants :

  • /junos/system/linecard/interface/traffic/

  • /junos/system/linecard/interface/queue/

  • /junos/system/linecard/interface/logical/usage/

  • /junos/system/linecard/cos/interface/interface-set/output/queue/

  • /junos/services/label-switched-path/usage/

  • /qos/interfaces/interface/output/queues/queue/state/

  • /interfaces/interface/état/compteurs/

  • /interfaces/interface/sous-interfaces/sous-interface/état/compteurs/

  • /interfaces/interface/subinterfaces/subinterface/ipv4/state/counters/

  • /interfaces/interface/subinterfaces/subinterface/ipv6/état/compteurs/

  • /instances-réseau/instance-réseau/mpls/lsps/chemin-contraint/tunnels/tunnel/état/compteurs/

  • /junos/system/linecard/interface/queue/ (chemin d’accès aux ressources natives CoS)

  • /junos/system/linecard/qmon-sw/ (chemin d’accès aux ressources natives CoS)

  • /qos/interfaces/interface/output/queues/queue/state/ (chemin d’accès à la ressource OpenConfig CoS)

  • /qos/interfaces/interface/input/virtual-output-queues/voq-interface/queues/queue/state/ (chemin d’accès aux ressources OpenConfig CoS)

  • /junos/system/linecard/interface/queue/ (chemin natif pour les statistiques des interfaces physiques, interfaces AE prises en charge)

  • /qos/interfaces/interface/output/queues/queue/state/ (interfaces AE prises en charge)

Pour plus d’informations sur les chemins d’accès aux ressources, leurs feuilles prises en charge et les plates-formes de périphériques qui les prennent en charge, reportez-vous à l’Explorateur de modèles de données Junos YANG .

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libérer
Description
23.2R1
À partir de la version 23.2R1 de Junos OS, l’agrégation intégrée est prise en charge sur les compteurs d’interface, CoS, MPLS et Ethernet agrégés. Les plates-formes prises en charge sont les suivantes : MX150, MX204, MX240, MX304, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10004, MX10008, MX10016 et vMX.