Monitorización remota

Puntos relevantes en este tema:

• Monitorización por ICMP.
• Monitorización por TCP.
• Monitorización según SNMP.
• Monitorización de rutas.
• Monitorización vía API.

La monitorización web clásica es tratada en un tema aparte.

El Network server ejecuta las tareas asignadas a él mediante un sistema de colas multiproceso, puede trabajar con otros servidores de red (modo HA).

Debe tener una visibilidad completa (direcciones IP y puertos) sobre los que se van a realizar las pruebas. En este capítulo también cubre el Heavy Server.

1. Pruebas ICMP: Son pruebas básicas de red que permiten saber si un anfitrión o host está en línea y accesible, además del tiempo que se tarda en llegar a dicho dispositivo a través de la red.
2. Pruebas TCP: Se forma remota se comprueba que un sistema tiene abierto el puerto TCP especificado en la definición del módulo.
3. Pruebas SNMP: Es posible lanzar peticiones SNMP (SNMP Polling ) a sistemas que tengan dicho servicio activado para obtener datos como el estado de las interfaces, el consumo de red por interfaz, etc.

Para monitorizar de forma remota un equipo o un servicio de un equipo (FTP, SSH, etc.), primero se debe crear el agente correspondiente, se accede por el menú Management → Resources → Manage agents → Create agent. Rellene los datos para su nuevo agente y pulse el botón Create.

Una vez que haya creado el agente, se pulsa sobre la solapa superior de los módulos (Modules). Allí seleccione crear un nuevo módulo de red pulsando botón Create. En el siguiente formulario que se muestre se selecciona Create a new network server module, y cuando se cargue el menú desplegable de la derecha, seleccione la comprobación deseada.

Son las comprobaciones más básicas que dan una información importante y exacta.

• icmp_proc: Comprobación en línea (ping) que permite saber si una dirección IP responde o no.
• icmp_data: Comprobación de latencia que indica el tiempo en milisegundos para responder a una consulta básica ICMP.

TCP está orientado hacia la conexión por lo que a un envío TCP Send corresponderá una respuesta TCP Receive que indica el estado de un puerto o un servicio a monitorizar. Opcionalmente se puede enviar una cadena de texto y esperar a recibir una respuesta que será tratada directamente por Pandora FMS como un dato.

• TCP Send: Campo para configurar los parámetros que enviar al puerto TCP. Para enviar varias cadenas en secuencia envío/respuesta, hay que separarlas con el carácter |; admite la cadena ^M para reemplazarla por el envío de un retorno de carro.
• TCP receive: Campo para configurar las cadenas de texto que se deben comparar con las repuestas recibidas de la conexión TCP. Si se envían/reciben en varios pasos, cada paso se debe separar con el carácter |.

Ejemplo:

TCP Send

HELO myhostname.com^M|MAIL FROM: ^M| RCPT TO: ^M

TCP Receive

250|250|250

Para poder utilizar con éxito estos módulos se necesitan las credenciales de conexión del agente a monitorizar. Por tanto todo esto se debe registrar en el almacén seguro de credenciales. Se repiten las instrucciones para la configuración genérica de un módulo y seleccionando alguno de los siguientes:

• remote_execution_data: numérico.
• remote_execution proc: booleano (0 FALSO, distinto de cero VERDADERO).
• remote_execution_data_string: alfanumérico (cadena).
• remote_execution_data_inc: incremental (ratio).

Además, se deben definir los siguientes parámetros:

1. Target IP: Opcionalmente la dirección IP del objetivo (si no, se usará la del agente).
2. Port: Opcionalmente el puerto al cual conectar (22 en Linux; indiferente en MS Windows®, en este sistema operativo se debe configurar el firewall para permitir los chequeos remotos).
3. Command: El comando a ejecutar para realizar la monitorización.
4. Credential identifier: El juego de credenciales a utilizar para conectar.
5. Connection method: Opcionalmente el método de conexión del objetivo (si no, se usará el del Agente).

Para que los módulos de ejecución remota en MS Windows® se ejecuten correctamente se deben habilitar varias reglas del Firewall en los ordenadores a monitorizar:

