Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Descripción general de los sensores

Paragon Insights acepta datos de Juniper, dispositivos de terceros y de varios tipos de sensores de telemetría, incluidos los protocolos tradicionales de administración de red como registro del sistema y SNMP. Paragon Insights admite modelos push y pull de recopilación de datos. En el modelo push, sus dispositivos envían datos de telemetría a Paragon Insights a través de notificaciones de trampa, por ejemplo. En el modo pull, Paragon Insights sondea periódicamente sus dispositivos en busca de datos. En esta guía se describe cada uno de los métodos de ingesta admitidos, con ejemplos, ordenados según si pertenecen al modelo de inserción o extracción. Junto con cada descripción, proporcionamos la versión de Junos OS necesaria y las configuraciones de dispositivo necesarias para habilitar el tipo de ingesta específico.

A medida que ha crecido la cantidad de objetos en la red y las métricas que generan, la recopilación de estadísticas operativas para monitorear la salud de una red se ha convertido en un desafío cada vez mayor. Los modelos tradicionales de recopilación de datos, como SNMP y la CLI, requieren un procesamiento adicional para sondear periódicamente el elemento de red y pueden limitar directamente el escalamiento.

El modelo de "empuje" supera estos límites al entregar datos de forma asíncrona, lo que elimina las encuestas. Con este modelo, el servidor de Paragon Insights puede realizar una única solicitud a un dispositivo de red para transmitir actualizaciones periódicas. Como resultado, el modelo de "inserción" es altamente escalable y puede admitir el monitoreo de miles de objetos en una red. Los dispositivos de Junos admiten este modelo en forma de interfaz de telemetría de Junos (JTI).

Paragon Insights actualmente admite cinco sensores de modelo de empuje:

Si bien el modelo de "inserción" es el enfoque preferido por su eficiencia y escalabilidad, todavía hay casos en los que el modelo de recopilación de datos de "extracción" es apropiado. Dos ejemplos pueden ser cuando un dispositivo no admite la interfaz de telemetría de Junos (JTI) o cuando se administran dispositivos de terceros. Con el modelo pull, Paragon Insights solicita datos de los dispositivos de red a intervalos periódicos definidos por el usuario.

Paragon Insights actualmente admite los siguientes sensores de modelo de tracción:

GPB nativo

Los sensores nativos utilizan un modelo de datos patentado de Juniper mediante el uso de búferes de protocolo de Google (GPB). El dispositivo inserta datos de telemetría (cuando está configurado) a través de UDP.

El dispositivo inserta datos del motor de reenvío de paquetes, es decir, directamente desde una tarjeta de línea. Esto significa que los datos de telemetría se envían a través del plano de reenvío, por lo que el recopilador debe tener conectividad en banda con el dispositivo.

Para usar el formato nativo, configure el dispositivo con opciones que incluyan dónde enviar los datos de telemetría. Cuando configure Paragon Insights para comenzar a recopilar los datos, la transmisión ya está fluyendo hacia el servidor.

Para obtener más información acerca de los sensores nativos, consulte Descripción del formato de exportación de datos recopilados de la interfaz de telemetría de Junos.

Flujo de red

Paragon Insights admite NetFlow v9 y NetFlow v10 (IPFIX) de forma nativa como método de ingesta de NetFlow, mediante un modelo de datos que se alinea con otros mecanismos de ingesta de Paragon Insights. NetFlow es un protocolo de red para recopilar estadísticas de tráfico IP, que luego se pueden exportar a una herramienta para su análisis. El formato de exportación de datos de NetFlow v9 se describe en RFC 3954; NetFlow v10 se conoce oficialmente como IPFIX y está estandarizado en RFC 7011.

Los dispositivos Junos admiten el monitoreo y la agregación de flujo mediante estos protocolos; Junos OS muestrea el tráfico, crea una tabla de flujo y envía los detalles de la tabla de flujo a través de un puerto UDP configurado a un recopilador, en este caso Paragon Insights. Paragon Insights recibe los datos entrantes de Netflow, los detecta automáticamente como v9 o v10 y los procesa más.

Como se mostró anteriormente, el dispositivo de red inserta datos desde el motor de reenvío de paquetes, es decir, directamente desde una tarjeta de línea. Esto significa que los datos de flujo se envían a través del plano de reenvío, por lo que el recopilador debe tener conectividad en banda con el dispositivo. Para usar la opción sensor de flujo, configure el dispositivo con ajustes que incluyan dónde enviar los datos de flujo. Cuando configura Paragon Insights para empezar a recopilar los datos, los datos del flujo ya están fluyendo hacia el servidor.

