Configurar un sensor de telemetría proxy NETCONF en Junos
Con la transmisión de telemetría de Junos, puede convertir cualquier información de estado disponible en un sensor de telemetría mediante la funcionalidad Proxy XML. El protocolo de administración XML de NETCONF y la API XML de Junos documentan completamente todas las opciones para cada solicitud operativa de Junos OS compatible. Después de configurar los sensores de proxy XML, puede tener acceso a los datos a través de llamadas a procedimiento remoto (RPC) "get" de NETCONF.
En esta tarea se muestra cómo transmitir el resultado de un comando del modo operativo de Junos OS.
Recomendamos no utilizar archivos YANG que se asignen a un comando operativo de Junos OS con una salida extensa o detallada, o que sea lenta en la producción de salida. Los comandos con un retraso notable deben evitarse en los archivos YANG. La inclusión de estos comandos puede afectar a otros sensores xmlproxyd, así como al rendimiento de xmlproxyd.
El resultado de algunos comandos del modo operativo es dinámico y el nivel de su detalle depende de factores como la configuración y el hardware. Algunos ejemplos de estos comandos son cualquier variación de show interfaces, , show arp, , show bgpshow routeshow bfdy .show ddos-protection
Para comprobar el nivel de detalle de un comando, emita el command-namecomando | | display xml count . Si el recuento de líneas supera un valor de 4000 líneas, no se recomienda el comando para la transmisión de proxy XML. Este valor es más una aproximación basada en el revestimiento de base interno. Puede ser menor dependiendo de varios factores, como el tipo de dispositivo, la potencia de procesamiento del dispositivo y la carga de CPU existente. En consecuencia, esta función debe usarse juiciosamente en función del rendimiento del dispositivo.
Puede emitir el comando | display xml antes de utilizar un archivo YANG que se asigne a un comando de modo operativo Junos OS o Junos OS evolucionado para comprobar que el comando command-namegenera resultados XML válidos y no contiene etiquetas, datos ni formato no válidos.
El uso de un archivo YANG que se asigna a un comando detallado da como resultado uno o varios de los siguientes elementos:
-
El uso de CPU del proceso xmlproxyd sigue siendo elevado. Si xmlproxyd tiene habilitado el seguimiento, el uso de la CPU es aún mayor.
-
Un aumento en el uso de memoria de proceso xmlproxyd.
-
El estado del proceso xmlproxyd puede mostrar
sbwait, lo que indica que el resultado del comando es detallado y que xmlproxyd está dedicando mucho tiempo a leer la salida de la llamada a procedimiento remoto (RPC) del comando. -
Los datos del sensor xmlproxyd no completan el ajuste.
-
xmlproxyd transmite datos parciales o nulos para los sensores.
-
xmlproxyd pierde ciclos de intervalo de informes. Los intervalos comienzan a superponerse debido a la salida detallada de un comando, lo que da como resultado que el sensor de xmlproxyd transmita datos lentos o retrasados.
-
El proceso o la aplicación que sirve al RPC del comando detallado puede mostrar un alto número de CPU o retrasos en la realización de las tareas principales. Este comportamiento se produce cuando el proceso o la aplicación está ocupado sirviendo la RPC que tiene un resultado detallado.
Esta tarea requiere lo siguiente:
-
Un enrutador serie MX, vMX o PTX que ejecute Junos OS versión 17.3R2 o posterior.
-
Instalación del paquete del Agente de red necesario ( network-agent-x86–32–17.4R1.16-C1.tgz o posterior).
-
Un receptor de datos de telemetría, como OpenNTI, para comprobar el correcto funcionamiento del sensor de telemetría.
En esta tarea, transmitirá el contenido del comando show system usersde Junos OS.
mostrar usuarios del sistema (serie vMX)
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)
Además de la lista esperada de usuarios que han iniciado sesión actualmente, el show system users resultado también proporciona la carga promedio del sistema como 1, 5 y 15 minutos. Puede encontrar los promedios de carga mediante el comando para ver el show system users | display xml etiquetado XML de los campos de salida. Consulte <load-average-1>, <load-average-5>y <load-average-15> en el resultado del etiquetado XML a continuación.
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 etiqueta que se muestra en el resultado anterior es un contenedor que contiene hojas, como date-time, , up-timeactive-user-count. y load-average-1. A continuación se muestra un archivo YANG de ejemplo para este contenedor:
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 etiqueta también tiene otro contenedor llamado user-table que contiene una lista de entradas de usuario.
A continuación se muestra un archivo YANG de ejemplo para este contenedor:
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
}
}
}
Crear un archivo YANG definido por el usuario
El archivo YANG define el comando de la CLI de Junos que se ejecutará, la ruta de recursos en la que se colocan los sensores y los pares de valores clave tomados de las etiquetas XML coincidentes.
Los archivos YANG personalizados para Junos OS se ajustan a la sintaxis del lenguaje YANG definida en RFC 6020 YANG 1.0 YANG: un lenguaje de modelado de datos para el protocolo de configuración de red (NETCONF) y RFC 7950, el lenguaje de modelado de datos YANG 1.1. Algunas directivas deben estar presentes en el archivo que configura el proxy XML.
Para usar el xmlproxyd proceso (daemon) para traducir datos de telemetría, cree un render.yang archivo. En este archivo, el dr:command-app se establece en xmlproxyd.
El nombre de archivo YANG del proxy XML y el nombre del módulo deben comenzar con xmlproxyd_:
Para el nombre de archivo YANG del proxy XML, agregue la extensión
.yang, por ejemplo,xmlproxyd_sysusers.yangPara el nombre del módulo, utilice el nombre de archivo sin la extensión
.yang, por ejemplo,xmlproxyd_sysusers
Para simplificar la creación de un archivo YANG, es más fácil comenzar modificando un ejemplo de trabajo.
Cargar el archivo Yang en Junos
Una vez completado el archivo YANG, cargue el archivo YANG y verifique que se haya creado el módulo.
Recopilar datos del sensor
Use su recopilador favorito para extraer los datos del sensor de telemetría recién creados del dispositivo.
Tenga en cuenta las limitaciones de recursos antes de iniciar los sensores:
- Evite especificar el mismo intervalo de informes para varios sensores proxy XML.
- En el caso de enrutadores PTX10008 que funcionan con Junos OS Evolved, no conecte más de 10 recopiladores por enrutador para RPC de telemetría.
- Dado que xmlproxyd realiza XML y procesamiento de texto, un dispositivo solo debe contener sensores proxy XML que se ejecuten dentro del intervalo de utilización de la CPU.
Las siguientes instrucciones utilizan el recopilador jtimon. Para obtener información acerca de la configuración de jtimon, consulte Cliente de interfaz de telemetría de Junos.
Si ya existe una suscripción para un sensor y se configura una suscripción duplicada, la conexión entre el recopilador y el dispositivo se cerrará con el mensaje AlreadyExistsde error .
Instalación de un archivo YANG definido por el usuario
Para agregar, validar, modificar o eliminar un archivo YANG definido por el usuario para proxy XML para la interfaz de telemetría de Junos, use el conjunto de comandos desde el request system yang modo operativo:
Ver también
Solucionar problemas de los sensores de telemetría
Problema
Descripción
Use los métodos siguientes para solucionar problemas de los sensores de telemetría definidos por el usuario:
Ejecute un tcpdump para la interfaz de la que provienen sus solicitudes gRPC (para esta tarea, se utilizó la interfaz
fxp0).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
Habilite traceoptions mediante el set services analytics traceoptions flag xmlproxy comando. Verifique el archivo de registro para confirmar si se envió el
xmlproxydRPC del comando de CLI y si se recibió una respuesta:
Ejecute el comando para mostrar el show log xmlproxyd registro xmlproxyd. El valor del campo
xmlproxy_execute_cli_command:indica si el RPC se envió o no. El valor del campoxmlproxy_build_contextindica el comando.
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