Recommandations pour l’agrégation des données de l’interface de télémétrie Junos
L’interface de télémétrie Junos se caractérise par le fait que le traitement des données s’effectue au niveau du collecteur qui transmet les données, plutôt que de l’équipement. Les données ne sont pas automatiquement agrégées, mais elles peuvent l’être à des fins d’analyse.
L’agrégation de données est utile dans les scénarios suivants :
Données pour la même mesure sur des périodes de temps fixes, telles que le nombre moyen d’erreurs d’entrée d’interface physique sur un intervalle de 30 secondes.
Données provenant de différentes sources (telles que plusieurs cartes de ligne) pour la même mesure, telles que les statistiques LSP (Label-switched Path) ou les statistiques de compteur de filtres.
Données provenant de sources multiples, telles que les statistiques d’entrée et de sortie pour les interfaces Ethernet agrégées.
Les sections suivantes décrivent comment effectuer l’agrégation de données pour différents scénarios. Les exemples de ces sections utilisent la base de données de séries chronologiques InfluxDB pour accepter des requêtes sur les données de télémétrie. InfluxDB est une base de données open source écrite en Go spécifiquement pour gérer les données de séries chronologiques.
Agrégation de données sur des périodes de temps fixes
L’agrégation de données pour la même mesure sur des périodes de temps fixes est un moyen courant et utile de détecter des tendances. Les mesures peuvent inclure des jauges, c’est-à-dire des valeurs uniques ou des compteurs cumulatifs. Vous pouvez également agréger les données en continu.
- Exemple : agrégation de données pour les mesures de jauge
- Exemple : agrégation de données pour les statistiques cumulatives
Exemple : agrégation de données pour les mesures de jauge
Dans cet exemple, les données for JuniperNetworksSensors.jnpr_interface_ext.interface_stats.egress_queue_info.current_buffer_occupancy from sont écrites dans la base de données InfluxDB avec des balises qui identifient le nom d’hôte, un nom d’interface et le numéro de port.proto file d’attente et la mesure correspondants appelés current_buffer_occupancy. Voir le tableau 1 pour les valeurs spécifiques utilisées dans cet exemple.
| Horodatage (secondes) |
Valeur |
Étiquettes |
|---|---|---|
| 1458704133 |
1547 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704143 |
3221 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704155 |
4860 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704166 |
6550 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
Chaque point de données de mesure a un horodatage et une valeur enregistrée. Dans cet exemple, la balise queue_number est l’identificateur numérique de la file d’attente d’interface.
Pour agréger ces données sur des intervalles de 30 secondes, utilisez la requête influxDB suivante :
select mean(value) from current_buffer_occupancy where time >= $time_start and time <= $time_end and queue_number=’0’ and interface_name=’xe-1/0/0’ and host=’sjc-a’ group by time(30s)
Pour $time_start et $time_end, spécifiez la plage de temps réelle.
Exemple : agrégation de données pour les statistiques cumulatives
Certains capteurs d’interface de télémétrie Junos indiquent des valeurs de compteur cumulées, telles que le nombre de paquets entrants, défini par JuniperNetworksSensors.jnpr_interface_ext.interface_stats.ingress_stats.packets.
Il est courant de calculer les taux de trafic à partir de compteurs de paquets ou d’octets. Contrairement aux mesures de jauge, le point de données initial de la série pour les compteurs cumulatifs est utilisé uniquement pour définir la ligne de base.
Utilisez les instructions suivantes pour créer une requête de base de données pour les statistiques cumulatives :
-
Calculez la valeur cumulée pour un intervalle de temps spécifique. Vous pouvez calculer une moyenne parmi plusieurs points de données enregistrés pendant l’intervalle de temps ou interpoler une valeur. Tous les points de données doivent appartenir à la même série. Si une réinitialisation de compteur s’est produite entre les deux points de données signalés à des moments différents, n’utilisez pas les deux points de données.
-
Déterminez la valeur appropriée pour l’intervalle de temps précédent. Si un compteur a été réinitialisé depuis la dernière mise à jour, déclarez cette valeur indisponible.
-
Si l’intervalle précédent est disponible, calculez la différence entre les points de données et le taux de trafic.
Ces instructions sont résumées dans la requête influxDB suivante. Cette requête suppose que les données sont stockées dans la mesure ingress_packets. La requête utilise les mêmes balises que l’exemple de métrique de jauge ainsi que la balise pour le temps d’initialisation du compteur, init_time. La requête utilise des valeurs moyennes sur un intervalle de temps de 30 secondes. Il calcule le taux pour les mesures qui ont la même initialisation de compteur.
select non_negative_derivative(mean(value)) from ingress_packets
where time >= $time_start and time <= $time_end and
interface_name=’xe-1/0/0’ and host=’sjc-a’
group by time(30s), init_time
Utilisez la requête suivante pour calculer le nombre de paquets reçus sur un intervalle de temps, sans calculer le débit.
select difference(mean(value)) from ingress_packets where time >= $time_start and time <= $time_end and interface_name=’xe-1/0/0’ and host=’sjc-a’ group by time(30s), init_time
Dans certains cas, plusieurs points de données agrégés sont retournés par la requête pour un intervalle de temps donné. Par exemple, quatre points de données sont disponibles pour un intervalle de temps. Deux points de données ont , et les deux autres ont init_time t0init_time t1. Vous pouvez exécuter une requête qui utilise la balise d’horodatage de la dernière modification, au lieu de , last_changepour calculer la différence et calculer le taux entre les deux points de données avec le même horodatage de init_timela dernière modification.
select difference(mean(value)) from ingress_packets
where time >= $time_start and time <= $time_end and
interface_name=’xe-1/0/0’ and host=’sjc-a’
group by time(30s), last_change
Ces requêtes peuvent toutes être exécutées en tant que requêtes continues et peuvent remplir périodiquement de nouvelles mesures de séries chronologiques.
Agrégation de données provenant de plusieurs sources
Certaines mesures sont signalées à partir de plusieurs cartes de ligne ou de moteurs de transfert de paquets. Il est utile d’agréger des données provenant de différentes sources dans les scénarios suivants :
-
Le nombre de paquets et d’octets pour les chemins de commutation d’étiquettes (LSP) est indiqué séparément par chaque carte de ligne. Toutefois, une vue des chemins LSP pour l’ensemble de l’équipement est requise pour les contrôleurs d’éléments de calcul de chemin.
-
Pour les appareils Juniper Networks qui prennent en charge les files d’attente de sortie virtuelles, les statistiques de suppression de queue ou de détection précoce aléatoire pour chaque file d’attente sont signalées séparément par chaque carte de ligne pour chaque interface physique. Il est utile de pouvoir agréger les statistiques de toutes les cartes de ligne d’une interface.
-
Les compteurs de filtre d’un filtre de pare-feu relié à une table de transfert ou à une interface Ethernet agrégée sont signalés séparément par chaque carte de ligne. Il est utile d’agréger les statistiques de toutes les cartes de ligne.
Pour agréger des données provenant de plusieurs sources, procédez comme suit :
Regroupez les données pour une période spécifique pour chaque source, par exemple, chaque carte de ligne.
Agrégez les données que vous obtenez pour chaque source à l’étape 1.
Pour les données stockées dans une base de données InfluxDB, vous pouvez effectuer l’étape 1 de la procédure en exécutant une requête continue et en remplissant une nouvelle mesure. Nous vous recommandons vivement de regrouper les points de données en fonction de chaque source. Par exemple, pour les statistiques LSP, le component_id dans le message gpb identifie la carte de ligne qui envoie les données. Regroupez les points de données en fonction de chaque component_idfichier .
Exemple : agrégation de données provenant de plusieurs sources
Dans cet exemple, vous exécutez deux requêtes pour dériver le débit de paquets LSP pour les données de toutes les cartes de ligne.
Tout d’abord, vous exécutez la requête continue suivante sur la mesure nommée lsp_packet_count pour chaque component_id balise et la counter_name balise. Chaque balise unique component_id correspond à une carte de ligne différente. Cette requête remplit une nouvelle mesure, lsp_packet_rate.
select non_negative_derivative(mean(value)) as value from lsp_packet_count into lsp_packet_rate group by time(30s), component_id, counter_name, host
Le capteur de statistiques LSP n’indique pas l’heure d’initialisation du compteur.
Utilisez la nouvelle mesure dérivée de cette requête continue —lsp_packet_count pour exécuter la requête suivante, qui agrège les données de toutes les cartes de ligne pour les débits de paquets d’un LSP nommé lsp-sjc-den-1.
select sum(value) from lsp_packet_rate where counter_name=’lsp-sjc-den-1’, host=’sjc-a’
Étant donné que cette requête ne regroupe pas les données en fonction de la balise ou de la carte de ligne, les débits de paquets LSP de tous les composants, ou cartes de component_id ligne, sont renvoyés.
Agrégation de données pour plusieurs mesures
Il peut être utile d’agréger des mesures pour plusieurs valeurs. Par exemple, pour les interfaces Ethernet agrégées, vous souhaiteriez généralement suivre les débits de paquets et d’octets pour chaque membre de l’interface, ainsi que l’utilisation de l’interface pour la liaison agrégée.
Exemple : agrégation de plusieurs valeurs de mesure
Dans cet exemple, vous exécutez les deux requêtes suivantes :
-
Requête continue pour calculer le nombre de paquets entrants pour chaque liaison membre dans une interface Ethernet agrégée
-
Requête pour agréger les données de comptage de paquets pour toutes les liaisons membres appartenant à la même interface Ethernet agrégée
La requête continue suivante dérive une mesure, , ingress_packetspour chaque liaison membre dans une interface Ethernet agrégée. La interface_name balise identifie chaque interface membre. Vous utilisez également la balise pour identifier l’appartenance parent-ae-name à une interface Ethernet agrégée spécifique. Le regroupement de chaque lien membre avec la balise garantit que les données ne sont collectées que pour les parent-ae-name liens membres actuels. Par exemple, une interface peut modifier son appartenance pendant l’intervalle de reporting. Le regroupement des interfaces membres avec l’interface Ethernet agrégée spécifique signifie que les données de la liaison membre ne seront pas transférées vers la nouvelle interface Ethernet agrégée dont elle est désormais membre.
select difference(mean(value)) as value from ingress_packets
into ingress_packets_difference
group by time(30s), component_id, interface_name, host, parent-ae-name
La requête suivante agrège les données des paquets entrants pour l’interface Ethernet agrégée, c’est-à-dire tous les liens membres.
select sum(value) from ingress_packets_difference
where parent-ae-name=’ae0’ and host=’sjc-a’
Cette requête agrège des données pour l’interface ae0Ethernet agrégée. La parent-ae-name balise ne vérifie pas les liens des membres réels.