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 des capteurs

Paragon Insights accepte les données provenant de Juniper, d’appareils tiers et de divers types de capteurs de télémétrie, y compris les protocoles de gestion de réseau traditionnels tels que le journal système et SNMP. Paragon Insights prend en charge les modèles push et pull de collecte de données. Dans le modèle push, vos appareils envoient des données de télémétrie à Paragon Insights par le biais de notifications d’interruption, par exemple. En mode pull, Paragon Insights interroge régulièrement vos appareils pour obtenir des données. Ce guide décrit chacune des méthodes d’ingestion prises en charge, avec des exemples, triés selon qu’elles appartiennent au modèle push ou pull. Avec chaque description, nous fournissons la version de Junos OS et les configurations d’équipement requises pour activer le type d’ingestion spécifique.

À mesure que le nombre d’objets sur le réseau et les mesures qu’ils génèrent augmentent, la collecte de statistiques opérationnelles pour surveiller l’état d’un réseau devient un défi de plus en plus important. Les modèles traditionnels de collecte de données « pull », tels que SNMP et la CLI, nécessitent un traitement supplémentaire pour interroger périodiquement l’élément réseau et peuvent limiter directement l’évolutivité.

Le modèle « push » surmonte ces limites en fournissant des données de manière asynchrone, ce qui élimine les polling. Avec ce modèle, le serveur Paragon Insights peut envoyer une seule requête à un équipement réseau pour diffuser des mises à jour périodiques. Par conséquent, le modèle « push » est hautement évolutif et peut prendre en charge la surveillance de milliers d’objets dans un réseau. Les équipements Junos prennent en charge ce modèle sous la forme de l’interface de télémétrie Junos (JTI).

Paragon Insights prend actuellement en charge cinq capteurs push-model :

Bien que le modèle « push » soit l’approche privilégiée pour son efficacité et son évolutivité, il existe encore des cas où le modèle de collecte de données « pull » est approprié. Par exemple, lorsqu’un équipement ne prend pas en charge l’interface de télémétrie Junos (JTI) ou lorsqu’il gère des équipements tiers. Avec le modèle pull, Paragon Insights demande des données aux équipements réseau à intervalles réguliers définis par l’utilisateur.

Paragon Insights prend actuellement en charge les capteurs pull-model suivants :

Gpb natif

Les capteurs natifs utilisent un modèle de données propriétaire de Juniper qui utilise les tampons de protocole Google (GPB). L’appareil envoie les données de télémétrie (lorsqu’il est configuré) sur UDP.

L’appareil envoie les données du moteur de transfert de paquets, c’est-à-dire directement à partir d’une carte de ligne. Cela signifie que les données de télémétrie sont envoyées sur le plan de transfert, de sorte que le collecteur doit disposer d’une connectivité intrabande à l’équipement.

Network telemetry setup with HealthBot collecting telemetry data from Junos device via in-band connection using Native GPB encoding. Out-of-band connection used for management.

Pour utiliser le format natif, vous configurez l’appareil avec des paramètres qui incluent l’emplacement d’envoi des données de télémétrie. Lorsque vous configurez Paragon Insights pour commencer à collecter les données, le flux s’écoule déjà vers le serveur.

Pour plus d’informations sur les capteurs natifs, consultez Présentation du format d’exportation de l’interface de télémétrie Junos des données collectées.

NetFlow

Paragon Insights prend en charge NetFlow v9 et NetFlow v10 (IPFIX) de manière native en tant que méthode d’ingestion NetFlow, à l’aide d’un modèle de données qui s’aligne sur les autres mécanismes d’ingestion de Paragon Insights. NetFlow est un protocole réseau permettant de collecter des statistiques de trafic IP, qui peuvent ensuite être exportées vers un outil pour analyse. Le format d’exportation des données NetFlow v9 est décrit dans la RFC 3954 ; NetFlow v10 est officiellement connu sous le nom d’IPFIX et normalisé dans RFC 7011.

Les équipements Junos prennent en charge la surveillance et l’agrégation des flux à l’aide de ces protocoles ; Junos OS échantillonne le trafic, crée une table de flux et envoie les détails de la table de flux à un collecteur via un port UDP configuré, en l’occurrence Paragon Insights. Paragon Insights reçoit les données Netflow entrantes, les détecte automatiquement en tant que v9 ou v10 et les traite ultérieurement.

Network setup with NetFlow data collection using Juniper HealthBot and Junos device. Solid line shows out-of-band connection via fxp0; dashed line indicates in-band NetFlow data flow via ge-0/0/0.

Comme indiqué ci-dessus, le périphérique réseau envoie les données du moteur de transfert de paquets, c’est-à-dire directement à partir d’une carte de ligne. Cela signifie que les données de flux sont envoyées sur le plan de transfert, le collecteur doit donc disposer d’une connectivité intrabande à l’équipement. Pour utiliser l’option de capteur de flux, vous configurez l’appareil avec des paramètres qui incluent l’emplacement d’envoi des données de flux. Lorsque vous configurez Paragon Insights pour commencer à collecter les données, les données de flux affluent déjà vers le serveur.

