Recommandations pour l’agrégation des données de télémétrie Junos
L’une des caractéristiques importantes de la télémétrie Junos est que le traitement des données s’effectue au niveau du collecteur qui les diffuse, et non 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 des données est utile dans les scénarios suivants :
Données relatives à la même mesure sur des périodes déterminées, par exemple 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 fiches de lignes) pour la même métrique, telles que les statistiques LSP (Label-switched path) ou les statistiques des compteurs 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 les 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 des données de séries temporelles.
Agréger les données sur des intervalles de temps fixes
L’agrégation des données d’un même indicateur sur des périodes fixes est un moyen courant et utile de détecter les tendances. Les mesures peuvent inclure des jauges, c’est-à-dire des valeurs uniques ou des compteurs cumulés. Vous pouvez également agréger les données en continu.
- Exemple : Agrégation de données pour les métriques de jauge
- Exemple : Agréger des données pour des statistiques cumulées
Exemple : Agrégation de données pour les métriques de jauge
Dans cet exemple, les données de 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 correspondant et la mesure appelée current_buffer_occupancy . Reportez-vous au tableau 1 pour connaître 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’identifiant numérique de la file d’attente de l’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éger des données pour des statistiques cumulées
Certains capteurs d’interface de télémétrie Junos signalent des valeurs de compteur cumulées, telles que le nombre de paquets entrants, défini comme JuniperNetworksSensors.jnpr_interface_ext.interface_stats.ingress_stats.packets.
Il est courant de dériver les débits 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 cumulés 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 soit calculer une moyenne parmi plusieurs points de données enregistrés au cours de l’intervalle de temps, soit interpoler une valeur. Tous les points de données doivent appartenir à la même série. Si une réinitialisation du 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 comme 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 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 au cours d’un intervalle de temps, sans en déduire 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 renvoyé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 init_time t0, et les deux autres ont init_time t1. Vous pouvez exécuter une requête qui utilise la balise d’horodatage de la dernière modification, last_change, au lieu de , pour calculer la différence et dériver le débit entre les deux points de données ayant 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 continu et peuvent remplir périodiquement de nouvelles mesures de séries chronologiques.
Agréger des données provenant de plusieurs sources
Certaines mesures sont signalées à partir de plusieurs cartes de ligne ou 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 du périphérique est requise pour les contrôleurs d’éléments de calcul de chemin.
-
Pour les équipements Juniper Networks qui prennent en charge les files d’attente de sortie virtuelles, les statistiques d’abandon 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 pour un filtre de pare-feu connecté à 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 fiches lignes.
Pour agréger des données provenant de plusieurs sources, procédez comme suit :
Agrégez les données d’une période donnée pour chaque source, par exemple, chaque carte de ligne.
Regroupez les données que vous déduisez 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 renseignant 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 chacun d’entre component_ideux.
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 renseigne 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 le temps 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 component_id carte de ligne, les débits de paquets LSP de tous les composants, ou cartes de ligne, sont renvoyés.
Agréger les données pour plusieurs mesures
Il peut être utile d’agréger les métriques de plusieurs valeurs. Par exemple, pour les interfaces Ethernet agrégées, il est généralement préférable de 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 du nombre 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_packets, pour chaque liaison membre dans une interface Ethernet agrégée. La interface_name balise identifie chaque interface membre. Vous pouvez également utiliser la balise pour identifier l’appartenance parent-ae-name à une interface Ethernet agrégée spécifique. Le regroupement de chaque lien de membre avec la parent-ae-name balise garantit que les données sont collectées uniquement pour les liens de membre actuels. Par exemple, une interface peut changer d’appartenance au cours de l’intervalle de rapport. 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 toutes les liaisons membres.
select sum(value) from ingress_packets_difference
where parent-ae-name=’ae0’ and host=’sjc-a’
Cette requête agrège les données de l’interface ae0Ethernet agrégée. La parent-ae-name balise ne vérifie pas les liens des membres réels.