Sondes

Processeurs

Les processeurs d’entrée d’une sonde gèrent la configuration requise pour ingérer la télémétrie brute dans la sonde afin de lancer le pipeline de traitement des données. Pour ces processeurs, le nombre d’éléments de sortie d’étape (un ou plusieurs) est égal au nombre de résultats dans la ou les requêtes graphiques spécifiées. Si plusieurs requêtes graphiques sont spécifiées, par exemple. graph_query: [A, B], et la requête A correspond à 5 nœuds et la requête B à 10 nœuds, les résultats de la requête A seront accessibles à l’aide d’index de 0 à 4 et les résultats de la requête B à l’aide d’index de 5 à query_result 14.

Si le type d’entrée et/ou le type de sortie d’un processeur n’est pas spécifié, le processeur prend une seule entrée appelée et produit une seule sortie appelée.

Certains champs du processeur sont appelés expressions. Dans certains cas, il s’agit de requêtes graphiques et sont ainsi notées. Dans d’autres cas, ce sont des expressions Python qui génèrent une valeur. Par exemple, dans le processeur Accumulate, la durée peut être spécifiée sous forme d’entier avec des secondes, par exemple , ou sous forme d’expression, par 900exemple 60 * 15. Cependant, les expressions pourraient être plus utiles : il existe plusieurs façons de les paramétrer.

Les expressions prennent en charge les valeurs de chaîne. Les paramètres de configuration du processeur qui sont des chaînes et des expressions de support doivent utiliser des guillemets spéciaux lors de la spécification de la valeur statique. Par exemple, state: "up" n’est pas valide car il fera référence à la variable « up », et non à une chaîne statique. state: '"up"'

Une expression est toujours associée à une requête graphique et est exécutée pour chaque correspondance résultante de cette requête. Le contexte d’exécution de l’expression est tel que chaque variable spécifiée dans la requête est résolue en un nœud nommé dans le résultat de correspondance associé. Pour plus d’informations, consultez Exemple de collecteur de données de service .

Les processeurs graphiques ont été étendus avec query_tag_filter permettant de filtrer les résultats des requêtes graphiques par balises (nouveauté de la version 4.0). Dans les sondes IBA, les balises sont utilisées uniquement comme critères de filtrage pour les serveurs et les routeurs externes, en particulier pour la sonde ECMP Imbalance (External Interfaces) et la sonde Total East/West Traffic. Pour obtenir des informations spécifiques sur les processeurs, reportez-vous à la section Processeurs de sonde dans la section Références.

Filtres d’ingestion

Avec les « filtres d’ingestion », un résultat de requête peut ingérer plusieurs métriques dans une sonde. Les types de données de table sont utilisés pour stocker plusieurs mesures dans le cadre d’un élément de sortie à une seule étape. Les types de données de table incluent table_ns, , - pour correspondre aux types existants - , table_dssdsstable_ts , ts -nsrespectivement.

Filtre de collecte IBA

Les filtres de collecte déterminent les mesures collectées à partir des appareils cibles.

Un filtre de collecte pour un collecteur donné sur un périphérique donné est simplement un ensemble de filtres d’ingestion présents dans différentes sondes. Vous pouvez également le spécifier dans le cadre de l’activation d’un service en dehors du contexte IBA ou des sondes, mais les règles de priorité existantes pour l’activation du service s’appliquent ici : seuls les filtres d’un niveau de priorité donné sont agrégés. Lorsque plusieurs sondes spécifient un filtre d’ingestion ciblant un service spécifique sur un équipement spécifique, les mesures collectées sont une union, en d’autres termes, une mesure est publiée lorsqu’elle correspond à l’un des filtres. C’est pourquoi les données sont également filtrées par le composant contrôleur avant d’être ingérées dans les sondes IBA.

Ce filtre est évalué par les collecteurs de télémétrie, souvent pour mieux contrôler même le sous-ensemble de mesures disponibles extrait du système d’exploitation de l’appareil sous-jacent. Par exemple, pour récupérer uniquement un sous-ensemble d’itinéraires au lieu d’obtenir tous les itinéraires, ce qui peut être un nombre énorme. Dans tous les cas, seules les mesures correspondant au filtre de collecte sont publiées en tant que télémétrie brute.