Paragon Insights utilise des modèles de flux pour identifier et décoder les données de flux entrantes avant de les envoyer pour traitement ultérieur. Paragon Insights fournit des modèles de flux prédéfinis pour NetFlow v9 et v10 (IPFIX), ou vous pouvez définir les vôtres. Les modèles prédéfinis correspondent à ceux que Junos OS prend actuellement en charge. Par exemple, le modèle Junos OS, ipv4-template, s’aligne sur le modèle hb-ipfix-ipv4-templateParagon Insights . Pour afficher les champs utilisés dans les modèles Junos OS, reportez-vous à la section Présentation de la surveillance des flux actifs en ligne.

Remarque :

Dans l’implémentation d’ingestion actuelle pour NetFlow, les types de champs suivants ne sont pas pris en charge :

  • Champs pour les éléments spécifiques à l’entreprise

  • Champs de longueur variable
Avertissement :

Pour l’ingestion NetFlow, assurez-vous qu’il n’y a pas de NAT source dans le(s) chemin(s) réseau(s) entre l’appareil et Paragon Insights. Si le chemin réseau contient du NAT source, les informations sur l’appareil reçues sont inexactes.

Un workflow classique comprend l’ajout d’un périphérique configuré NetFlow dans Paragon Insights, la configuration de modèles NetFlow, la configuration d’une règle avec un capteur de flux et le déploiement d’un playbook avec la règle sur un groupe d’appareils.

Une fois le playbook appliqué, vous pouvez commencer à surveiller les appareils.

  1. Cliquez sur Surveillance >intégrité du réseau dans la barre de navigation de gauche, puis sur l’onglet Groupe d’appareils .

  2. Sélectionnez le groupe d’appareils auquel vous avez appliqué le playbook dans le menu déroulant Groupe d’appareils .

  3. Sélectionnez un ou plusieurs des appareils à surveiller.

  4. Dans la vue en mosaïque, la tuile externe contient les paramètres de la règle que vous avez configurée précédemment.

sFlow

Paragon Insights prend nativement en charge sFlow (v5) en tant que autre méthode d’ingestion basée sur le flux.

sFlow est une technologie basée sur l’échantillonnage statistique pour les réseaux à haut débit, commutés ou routés. Vous pouvez configurer sFlow pour surveiller en continu et à vitesse filaire sur toutes les interfaces simultanément si vous le souhaitez.

sFlow fournit ou aide à :

  • Mesures détaillées et quantitatives du trafic à des vitesses gigabit

  • Compréhension des décisions de transfert

  • Dépannage des problèmes de réseau

  • Contrôle de la congestion

  • Analyse de la piste de sécurité et des pistes d’audit

  • Profilage de route

Tout ce que sFlow fait ci-dessus, il le fait sans impact sur le transfert ou les performances du réseau. Pour plus d’informations sur sFlow, consultez : RFC 3176, InMon Corporation’s sFlow : une méthode de surveillance du trafic sur les réseaux commutés et routés.

En tant que protocole d’échantillonnage statistique, l’agent sFlow de Juniper échantillonne le trafic et les compteurs sur les interfaces réseau, crée des datagrammes sFlow et les transmet à des collecteurs sFlow externes. Paragon Insights est l’un de ces collectionneurs.

Pour savoir comment configurer les paquets sFlow dans Paragon Insights, accédez à Configuration des paramètres sFlow.

OpenConfig

Pour utiliser le format OpenConfig, vous configurez l’appareil en tant que serveur gRPC. Avec Paragon Insights agissant en tant que client, vous définissez les capteurs auxquels vous souhaitez qu’il s’abonne, puis il envoie des demandes d’abonnement à l’appareil.

Les données transmises via gRPC sont formatées en paires clé/valeur OpenConfig dans des messages codés GPB (protocol buffer). Les clés sont des chaînes qui correspondent au chemin des ressources système dans le schéma OpenConfig de l’appareil surveillé ; Les valeurs correspondent à des entiers ou à des chaînes qui identifient l’état opérationnel de la ressource système, tels que les compteurs d’interface. Les messages RPC OpenConfig peuvent être transférés en masse, par exemple en fournissant plusieurs compteurs d’interface dans un message, ce qui augmente l’efficacité du transfert de message.

Pour plus d’informations sur les capteurs OpenConfig, consultez Présentation d’OpenConfig et de gRPC sur l’interface de télémétrie Junos.

RPC OpenConfig encodé gNMI