• File and Printer Sharing (SMB-In).
• File and Printer Sharing (Spooler Service - RPC-EPMAP):
  
• Windows Management Instrumentation (WMI-In):
  

• Custom ID (pestaña Categorization): Permite almacenar un identificador de una aplicación externa para facilitar la integración de Pandora FMS con aplicaciones de terceros, tales como una Configuration Management DataBase (CMDB).
• Interval (pestaña Intervals): Intervalo de ejecución del módulo, el cual puede ser personalizado (token Interval values) por un usuario Administrador de manera predefinida y luego ser utilizado por usuarios estándar.
• Post process (pestaña Data): Para posprocesado del módulo (multiplicar el valor devuelto), como cuando se obtienen bytes y se necesita mostrar el valor en Megabytes.
• Min. Value y Max. Value (pestaña Data): Cualquier valor por debajo del mínimo o por encima del máximo se tomará como inválido y se descartará.
• Export target (pestaña Data): Solamente disponible con Export Server.
• Category (pestaña Categorization): Solamente se usa en conjunto con la Metaconsola (Command Center).
• Si Cron from está activado (pestaña Intervals), el módulo se ejecutará una vez cuando la fecha y hora actuales coincidan con la fecha y hora configuradas en Cron from, ignorando el propio intervalo del módulo.
• Target IP: Dirección IP del dispositivo a monitorizar. Se puede utilizar la macro _agentname_ o _agentalias_ siempre y cuando el nombre de agente o su alias tengan una dirección IP válida.

• Polling SNMP: Se realiza cada cierto tiempo de forma activa e implica ordenar que Pandora FMS ejecute un comando get contra un dispositivo SNMP.
• Trap SNMP: Ocurre con cambios o eventos en el dispositivo, que pueden suceder en cualquier momento o no. Es necesario activar la consola de traps SNMP en Pandora FMS, donde se mostrarán los que se reciban de cualquier dispositivo. Se pueden definir alertas mediante reglas de filtrado de traps por cualquiera de sus campos.

Pandora FMS trabaja con SNMP manejando Identificadores de Objetos u Object IDentifier (OID) individuales, así cada OID es un módulo de red.

Pasos necesarios para trabajar con SNMP

• Activar la gestión SNMP del dispositivo para que desde el servidor de red se pueda hacer consultas SNMP.
• Conocer la IP y la comunidad SNMP del dispositivo remoto.
• Conocer el OID concreto del dispositivo remoto (o utilizar uno de los múltiples wizards de que dispone Pandora FMS o su explorador de OID SNMP).
• Saber cómo gestionar el dato que devuelve el dispositivo. Los dispositivos SNMP devuelven datos en diferentes formatos. Pandora FMS puede tratar casi todos. Los datos de tipo contador son los que Pandora FMS gestiona como remote_snmp_inc y son de especial importancia, ya que al ser contadores no pueden tratarse como datos numéricos sino como tasa de elementos por segundo. La mayoría de datos estadísticos SNMP son de tipo contador y se han de configurar como remote_snmp_inc si se quiere monitorizar de forma adecuada.

Para poder monitorizar cualquier otro elemento por SNMP se debe conocer su comunidad SNMP. Durante la creación del módulo debe seleccionar Manual setup. En el campo Type existen tres opciones para SNMP, al seleccionar una de ellas se expandirá el formulario mostrando los campos adicionales para SNMP.

• SNMP community: es como una identificación de usuario o una contraseña que permite el acceso a las estadísticas de un enrutador u otro dispositivo (versiones SNMPv1 y SNMPv2c ya que SNMPv3 utiliza autentificación por credenciales). Por defecto los dispositivos traen la comunidad pública (public) de solo lectura y generalmente cada administrador de red cambia todas las cadenas de la comunidad a valores personalizados en la configuración del dispositivo.
• SNMP OID: identificador OID que monitorizar, el cual consiste en una cadena de números y puntos. Estas cadenas son automáticamente traducidas por cadenas alfanuméricas más descriptivas si las MIB correspondientes se encuentran instaladas en el sistema.
• Target IP: Dirección IP del dispositivo a monitorizar. Se puede utilizar la macro _agentname_ o _agentalias_ siempre y cuando el nombre de agente o su alias tengan una dirección IP válida.

