Configurer un capteur de télémétrie proxy NETCONF dans Junos
Grâce à la diffusion en continu de la télémétrie Junos, vous pouvez transformer toutes les informations d’état disponibles en capteur de télémétrie à l’aide de la fonctionnalité de proxy XML. Le protocole de gestion XML NETCONF et l’API Junos XML documentent de manière complète toutes les options pour chaque demande opérationnelle Junos OS prise en charge. Une fois que vous avez configuré les capteurs proxy XML, vous pouvez accéder aux données via des appels de procédure à distance (RPC) NETCONF « get ».
Cette tâche vous montre comment diffuser la sortie d’une commande en mode opérationnel Junos OS.
Nous vous recommandons de ne pas utiliser de fichiers YANG qui correspondent à une commande opérationnelle Junos OS avec une sortie étendue ou détaillée ou qui est lente à produire une sortie. Les commandes avec un retard notable doivent être évitées dans les fichiers YANG. L’inclusion de telles commandes peut affecter d’autres capteurs xmlproxyd ainsi que les performances de xmlproxyd.
La sortie de certaines commandes en mode opérationnel est dynamique et le niveau de leur verbosité dépend de facteurs tels que la configuration et le matériel. Des exemples de telles commandes incluent toute variation de show interfaces, show route, show arp, show bfdshow bgp, , et show ddos-protection.
Pour vérifier le niveau de détail d’une commande, exécutez la command-namecommande | display xml | count . Si le nombre de lignes dépasse une valeur de 4000 lignes, la commande n’est pas recommandée pour la diffusion en continu proxy XML. Il s’agit plutôt d’une approximation basée sur le revêtement de base interne. Elle peut être inférieure en fonction de divers facteurs tels que le type d’appareil, la puissance de traitement de l’appareil et la charge existante du processeur. Par conséquent, cette fonctionnalité doit être utilisée judicieusement en fonction des performances de l’appareil.
Vous pouvez exécuter la commande command-name| display xml avant d’utiliser un fichier YANG mappé à une commande en mode opérationnel Junos OS ou Junos OS Evolved pour vérifier que la commande produit une sortie XML valide et ne contient pas de balises, de données ou de mise en forme non valides.
L’utilisation d’un fichier YANG mappé à une commande détaillée entraîne l’un ou plusieurs des éléments suivants :
-
L’utilisation du processeur du processus xmlproxyd reste élevée. Si le suivi est activé sur xmlproxyd, l’utilisation du processeur est encore plus élevée.
-
Une augmentation de l’utilisation de la mémoire du processus xmlproxyd.
-
L'état du processus xmlproxyd peut s'afficher
sbwait, ce qui indique que la sortie de la commande est verbeuse et que xmlproxyd passe beaucoup de temps à lire la sortie de l'appel de procédure à distance (RPC) de la commande. -
Les données du capteur xmlproxyd ne complètent pas l’encapsulation.
-
Le xmlproxyd ne transmet qu’une partie ou pas de données aux capteurs.
-
Le xmlproxyd manque les cycles d’intervalle de rapport. Les intervalles commencent à se chevaucher en raison de la sortie verbeuse d'une commande, ce qui ralentit ou retarde le flux de données du capteur xmlproxyd.
-
Le processus ou l'application qui sert le RPC de la commande verbeuse peut afficher un nombre élevé de CPU ou des retards dans l'exécution des tâches principales. Ce comportement se produit lorsque le processus ou l’application est occupé à servir le RPC dont la sortie est détaillée.
Cette tâche requiert les éléments suivants :
-
Un routeur MX Series, vMX Series ou PTX Series exécutant Junos OS version 17.3R2 ou ultérieure.
-
Un récepteur de données de télémétrie, tel qu’OpenNTI, pour vérifier le bon fonctionnement de votre capteur de télémétrie.
Dans cette tâche, vous allez diffuser le contenu de la commande show system usersJunos OS .
afficher les utilisateurs du système (vMX Series)
user@switch> show system users USER TTY FROM LOGIN@ IDLE WHAT user1 pts/0 172.31.12.36 12:40PM 39 -cli (cli) user2 pts/1 172,16.03.25 3:01AM - -cli (cli)
En plus de la liste attendue des utilisateurs actuellement connectés, la show system users sortie fournit également la charge système moyenne de 1, 5 et 15 minutes. Vous pouvez trouver les moyennes de charge à l’aide de la show system users | display xml commande pour afficher le balisage XML des champs de sortie. Reportez-vous à la section <load-average-1>, <load-average-5>, et <load-average-15> dans la sortie de balisage XML ci-dessous.
user@switch> show system users | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.4R1/junos">
<system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos">
<uptime-information>
<date-time junos:seconds="1520170982">1:43PM</date-time>
<up-time junos:seconds="86460">1 day, 40 mins</up-time>
<active-user-count junos:format="2 users">2</active-user-count>
<load-average-1>0.70</load-average-1>
<load-average-5>0.58</load-average-5>
<load-average-15>0.55</load-average-15>
<user-table>
<user-entry>
<user>root</user>
<tty>pts/0</tty>
<from>172.21.0.1</from>
<login-time junos:seconds="1520167202">12:40PM</login-time>
<idle-time junos:seconds="0">-</idle-time>
<command>cli</command>
</user-entry>
<user-entry>
<user>mwiget</user>
<tty>pts/1</tty>
<from>66.129.241.10</from>
<login-time junos:seconds="1520170862">1:41PM</login-time>
<idle-time junos:seconds="60">1</idle-time>
<command>cli</command>
</user-entry>
</user-table>
</uptime-information>
</system-users-information>
<cli>
<banner></banner>
</cli>
</rpc-reply>
La uptime-information balise affichée dans la sortie précédente est un conteneur qui contient des feuilles, telles que date-time, up-time, active-user-count. et load-average-1. Vous trouverez ci-dessous un exemple de fichier YANG pour ce conteneur :
container uptime-information {
dr:source "uptime-information"; // Exact name of the XML tag
leaf date-time { // YANG model leaf
type string; // Type of value
dr:source date-time; // Exact name of the XML tag
}
leaf up-time { // YANG model leaf
type string; // Type of value
dr:source up-time; // Exact name of the XML tag
}
leaf active-user-count { // YANG model leaf
type int32; // Type of value
dr:source active-user-count; // Exact name of the XML tag
}
leaf load-average-1 { // YANG model leaf
type string; // Type of value
dr:source load-average-1; // Exact name of the XML tag
}
...
La uptime-information balise comporte également un autre conteneur nommé user-table qui contient une liste d’entrées utilisateur.
Vous trouverez ci-dessous un exemple de fichier YANG pour ce conteneur :
container user-table { // "user-table" container which contains list of user-entry
dr:source "user-table"; // Exact name of the XML tag
list user-entry { // "user-entry" list which contains the users' details in form of leafs
key "user"; // Key for the list "user-entry" which is a leaf in the list "user-entry"
dr:source "user-entry"; // Source of the list "user-entry" which is the exact name of the XML tag
leaf user { // YANG model leaf
dr:source user; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf tty { // YANG model leaf
dr:source tty; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf from { // YANG model leaf
dr:source from; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf login-time { // YANG model leaf
dr:source login-time; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf idle-time { // YANG model leaf
dr:source idle-time; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
leaf command { // YANG model leaf
dr:source command; // A leaf in the list "user-entry", exact name of the XML tag
type string; // Type of value
}
}
}
Création d’un fichier YANG défini par l’utilisateur
Le fichier YANG définit la commande CLI Junos à exécuter, le chemin d’accès aux ressources sous lequel les capteurs sont placés et les paires clé-valeur extraites des balises XML correspondantes.
Les fichiers YANG personnalisés pour Junos OS sont conformes à la syntaxe du langage YANG définie dans les RFC 6020 YANG 1.0 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) et RFC 7950 The YANG 1.1 Data Modeling Language. Certaines directives doivent être présentes dans le fichier qui configure le proxy XML.
Pour utiliser le xmlproxyd processus de traduction des données de télémétrie, créez un render.yang fichier. Dans ce fichier, la dr:command-app valeur est .xmlproxyd
Le nom de fichier YANG du proxy XML et le nom du module doivent commencer par xmlproxyd_:
Pour le nom de fichier YANG du proxy XML, ajoutez l’extension
.yang, par exemple,xmlproxyd_sysusers.yangPour le nom du module, utilisez le nom de fichier sans l’extension
.yang, par exemple,xmlproxyd_sysusers
Pour simplifier la création d’un fichier YANG, il est plus facile de commencer par modifier un exemple de travail.
Charger le fichier Yang dans Junos
Une fois le fichier YANG terminé, téléchargez-le et vérifiez que le module est créé.
Collecter les données du capteur
Utilisez votre collecteur préféré pour extraire les données du capteur de télémétrie nouvellement créées de l’appareil.
Tenez compte des contraintes de ressources avant d’activer des capteurs :
-
Évitez de spécifier le même intervalle de rapport pour plusieurs capteurs proxy XML.
-
Étant donné que xmlproxyd effectue des traitements XML et de texte, un périphérique ne doit contenir que des capteurs proxy XML qui s’exécutent dans la plage d’utilisation du processeur.
Collecte spécifique à la plate-forme Comportement des données des capteurs
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Utilisez le tableau suivant pour passer en revue les comportements spécifiques à vos plateformes :
| Plateforme |
Différence |
|---|---|
| PTX10008 |
Pour les routeurs PTX10008 fonctionnant Junos OS Evolved, ne connectez pas plus de 10 collecteurs par routeur pour les RPC de télémétrie. |
Les instructions suivantes utilisent le collecteur jtimon. Pour plus d’informations sur la configuration de jtimon, reportez-vous à la section Client de l’interface de télémétrie Junos.
S’il existe déjà un abonnement pour un capteur et qu’un abonnement dupliqué est configuré, la connexion entre le collecteur et l’appareil se ferme avec le message AlreadyExistsd’erreur .
Installation d’un fichier YANG défini par l’utilisateur
Pour ajouter, valider, modifier ou supprimer un fichier YANG défini par l’utilisateur pour un proxy XML pour l’interface de télémétrie Junos, utilisez l’ensemble request system yang de commandes du mode opérationnel :
Dépannage des capteurs de télémétrie
Problème
Description
Utilisez les méthodes suivantes pour dépanner les capteurs de télémétrie définis par l’utilisateur :
-
Exécutez un tcpdump pour l’interface d’où proviennent vos requêtes gRPC (pour cette tâche, c’est l’interface
fxp0qui a été utilisée).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
-
Activez les traceoptions à l’aide de la set services analytics traceoptions flag xmlproxy commande. Vérifiez dans le
xmlproxydfichier journal si le RPC de la commande CLI a été envoyé et si une réponse a été reçue :
Exécutez la show log xmlproxyd commande pour afficher le journal xmlproxyd. La valeur du champ
xmlproxy_execute_cli_command:indique si le RPC a été envoyé ou non. La valeur du champxmlproxy_build_contextindique la commande.
user@switch>show log xmlproxyd Mar 4 18:52:46 vmxdockerlight_vmx1_1 clear-log[52495]: logfile cleared Mar 4 18:52:51 xmlproxy_telemetry_start_streaming: sensor /junos/system-users-information/ Mar 4 18:52:51 xmlproxy_build_context: command show system users merge-tag: Mar 4 18:52:51 <command format="xml">show system users</command> Mar 4 18:52:51 xmlproxy_execute_cli_command: Sent RPC.. Mar 4 18:52:51 <system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos" xmlns:junos="http://xml.juniper.net/junos/*/junos"> <uptime-information> <date-time junos:seconds="1520189571"> 6:52PM </date-time> <up-time junos:seconds="107400"> 1 day, 5:50 </up-time> <active-user-count junos:format="1 users"> 1 </active-user-count> <load-average-1> 0.94 </load-average-1> <load-average-5> 0.73 </load-average-5> <load-average-15> 0.65