OpenConfig codé gNMI fonctionne un peu comme OpenConfig RPC en ce sens que vous devez configurer le périphérique réseau en tant que serveur OpenConfig auquel Paragon Insights fait des demandes d’abonnement. Cependant, gNMI prend en charge davantage de types d’abonnement que Paragon Insights ne prend actuellement en charge. Actuellement, Paragon Insights accepte uniquement les abonnements gNMI STREAM en mode SAMPLE. Les abonnements STREAM sont des abonnements de longue durée qui continuent, indéfiniment, à transmettre des mises à jour relatives à l’ensemble des chemins configurés dans l’abonnement. Les abonnements SAMPLE Mode STREAM doivent inclure un sample_intervalfichier .

Les messages renvoyés au client via gNMI sont encodés par l’appareil au format protobuf, JSON ou JSON-IETF et ne peuvent pas être envoyés en masse. Ceci, en partie, rend la messagerie codée gNMI moins efficace que la messagerie codée gRPC.

Avertissement :

  • Pour JSON ou JSON-IETF, il est supposé que le périphérique renvoie les mises à jour gNMI sous forme de valeurs leaf encodées en JSON, plutôt que de renvoyer une hiérarchie ou une sous-hiérarchie entière en tant qu’objet JSON.

  • Les nombres encodés en JSON ou JSON-IETF sont décodés par Paragon Insights sous forme float64, int64 ou string, conformément aux RFC 7159 et RFC 7951. Si vos règles OpenConfig contiennent des champs d’un type différent, nous vous recommandons de modifier les types de champs en conséquence.

Les équipements Junos OS et Cisco peuvent être gérés par Paragon Automation à l’aide d’OpenConfig codé gNMI. Si un périphérique ne prend pas en charge gNMI en général, ou l’abonnement STREAM en mode SAMPLE, ou ne prend pas en charge une requête OpenConfig, il renvoie l’une des erreurs suivantes :

  • Non implémenté

  • Indisponible

  • Argument invalide

Dans le cas d’un équipement Junos OS ou Cisco, l’erreur entraîne le retour de la connexion à OpenConfig RPC. Dans le cas d’un appareil tiers, la connexion échoue tout simplement en raison de l’erreur.

OpenConfig codé gNMI peut être activé au niveau de l’appareil ou du groupe d’appareils. Si cette option est activée au niveau du groupe de périphériques, tous les périphériques ajoutés au groupe utilisent gNMI par défaut. S’il est activé (ou non activé) au niveau de l’appareil, le paramètre au niveau de l’appareil a la priorité sur le paramètre au niveau du groupe d’appareils.

Remarque :

Lors de la connexion initiale, les appareils gNMI tentent d’effectuer une synchronisation initiale avec le client. L’appareil envoie un flux continu de données jusqu’à ce que l’appareil et le collecteur (Paragon Insights) soient synchronisés. Après la synchronisation initiale, l’appareil commence les opérations de streaming normales en fonction du taux de création de rapports configuré. En raison de la charge de traitement que cela crée, cette fonctionnalité est désactivée par défaut dans Paragon Insights. Il peut être activé au niveau du groupe d’appareils ou de l’appareil si nécessaire.

Pour plus d’informations sur gNMI, voir : gRPC Network Management Interface (gNMI).

Configuration de l’appareil pour OpenConfig