Paragon Insights utiliza plantillas de flujo como un mecanismo para identificar y decodificar los datos del flujo entrante antes de enviarlos para su posterior procesamiento. Paragon Insights ofrece plantillas de flujo predefinidas para NetFlow v9 y v10 (IPFIX), o puede definir las suyas propias. Las plantillas predefinidas coinciden con las que admite actualmente Junos OS. Por ejemplo, la plantilla de Junos OS, ipv4-template, se alinea con la plantilla hb-ipfix-ipv4-templatede Paragon Insights . Para ver los campos utilizados en las plantillas de Junos OS, consulte Descripción de la supervisión de flujo activo en línea.

Nota:

En la implementación de ingesta actual para NetFlow, no se admiten los siguientes tipos de campo:

  • Campos para elementos específicos de la empresa

  • Campos de longitud variable
Advertencia:

Para la ingesta de NetFlow, asegúrese de que no haya TDR de origen en las rutas de red entre el dispositivo y Paragon Insights. Si la ruta de acceso de red contiene TDR de origen, la información del dispositivo recibida no es precisa.

Un flujo de trabajo típico incluye agregar un dispositivo configurado para NetFlow en Paragon Insights, configurar plantillas de NetFlow, configurar una regla con sensor de flujo e implementar un manual con la regla en un grupo de dispositivos.

Con el manual aplicado, puede comenzar a monitorear los dispositivos.

  1. Haga clic en Supervisión > estado de la red en la barra de navegación izquierda y haga clic en la pestaña Grupo de dispositivos .

  2. Seleccione el grupo de dispositivos al que aplicó el manual en el menú desplegable Grupo de dispositivos .

  3. Seleccione uno o más de los dispositivos que desea supervisar.

  4. En la vista de mosaico, el mosaico externo contiene los parámetros de la regla que configuró anteriormente.

sFlow

Paragon Insights admite sFlow (v5) de forma nativa como otro método de ingesta basado en el flujo.

sFlow es una tecnología basada en muestreo estadístico para redes conmutadas o enrutadas de alta velocidad. Si lo desea, puede configurar sFlow para monitorear continuamente el tráfico a velocidad de cable en todas las interfaces simultáneamente.

sFlow proporciona o ayuda con:

  • Mediciones detalladas y cuantitativas del tráfico a velocidades de gigabit

  • Información sobre decisiones de reenvío

  • Solución de problemas de red

  • Control de congestión

  • Análisis de pista de auditoría y seguridad

  • Perfil de ruta

Todo lo que sFlow hace anteriormente, lo hace sin afectar el reenvío o el rendimiento de la red. Para obtener más información sobre sFlow, consulte: RFC 3176, sFlow de InMon Corporation: un método para monitorear el tráfico en redes conmutadas y enrutadas.

Como protocolo de muestreo estadístico, el agente de sFlow de Juniper muestrea el tráfico y los contadores en las interfaces de red, crea datagramas de sFlow y los reenvía a recopiladores de sFlow externos. Paragon Insights es uno de esos recopiladores.

Para saber cómo configurar paquetes de sFlow en Paragon Insights, vaya a Configurar ajustes de sFlow.

OpenConfig

Para usar el formato OpenConfig, configure el dispositivo como un servidor gRPC. Con Paragon Insights actuando como cliente, usted define a qué sensores quiere que se suscriba y realiza solicitudes de suscripción hacia el dispositivo.

Los datos transmitidos a través de gRPC se formatean en pares clave/valor OpenConfig en mensajes codificados en búfer de protocolo (GPB). Las claves son cadenas que corresponden a la ruta de los recursos del sistema en el esquema de OpenConfig para el dispositivo que se está monitoreando; Los valores corresponden a enteros o cadenas que identifican el estado operativo del recurso del sistema, como los contadores de interfaz. Los mensajes RPC de OpenConfig se pueden transferir de forma masiva, como proporcionar varios contadores de interfaz en un mensaje, lo que aumenta la eficiencia de la transferencia de mensajes.

Para obtener más información acerca de los sensores de OpenConfig, consulte Descripción de OpenConfig y gRPC en la interfaz de telemetría de Junos.

RPC de OpenConfig codificado con gNMI

OpenConfig codificado en gNMI funciona de manera muy similar a OpenConfig RPC en el sentido de que debe configurar el dispositivo de red como un servidor OpenConfig al que Paragon Insights realiza solicitudes de suscripción. Sin embargo, gNMI admite más tipos de suscripción de los que admite actualmente Paragon Insights. Actualmente, Paragon Insights solo admite suscripciones a gNMI STREAM en el modo SAMPLE. Las suscripciones STREAM son suscripciones de larga duración que continúan, indefinidamente, transmitiendo actualizaciones relacionadas con el conjunto de rutas configuradas dentro de la suscripción. Modo SAMPLE Las suscripciones a STREAM deben incluir un sample_intervalarchivo .