Un EndPoint es generalmente es utilizado para obtener datos locales, sin embargo también puede realizar monitorización SNMP.

En Linux®

snmpget suele estar instalado por defecto, por lo que puede ser llamado desde la línea module_exec.

module_exec snmpget -v <versión> -c <comunidad> <dirección IP> <OID numérica>

Cabe destacar que solo las OID “básicas” son traducibles por su equivalente numérico, y que es recomendable usar siempre OID numéricas, ya que no se sabe si la herramienta va a saber traducirla o no. En cualquier caso siempre se pueden cargar los MIB en el directorio:

/usr/share/snmp/mibs.

En MS Windows®

snmpget.exe (el cual forma parte del proyecto net-snmp, con licencia BSD) está añadido al EndPoint junto con las MIB básicas, además de un empaquetador o guión (wrapper o script) para encapsular la llamada. De similar manera que en Linux, se pueden cargar los MIB en el directorio:

/util/mibs.

Pandora FMS de manera predeterminada utiliza las MIB que están alojadas por el sistema operativo en:

 /usr/share/snmp/mibs.

Se pueden incorporar nuevas MIB (y gestionarlas luego) por medio de la funcionalidad MIB uploader desde el menú Operation → Monitoring → SNMP.

Estas MIB solamente son usadas por Pandora FMS y están almacenadas en la ruta:

 {PANDORA_CONSOLE}/attachment/mibs.

Menú Operation → Monitoring → SNMP → SNMP Browser.

El SNMP Browser realiza un recorrido completo del árbol del dispositivo. Dicha operación puede tardar varios minutos y también es posible recorrer ramas precisas y acortar el recorrido.

El sistema hará una exploración con los parámetros especificados en los campos de la sección Filters y además mostrará (si está disponible) la información del OID solicitado y obtenido. Si no existe información sobre el OID del dispositivo, esta se mostrará únicamente en formato numérico. En caso de fallar la exploración se obtendrá el mensaje The server did not return any response.

El explorador SNMP también permite buscar una cadena de texto tanto en los valores de OID obtenidos como en los valores traducidos de los propios OID (si están disponibles). Esto es especialmente útil para buscar cadenas conocidas concretas y localizar su OID. Si localiza varias entradas permitirá ir saltando de una ocurrencia a otra y las mostrará resaltadas en amarillo.

Es posible seleccionar varios OID y añadirlos a uno o varios agentes seleccionando Create agent modules del listado Actions y pulsando luego el botón Create:

Con los OID seleccionados, también se pueden agregar a una política de monitorización existente o incluso crear un componente de red con los mismos.

Vista de administración de un agente.

Se debe definir la dirección IP de destino (el campo Target IP no puede utilizar la macro _agentname_ ni _agentalias_), la comunidad y otros parámetros opcionales (SNMP v3 está soportado) para hacer un Walk SNMP al objetivo. Una vez se reciba la información correctamente, aparecerá un formulario para la creación de módulos tales como Devices, Processes, Free space on disk, Temperature sensors y Other SNMP data.

Se selecciona el tipo de módulo y se agregan a la lista de creación, cuando acabe este proceso se podrá hacer clic en el botón de Create Modules.

Este wizard creará dos tipos de módulos:

• Módulos SNMP para las consultas con OID estático: Sensores, Memoria, CPU, etcétera.
• Módulos Plugin para las consultas con OID dinámico o los datos calculados: Procesos, Espacio en disco, Memoria usada expresada en porcentaje, etcétera.

Para que el wizard SNMP pueda obtener datos de un dispositivo SNMP gracias a los componentes remotos, es necesario cumplir 2 requisitos:

• Tener registrado en Pandora el Private Enterprise Number (PEN) del fabricante del dispositivo.
• Tener registrados y habilitados en Pandora componentes del wizard SNMP para el fabricante del dispositivo.

Si el dispositivo explorado cumple estos requisitos, se mostrarán todos los módulos de los cuales se hayan podido obtener datos para dar la oportunidad de seleccionar cual crear y cual no.