Dans le cadre de l’activation d’un service sur un appareil, vous pouvez désormais spécifier des filtres de collecte pour les services. Ce filtre devient une entrée supplémentaire fournie aux collecteurs dans le cadre de « self.service_config.collection_filters ».

Format de filtre IBA

Voici les objectifs de conception/convivialité des filtres (ingestion et collecte)

1. Facilité de création : ce sont les auteurs des sondes qui la spécifient
   • Le plus souvent, les cas correspondent à n’importe lequel, correspondent à une liste donnée de valeurs possibles, correspondent à l’égalité, vérifient si la clé a des valeurs numériques.
2. Évaluation efficace - étant donné que les filtres sont évalués dans les chemins chauds de collecte ou d’ingestion.
3. Agrégatible : plusieurs filtres sont agrégés, de sorte que cette logique d’agrégation ne doit pas nécessairement relever de la responsabilité des collecteurs individuels.
4. Langage de programmation neutre - les composants fonctionnant sur des filtres peuvent être en Python ou C ++ ou un autre langage à l’avenir.
5. Programmable - se prêter à une programmabilité future autour des filtres, par le contrôleur lui-même et / ou les collecteurs, pour améliorer des choses comme la convivialité, les performances, etc.

Compte tenu des objectifs ci-dessus, voici un schéma suggéré et illustratif pour filter1. Reportez-vous aux sections sur les filtres d’ingestion pour obtenir des exemples spécifiques afin de mieux comprendre cela.

Une instance de spécification de filtre est interprétée comme AND de toutes les clés spécifiées (c’est-à-dire les contraintes par clé). Les spécifications de filtre multiples provenant de plusieurs sondes sont considérées comme OR au niveau du filtre.

Note:

Le schéma présenté ici sert uniquement à communiquer les exigences et l’ingénierie est libre de choisir n’importe quelle manière qui accomplit les cas d’utilisation indiqués.

Les processeurs de collecteur additional_properties spécifiés dans la configuration des processeurs de collecteur sont accessibles à l’aide de l’espace de noms spécial context. . Par exemple, si un collecteur définit une propriété system_role, il peut être utilisé de la manière suivante :

Note:

Le contexte des éléments est disponible tant que le jeu d’éléments est inchangé par rapport à l’ensemble d’origine dérivé de la configuration du processeur du collecteur. Une fois que les données passent par un processeur qui modifie cet ensemble, par exemple un processeur de regroupement, elles ne sont plus disponibles.

Dans le Blueprint, accédez à Analytics > Sondes pour accéder à la table des sondes. Pour accéder aux détails d’une sonde, cliquez sur son nom. Vous pouvez instancier, créer, cloner, modifier, supprimer, importer et exporter des sondes.

Vous pouvez afficher les étapes de certaines sondes de différentes manières. Par exemple, lorsque vous cliquez sur la sonde nommée Device Traffic, l’image ci-dessous s’affiche. La modification de la source de données des compteurs d’interface moyens du temps réel à la série chronologique vous permet d’afficher les séries chronologiques sous forme de graphiques distincts, de graphiques combinés : graphiques linéaires ou combinés : empilés (à partir d’Apstra version 4.0). Vous pouvez également voir l’espace disque utilisé sur chaque sonde, le cas échéant.

ATTENTION:

Si l’espace disque du contrôleur Apstra est insuffisant, les anciens fichiers de données de télémétrie sont supprimés. Pour conserver les anciennes données de télémétrie, vous pouvez augmenter la capacité avec les clusters de machines virtuelles Apstra.

La structure et la logique des sondes non linéaires avec des dizaines de processeurs ne sont pas faciles à distinguer dans la vue standard. Vous pouvez cliquer sur le bouton de développement (en haut du panneau de gauche) pour voir une représentation étendue de la façon dont les processeurs sont interdépendants (nouveau dans la version 4.0). Par exemple, l’image ci-dessous montre la vue agrandie de la sonde MLAG Imbalance .