Los mensajes devueltos al cliente a través de gNMI están codificados por el dispositivo en formato protobuf, JSON o JSON-GTI-I y no se pueden enviar de forma masiva. Esto, en parte, hace que la mensajería codificada en gNMI sea menos eficiente que la mensajería codificada en gRPC.

Advertencia:

  • Para JSON o JSON-GTI-I, se supone que el dispositivo devuelve actualizaciones de gNMI solo como valores de hoja codificados en JSON, en lugar de devolver una jerarquía o subjerarquía completa como un objeto JSON.

  • Los números codificados en JSON o JSON-GTI-I son decodificados por Paragon Insights como float64, int64 o string, de acuerdo con RFC 7159 y RFC 7951. Si las reglas de OpenConfig contienen campos de un tipo diferente, le recomendamos que cambie los tipos de campo en consecuencia.

Paragon Automation puede administrar los dispositivos Junos OS y Cisco mediante OpenConfig codificado con gNMI. Si un dispositivo no es compatible con gNMI en general, o la suscripción STREAM en modo SAMPLE, o no admite una solicitud OpenConfig, devuelve uno de los siguientes errores:

  • Sin implementar

  • No disponible

  • Argumento inválido

En el caso de un dispositivo Junos OS o Cisco, el error hace que la conexión vuelva a la RPC de OpenConfig. En el caso de un dispositivo de terceros, la conexión simplemente falla debido al error.

OpenConfig codificado en gNMI se puede habilitar en el dispositivo o en el nivel de grupo de dispositivos. Si está habilitado en el nivel de grupo de dispositivos, todos los dispositivos agregados al grupo usan gNMI de forma predeterminada. Si está habilitada (o no habilitada) en el nivel de dispositivo, la configuración de nivel de dispositivo tiene prioridad sobre la configuración de nivel de grupo de dispositivos.

Nota:

Durante la conexión inicial, los dispositivos gNMI intentan realizar una sincronización inicial con el cliente. El dispositivo envía un flujo continuo de datos hasta que el dispositivo y el recopilador (Paragon Insights) están sincronizados. Después de la sincronización inicial, el dispositivo comienza las operaciones normales de transmisión en función de la velocidad de informe configurada. Debido a la carga de procesamiento que esto crea, Paragon Insights tiene esta función deshabilitada de forma predeterminada. Se puede habilitar en el grupo de dispositivos o en el nivel de dispositivo si es necesario.

Para obtener más información acerca de gNMI, consulte: Interfaz de administración de red gRPC (gNMI).

Configuración de dispositivos para OpenConfig