Una vez pulsado el botón Create modules se mostrará un listado resumen de los módulos elegidos con su configuración. En este listado se verán los módulos que no se puedan crear, ya sea porque ya existen en el agente o porque se han configurado 2 o más módulos con el mismo nombre en el propio wizard.

Antes de que se añadan al agente, habrá una última oportunidad de confirmar la creación de estos módulos o de cancelarla y seguir modificando el resultado del wizard.

Este Wizard navega por la rama de SNMP IF-MIB::interfaces, ofreciendo la posibilidad de crear múltiples módulos de varios interfaces con la selección múltiple. Después de seleccionar la dirección IP de destino (el campo Target IP no puede utilizar la macro _agentname_ ni _agentalias_) y demás campos necesarios, el sistema hará una consulta SNMP a la máquina destino y rellenará el formulario para la creación de módulos.

Una vez confirmada la creación de los módulos, se volverá a evaluar uno a uno si se pueden crear o no, para evitar módulos duplicados en el caso de que en el lapso de tiempo de la confirmación se hayan creado los mismos módulos por otro medio.

Se nos notificará si el proceso se ha podido completar con éxito o, si por el contrario, ha habido algún módulo que no se haya podido crear.

WMI es una tecnología empleada en el sistema operativo (S.O.) de Microsoft® para obtener información remota de equipos funcionando con Windows®; está disponible desde la versión Windows XP hasta las versiones más actuales. WMI permite obtener todo tipo de información del S.O., las aplicaciones e incluso el hardware. Las consultas de WMI se pueden realizar localmente con el EndPoint (llamando a la API del S.O.) o de forma remota.

Las consultas se hacen en WQL, una especie de lenguaje SQL específico de Microsoft®, para todo objeto que aparezca en la base de datos del sistema WMI.

Para comenzar a monitorizar por WMI, primero se deberá crear el agente correspondiente, luego se pulsará sobre la solapa superior de los módulos (Modules). Una vez en ella, se selecciona Create a new WMI server module y se pulsa el botón Create.

Campos específicos WMI:

• Namespace: Espacio de nombres WMI; en algunas consultas este campo es diferente de cadena vacía (por defecto), dependiendo del proveedor de información de la aplicación que se monitorice.
• Key string: Opcional, campo para comparar con la cadena devuelta por la consulta, y de existir el módulo devuelve 1 o 0, en lugar de la cadena en sí.
• Field number: El número del campo devuelto empezando desde 0 (las consultas WMI pueden devolver más de un campo). En la mayoría de las veces es 0 o 1.
• WMI Query: Consulta WMI, similar a una sentencia en SQL.

Utilizado para navegar y crear módulos con consultas WMI a un agente específico. En el Wizard de agente (pestaña en la vista de administración de un agente), haga clic en el icono:

Debe especificar el nombre de usuario y contraseña que tenga permisos para hacer consultas WMI (o en su defecto la del Administrador) en el servidor de destino para hacer las primeras consultas WMI. Esta información será utilizada para la creación de módulos.

Con el Wizard WMI es posible crear módulos de diferentes tipos de información WMI:

• Servicios: Se crearán monitores booleanos en estado normal si el servicio está corriendo y en estado crítico cuando se encuentre detenido.
• Procesos: Los monitores de procesos recibirán información solamente cuando el proceso esté activo. De lo contrario, caerán en estado desconocido.
• Espacio libre en disco
• Componentes WMI: En este caso escogerá entre los componentes WMI registrados en el sistema.

Estos módulos se mostrarán organizados en bloques en base al grupo al que pertenezca el componente del wizard que los haya generado.

Todos los bloques se mostrarán comprimidos en un primer momento para facilitar la visualización y se podrán ir expandiendo para modificar los seleccionados o los datos. Además, en cada bloque donde se hayan marcado módulos para su creación se verá un icono informativo que indicará.

Si desplegamos un bloque, se podrán elegir los módulos que se agregarán y los que no, así como la opción de modificar el nombre, la descripción o los umbrales de cada módulo individualmente.

Una vez pulsado el botón Create modules se mostrará un listado con un resumen de los módulos elegidos con su configuración. En este listado se verán los módulos que no puedan ser creados, ya sea porque ya existen en el agente o porque se han configurado dos o más módulos con el mismo nombre en el mismo wizard.