OpenConfig nécessite :

  • Version de Junos OS : 16.1 ou ultérieure

    • Le capteur OpenConfig nécessite que les packages OpenConfig et d’agent réseau soient installés sur l’équipement Junos. Ces packages sont intégrés à Junos OS versions 18.2X75, 18.3 et ultérieures. Pour les versions comprises entre 16.1 et 18.2X75 ou 18.2, vous devez installer les packages OpenConfig et Network Agent.

      Avant d’installer le package de l’Agent d’administration :

      • Installez Junos OS version 16.1R3 ou ultérieure.

      • Installez le module OpenConfig pour Junos OS. À l’aide d’un navigateur Web, accédez à l’URL de téléchargement du logiciel All Junos Platforms sur la page Web Juniper Networks : https://www.juniper.net/support/downloads/. Dans l’onglet Gestion du réseau , faites défiler vers le bas pour sélectionner OpenConfig. Sélectionnez l’onglet Logiciels . Sélectionnez le package OpenConfig (Junos avec FreeBSD mis à niveau). Pour plus d’informations, consultez Installation du package OpenConfig.

      • Installez des certificats d’authentification SSL (Secure Sockets Layer) sur votre équipement Juniper Networks.

        Remarque :

        Seule l’authentification SSL basée sur serveur est prise en charge. L’authentification basée sur le client n’est pas prise en charge.

      Voici un exemple de nom de package d’Agent d’infrastructure valide :

      network-agent-x86-32-16.1R4.12-C1.1.tgz

      Remarque :

      Chaque version du package de l’Agent d’administration est prise en charge sur une seule version de Junos OS uniquement. La version de Junos OS prise en charge est identifiée par le numéro de version de Junos OS inclus dans le nom du package de l’Agent d’infrastructure.

      Utilisez le package d’agent d’administration 32 bits pour les versions 32 bits et 64 bits de Junos OS ou de Junos OS Evolved.

      Pour télécharger et installer le package de l’Agent d’administration :

      1. Accédez à l’URL de téléchargement du logiciel All Junos Platforms sur la page Web Juniper Networks : https://www.juniper.net/support/downloads/.

      2. Sélectionnez le nom de la plate-forme Junos OS du logiciel que vous souhaitez télécharger.

      3. Sélectionnez le numéro de version (le numéro de la version du logiciel que vous souhaitez télécharger) dans la liste déroulante Version à droite de la page Télécharger le Logiciel.

      4. Sélectionnez l’onglet Logiciels .

      5. Accédez à la section Outils de l’onglet Logiciels et sélectionnez le package Junos Network Agent pour la version.

      6. Connectez-vous au système d’authentification de Juniper Networks à l’aide du nom d’utilisateur (généralement votre adresse e-mail) et du mot de passe fournis par un représentant de Juniper Networks.

      7. Téléchargez le logiciel sur un hôte local.

      8. Copiez le logiciel sur l’équipement Juniper Networks ou sur votre site de distribution de logiciels interne.

      9. Installez le nouveau network-agent package sur l’appareil en sortant du request system software add package-name mode opérationnel :

        Par exemple :

        Remarque :

        La commande utilise l’option validate par défaut. Cette option valide le package logiciel par rapport à la configuration actuelle comme condition préalable à l’ajout du package logiciel pour s’assurer que le périphérique redémarre correctement. Il s’agit du comportement par défaut lorsque le package logiciel ajouté est une version différente.

      Pour vérifier si les packages OpenConfig et de l’Agent d’administration sont installés, entrez la commande suivante :

      Pour plus d’informations, reportez-vous à la section Présentation d’OpenConfig et de gRPC sur l’interface de télémétrie Junos .

    • L’agent d’architecture n’est pas pris en charge sur les plates-formes PPC (MX104, MX80, etc.).

Device Configuration

Configurez un appareil en entrant la commande suivante :

Pour configurer le port OpenConfig sous Configuration des périphériques dans l’interface graphique de Paragon Automation, reportez-vous à la section Champs modifiables dans le tableau Modifier la page Périphériques dans Modifier les périphériques.

syslog

Outre les options liées à JTI mentionnées ci-dessus, Paragon Insights prend également en charge les journaux système comme méthode de collecte de données, à l’aide d’un modèle de données qui s’aligne sur d’autres mécanismes d’ingestion.

Un appareil peut envoyer des messages syslog (lorsqu’il est configuré) via UDP au serveur Paragon Insights soit hors bande via le moteur de routage (RE) à l’aide de l’interface de gestion du routeur, soit intrabande via le moteur de transfert de paquets, c’est-à-dire directement à partir d’une carte de ligne.

Syslog message flow between Junos device and HealthBot system via out-of-band fxp0 and in-band ge-0/0/0 interfaces for redundancy and flexibility.

Pour utiliser le format syslog, vous configurez l’appareil avec des paramètres qui incluent l’emplacement d’envoi des messages syslog. Lorsque vous configurez Paragon Insights pour commencer à collecter les données, les messages affluent déjà vers le serveur.

Pour plus d’informations sur syslog tel qu’il est utilisé par les appareils Juniper, consultez Vue d’ensemble du journal système de Junos OS.

Un message syslog se compose d’un en-tête, de données structurées au format clé-valeur entre crochets et du message du journal. L’en-tête se compose des informations suivantes :

  • Priorité journalisée

  • Numéro de version de la spécification du protocole Syslog au format d’en-tête.

    Actuellement, ce nombre est de 1.

  • Horodatage du moment où le message a été généré au format « Mmm jj hh :mm :ss ».

  • Le nom d’hôte identifie le périphérique qui a envoyé le message syslog.

  • Nom de l’application

  • ID du processus de candidature

  • Message ID

Configuration requise pour configurer Syslog dans Paragon Insights

L’ingestion syslog nécessite une certaine configuration avant de pouvoir l’utiliser comme capteur dans une règle :

  • Pattern - Un pattern identifie un événement syslog ; Vous créez un modèle pour chaque événement que vous souhaitez surveiller. Vous pouvez configurer des modèles pour les événements structurés et non structurés.

  • Jeu de modèles - Une fois les modèles configurés, vous les regroupez ensuite dans un ensemble de modèles, auquel vous faites ensuite référence lors de la définition des paramètres du capteur syslog dans une règle.

Avant de configurer les modèles et l’ensemble de modèles pour l’ingestion Syslog, notez que les champs suivants sont courants dans les messages syslog. Paragon Insights extrait ces champs et les inclut automatiquement dans la table brute, ce qui vous permet de les utiliser directement lors de la création d’une règle et d’éviter d’avoir à configurer des modèles.

Pour illustrer l’utilisation de ces valeurs, considérez les exemples de messages syslog suivants :