OpenConfig requiere:

  • Versión de Junos OS: 16.1 o posterior

    • El sensor OpenConfig requiere que el dispositivo Junos tenga instalados los paquetes de OpenConfig y del agente de red. Estos paquetes están integrados en las versiones 18.2X75, 18.3 y posteriores de Junos OS. Para las versiones comprendidas entre 16.1 y 18.2X75 o 18.2, debe instalar los paquetes de OpenConfig y del agente de red.

      Antes de instalar el paquete del agente de red:

      • Instale la versión 16.1R3 o posterior de Junos OS.

      • Instale el módulo OpenConfig para Junos OS. Con un navegador web, vaya a la URL de descarga del software All Junos Platforms en la página web Juniper Networks: https://www.juniper.net/support/downloads/. En la pestaña Administración de red , desplácese hacia abajo para seleccionar OpenConfig. Seleccione la pestaña Software . Seleccione el paquete OpenConfig (Junos con FreeBSD actualizado). Para obtener más información, consulte Instalación del paquete OpenConfig.

      • Instale certificados de autenticación de capa de sockets seguros (SSL) en su dispositivo de Juniper Networks.

        Nota:

        Solo se admite la autenticación SSL basada en servidor. No se admite la autenticación basada en clientes.

      Un ejemplo de un nombre de paquete de agente de red válido es:

      network-agent-x86-32-16.1R4.12-C1.1.tgz

      Nota:

      Cada versión del paquete del agente de red solo se admite en una sola versión de Junos OS. La versión de Junos OS compatible se identifica por el número de versión de Junos OS incluido en el nombre del paquete del agente de red.

      Utilice el paquete del agente de red de 32 bits para las versiones de 32 bits y 64 bits de Junos OS o Junos OS Evolved.

      Para descargar e instalar el paquete del agente de red:

      1. Vaya a la URL de descarga del software All Junos Platforms en la página web del Juniper Networks: https://www.juniper.net/support/downloads/.

      2. Seleccione el nombre de la plataforma de Junos OS para el software que desea descargar.

      3. Seleccione el número de versión (el número de la versión de software que desea descargar) en la lista desplegable Versión a la derecha de la página Descargar software.

      4. Seleccione la pestaña Software .

      5. Vaya a la sección Herramientas de la pestaña Software y seleccione el paquete de agente de red de Junos para la versión.

      6. Inicie sesión en el sistema de autentificación de Juniper Networks con el nombre de usuario (generalmente su dirección de correo electrónico) y la contraseña proporcionados por un representante de Juniper Networks.

      7. Descargue el software a un host local.

      8. Copie el software en el dispositivo de Juniper Networks o en su sitio interno de distribución de software.

      9. Instale el paquete nuevo network-agent en el dispositivo emitiendo el request system software add package-name desde el modo operativo:

        Por ejemplo:

        Nota:

        El comando utiliza la validate opción de forma predeterminada. Esta opción valida el paquete de software con la configuración actual como requisito previo para agregar el paquete de software y garantizar que el dispositivo se reinicie correctamente. Este es el comportamiento predeterminado cuando el paquete de software que se agrega es una versión diferente.

      Para comprobar si tiene instalados los paquetes OpenConfig y el agente de red, escriba el siguiente comando:

      Consulte Descripción de OpenConfig y gRPC en la interfaz de telemetría de Junos para obtener más información.

    • El agente de red no es compatible con plataformas PPC (MX104, MX80, etc.).

Device Configuration

Configure un dispositivo ingresando el siguiente comando:

Para configurar el puerto de OpenConfig en la configuración del dispositivo en la GUI de Paragon Automation, consulte Campos editables en la tabla Editar página de dispositivos en Editar dispositivos.

Syslog

Además de las opciones relacionadas con JTI anteriores, Paragon Insights también admite registros del sistema como un método de recopilación de datos, utilizando un modelo de datos que se alinea con otros mecanismos de ingesta.

Un dispositivo puede enviar mensajes syslog (cuando está configurado) a través de UDP al servidor de Paragon Insights fuera de banda a través del motor de enrutamiento (RE) mediante la interfaz de administración del enrutador, o en banda a través del motor de reenvío de paquetes, es decir, directamente desde una tarjeta de línea.

Para usar el formato syslog, configure el dispositivo con opciones que incluyan dónde enviar los mensajes syslog. Cuando configura Paragon Insights para comenzar a recopilar los datos, los mensajes ya están fluyendo hacia el servidor.

Para obtener más información sobre syslog tal como lo utilizan los dispositivos Juniper, consulte Descripción general del registro del sistema de Junos OS.

Un mensaje syslog consta de un encabezado, datos estructurados en formato de clave-valor entre corchetes y el mensaje de registro. El encabezado consta de la siguiente información:

  • Prioridad de registro

  • Número de versión de la especificación del protocolo Syslog en formato de encabezado.

    Actualmente, este número es 1.

  • Marca de tiempo de cuando se generó el mensaje en el formato "Mmm dd hh:mm:ss".

  • El nombre de host identifica el dispositivo que envió el mensaje syslog.

  • Nombre de la aplicación

  • ID del proceso de aplicación

  • ID de mensaje

Requisitos para configurar Syslog en Paragon Insights

La ingesta de Syslog requiere cierta configuración antes de poder usarla como sensor en una regla:

  • Patrón: un patrón identifica algún evento syslog; Se crea un patrón para cada evento que se desea monitorear. Puede configurar patrones para eventos estructurados y no estructurados.

  • Conjunto de patrones: con los patrones configurados, se agrupan en un conjunto de patrones, al que luego se hace referencia al definir la configuración del sensor syslog dentro de una regla.

Antes de configurar patrones y conjunto de patrones para la ingesta de syslog, tenga en cuenta que los siguientes campos son comunes en los mensajes syslog. Paragon Insights extrae estos campos y los incluye automáticamente en la tabla sin procesar, lo que le permite utilizarlos directamente al crear una regla y evitar la necesidad de configurar patrones.

Para ilustrar el uso de estos valores, considere los siguientes mensajes syslog de ejemplo:

Estructurado - <30>1 2019-11-22T03:17:53.605-08:00 R1 mib2d 28633 SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

Equivalente no estructurado - <30>Nov 22 03:17:53 R1 mib2d[28633]: SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16