A pesar de todas las modificaciones que se realicen habrá una última oportunidad de confirmar la creación de estos módulos o de cancelarla y seguir modificando el resultado del wizard.

Una vez confirmada la creación de los módulos, se volverá a evaluar uno a uno si se pueden crear o no, para evitar módulos duplicados en el caso de que en el lapso de tiempo de la confirmación se hayan creado los mismos módulos por otro medio.

El asistente notificará si el proceso se ha podido completar con éxito o si por el contrario ha habido algún módulo que no haya podido ser creado.

Un plugin remoto es un script o fichero ejecutable que admite parámetros y devuelve un único valor. El resultado podría ser un número, un valor booleano (0 = error, OK <> 0 ) o una cadena de texto. Un plugin remoto generalmente permite parámetros de entrada. Por defecto varios plugins de servidor vienen instalados y listos para utilizarse y el usuario puede siempre añadir los que necesite.

Existen dos clases de plugin remoto: estándar y tipo Nagios. La diferencia estriba principalmente en que los de tipo Nagios responden con un tipo de errores (error level) y además, de manera opcional, con una cadena descriptiva.

Se accede por Management → Servers → Plugins, se abrirá una nueva ventana con un listado de los plugins registrados. Cada ítem tiene sus correspondientes botones de edición y borrado, excepto si tiene módulos en uso los cuales se pueden listar por medio del botón Lock.

Al editar un plugin:

• Plug-in type: Permite establecer si es de tipo estándar o tipo Nagios.
• Max. timeout: Para fijar el tiempo de espera para su ejecución, se debe prestar especial atención en este valor ya que debe abarcar suficiente tiempo para la ejecución de lo contrario no obtendrá valor alguno.
• El campo de la descripción es importante ya que se verá en la interfaz de uso del plugin por parte del usuario, escoja una leyenda corta y explicativa.

De una forma similar a las alertas, también se pueden utilizar macros internas en la configuración de plugins. Las macros soportadas son las siguientes:

• _agent_ o _agentalias_: Alias del agente al que pertenece el módulo.
• _agentname_: Nombre del agente al que pertenece el módulo.
• _agentdescription_: Descripción del agente al que pertenece el módulo.
• _agentstatus_: Estado actual del agente.
• _address_: Dirección del agente al que pertenece el módulo.
• _module_: Nombre del módulo.
• _modulegroup_: Nombre del grupo del módulo.
• _moduledescription_: Descripción del módulo.
• _modulestatus_: Estado del módulo.
• _moduletags_: Etiquetas (tags) asociados al módulo.
• _id_agent_: ID del agente, útil para construir directamente la URL o redireccionar a la Consola de Pandora FMS.
• _id_module_: ID del módulo.
• _policy_: Nombre de la política a la que pertenece el módulo si está establecida alguna.
• _interval_: Intervalo de ejecución del módulo.
• _target_ip_: Dirección IP del destino del módulo.
• _target_port_: Puerto del destino del módulo.
• _plugin_parameters_: Parámetros de plugin del módulo.
• _email_tag_: correos electrónicos asociados a tags de módulos.

Las macros de campos personalizados permiten utilizar los campos personalizados de agentes como macros para ciertas opciones de configuración de módulos.

Las macros de campos personalizados funcionan con módulos de tipo SNMP, WMI, plug-in e inventario. Se pueden utilizar en módulos independientes, componentes de red y en módulos de política.

Se accede por Management → Resources → Custom fields → Create field en este nuevo campo personalizado se almacenará la cadena de comunidad SNMP. Apunte su ID, ya que más tarde formará parte de la macro, y rellene la cadena de comunidad con el valor adecuado en sus agentes SNMP.

Luego se debe crear un componente de red SNMP al que se debe introducir _agentcustomfield_<n>_ como cadena en SNMP community, donde n es el ID del campo personalizado creado.

Esta funcionalidad permite que desde la consola de Pandora FMS se puedan ejecutar algunas acciones en servidores remotos de Pandora FMS.

Con un Exec server configurado se podrá elegir desde:

• El SNMP browser en la sección SNMP.
• En los Event responses en la sección de eventos.
• En los wizards de SNMP de agente.
• En los wizards de WMI de agente.
• En los wizards de interfaces SNMP de agente (excepto para los Satellite Server).

Dependiendo del servidor seleccionado a la hora de lanzar cada wizard, se crearán los módulos adaptados para servidor o Satellite Server. En este último caso se escribirán los módulos en el fichero de configuración remota para que puedan ser ejecutados por el servidor.

Los Exec server funcionan internamente a través de la ejecución de comandos remotos SSH desde la consola de Pandora FMS a los servidores habilitados, llamados Exec Server. Estos pueden ser Network servers o Satellite servers de Pandora FMS.

El proceso de configuración requerirá el concurso de la persona encargada de la administración de red para configurar tanto los servidores PFMS como para los ordenadores destino y el tráfico de conexiones y datos, entre otros aspectos como los cortafuegos y las VLAN para aumentar la seguridad.

• Se debe contar con un agente lógico configurado con la configuración remota habilitada.

• En el servidor que ejecuta la Consola web PFMS se debe tener un usuario creado a nivel de sistema operativo y con acceso debido a su propio directorio y que permita ejecutar una shell válida para las tareas a encomendar.
• En la Consola web PFMS se deberá acceder como usuario superadmin o Pandora Administrator.

Consulte el anexo técnico para más información.

Pandora FMS ofrece por defecto la monitorización de rutas completas entre dos puntos de la red, indicando visualmente el camino que se está siguiendo en todo momento para comunicarse entre estos dos puntos. El analizador de rutas de Pandora FMS utiliza un plugin de agente para trazar un mapa de la ruta.

Para utilizar este sistema se necesita:

• Un EndPoint en el punto de origen de la ruta a analizar.
• Alcance vía ICMP desde el punto de origen.

De manera opcional, si desea hacer escaneos de rutas a través de Internet, se recomienda que despliegue la aplicación MTR en el equipo origen de ruta.

Se accede a la pestaña de configuración de plugins en agente y se agrega la siguiente línea:

route_parser -t <target_address>

Por último active la ejecución del plugin.

Existen dos tipos de módulos los cuales comparten características comunes con el resto de los módulos y se utilizan para obtener datos con llamadas API:

• API retrieve module: Puede recibir tres tipos de datos de la consulta API realizada, numérico, verdadero o falso (bool) y alfanumérico.

• API custom module: Solamente tiene un tipo bool el cual será normal si todas las condiciones se cumplen o si el código de respuesta de la API no coincide con ninguno de los especificados (se espera código 200 como respuesta). Por defecto los códigos de comparación con la respuesta son 500, 404, 403 y se pueden agregar tantos como se necesiten, siempre separados por comas. Si se recibe alguno de estos códigos como respuesta el módulo pasará a estado crítico (0).

En ambos casos se debe tener configurados los siguientes campos:

1. Timeout: Tiempo máximo de espera de respuesta de la llamada API, 10 segundos por defecto.
2. URL: La dirección web del endpoint API encargado de recibir la consulta.
3. Method: Puede ser GET (valor por defecto), POST, PUT, GET y DELETE.
4. Ignore certificate: Si está activado (no recomendado) ignorará los certificados.
5. Headers: Se especifican las cabeceras HTTP de la petición, lo cual permite establecer pares de valores convenidos. Por defecto tiene establecido Content-Type application/json para recibir respuesta en formato JSON y se podrá agregar una cabecera adicional.
6. Body: Para especificar el contenido de la petición, la consulta en sí misma (especialmente útil con PUT y POST).

Para API custom module se dispone de JSON path query, botón en el primer renglón, el cual abre una ventana emergente realizando una consulta previa, mostrando los resultados para especificar el campo JSON con el que se hará comparación. Una vez seleccionado el objetivo, se debe especificar el tipo de dato esperado, la condición y el valor de comparación que debe satisfacer para introducir la respuestas bool en el módulo. Se podrán agregar tantas condiciones como se necesiten, todas se deben de cumplir para que el módulo esté en estado normal (1).

Volver al índice de documentación de Pandora FMS