Structuré - <30>1 2019-11-22T03:17:53.605-08:00 R1 mib2d 28633 SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

Équivalent non structuré - <30>Nov 22 03:17:53 R1 mib2d[28633]: SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

Champs générés par le système :

  • « __log_priority__ » - Priorité du message syslog

    • Dans les exemples, <30> indique la priorité

  • « __log_timestamp__ » - Horodatage en epcoh dans le message syslog

    • Dans l’exemple structuré, 2019-11-22T03:17:53.605-08:00 est converti en époque avec -08:00 indiquant le fuseau horaire

    • Dans l’exemple non structuré, le fuseau horaire de la configuration sera utilisé pour calculer l’époque

  • « __log_host__ » - Nom d’hôte dans le message syslog

    • Dans les exemples, R1 désigne le nom d’hôte

  • « __log_application_name__ » - Nom de l’application dans le message syslog

    • Dans les exemples, mib2d le nom de l’application

  • « __log_application_process_id__ » - ID du processus d’application dans le message syslog

    • Dans les exemples, 28633 l’ID

  • « __log_message_payload__ » - charge utile dans le message

    • Exemple structuré - “SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

    • Exemple non structuré - “SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

  • « event-id » - Indique l’ID d’événement configuré dans le modèle

    • Dans les exemples, SNMP_TRAP_LINK_DOWN se trouve l’ID d’événement

Remarque :

Veillez à ne pas définir de nouveaux champs en utilisant un nom déjà défini ci-dessus.

Pour savoir comment configurer l’ingestion Syslog, consultez Configurer l’ingestion du journal système.

Capteur de surveillance du serveur

Dans Paragon Automation, le capteur de surveillance des serveurs collecte des données à partir des serveurs et des machines virtuelles sur lesquels vous hébergez l’application Paragon. Le capteur utilise le plug-in tiers Node Exporter. Le plug-in Node Exporter est préinstallé dans tous les clusters de serveurs de Paragon Automation. Dans l’interface graphique, les serveurs et les machines virtuelles par défaut déployés dans le cluster Paragon Automation sont représentés sous forme de périphériques qui sont automatiquement ajoutés au groupe de périphériques Paragon-Cluster . Le capteur collecte des données à partir des serveurs et des machines virtuelles pour suivre les mesures du processeur, de la mémoire, du réseau, du trafic, du disque et du système de fichiers. Il écrit la sortie dans une base de données de séries chronologiques.

Remarque :

Les utilisateurs ne doivent pas supprimer le groupe d’appareils Paragon-Cluster par défaut.

Paragon Automation dispose des playbooks préconfigurés suivants pour surveiller les données des serveurs.

  • Utilisation du processeur
  • Lectures et écritures sur disque
  • Erreurs, octets disponibles et octets utilisés dans le système de fichiers
  • Octets utilisés et octets disponibles en mémoire
  • Taille totale des paquets reçus et transmis, erreurs dans les paquets reçus et transmis, nombre total de paquets multicast reçus et transmis dans le réseau

Lorsque vous configurez une règle à l’aide de l’ingestion de la surveillance des serveurs, vous pouvez utiliser certains des chemins de capteur répertoriés dans le tableau 1.