Campos generados por el sistema:

  • "__log_priority__" - Prioridad del mensaje syslog

    • En los ejemplos, <30> denota la prioridad

  • "__log_timestamp__" - Marca de tiempo en epcoh en el mensaje syslog

    • En el ejemplo estructurado, 2019-11-22T03:17:53.605-08:00 se convierte a época con -08:00 que indica la zona horaria

    • En el ejemplo no estructurado, se utilizará la zona horaria de la configuración para calcular la época

  • "__log_host__": nombre de host en el mensaje syslog

    • En los ejemplos, R1 denota el nombre de host

  • "__log_application_name__": nombre de la aplicación en el mensaje syslog

    • En los ejemplos, mib2d es el nombre de la aplicación

  • "__log_application_process_id__": ID del proceso de aplicación en el mensaje syslog

    • En los ejemplos, 28633 es el ID

  • "__log_message_payload__" - carga en el mensaje

    • Ejemplo estructurado - “SNMP_TRAP_LINK_DOWN [junos@2636.10.1.1.2.29 snmp-interface-index="545" admin-status="up(1)" operational-status="down(2)" interface-name="ge-1/0/0.16"] ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

    • Ejemplo no estructurado - “SNMP_TRAP_LINK_DOWN: ifIndex 545, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/0.16”

  • "Event-id": denota el ID de evento configurado en el patrón

    • En los ejemplos, SNMP_TRAP_LINK_DOWN es el ID de evento

Nota:

Asegúrese de no definir ningún campo nuevo con un nombre ya definido anteriormente.

Para saber cómo configurar la ingesta de Syslog, consulte Configurar ingesta de registros del sistema.

Sensor de monitoreo de servidores

En Paragon Automation, el sensor Server Monitoring recopila datos de los servidores y máquinas virtuales en los que aloja la aplicación de Paragon. El sensor utiliza el complemento de terceros, Node Exporter. El complemento Exportador de nodos está preinstalado en todos los clústeres de servidores de Paragon Automation. En la GUI, los servidores predeterminados y las máquinas virtuales implementados en el clúster de Paragon Automation se representan como dispositivos que se agregan automáticamente al grupo de dispositivos de Paragon-Cluster . El sensor recopila datos de servidores y máquinas virtuales para rastrear métricas de CPU, memoria, red, tráfico, disco y sistema de archivos. Escribe la salida en una base de datos de series temporales.

Nota:

Los usuarios no deben eliminar el grupo de dispositivos predeterminado de Paragon-Cluster .

Paragon Automation tiene los siguientes manuales preconfigurados para monitorear los datos del servidor.

  • Utilización de CPU
  • Lecturas y escrituras de disco
  • Errores, bytes disponibles y bytes utilizados en el sistema de archivos
  • Bytes utilizados y bytes disponibles en la memoria
  • Tamaño total de paquetes recibidos y transmitidos, errores en paquetes recibidos y transmitidos, total de paquetes de multidifusión recibidos y transmitidos en la red

Cuando configure una regla mediante la ingesta de Server Monitoring, puede utilizar algunas de las rutas de sensor enumeradas en la tabla 1.

