Configurar un sensor de telemetría de proxy NETCONF en Junos
Mediante 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 NETCONF y la API XML de Junos documentan completamente todas las opciones para cada solicitud operativa Junos OS compatible. Después de configurar los sensores de proxy XML, puede tener acceso a los datos a través de llamadas de procedimiento remoto (RPCs) "get" de NETCONF.
Esta tarea muestra cómo transmitir la salida de un comando en modo operativo de Junos OS.
Recomendamos no usar archivos YANG que se asignen a un comando operativo de Junos OS con salida extensa o detallada o que sea lento en la producción. Los comandos con un retraso notable deben evitarse en los archivos YANG. Incluir 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 verbosidad depende de factores como la configuración y el hardware. Algunos ejemplos de estos comandos incluyen cualquier variación de show interfaces, show route, show arp, show bfd, show bgp, y 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 bien una aproximación basada en el revestimiento interno de la base. Puede ser menos 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 con criterio según el rendimiento del dispositivo.
Puede emitir el comando command-name| display xml antes de usar un archivo YANG que se asigne a un comando en modo operativo Junos OS o Junos OS Evolucionado para comprobar que el comando produce una salida XML válida 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:
-
El uso de cpu del proceso xmlproxyd sigue siendo alto. Si xmlproxyd tiene el rastreo habilitado, la utilización de la CPU es aún mayor.
-
Un aumento en la utilización de memoria del proceso xmlproxyd.
-
El estado de proceso xmlproxyd puede mostrar
sbwait, lo que indica que la salida del comando es detallada y que xmlproxyd está pasando un tiempo significativo leyendo la salida de la llamada a procedimiento remoto del comando (RPC). -
Los datos del sensor xmlproxyd no completan la envoltura.
-
Xmlproxyd transmite datos parciales o nulos para los sensores.
-
El xmlproxyd pierde los ciclos de intervalos de informes. Los intervalos comienzan a superponerse debido a la salida detallada de un comando, lo que da como resultado que los datos de transmisión del sensor xmlproxyd sean lentos o retrasados.
-
Es posible que el proceso o la aplicación que sirve al comando detallado DE LARR muestre altos números de CPU o retrasos en la realización de las tareas principales. Este comportamiento se produce cuando el proceso o la aplicación están ocupados sirviendo al RPC que tiene una salida detallada.
Esta tarea requiere lo siguiente:
-
Un enrutador serie MX, vMX o serie PTX que funcione con Junos OS versión 17.3R2 o posterior.
-
Instalación del paquete de 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 verificar el correcto funcionamiento de su sensor de telemetría.
En esta tarea, transmitirá el contenido del comando show system usersJunos OS .
muestra a los 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 en 1, 5 y 15 minutos. Puede encontrar los promedios de carga mediante el show system users | display xml comando para ver el etiquetado XML para los campos de salida. Consulte <load-average-1>, <load-average-5>, y <load-average-15> en la salida de etiquetado XML que se encuentra 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 leaf, como date-time, up-time. active-user-county 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 denominado 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 CLI de Junos que se va a ejecutar, la ruta de recurso en la que se colocan los sensores y los pares de valores de clave tomados de las etiquetas XML correspondientes.
Los archivos YANG personalizados para Junos OS cumplen con 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. Ciertas directivas deben estar presentes en el archivo que configura el proxy XML.
Para usar el xmlproxyd proceso (demonio) 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 módulo y el nombre del nombre de módulo de YANG proxy XML deben comenzar por xmlproxyd_:
Para el nombre de archivo YANG 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 por modificar un ejemplo de trabajo.
Cargar el archivo Yang en Junos
Una vez completado el archivo YANG, cargue el archivo YANG y verifique que el módulo está creado.
Recopilar datos de sensores
Utilice 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 de proxy XML.
- Para los enrutadores PTX10008 que funcionan con Junos OS Evolucionado, no conecte más de 10 recolectores por enrutador para RPC de telemetría.
- Dado que xmlproxyd realiza el procesamiento de XML y texto, un dispositivo solo debe contener sensores de proxy XML que se ejecuten dentro del intervalo de utilización de CPU.
Las siguientes instrucciones usan el jtimon del recopilador. Para obtener más 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, utilice el request system yang conjunto de comandos desde el modo operativo:
Ver también
Solución de problemas de sensores de telemetría
Problema
Descripción
Utilice los siguientes métodos para solucionar problemas de los sensores de telemetría de definición del usuario:
Ejecute una tcpdump para la interfaz de la que provenían sus solicitudes gRPC (para esta tarea, se utilizó la interfaz
fxp0).user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
Habilite las evaluaciones de seguimiento mediante el set services analytics traceoptions flag xmlproxy comando. Compruebe el
xmlproxydarchivo de registro para confirmar si se envió el RPC del comando de la CLI y si se recibió una respuesta:
Emita el show log xmlproxyd comando para mostrar el 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