Tableau 1 : métriques du serveur
Chemin du capteur Descriptif
/nœud/démarrage/heure/secondes Heure de démarrage de chaque nœud du serveur.
/nœud/cpu/secondes/total Durée totale (en secondes) pendant laquelle le processeur reste en mode veille, système, utilisateur et agréable.
/nœud/disque/lecture/octets/total Nombre total d’octets lus avec succès.
/node/disk/read/errors/total Nombre total d’erreurs de lecture dans un nœud.
/node/disque/lecture/tentatives/total Nombre de fois que l’ingestion tente de lire à partir du disque en cas d’échec.
/nœud/disque/lecture/secteurs/total Le nombre total de secteurs a été lu avec succès.
/node/disk/read/time/seconds/total Temps total nécessaire pour effectuer des lectures avec succès par nœud.
/node/disque/lectures/completed/total Nombre total de lectures effectuées avec succès.
/nœud/disque/écriture/erreurs/total Nombre total d’erreurs d’écriture
/node/disque/écriture/tentatives/total Nombre de fois que l’ingestion tente d’écrire sur le disque en cas d’échec.
/nœud/disque/écriture/heure/secondes/total Temps total nécessaire pour terminer toutes les écritures.
/node/disk/writes/completed/total Nombre total d’écritures effectuées par nœud.
/node/disk/write/bytes/total Nombre total d’octets écrits avec succès.
/nœud/disque/écrit/secteurs/total Nombre total de secteurs écrits avec succès.
/node/exporter/build/info Une métrique qui a la valeur « 1 » et qui a la version, la révision, la version go et la branche à partir de laquelle l’exportateur de nœud est construit.
/node/filesystem/avail/bytes Taille du système de fichiers disponible pour les utilisateurs non-root.
/nœud/système de fichiers/périphérique/erreur Nombre d’erreurs d’E/S qui se produisent lors de la collecte de données à partir d’un système de fichiers.
/node/filesystem/files Nombre total de nœuds d’index autorisés dans un nœud.
/node/filesystem/files/free Nombre de nœuds d’index pouvant être utilisés librement dans un nœud.
/node/filesystem/free/bytes L’espace libre (en octets) disponible pour l’utilisateur, à l’exclusion des blocs réservés.
/node/filesystem/readonly Données indiquant si le système de fichiers d’un nœud est monté en lecture seule.
/node/filesystem/size/bytes Taille de tous les fichiers en octets.
/nœud/charge1 Charge sur chaque nœud serveur/hôte capturée toutes les 1 minute.
/nœud/charge15 Charge sur chaque nœud serveur/hôte capturée toutes les 15 minutes.
/nœud/charge5 Charge sur chaque nœud serveur/hôte capturée toutes les 5 minutes.
/node/memory/active/bytes Octets mémoire activement utilisés par les processus.
/node/memory/compressed/bytes Taille totale de la mémoire compressée.
/node/memory/free/bytes Mémoire totale en octets libre d’utilisation dans un nœud.
/nœud/mémoire/inactif/octets Octets mémoire qui ne sont pas activement utilisés par les processus.
/node/memory/swap/total/bytes Mémoire totale échangée dans un nœud.
/node/memory/swap/used/bytes Quantité de mémoire permutée utilisée dans un nœud.
/node/memory/swapped/in/bytes/total Total échangé en mémoire dans un nœud.
/node/memory/swapped/out/bytes/total Nombre total de mémoire échangée dans un nœud.
/nœud/mémoire/total/octets Nombre total d’octets de mémoire dans un nœud.
/nœud/mémoire/filaire/octets Mémoire qui ne peut pas être échangée.
/node/network/receive/bytes/total Taille totale des paquets reçus par un équipement.
/node/network/receive/errs/total Nombre total d’erreurs rencontrées par un équipement lors de la réception de paquets.
/node/network/receive/multicast/total Nombre total de paquets de multicast reçus par un équipement.
/node/network/receive/packets/total Nombre total de paquets reçus par un équipement.
/node/network/transmit/bytes/total Taille totale des paquets envoyés à partir d’un appareil.
/node/network/transmit/errs/total Nombre total d’erreurs rencontrées par un appareil lors de la transmission de paquets.
/node/network/transmit/multicast/total Nombre total de paquets multicast transmis par un équipement.
/node/network/transmit/packets/total Nombre total de paquets transmis par un équipement.
/node/scrape/collector/duration/secondes Temps pris par chaque collecteur pour extraire les métriques.
/node/scrape/collector/success Nombre de fois où le collecteur Node Exporter a réussi à gratter des cibles.
/node/textfile/scrape/error Erreurs rencontrées par l’exportateur de nœuds lors de l’extraction de cibles à l’aide de scripts de fichier texte.
/nœud/heure/secondes Affiche l’heure système en secondes dans le nœud depuis Epoch (1970).
/node/uname/info Nom du nœud à partir duquel Node Exporter collecte les métriques.

Les balises suivantes, telles que le mode, l’appareil, etc., peuvent être utilisées comme champs clés applicables à toutes les mesures répertoriées sous les mesures principales (/node/cpu ou /node/network).

Lorsque vous configurez un champ clé dans une règle, vous ne pouvez mentionner que le nom du champ clé dans le champ Chemin .

  • /nœud/cpu/
    • cpu: nombre de cœurs disponibles dans le CPU.
    • mode: Le type d’utilisation du processeur dans un nœud tel que inactif, système, utilisateur et agréable.
  • /nœud/disque/
    • device: Nom des disques tels que disk0, disk1, sda, sdb ou sdc.
  • /node/filesystem/
    • device: chemins de disque tels que /dev/sda1, /dev/sda2 et /dev/sdb1
    • fstype: Type de formatage de partition tel que ext4, NTFS (New Technology File System) et APFS (Apple File System).
    • mountpoint: Monter les chemins dans l’appareil.
  • /nœud/réseau/
    • device: noms d’interface du périphérique tels que wlan0, en0 ou docker0.

Pour configurer un exemple de règle à l’aide de Server Monitoring Ingest, consultez Configurer une règle à l’aide de Server Monitoring Sensor

iAgent (CLI/NETCONF)

Malgré tous les avantages des méthodes de collecte de données « push », certaines informations opérationnelles et d’état sont disponibles uniquement via des commandes CLI/VTY. iAgent comble cette lacune en tirant parti de la fonctionnalité NETCONF/SSH pour permettre à Paragon Automation de se connecter à un appareil, d’exécuter des commandes et de capturer les résultats.

