Configuration d’un capteur de télémétrie proxy NETCONF dans Junos
Grâce au streaming de télémétrie Junos, vous pouvez transformer toutes les informations d’état disponibles en capteur de télémétrie au moyen de la fonctionnalité XML Proxy. Le protocole de gestion XML NETCONF et l’API XML Junos documentent toutes les options pour chaque demande opérationnelle Junos OS prise en charge. Après avoir configuré les capteurs proxy XML, vous pouvez accéder aux données via NETCONF « get » remote procedure calls (RPC).
Cette tâche vous montre comment diffuser la sortie d’une commande en mode de fonctionnement de Junos OS.
Nous vous recommandons de ne pas utiliser de fichiers YANG mappés à une commande opérationnelle Junos OS avec une sortie étendue ou détaillée ou dont la production est lente. 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 détail dépend de facteurs tels que la configuration et le matériel. Des exemples de telles commandes incluent toute variante de show interfaces, , , show bfdshow bgp, show routeshow arpet 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 la valeur de 4000 lignes, la commande n’est pas recommandée pour le streaming proxy XML. Cette valeur est davantage une approximation basée sur une base de référence interne. Cela peut être inférieur en fonction de divers facteurs tels que le type de périphérique, la puissance de traitement de l’appareil et la charge CPU existante. Par conséquent, cette fonctionnalité doit être utilisée judicieusement en fonction des performances de l’appareil.
Vous pouvez émettre la commande | 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 command-nameproduit une sortie XML valide et ne contient pas de balises, de données ou de formatage non valides.
L’utilisation d’un fichier YANG mappé à une commande détaillée donne un ou plusieurs des résultats 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 afficher
sbwait, indiquant que la sortie de la commande est détaillée et que xmlproxyd passe beaucoup de temps à lire la sortie de l'appel de procédure distante (RPC) de la commande. -
Les données de capteur xmlproxyd ne terminent pas le wrap.
-
Les flux xmlproxyd ne contiennent que partiellement ou pas de données pour les capteurs.
-
Le xmlproxyd manque les cycles d’intervalle de reporting. Les intervalles commencent à se chevaucher en raison de la sortie détaillée 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 détaillée peut afficher un nombre élevé de processeurs ou des retards dans l'exécution des tâches principales. Ce problème est provoqué lorsque le processus ou l’application est occupé à servir le RPC qui a une sortie détaillée.
Cette tâche nécessite les éléments suivants :
-
Un routeur MX Series, vMX Series ou PTX Series fonctionnant sous Junos OS version 17.3R2 ou ultérieure.
-
Installation du package de l’Agent d’administration requis ( network-agent-x86–32–17.4R1.16-C1.tgz ou version 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 une charge système moyenne de 1, 5 et 15 minutes. Vous pouvez trouver les moyennes de charge en utilisant la show system users | display xml commande pour afficher le balisage XML pour les champs de sortie. Voir <load-average-1>, <load-average-5>et <load-average-15> dans la sortie du 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 a é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éer un fichier YANG défini par l’utilisateur
Le fichier YANG définit la commande Junos CLI à exécuter, le chemin de ressource 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 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 qui configurent le proxy XML doivent être présentes dans le fichier.
Pour utiliser le processus (démon) afin de traduire les xmlproxyd données de télémétrie, créez un render.yang fichier. Dans ce fichier, la dr:command-app valeur xmlproxydest .
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 fonctionnel.
Charger le fichier yang dans Junos
Une fois le fichier YANG terminé, téléchargez le fichier YANG et vérifiez que le module est créé.
Collecter les données des capteurs
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 de lancer des capteurs :
- Évitez de spécifier le même intervalle de rapport pour plusieurs capteurs proxy XML.
- Pour PTX10008 routeurs exécutant Junos OS Evolved, ne connectez pas plus de 10 collecteurs par routeur pour les RPC de télémétrie.
- Étant donné que xmlproxyd effectue le traitement 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.
Les instructions suivantes utilisent le collecteur jtimon. Pour plus d’informations sur la configuration de jtimon, voir Junos Telemetry Interface Client.
Si un abonnement existe déjà pour un capteur et qu’un abonnement en double est configuré, la connexion entre le collecteur et le périphérique 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 le proxy XML de l’interface de télémétrie Junos, utilisez l’ensemble request system yang des commandes du mode opérationnel :
Voir aussi
Dépanner les 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, l’interface
fxp0a été utilisée).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
Activez traceoptions à l’aide de la set services analytics traceoptions flag xmlproxy commande. Vérifiez dans le fichier journal si le
xmlproxydRPC 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