Tabla 1: Métricas del servidor
Descripción de la ruta del sensor
/node/boot/time/seconds Tiempo de arranque en cada nodo del servidor.
/node/cpu/seconds/total El tiempo total (en segundos) que la CPU permanece en los modos inactivo, sistema, usuario y agradable.
/node/disk/read/bytes/total Número total de bytes leídos correctamente.
/node/disk/read/errors/total Número total de errores de lectura en un nodo.
/node/disk/read/retries/total Número de veces que la ingesta intenta leer del disco si se produce un error.
/node/disk/read/sectors/total El número total de sectores leídos correctamente.
/nodo/disco/lectura/tiempo/segundos/total El tiempo total necesario para completar las lecturas correctas por nodo.
/node/disk/reads/completed/total El número total de lecturas completadas correctamente.
/node/disk/write/errors/total El número total de errores en escrituras
/node/disk/write/retries/total Número de veces que la ingesta intenta escribir en el disco si se produce un error.
/nodo/disco/escritura/tiempo/segundos/total El tiempo total necesario para completar todas las escrituras.
/node/disk/writes/completed/total Número total de escrituras completadas por nodo.
/node/disk/written/bytes/total Número total de bytes escritos correctamente.
/nodo/disco/escrito/sectores/total El número total de sectores escritos correctamente.
/node/exporter/build/info Una métrica que tiene el valor "1" y tiene versión, revisión, versión go y rama a partir de la cual se construye el exportador de nodos.
/node/filesystem/avail/bytes El tamaño del sistema de archivos disponible para usuarios que no son root.
/node/filesystem/device/error Número de errores de E/S que se producen al recopilar datos de un sistema de archivos.
/node/filesystem/files Número total de nodos de índice permitidos en un nodo.
/node/filesystem/files/free Número de nodos de índice que están libres para su uso en un nodo.
/node/filesystem/free/bytes El espacio libre (en bytes) disponible para el usuario, excluyendo los bloques reservados.
/node/filesystem/readonly Datos que muestran si el sistema de archivos en un nodo está montado como de solo lectura.
/node/filesystem/size/bytes El tamaño de todos los archivos en bytes.
/node/load1 Carga en cada nodo de servidor o host capturada cada 1 minuto.
/node/load15 Carga en cada nodo de servidor o host capturada cada 15 minutos.
/node/load5 Carga en cada nodo de servidor o host capturada cada 5 minutos.
/nodo/memoria/activo/bytes Bytes de memoria que los procesos utilizan activamente.
/nodo/memoria/comprimido/bytes Tamaño total de la memoria comprimida.
/node/memory/free/bytes Memoria total en bytes que está libre para su uso en un nodo.
/nodo/memoria/inactivo/bytes Bytes de memoria que los procesos no utilizan activamente.
/nodo/memoria/intercambio/total/bytes Memoria total intercambiada en un nodo.
/nodo/memoria/intercambio/usado/bytes La cantidad de memoria intercambiada utilizada en un nodo.
/node/memory/swapped/in/bytes/total Total intercambiado en memoria en un nodo.
/node/memory/swapped/out/bytes/total Total de memoria intercambiada en un nodo.
/nodo/memoria/total/bytes Total de bytes de memoria en un nodo.
/nodo/memoria/cableado/bytes Memoria que no se puede intercambiar.
/node/network/receive/bytes/total Tamaño total de paquetes recibidos por un dispositivo.
/node/network/receive/errs/total Número total de errores que encuentra un dispositivo al recibir paquetes.
/node/network/receive/multidifusión/total Número total de paquetes de multidifusión recibidos por un dispositivo.
/node/network/receive/packets/total Número total de paquetes recibidos por un dispositivo.
/node/network/transmit/bytes/total Tamaño total de los paquetes enviados desde un dispositivo.
/node/network/transmit/errs/total Número total de errores encontrados en un dispositivo al transmitir paquetes.
/node/network/transmit/multidifusión/total Número total de paquetes de multidifusión transmitidos por un dispositivo.
/node/network/transmit/packets/total Número total de paquetes transmitidos por un dispositivo.
/node/scrape/collector/duration/seconds Tiempo que tarda cada recolector en extraer métricas.
/node/scrape/collector/success Número de veces que el recolector de Node Exporter raspó con éxito los objetivos.
/node/textfile/scrape/error Errores encontrados por el exportador de nodos al raspar objetivos mediante scripts de archivo de texto.
/nodo/tiempo/segundos Muestra el tiempo del sistema en segundos en el nodo desde la época (1970).
/node/uname/info Nombre del nodo del que el exportador de nodos recopila métricas.

Las siguientes etiquetas, como modo, dispositivo, etc., se pueden usar como campos clave aplicables a todas las métricas enumeradas en las métricas principales (/node/cpu o /node/network).

Cuando configure un campo clave en una regla, solo puede mencionar el nombre del campo clave en el campo Ruta .

  • /nodo/cpu/
    • cpu: El número de núcleos disponibles en la CPU.
    • mode: El tipo de uso de CPU en un nodo como inactivo, sistema, usuario y agradable.
  • /nodo/disco/
    • device: Nombre de discos como disk0, disk1, sda, sdb o sdc.
  • /nodo/sistema de archivos/
    • device: Vías de acceso de disco como /dev/sda1, /dev/sda2 y /dev/sdb1
    • fstype: Tipo de formato de partición como ext4, NTFS (Sistema de archivos de nueva tecnología) y APFS (Sistema de archivos de Apple).
    • mountpoint: Rutas de montaje en el dispositivo.
  • /nodo/red/
    • device: Nombres de interfaz del dispositivo, como wlan0, en0 o docker0.

Para configurar una regla de ejemplo con Server Monitoring ingest, consulte Configurar una regla con Server Monitoring Sensor

iAgent (CLI/NETCONF)