Les capteurs iAgent utilisent des tables et des vues PyEZ basées sur NETCONF/SSH et YAML pour récupérer les données nécessaires. Les données structurées (XML) et non structurées (commandes VTY et sortie CLI) sont prises en charge.

Avec iAgent, le serveur Paragon Automation initie les requêtes SSH entrantes sur n’importe quelle interface réseau disponible, qu’elle soit intrabande ou hors bande ; et l’appareil répond (lorsqu’il est correctement configuré) avec les données demandées.

Communication flow between Juniper HealthBot, iAgent, and Junos device highlighting Out-of-Band and In-Band connections with NETCONF and operational/configuration data paths.

Dans la plate-forme Paragon Automation, l’ingestion iAgent est étendue aux équipements d’autres fournisseurs tels qu’Arista Networks, Palo Alto Networks et Cisco.

Vous devez configurer un équipement Junos pour envoyer des données de télémétrie à l’aide d’un capteur iAgent ou d’une connexion NETCONF.

Au minimum, iAgent (NETCONF) nécessite :

  • Version de Junos OS : 11.4 ou ultérieure

  • Configuration minimale requise de l’appareil :

Pour configurer le port iAgent ou NETCONF pour la connexion entrante dans l’interface graphique de Paragon Automation, reportez-vous au Tableau 1.

Paragon Automation utilise Netmiko pour établir des connexions SSH entrantes sur le port sélectionné vers un équipement tiers. Pour collecter des informations sur l’appareil, Paragon Automation envoie des commandes CLI via SSH et reçoit des blobs de chaîne en sortie. Les objets blob de chaînes sont ensuite analysés via TextFSM, à l’aide de modèles NTC au format JSON, puis stockés dans la base de données. Les modèles par défaut se trouvent dans /srv/salt/_textfsm. Vous pouvez visiter le référentiel GitHub de modèles NTC pour les périphériques réseau.

Pour les utilisateurs avancés qui ont besoin d’un modèle qui n’existe pas, vous pouvez créer vos propres modèles et les télécharger sur Paragon Insights à l’aide du bouton Télécharger les fichiers de règles sur la page Configuration > Règles . Les modèles définis par l’utilisateur sont stockés dans /jfit/_textfsm. Les fichiers doivent se terminer par le suffixe .textfsm . Pour savoir comment télécharger des règles prédéfinies dans la plate-forme Paragon Automation, reportez-vous à la section Ajouter une règle prédéfinie.

TextFSM est intégré à la fonction table/view de PyEZ qui fait partie intégrante d’iAgent.

Example: PaloAlto Panos– Show Running Security Policy

Pour voir la politique de sécurité en cours d’exécution sur un appareil Panos, nous devons :

Définir la table/vue PyEZ

Nous devons définir une table PyEZ qui est utilisée par la règle iAgent affectée au périphérique Panos. La définition de table suivante manque de définition de vue. Pour cette raison, toute la sortie de la show running security-policy finit par être stockée dans la base de données après traitement.

(Facultatif) Pour stocker uniquement une partie des données reçues dans Paragon Automation, vous pouvez définir une vue dans le même fichier. La vue indique à Paragon Automation les champs auxquels prêter attention.

Collecter les résultats des appareils

À l’aide d’une règle iAgent qui fait référence à la table (ou table/vue) PyEZ définie ci-dessus, Paragon Automation envoie la commande show running security-policy à l’appareil, qui produit le résultat suivant :

Générez du JSON pour une utilisation dans la base de données Paragon Automation

Étant donné que la configuration de l’appareil spécifie Palo Alto Networks comme fournisseur et Panos OS comme système d’exploitation, le modèle TextFSM utilisé pour cet exemple ressemblerait à ceci :

Lorsque le modèle ci-dessus est utilisé par Paragon Automation pour analyser la sortie affichée précédemment, le JSON résultant ressemble à :

SSH sortant (initié par l’appareil)

Paragon Automation prend également en charge les connexions iAgent (NETCONF) initiées par l’appareil à l’aide de SSH sortant. Grâce à cette configuration, Paragon Automation agit comme le client de l’appareil qui établit la connexion. Ce type de connexion est utile dans les environnements dans lesquels les appareils distants ne peuvent pas accepter les connexions entrantes. Toutes les règles iAgent existantes peuvent être utilisées lorsque SSH sortant est configuré dans les équipements Junos.

Remarque :

Les connexions NETCONF sur SSH sont prises en charge uniquement sur les équipements Junos.

SSH sortant est désactivé par défaut. Vous pouvez configurer une connexion SSH sortante :

  • Dans l’ingestion en configurant un seul port. Ce port est utilisé par tous les groupes d’appareils.

  • Dans les groupes de périphériques en configurant ses ports. Cette configuration est prioritaire sur la configuration d’ingestion.

