Configurer un capteur de télémétrie proxy NETCONF dans Junos
Grâce au streaming de télémétrie Junos, vous pouvez transformer n’importe quelle information d’état disponible 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 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 par l’intermédiaire d’appels de procédure à distance NETCONF « get » (RPC).
Cette tâche vous montre comment diffuser en continu la sortie d’une commande du mode opérationnel Junos OS.
Nous vous recommandons de ne pas utiliser de fichiers YANG qui s’associent à une commande opérationnelle Junos OS avec une sortie détaillée ou détaillée, ou qui est lente à produire. 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.
Le résultat de certaines commandes de mode opérationnel est dynamique et leur niveau de verbosité dépend de facteurs tels que la configuration et le matériel. Des exemples de ces commandes incluent les variantes de show interfaces, show route, show arp, show bfdshow bgpet show ddos-protection.
Pour vérifier le niveau de verbosité d’une commande, émettez la command-name| display xml count commande. Si le nombre de lignes dépasse une valeur de 4 000 lignes, la commande n’est pas recommandée pour la diffusion de proxy XML. Cette valeur est davantage une approximation basée sur la base interne. Il peut être moins dépendant de divers facteurs tels que le type d’équipement, la puissance de traitement de l’équipement et la charge du processeur existant. Par conséquent, cette fonctionnalité doit être utilisée judicieusement en fonction des performances de l’équipement.
Vous pouvez émettre la commande command-name| display xml avant d’utiliser un fichier YANG qui s’associe à une commande de 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 formatage non valides.
L’utilisation d’un fichier YANG qui correspond à une commande détaillée permet d’obtenir un ou plusieurs des résultats suivants :
-
L’utilisation du processeur du processus xmlproxyd reste élevée. Si le traçage de xmlproxyd est activé, l’utilisation du processeur est encore plus élevée.
-
Une augmentation de l’utilisation de la mémoire de processus xmlproxyd.
-
L'état du processus xmlproxyd peut indiquer
sbwait, ce qui indique 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 du capteur xmlproxyd ne complètent pas l’enveloppement.
-
Le xmlproxyd transmet des données partielles ou inexistantes 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 entraîne le flux de données du capteur xmlproxyd qui est lent ou retardé.
-
Le processus ou l'application qui sert le RPC de la commande verbose peut afficher des nombres de processeur élevés ou des retards dans l'exécution des tâches principales. Ce comportement est causé 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 exploitant Junos OS version 17.3R2 ou ultérieure.
-
Installation du package d’agent réseau requis (agent réseau-x86-32-17.4R1.16-C1.tgz ou versions ultérieures).
-
Un récepteur de données de télémétrie, comme 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 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, le show system users résultat 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. Voir <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 indiquée dans la sortie précédente est un conteneur qui contient des leafs, telles que date-time, up-time, active-user-count. et load-average-1. Voici 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 dispose également d’un autre conteneur nommé user-table qui contient une liste d’entrées d’utilisateurs.
Voici 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 Cli Junos à exécuter, le chemin de ressources sous lequel les capteurs sont placés et les paires de valeurs de clés issues 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 doivent être présentes dans le fichier qui configure le proxy XML.
Pour traduire les données de télémétrie à l’aide du xmlproxyd processus (daemon), créez un render.yang fichier. Dans ce fichier, le dr:command-app fichier est défini sur xmlproxyd.
Le nom de fichier et le nom du module YANG du proxy XML doivent commencer xmlproxyd_par :
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 du 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 fichier YANG et vérifiez que le module est créé.
Collecte des données des capteurs
Utilisez votre collecteur favori pour extraire les données du capteur de télémétrie nouvellement créés de l’équipement.
Tenez compte des contraintes de ressources avant de lancer des capteurs :
- Évitez de spécifier le même intervalle de reporting pour plusieurs capteurs proxy XML.
- Pour les routeurs PTX10008 exploitant Junos OS Evolved, ne connectez pas plus de 10 collecteurs par routeur pour les RPC de télémétrie.
- Comme xmlproxyd effectue le traitement XML et le traitement du texte, un équipement doit uniquement contenir 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 l’équipement se fermera 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 pour 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 les options de suivi à 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 :
Émettez 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