Para todos los beneficios de los métodos de recopilación de datos "push", parte de la información operativa y de estado está disponible solo a través de comandos CLI/VTY. iAgent llena este vacío al aprovechar la funcionalidad de NETCONF/SSH para proporcionar a Paragon Automation la capacidad de conectarse a un dispositivo, ejecutar comandos y capturar la salida.

Los sensores de iAgent utilizan tablas y vistas de PyEZ basadas en NETCONF/SSH y YAML para obtener los datos necesarios. Se admiten datos estructurados (XML) y no estructurados (comandos VTY y salida de CLI).

Con iAgent, el servidor de Paragon Automation inicia solicitudes SSH entrantes a través de cualquier interfaz de red disponible, ya sea en banda o fuera de banda; y el dispositivo responde (cuando está configurado correctamente) con los datos solicitados.

En la plataforma Paragon Automation, la ingesta de iAgent se extiende a otros dispositivos de proveedores de Arista Networks, Palo Alto Networks y Cisco.

Debe configurar un dispositivo Junos para enviar datos de telemetría mediante el sensor iAgent o una conexión NETCONF.

Como mínimo, iAgent (NETCONF) requiere:

  • Versión de Junos OS: 11.4 o posterior

  • Configuración mínima requerida del dispositivo:

Para configurar el puerto iAgent o NETCONF para la conexión entrante en la GUI de Paragon Automation, consulte la Tabla 1.

Paragon Automation utiliza Netmiko para realizar conexiones SSH entrantes a través del puerto seleccionado a un dispositivo de terceros. Para recopilar información del dispositivo, Paragon Automation envía comandos de CLI a través de SSH y recibe blobs en cadenas como salida. A continuación, los blobs en cadenas se analizan a través de TextFSM, utilizando plantillas NTC en formato JSON y, a continuación, se almacenan en la base de datos. Las plantillas predeterminadas se encuentran en /srv/salt/_textfsm. Puede visitar el repositorio de GitHub de plantillas NTC para dispositivos de red.

Para los usuarios avanzados que necesitan una plantilla que no existe, puede crear sus propias plantillas y cargarlas en Paragon Insights mediante el botón Cargar archivos de reglas en la página Configuración > reglas . Las plantillas definidas por el usuario se almacenan en /jfit/_textfsm. Los archivos deben terminar con el sufijo .textfsm . Para saber cómo cargar reglas predefinidas en Paragon Automation Platform, consulte Agregar una regla predefinida.

TextFSM está integrado en la función de tabla/vista de PyEZ, que es una parte integral de iAgent.

Example: PaloAlto Panos– Show Running Security Policy

Para ver la política de seguridad en ejecución en un dispositivo Panos, necesitamos:

Definir tabla/vista de PyEZ

Necesitamos definir una tabla PyEZ que sea utilizada por la regla de iAgent asignada al dispositivo Panos. La siguiente definición de tabla carece de una definición de vista. Debido a esto, toda la salida del termina almacenándose en la base de show running security-policy datos después del procesamiento.

(Opcional) Para almacenar solo una parte de los datos recibidos en Paragon Automation, puede definir una vista en el mismo archivo. La vista le indica a Paragon Automation a qué campos debe prestar atención.

Recopilar la salida del dispositivo

Con una regla de iAgent que hace referencia a la tabla (o tabla/vista) de PyEZ definida anteriormente, Paragon Automation envía el comando show running security-policy al dispositivo, el cual produce el siguiente resultado:

Genere JSON para su uso en la base de datos de Paragon Automation

Dado que la configuración del dispositivo especifica Palo Alto Networks como proveedor y Panos OS como sistema operativo, la plantilla TextFSM utilizada para este ejemplo se vería así:

Cuando Paragon Automation utiliza la plantilla anterior para analizar el resultado mostrado anteriormente, el JSON resultante se ve de la siguiente manera:

SSH saliente (iniciado por dispositivo)

Paragon Automation también admite conexiones de iAgent (NETCONF) que se inician mediante el dispositivo mediante SSH de salida. Esta configuración hace que Paragon Automation actúe como cliente del dispositivo que realiza la conexión. Este tipo de conexión es útil en entornos en los que los dispositivos remotos no pueden aceptar conexiones entrantes. Todas las reglas de iAgent existentes se pueden utilizar cuando se configura SSH de salida en dispositivos Junos.

Nota:

Las conexiones NETCONF a través de SSH solo se admiten en dispositivos Junos.

El SSH saliente está deshabilitado de forma predeterminada. Puede configurar una conexión SSH de salida:

  • En la ingesta mediante la configuración de un único puerto. Este puerto lo utilizan todos los grupos de dispositivos.

  • En grupos de dispositivos mediante la configuración de sus puertos. Esta configuración tiene prioridad sobre la configuración de ingesta.