Lorsque vous configurez SSH sortant dans device-groups, vous devez entrer un numéro de port TCP sur lequel tous les périphériques membres initient leurs connexions NETCONF à Paragon Automation. Vous pouvez désactiver SSH sortant dans un appareil via la CLI de gestion. Pour configurer les ports SSH sortants dans les groupes d’appareils, reportez-vous à la section ports de la configuration du groupe d’appareils dans Ajouter un groupe d’appareils.

Paragon Automation prend en charge un seul port TCP pour les connexions SSH sortantes iAgent (NETCONF) de tous les groupes d’appareils. Ce port peut être configuré au niveau de l’ingestion. Vous pouvez éviter d’ouvrir plusieurs ports TCP dans différents groupes d’appareils et simplifier la gestion du réseau avec un seul port. Pour configurer le port iAgent lors de l’ingestion, consultez Configurer le port SSH sortant pour iAgent.

Vous pouvez connecter un appareil géré dans différents groupes d’appareils via SSH sortant en configurant plusieurs clients, où chaque client a le même port. Dans ce cas, vous devez créer autant de copies de l’appareil qu’il y a de groupes d’appareils. Chaque périphérique doit avoir le même numéro de port.

À titre d’exemple, considérons l’appareil r0 (10.1.1.1) configuré pour les groupes d’appareils dg1 et dg2. Pour connecter 10.1.1.1 aux deux groupes d’appareils via le même port SSH sortant, vous pouvez créer un autre appareil r1 (10.1.1.1) avec la même adresse IP et le déployer dans dg2.

Vous devez également configurer Paragon Automation pour ces ports dans les groupes d’appareils respectifs. La figure 1 est un exemple de configuration de groupe d’appareils.

Figure 1 : Modifier la configuration Configuration interface for editing device group with fields for description, device selection, and advanced settings like flow ingest, reports, and retention policies. Options to Save or Save and Deploy. du groupe d’appareils

À l’aide des exemples de configuration client suivants, l’appareil 10.1.1.1 peut se connecter à deux groupes d’appareils à l’aide de deux clients SSH sortants avec le même port.

Remarque :

Dans l’exemple, 10.1.1.1 indique l’adresse IP de Paragon Automation (hôte).

SNMP

SNMP est un protocole de gestion de réseau largement connu et accepté que de nombreux fabricants d’équipements réseau, dont Juniper Networks, fournissent pour leurs équipements. Il s’agit d’un protocole de type interrogation dans le cadre duquel les équipements réseau configurés pour SNMP mettent à la disposition des collecteurs des informations de configuration, de diagnostic et d’événement, qui doivent également être correctement configurées et authentifiées. Les collecteurs interrogent les appareils en envoyant des requêtes structurées spécifiques, appelées requêtes get, pour récupérer des données.

Paragon Automation prend en charge SNMP comme type de capteur, à l’aide de requêtes get standard pour collecter des statistiques à partir de l’appareil. Paragon Automation émet des requêtes sur n’importe quelle interface disponible, qu’elle soit intrabande ou hors bande, et l’appareil répond (lorsqu’il est configuré) avec les données demandées.

Communication flow between HealthBot system and Junos Device using SNMP via fxp0 for out-of-band and ge-0/0/0 for in-band management paths.

Pour plus d’informations sur le SNMP tel qu’il est utilisé sur les équipements Junos OS, reportez-vous à la section Comprendre l’implémentation SNMP dans Junos OS.

Paragon Insights prend également en charge les instances d’objets scalaires ainsi que les objets tabulaires dans SNMP.

  • L’objet SNMP peut être scalaire, tabulaire ou une combinaison des deux dans les règles. Lorsque vous créez une règle en utilisant l’ingestion SNMP, vous pouvez ajouter :

    • Uniquement des champs scalaires.

    • Une combinaison de champs tabulaires et scalaires.

    • Une colonne tabulaire avec l’index interrogé en tant qu’objet scalaire.

      Une colonne tabulaire interrogée en tant que scalaire est limitée par le fait que le numéro d’index ne fait pas référence au même objet sur tous les appareils lorsque vous configurez le champ tabulaire dans la règle. Par exemple, IF-MIB::ifAdminStatus.16. Le ifAdminStatus est une colonne de la table IF MIB . Le IF-MIB::ifAdminStatus.16 fait référence à la colonne du tableau avec l’index 16.

    • Uniquement les champs tabulaires.

  • Un objet scalaire est identifié par son nom de MIB (par exemple, JUNIPER-MIB::scalarObjectName) ou par un OID.

  • Paragon Insights valide un scalaire donné en vérifiant la MAX-ACCESS propriété dans la définition de la MIB.

    Si vous trouvez MAX-ACCESS dans la définition de la MIB défini sur lecture seule, lecture-création ou lecture-écriture, cet objet peut être interrogé en tant que scalaire.

Le chemin complet pour interroger un objet scalaire est MIB-Name::table column name:index number .

Par exemple, IF-MIB::ifInOctets:16 .

Prochaine étape