Cuando configure SSH de salida en grupos de dispositivos, debe ingresar un número de puerto TCP mediante el cual todos los dispositivos miembro inicien sus conexiones NETCONF a Paragon Automation. Puede deshabilitar el SSH saliente en un dispositivo a través de la CLI de administración. Para configurar puertos SSH de salida en grupos de dispositivos, consulte la sección puertos de la configuración del grupo de dispositivos en Agregar un grupo de dispositivos.

Paragon Automation admite un único puerto TCP para conexiones SSH salientes de iAgent (NETCONF) de todos los grupos de dispositivos. Este puerto se puede configurar en el nivel de ingesta. Puede evitar abrir varios puertos TCP en diferentes grupos de dispositivos y simplificar la administración de red con un solo puerto. Para configurar el puerto de iAgent en la ingesta, consulte Configurar puerto SSH de salida para iAgent.

Puede conectar un dispositivo que se administra en diferentes grupos de dispositivos mediante SSH saliente configurando varios clientes, donde cada cliente tiene el mismo puerto. En este caso, debe crear tantas copias del dispositivo como grupos de dispositivos. Cada dispositivo debe tener el mismo número de puerto.

Como ejemplo, considere el dispositivo r0 (10.1.1.1) configurado para los grupos de dispositivos dg1 y dg2. Para conectar 10.1.1.1 a ambos grupos de dispositivos mediante el mismo puerto SSH de salida, puede crear un dispositivo r1 más (10.1.1.1) con la misma IP e implementarlo en dg2.

También debe configurar Paragon Automation para estos puertos en los respectivos grupos de dispositivos. La figura 1 es un ejemplo de configuración de grupo de dispositivos.

Figura 1: Editar la configuración del grupo de Edit Device Group Configuration dispositivos

Con las siguientes configuraciones de cliente de ejemplo, el dispositivo 10.1.1.1 puede conectarse a dos grupos de dispositivos mediante dos clientes SSH de salida con el mismo puerto.

Nota:

El 10.1.1.1 del ejemplo indica la dirección IP de Paragon Automation (host).

SNMP

SNMP es un protocolo de administración de red ampliamente conocido y aceptado que muchos fabricantes de dispositivos de red, incluyendo Juniper Networks, proporcionan para su uso con sus dispositivos. Es un protocolo de tipo sondeo en el que los dispositivos de red configurados para usar SNMP ponen a disposición de los recopiladores información de configuración, diagnóstico y eventos, que también debe configurarse y autenticarse correctamente. Los recopiladores sondean los dispositivos mediante el envío de solicitudes estructuradas específicas, denominadas solicitudes get, para recuperar datos.

Paragon Automation admite SNMP como un tipo de sensor, utilizando solicitudes get estándar para recopilar estadísticas del dispositivo. Paragon Automation realiza solicitudes a través de cualquier interfaz disponible, ya sea en banda o fuera de banda, y el dispositivo responde (cuando se configura) con los datos solicitados.

Para obtener información acerca de SNMP tal como se utiliza en dispositivos Junos OS, consulte Descripción de la implementación de SNMP en Junos OS.

Paragon Insights también admite instancias de objetos escalares junto con objetos tabulares en SNMP.

  • El objeto SNMP puede ser escalar, tabular o una combinación de ambos en reglas. Cuando cree una regla con la ingesta de SNMP, puede agregar:

    • Solo campos escalares.

    • Una combinación de campos tabulares y escalares.

    • Una columna tabular junto con el índice consultado como un objeto escalar.

      Una columna tabular consultada como escalar tiene la limitación de que el número de índice no hace referencia al mismo objeto en todos los dispositivos cuando se configura el campo tabular en rule. Por ejemplo, IF-MIB::ifAdminStatus.16. ifAdminStatus es una columna de la tabla MIB IF . Se IF-MIB::ifAdminStatus.16 refiere a la columna de la tabla con el índice 16.

    • Solo campos tabulares.

  • Un objeto escalar se identifica por su nombre MIB (por ejemplo, JUNIPER-MIB::scalarObjectName) o como OID.

  • Paragon Insights valida un escalar determinado comprobando la propiedad en la definición de MAX-ACCESS MIB.

    Si encuentra MAX-ACCESS en la definición de MIB establecido en solo lectura, lectura y creación o lectura y escritura, ese objeto se puede consultar como un escalar.

La ruta completa para consultar un objeto escalar es MIB-Name::table column name:index number.

Por ejemplo, IF-MIB::ifInOctets:16 .

¿Qué sigue?