Pandora: Documentation es: Monitorizacion remota

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Monitorización remota

1.1 Introducción

El servidor de red de Pandora FMS es una pieza clave, ya que permite ejecutar pruebas de forma remota y centralizada. Al contrario que el servidor de datos, el servidor de red ejecuta las tareas asignadas a él mediante un sistema de colas multiproceso. Además, un servidor de red puede trabajar con otros servidores de red balanceando la carga y actuando como respaldo en caso de que otro servidor de red caiga, haciéndose cargo del trabajo que tenía el servidor caído. Para saber más sobre la HA en Pandora FMS consulta el capitulo correspondiente.

El servidor de red trabaja únicamente con aquellos módulos de red asignados a él. Obviamente, y dado que se trata de pruebas de red, el servidor de red tiene que tener una visibilidad completa (direcciones IP y puertos) sobre los que se van a realizar las pruebas. No tiene sentido realizar pruebas contra un sistema cuyos puertos no se pueden ver o sobre el cual no se tienen las rutas. La existencia de cortafuegos (firewalls) o rutas en la red no tiene nada que ver con Pandora FMS y los problemas generados por estas razones tampoco tienen nada que ver con una configuración concreta de Pandora FMS.

Además del network server (servidor de red) existen muchos otros subtipos de servidores de Pandora FMS que ejecutan pruebas remotas. En este capítulo veremos los servidores de red, los servidores de plugin remotos, los servidores que lanzan pruebas remotas contra máquinas Windows (WMI Server). Otros servidores que también realizan pruebas remotas, como el servidor de pruebas WEB (WEB Server o Goliat server) tienen capítulos específicos de documentación.


Remote-monitoring.jpg


1.2 Monitorización básica de red

Los módulos de red básicos de Pandora FMS ejecutan tareas de monitorización remota. Las tareas de ejecución remota se pueden resumir en tres bloques.

Pruebas ICMP

Son pruebas básicas de red que permiten saber si un host está accesible y vivo y el tiempo que se tarda en llegar a dicho dispositivo a través de la red.

Pruebas TCP

De forma remota se comprueba que un sistema tiene abierto el puerto TCP especificado en la definición del módulo. Adicionalmente se puede enviar una cadena de texto y se puede esperar al recibir una respuesta concreta para comprobar que la comunicación es correcta. Esto permite implementar comprobaciones simples de protocolo, además de verificar si el otro extremo responde o no.

Por ejemplo, podríamos comprobar si un servidor HTTP está vivo enviando la cadena «GET / HTTP/1.0» esperando recibir la cadena «200 OK».

Pruebas SNMP

Remotamente es posible lanzar peticiones SNMP (SNMP Polling) a sistemas que tengan su servicio SNMP activado y accesible para obtener datos como estado el de las interfaces, el consumo de red por interfaz, etc. Existe un a sección dedicada a SNMP con Pandora FMS (ver más adelante).



Pandora 1.3 Network&DataServer Arch.png


Como resumen, se puede concluir que el servidor de red es quien ejecuta las diferentes pruebas de red asignadas en cada agente. Cada agente se asigna a un servidor de red, y es éste quien se encarga de su ejecución, insertando los resultados en la BB.DD. del sistema de Pandora FMS.

1.3 Configuración genérica de un módulo para monitorización de red

Para monitorizar de forma remota un equipo o un servicio de un equipo (FTP, SSH, etc.), primero se deberá crear el agente correspondiente para monitorizar el servicio, por ello, se empezará por ahí.

Info.png

Cuando se habla de crear un agente, no se refiere a instalar un agente software en la máquina destino, si no a crear un agente en la interfaz de Pandora FMS

 


En la sección de administración de la consola de Pandora FMS pulse sobre Resources > Manage agents:

Anvi.jpg


En la siguiente pantalla, pulse el botón Create agent:

Bibi.jpg


Rellene los datos para su nuevo agente y pulse el botón Create:

Raro.jpg


Una vez que haya creado el agente, pulse sobre la solapa superior de los módulos (Modules). En ella, seleccione crear un nuevo módulo de red y pulse el botón Create:

Sasa.jpg


En el siguiente formulario seleccione un módulo de componente de red, y cuando se cargue el menú desplegable de la derecha, busque la comprobación que le interese. En este ejemplo se seleccionará Host Alive, que representa un ping a la máquina, una simple comprobación para saber si la máquina está conectada a Internet o no.

Alive.jpg


Se dejan las opciones avanzadas para más tarde. Note que el módulo ha obtenido la dirección IP del agente. Si lo desea, ésta puede ser diferente. Una vez que termine de definir el módulo, pulse el botón Create.

En la siguiente pantalla se mostrarán los módulos para el agente, el predeterminado Keepalive que se crea con el agente y el módulo Host Alive añadido:

Kiji.jpg


Como se ve, existe una advertencia sobre los módulos. La advertencia sólo significa que aún no se ha recibido ningún dato en el módulo, ya que se acaban de añadir. Una vez que se comiencen a recibir datos, la advertencia desaparecerá.

Para ver los datos del módulo recién creado, pulse sobre la solapa superior View, y en ella vaya a la parte de abajo, donde se mostrarán los datos una vez se empiecen a recibir:

Keso.jpg


Para añadir otro tipo de comprobaciones de red, proceda de forma similar a la anterior, pero seleccionando otro tipo de módulos.

1.4 Monitorización ICMP

El ejemplo anterior es un ejemplo de monitorización ICMP. Estas son las comprobaciones mas básicas y sencillas que nos dan una información importante y exacta. Existen dos tipos de comprobaciones ICMP:

  • icmp_proc, o comprobación de host (ping), que permite saber si una dirección IP responde o no.
  • icmp_data o comprobación de latencia. Básicamente nos dice el tiempo en milisegundos que tarda en responder la dirección IP en responder a una consulta básica ICMP.

1.5 Monitorización TCP

Los chequeos TCP permiten comprobar el estado de un puerto o un servicio TCP.

Los campos fundamentales de este tipo de módulos son:


Tcpfields.JPG


Las comprobaciones TCP por defecto simplemente miran si el puerto de destino esta abierto o no. Opcionalmente se le puede enviar una cadena de texto, y esperar a recibir algo que será tratado directamente por Pandora FMS como un dato, mediante los campos TCP Send y TCP Receive.

Se puede enviar una cadena de texto (utilizando la cadena «^M» para reemplazar al retorno de carro) y se puede esperar al recibir una subcadena de respuesta para comprobar que la comunicación es correcta. Esto permite implementar comprobaciones simples de protocolo. Por ejemplo, podríamos comprobar si un servidor está vivo enviando la cadena

 GET / HTTP/1.0^M^M 

y esperando recibir la cadena

200 OK

Esto se codifica en los campos TCP Send y TCP receive.

TCP send

Campo para configurar los parámetros que enviar al puerto TCP. Admite la cadena ^M para reemplazarla por el envió de un retorno de carro. Para enviar varias cadenas en secuencia envió/respuesta, hay que separarlas con el carácter |

TCP receive

Campo para configurar las cadenas de texto que se esperan recibir en la conexión TCP. Si se envían/reciben en varios pasos, cada paso se separa con el carácter |

A través de las comprobaciones TCP de Pandora se puede hacer algo más que ver simplemente si un puerto está abierto o esperar una respuesta ante una petición simple. Se pueden enviar datos, esperar a recibir algo, enviar algo después, esperar a recibir algo y así hasta el paso que queramos. Solo si todo el proceso es correcto, podemos dar por válido el resultado.

Para utilizar el sistema de comprobaciones diálogo/respuesta de Pandora, puede separar las diferentes peticiones con el carácter |

Veamos un ejemplo de una conversación SNMP:

R: 220 mail.supersmtp.com Blah blah blah
S: HELO myhostname.com
R: 250 myhostname.com
S: MAIL FROM: 
R: 250 OK
S: RCPT TO: 
R: 250 OK
S: DATA
R: 354 Start mail input; end with .
S: .......your mail here........
S: .
R: 250 OK
S: QUIT
R: 221 mail.supersmtp.com Service closing blah blah blah

Si quiere chequear los primeros puntos del protocolo, los campos necesarios para emular esta conversación serían:

TCP Send

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

TCP Receive

250|250|250

Si los tres primeros pasos son OK (código 250), entonces el servidor SMTP esta ok. No necesita enviar un mail completo (aunque podría, en cualquier caso). Esto permite realizar comprobaciones TCP basadas en el protocolo, que pueden usarse para cualquier protocolo que utilice conversaciones en texto plano.

1.6 Monitorización SNMP

1.6.1 Introducción a la monitorización SNMP

Cuando se habla de la monitorización SNMP, lo más importante al principio es separar los conceptos de polling y los traps. El testeo o polling SNMP implica ordenar que Pandora FMS ejecute un comando «get» contra un dispositivo SNMP, como por ejemplo un router o un switch, esta es una operación síncrona (que se realiza cada cierto tiempo de forma activa).

Por el contrario, recibir un trap SNMP es una operación asíncrona (basada en cambios o eventos, que pueden no ocurrir), comúnmente utilizada para recibir avisos provenientes del dispositivo como, por ejemplo, cuando un switch tumba un puerto o su ventilador se calienta demasiado.

Los chequeos SNMP tipo polling se realizan creando módulos de red en Pandora FMS de la forma habitual.

Utilizar los Traps SNMP es algo totalmente diferente. Se pueden recibir traps de cualquier dispositivo, únicamente será necesario activar la consola de traps SNMP en Pandora FMS, donde se mostrarán los traps 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 OID individuales. Para Pandora FMS cada OID es un módulo de red. Es decir, si queremos monitorizar un switch Cisco Catalyst de 24 puertos, y conocer el estado operativo de cada puerto así como el tráfico de entrada y salida, tenemos que definir un total de 72 módulos (24 x 3).

Para trabajar con dispositivos SNMP es necesario:

  • Conocer qué es y cómo trabaja el protocolo SNMP. Esto se describe en profundidad en el RFC3411 publicado por el IETF.
  • Conocer la IP y la comunidad SNMP del dispositivo remoto.
  • Activar la gestión SNMP del dispositivo para que desde el servidor de red se puedan hacer consultas SNMP. Este servidor de red debe ser el asignado por el agente donde vayamos a definir los módulos de red. También hay que tener en cuenta que si queremos que otros servidores de red hagan consultas en caso de caída del servidor asignado, estos harán las consultas con otra dirección IP.
  • Conocer el OID concreto del dispositivo remoto que queramos consultar (o utilizar uno de los múltiples wizards de que dispone Pandora FMS o su explorador de OIDs 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 monitorizarlos adecuadamente.

1.6.2 Monitorizando con módulos de red tipo SNMP

Para poder monitorizar cualquier elemento por SNMP deberemos saber, al menos, su IP y su comunidad SNMP. También sería muy interesante saber la OID que se pretende monitorizar, aunque se pueden obtener a través de un SNMP Walk o del explorador SNMP integrado en Pandora, siempre que se sepa a qué pertenece cada OID. Esto último no siempre es fácil.

Para monitorizar un elemento por SNMP, primero se habrá de crear un agente para ello, si ya se dispone de uno, simplemente se le añadirá un módulo de red nuevo siguiendo las indicaciones anteriores.

Una vez que se haya creado el módulo, se debe seleccionar un tipo de dato SNMP en el formulario de configuración del módulo, ver la imagen:

Cap5 snmp 1.png



Cualquiera de los tres tipos de datos SNMP son válidos, simplemente seleccione el que coincida con el tipo de dato que quiere monitorizar.

Una vez que haya seleccionado un tipo de dato SNMP, se expandirá el formulario mostrando los campos adicionales para SNMP:

Cap5 snmp 2.png



A continuación se detallan los campos:

SNMP community

Comunidad SNMP. Necesaria para poder monitorizar el elemento. Actúa como si fuese una contraseña.

SNMP version

Versión del protocolo SNMP del dispositivo. Puede ser 1, 2, 2c y 3. La versión 3 incorpora cifrado y autenticación segura en la comunicación, lo que complica bastante la configuración y empeora el rendimiento del polling de los servidores de red de Pandora FMS.

SNMP OID

Identificador OID que monitorizar. 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. Las MIB son librerías de fabricantes que sirven para traducir estos OID en cadenas más descriptivas.

Un OID alfanumérico puede tener este aspecto:

iso.org.dod.internet.private.transition.products.chassis.card.slotCps.cpsSlotSummary.cpsModuleTable.cpsModuleEntry.cpsModuleModel.3562.3

El equivalente numérico sería este:

1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3

Pandora FMS incluye algunos OID, en su base de datos, que puede usar directamente. Por ejemplo, a la hora de crear el módulo seleccione el componente Cisco MIBs para mostrar una lista de los chequeos con OID traducidos disponibles para Cisco:


Cap5 snmp 4.png


Una vez que seleccione este componente, puede elegir entre los OID disponibles para él:


Cap5 snmp 5.png


Al hacerlo, se rellenarán los campos con la información necesaria.

Existen más MIB incluidas en Pandora FMS y con la versión Enterprise se incluyen paquetes de MIB para distintos dispositivos.

Una vez que haya introducido los datos, pulse el botón Create.

Para ver los datos del módulo recién creado, pulse sobre la solapa superior View, y en ella vaya a la parte de abajo, donde se mostrarán los datos una vez se empiecen a recibir.



Cap5 snmp 7.png



1.6.3 Monitorizando SNMP desde los agentes

Los agentes software Windows tienen una utilidad para obtener información SNMP. En los agentes Unix/Linux snmpget suele estar disponible, por lo que puede ser llamado desde la línea module_exec.

Hemos empaquetado en el agente "por defecto" de Windows la utilidad snmpget.exe (parte del proyecto net-snmp, con licencia BSD), y hemos añadido las MIB básicas y un wrapper o script para encapsular la llamada a la utilidad snmpget.exe.

Utilizando esta llamada podemos monitorizar SNMP desde un agente, obteniendo información de cualquier equipo remoto al que el agente tenga acceso, pudiendo funcionar así como un "agente satélite" o "agente proxy" (según documentación).

En windows la sintaxis de la ejecución es:

module_exec getsnmp.bat <comunidad_SNMP> <ip de destino> <OID>

Algunos ejemplos de módulos SNMP ejecutados por agentes windows:

module_begin
module_name SNMP_if3_in
module_type generic_data_inc
module_exec getsnmp.bat public 192.168.55.1 .1.3.6.1.2.1.2.2.1.10.3
module_end
module_begin
module_name SNMP_if3_desc
module_type generic_data_string
module_exec getsnmp.bat public 192.168.55.1 IF-MIB::ifDescr.3
module_end
module_begin
module_name SNMP_Sysup
module_type generic_data
module_exec getsnmp.bat public 192.168.55.1 DISMAN-EVENT-MIB::sysUpTimeInstance
module_end

Los mismos ejemplos ejecutados desde agentes Unix

module_begin
module_name SNMP_if3_in
module_type generic_data_inc
module_exec snmpget -v 1 -c public 192.168.55.1 .1.3.6.1.2.1.2.2.1.10.3
module_end
module_begin
module_name SNMP_Sysup
module_type generic_data
module_exec snmpget -v 1 -c public 192.168.55.1 DISMAN-EVENT-MIB::sysUpTimeInstance
module_end

Cabe destacar que sólo las OID "basicas" 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 las mibs en el directorio /util/mibs en Windows o /usr/share/snmp/mibs en Linux.

1.6.4 Navegador SNMP de Pandora FMS

Podemos acceder al explorador SNMP a través del menú Monitoring > SNMP > SNMP Browser.

Lo primero que hay que entender es que Pandora FMS hace un recorrido completo del árbol del dispositivo, por lo que si este es grande (como un switch) esta operación puede tardar varios minutos. Tambien podemos escoger explorar únicamente una subrama, con lo que nos ahorraremos mucho tiempo.

Por ejemplo, para sacar la informacion de CISCO únicamente, podria explorar su sub-mib enterprise de cisco que empieza por :

 .1.3.6.1.4.1.9

El explorador se utiliza para "navegar", esto es, ir desplegando las ramas y obteniendo los valores, pulsando en el icono del ojo. El sistema pedirá esa informacion al sistema y además mostrará (si esta disponible) la informacion del OID solicitado. Si no existe informacion sobre el OID del dispositivo, esta se muestra unicamente en formato numerico. La informacion descriptiva de los OID se almacena mediante las mibs [1]. Si no dispone de una MIB para el dispositivo que desea explorar, probablemente tenga que recurrir a buscar "trozos de informacion" en la informacion visualizada por pandora, lo cual es complejo y lleva tiempo.

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


Snmp browser module creator.png


Desde el explorador SNMP se puede crear un componente de red para reutilizarlo después.

Snmp browser from module creation.jpg

Desde el editor de módulos SNMP, cuando creemos o editemos un módulo de red, podemos lanzar el navegador de SNMP haciendo clic en el botón de "Navegador SNMP", que lo abrirá en una ventana flotante. Una vez escogido el OID que buscamos, haciendo clic en el icono de la mano con el dedo apuntando hacia abajo, escogeremos ese OID y lo pasaremos al campo correspondiente de la definición del módulo, de forma automática, para su uso con Pandora FMS.

1.6.4.1 Gestor de MIBS

A través de Pandora FMS podemos subir y gestionar las MIBS para poder incorporar nuevas mibs o borrar las que no nos interesen. Estas Mibs las usará solo Pandora, que además usará las del sistema operativo (en /usr/share/snmp/mibs). Pandora FMS utilizará el path {PANDORA_CONSOLE}/attachment/mibs para almacenar las mibs.

New snmp browser mibmanager.png

Es importante destacar que el gestor de mibs de Pandora sólo gestiona las mibs de "polling" que para nada tiene que ver con las mibs de traps SNMP. Para esta funcionalidad existe otro gestor, exclusivo de la versión Enteprise de Pandora FMS.

1.6.5 Wizard SNMP de Pandora FMS

En la vista de administración de un agente, hay un conjunto de herramientas para crear módulos de forma masiva: los wizard de agente.


Agent wizard.png


1.6.5.1 Wizard SNMP


Agent wizard snmp wizard.png


Deberás definir la IP de destino, la comunidad y otros parámetros optativos (SNMP v3 está soportado) para hacer un Walk a la máquina.


Snmp wizard form.png


Una vez se reciba la información correctamente, aparecerá un formulario para la creación de módulos:



Snmp wizard module creator.png



Con el Wizard SNMP es posible crear módulos de varios tipos de datos SNMP:

  • Dispositivos
  • Procesos
  • Espacio libre en disco
  • Sensores de temperatura
  • Otros datos SNMP

Seleccionarás el tipo de módulo y pasarás los elementos que quieras del combo de la izquierda al de la derecha. Cuando acabes este proceso podrás hacer click en el botón de Crear módulos.

Este wizard creará dos tipos de módulos:

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


Template warning.png

Para los módulos de tipo plugin usaremos el plugin de SNMP remoto. Por lo que si el plugin no está instalado en el sistema, estas características permanecerán desactivadas. El plugin deberá tener el nombre "snmp_remote.pl". La localización donde esté alojado no importará.

 


1.6.5.2 SNMP Interfaces wizard



Agent wizard snmp interfaces wizard.png



En el Wizard de agente hay un Wizard SNMP específicamente creado para la navegación de Interfaces.

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.

Como el Wizard SNMP, después de seleccionar la IP de destino, comunidad, etc. el sistema hará una consulta SNMP a la máquina destino y rellenará el formulario para la creación de módulos.

Usándolo, podrás seleccionar una o más interfaces del combo de la izquierda. Espués, en el de la derecha aparecerán los elementos comunes a ellos (Descripción, Velocidad, Tráfico entrante/saliente...). Podrás seleccionar uno o más elementos del combo y hacer click en Crear módulos para crear los módulos seleccionados para cada interfaz seleccionada en el combo de la izquierda.



Agent wizard snmp interfaces creation.png



1.7 Propiedades avanzadas comunes de los módulos de red

La siguiente pantalla muestra las propiedades avanzadas para la configuración de los módulos de red:


Cap5 snmp 8.png


Description

Descripción del módulo. De forma predeterminada ya existe una descripción, que se puede cambiar.

Custom ID

Identificador personalizado necesario si se desea que el servidor envíe mensajes multicast con información sobre los agentes o utilizar este campo para integrar los datos de Pandora FMS en un sistema externo de información, como una CMDB.

Interval

Intervalo de ejecución del módulo, puede ser distinto al del agente, de hecho en el ejemplo lo es.

Los valores mostrados dependen de los que se tengan configurados en la sección "Configuración > Estilos visuales", en el apartado "Valores del intervalo".

Mientras que a un usuario administrador se le dará la posibilidad de definir un intervalo personalizado en el momento de crear o editar un módulo, los usuarios estandar únicamente podrán definir intervalos previamente configurados, mostrándose los de por defecto en el caso de no definirse ninguno en "Estilos visuales".

Post process

Posprocesado del módulo. Sirve para multiplicar o dividir el valor devuelto, como por ejemplo cuando se obtienen bytes y se desea mostrar el valor en Megabytes.

Min. Value

Valor mínimo del módulo. Cualquier valor por debajo de éste se tomará como inválido y se descartará.

Max. Value

Valor máximo del módulo. Cualquier valor por encima de éste se tomará como inválido y se descartará.

Export target

Sirve para exportar los valores devueltos por el módulo a un servidor de exportación. Sólo está disponible en la versión Enterprise de Pandora FMS y si se ha configurado un servidor de exportación. Consultar la sección referente al servidor de exportación para obtener más detalles.


Module advanced.png


Cron

Si Cron from está activado, 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. Por ejemplo, la siguiente configuración haría que el módulo se ejecutase cada lunes a las 6:30:

Cron from ex1.png

Si tanto Cron from como Cron to están activados, el módulo se ejecutará una vez cuando la fecha y hora actuales esté comprendida entre la fecha y hora configuradas en Cron from y la fecha y hora configuradas en Cron to, ignorado el propio intervalo del módulo. Por ejemplo, la siguiente configuración haría que un módulo se ejecutase todos los días entre las 6 y las 7:

Cron from ex2.png

Para los módulos locales se añade la línea module_crontab correspondiente al fichero de configuración del agente. Vea [Monitorización programada] para más información.

Timeout

Tiempo que espera el agente a la ejecución del módulo expresado en segundos.

Category

Esta categorización no tiene efectos desde la interfaz de usuario normal, está pensada para usarse en conjunto con la metaconsola.

1.8 Monitorización de Windows remotos con WMI

WMI es un sistema de microsoft para obtener información remota de equipos funcionando con SO Windows, esta disponible desde la version Windows XP hasta las versiones más actuales. WMI permite obtener todo tipo de información del SO, las aplicaciones e incluso el hardware. Las consultas de WMI se pueden realizar localmente (de hecho el agente de Pandora lo hace internamente, llamando a la API del sistema operativo y preguntando al subsistema WMI) o de forma remota. En algunos sistemas, el acceso remoto a WMI no está activado y es preciso activarlo para poder consultarle desde el exterior.

Pandora FMS permite la monitorización remota de equipos Windows mediante consultas WMI. Para ello será necesario habilitar el componente wmiserver en el fichero de configuración del servidor de Pandora FMS.

 # wmiserver : 1 or 0. Set to 1 to activate WMI server with this setup
 # DISABLED BY DEFAULT
   wmiserver 1

Las consultas se hacen en WQL, una especie de lenguaje SQL específico de Microsoft para consultas internas al sistema operativo, y se puede realizar cualquier consulta que aparezca en la base de datos del sistema WMI.

Para comenzar a monitorizar por WMI, primero se deberá crear el agente correspondiente, y una vez listo pulse sobre la solapa superior de los módulos (Modules). En ella, seleccione crear un nuevo módulo WMI y pulse el botón Create:



Feo.jpg


Algunos campos son específicos de WMI y requieren una pequeña explicación:

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.

Username

Nombre del usuario administrador o de otro usuario que tenga privilegios para ejecutar consultas WMI de forma remota.

Password

Contraseña para el usuario administrador o el usuario suministrado.

WMI Query

Consulta WMI, similar a una sentencia en SQL, veamos algunos ejemplos:

SELECT LoadPercentage from Win32_Processor WHERE DeviceID = "CPU0"
SELECT SerialNumber FROM Win32_OperatingSystem
SELECT AvailableBytes from Win32_PerfRawData_PerfOS_Memory
SELECT DiskWriteBytesPersec from Win32_PerfRawData_PerfDisk_PhysicalDisk WHERE name = "_Total"

Key string

Opcional, campo para comparar con la cadena devuelta por la consulta, y de existir el módulo devuelve 1 ó 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.

Campos.jpg

Si no conoce los parámetros exactos, puede seleccionar uno de los predeterminados incluidos en la base de datos de Pandora FMS. Para ello, seleccione el componente de módulo WMI:



Galleta.jpg


Y después seleccione una comprobación WMI de las posibles:



Galletita.jpg



La información necesaria se rellena automáticamente, salvo el usuario y la contraseña. Note que debe introducir un usuario con permisos de administración y su contraseña, de lo contrario el módulo no podrá devolver ningún valor:



Otro.jpg


La versión Enterprise de Pandora FMS dispone de más de 400 módulos WMI de monitorización remota para Windows, cubriendo las tecnologías:

  • Active Directory
  • BIOS
  • Información del sistema
  • Información de Windows
  • Impresoras
  • MSTDC
  • IIS
  • LDAP
  • Microsoft Exchange

1.8.1 Wizard WMI

En el Wizard de agente (Pestaña en la vista de administración de un agente), hay un Wizard WMI, usado para navegar y crear módulos con consultas WMI a un agente específico.



Agent wizard wmi wizard.png



Deberás especificar el usuario y password del Administrador (o de un usuario con permisos para hacer consultas WMI) en el servidor de destino para hacer las primeras consultas WMI. Esta información será utilizada para la creación de módulos.



Wmi wizard module creator.png



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 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ás entre los componentes WMI registrados en el sistema (Administración->Gestionar módulos->Componentes de red)

1.9 Monitorización con plugins remotos de servidor

Este tipo de monitorización consiste en la ejecución de plugins de forma remota desde el servidor de Pandora FMS contra otros sistemas. Las instalaciones traen por defecto varios plugins de servidor listos para utilizarse, y el usuario puede siempre añadir los que necesite.

Un plugin remoto es un script o ejecutable que admite parámetros y devuelve un valor. A través de un plugin puede implementar usted mismo cualquier tipo de operación, y a través de unos parámetros de entrada, personalizar, como quiere que se comporte esa aplicación que ha desarrollado. Esto le permitiría por ejemplo, pasarle como parámetro la IP de destino del test. El resultado podría ser un número, un valor booleano (0 error, > 0 OK), o una cadena de texto. La única limitación que tienen los plugins remotos es que sólo pueden devolver un único valor.

Para registrar un plugin en Pandora FMS, iremos a la sección de administración de la consola, y en ella, pulsaremos sobre Manage servers; después pulsar Manage plugins:



Verdecito1.jpg





Verdecito2.jpg


Desde esta pantalla podrá ver que ya tiene unos cuantos plugins registrados. Aquí también puede registrar su plugin de forma manual. Para explicar como funciona, vamos a ver un plugin ya registrado, haga clic en el que se llama "UDP Plugin" que permite hacer una prueba de conectividad UDP contra una máquina remota.

Plugin create 1.jpg

Plugin type

Hay dos tipos de plugins: estándar (standard) y los de tipo Nagios. Los complementos estándar son scripts que ejecutan acciones y admiten parámetros. Los complementos de Nagios son, como su nombre indica, complementos de Nagios que se pueden usar en Pandora FMS. La diferencia estriba principalmente en que los plugins de nagios devuelven un error level para indicar si la prueba ha tenido éxito o no y una cadena descriptiva adicional. Esa descripción no es un valor numérico que se pueda usar como valor de un módulo, así que en este caso la utilizaremos para actualizar la descripción del módulo.

En este caso (para el plugin de ejemplo, UDP port check), seleccionaremos Standard ya que no se trata de un plugin de Nagios.

Max. timeout

Es el tiempo de expiración del complemento. Si no se recibe una respuesta en ese tiempo, se detendrá su ejecución. Este es un elemento muy relevante a la hora de implementar monitorización con plugins, ya que si el tiempo que tarda en ejecutar el plugin es mayor que este numero, nunca podremos obtener valores con él (no se inicializará siquiera). Este valor siempre debe ser mayor que el tiempo que tarde normalmente en devolver un valor el script/ejecutable usado como plugin. Si no se indica nada, se utilizará el valor indicado en la configuración como plugin_timeout.

Info.png

En la ejecución de un plugin existen tres timeouts: el del servidor, el del plugin y el del módulo. Tenga en cuenta que el del servidor prevalece sobre los demás, y en segundo lugar, el del plugin. Es decir, si tiene un servidor con un timeout de 10 segundos y un plugin con un timeout de 20 y un módulo que usa ese plugin con un timeout de 30, el máximo tiempo que se esperará a la ejecución de ese módulo será de 10 segundos.

 


En este caso, seleccionamos 15.

Description

Descripción del complemento. Escribir una breve descripción, como por ejemplo: Check a remote UDP port (by using NMAP). Use IP address and Port options. La descripción no es baladí, ya que se verá en la interfaz de uso del plugin por parte del usuario. Asegúrese de que explique para qué sirve el plugin.

Plugin create 2.jpg

Plug-in command

Path al ejecutable del plugin. De forma predeterminada, si la instalación ha sido estándar, estarán en el directorio /usr/share/pandora_server/util/plugin/. Aunque puede ser cualquier ruta del sistema. Para este caso, escribir /usr/share/pandora_server/util/plugin/udp_nmap_plugin.sh en el campo. Si utiliza plugin propios, asegurese de que conoce bien la ruta donde ha dejado el plugin y de que tiene permisos de ejecución (chmod 755).

Plug-in parameters

Una cadena con los parámetros del plugin, que irán tras el comando y un espacio en blanco. Este campo acepta macros tales como _field1_ _field2_ ... _fieldN_. Aquí es donde está la parte más compleja del funcionamiento de un plugin, no se asuste, lo veremos con une ejemplo.

Parameters macros

Es posible agregar macros ilimitadas para usarlas en el campo de los parámetros del plugin. Estas macros aparecerán como campos de texto en la configuración del módulo para que el usuario abstraiga la complejidad de uso de un módulo de tipo plugin. Se trata de que el usuario utilice un plugin como si fuera un módulo "de librería" en el que rellena campos, sin tener que saber como funciona por debajo. La definición de macros permite que el usuario rellene los parámetros de llamada al script sin saber como funciona, ni el script ni la forma de llamarlo.

Cada macro tiene tres campos:

  • Descripcion: Una cadena corta descriptiva de la macro. Será la etiqueta que aparecerá junto al campo en el formulario.
  • Valor por defecto: Valor asignado al campo por defecto.
  • Ayuda: Un texto explicativo de la macro, para mostrar algún ejemplo de uso o explicar mejor para que sirve ese campo.

Ejemplo de la configuración de macros:



Macro configuration.png



Ejemplo de esta misma macro en el editor del módulo:



Macro editor2.jpg



Macros internas

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_: 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_: Tags asociados al módulo.
  • _id_agent_: ID del agente, util 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 se da el caso).
  • _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 Plug-in del módulo.
  • _email_tag_: Emails asociados a tags de módulos.

1.9.1 Un plugin remoto por dentro

El código del plugin UP es extremadamente sencillo y nos sirve para explicar como funciona todo el proceso:

#!/bin/bash
# This is called like -p xxx -t xxxx
HOST=$4
PORT=$2
nmap -T5 -p $PORT -sU $HOST | grep open | wc -l

Este plugin para Linux toma dos parámetros, el puerto UDP a probar y la direccion de destino, con los parámetros -p y -sU respectivamente. Al registrar el plugin hemos definido dos macros, una para el puerto y otra para la IP de forma que cuando el usuario vaya a crear un modulo de tipo plugin solo vea eso, nada más.

Una vez registrado el plugin, para poder usarlo en un agente, se deberá crear un mógulo de tipo plugin server, pulse sobre la solapa superior de los módulos (Modules). En ella, seleccione crear un nuevo módulo de red y pulse el botón Create:


Trescientos1.jpg

En el siguiente formulario, rellene los campos vacíos, seleccione el tipo de módulo Generic module to adquire numeric data, especifique la dirección IP contra la que realizar el análisis, y también el puerto sobre el que hacerlo:



Example1 edition module.png


Una vez que haya finalizado pulse el botón Create.

En la siguiente pantalla se mostrarán los módulos para el agente, el módulo UDP Port check que acabamos de crear:



Udp port check demo.jpg



1.9.2 Ejemplo #1: Módulo de plugin remoto para MySQL

Este es otro ejemplo, algo más complejo de como implementar un plugin, en este caso otro plugin por defecto que viene con Pandora, el plugin de chequeo de MYSQL.

Cree un módulo de complemento (Administration -> Manage servers -> Manage plugins) para MySQL con los siguientes datos:

  • Nombre: MySQL
  • Plugin type: Standard
  • Max. timeout: 10 seconds
  • Descripcion: MySQL check plugin
  • Plugin command: /usr/share/pandora_server/util/plugin/mysql_plugin.sh
  • Plugin parameters: -s _field1_ -u _field2_ -p _field3_ -q _field4_
  • Macro _field1_:
    • Descripción: IP Address
    • Valor por defecto: X.X.X.X
  • Macro _field1_:
    • Descripción: User
    • Valor por defecto: User
  • Macro _field1_:
    • Description: Password
    • Valor por defecto: Password
  • Macro _field1_:
    • Descripción: Check
    • Valor por defecto: Connections
    • Ayuda: Possible values: Connections/Com_select/Com_update/Innodb_rows_read

El plugin quedaría como sigue:



Plugin mysql1.png
Plugin mysql2.png
Plugin mysql3.png
Plugin mysql4.png

Este plugin proporciona cuatro comprobaciones:

  • -q Connections: Conexiones
  • -q Com_select: Número de consultas select desde el inicio
  • -q Com_update: Número de consultas update desde el inicio
  • -q Innodb_rows_read: Lecturas de filas Innodb

Cree un módulo en el agente del equipo donde está instalado Pandora FMS y asígnelo; su nombre será Mysql Connections, usando como plugin "MySQL", como IP localhost, como usuario pandora, como contraseña la contraseña de la base de datos de Pandora, y como comprobación la palabra Connections.

El módulo para crear quedaría como sigue:



Plugin mysql module.png
Mysql module2.png


Una vez que lo cree, aparecerá en el listado de módulos, como un modulo de tipo plugin (en este caso, pendiente de inicializarse)



Fosforo3.jpg


1.9.3 Ejemplo #2: Módulo de plugin remoto para servidor SMTP

Este plugin envia un correo utilizando un servidor remoto, se puede especificar IP del servidor, puerto, usuario y password y esquema de autenticación, asi como el correo de destino y el correo de destino. Devuelve 1 si funciona y 0 si falla, es decir, se debería utilizar usando el tipo generic_proc.

Esta es una captura de la configuración de un módulo usando el plugin:



Pandora plugin SMTP5.png
Smtp module2.png


1.9.4 Ejemplo #3: Módulo de plugin remoto para servidor DNS

Este plugin verifica que la dirección IP de un dominio dado (p.e: artica.es) es una IP determinada, utilizando como referencia un DNS externo. De esta forma podemos validar si ese dominio está devolviendo la IP correcta, para evitar balanceos innecesarios, ataques DNS, etc. Devuelve 1 si funciona y 0 si falla, es decir, se deberia utilizar usando el tipo generic_proc.

Esta es una captura de la configuración de un módulo usando el plugin:



Pandora plugin DNS5.png
Dns module2.png


1.10 Ejecución remota de wizards y pruebas de red (Exec Server)

Esta funcionalidad permite que desde la consola de Pandora se puedan ejecutar algunas acciones en servidores remotos de Pandora. Así, podrá usar los Wizards SNMP de agente, el navegador de MIBs y las 'event responses' desde un servidor remoto, además de poder hacerlo desde el servidor donde está la consola.

Internamente, funciona a través de la ejecución de comandos remotos SSH desde la consola de Pandora a los servidores habilitados, a los que llamaremos “Exec Server”. Estos pueden ser servidores de Pandora o Satélite Servers, pero siempre en Linux.

1.10.1 Configuración

Para esta funcionalidad necesitaremos configurar los sistemas siguiendo una serie de pasos:

1. En la lista de servidores, en PandoraFMS, debemos acceder a la edición del servidor que queremos usar como proxy:



Exec-server-1.jpg

2. Editamos la IP del servidor donde vamos a lanzar los comandos deseados y activamos el check de “Exec Server”. Esta opción se podrá configurar sobre el Network Server y/o sobre Satélite Server.

3. No realizamos el test de configuración, ya que no hemos terminado de configurar el sistema y dará error.



Exec-server-2.1.png

4. Habilitamos el servidor donde se ejecuta la CONSOLA de Pandora para que el usuario “apache” o equivalente, tenga una shell de ejecución. Modificamos el fichero /etc/passwd y modificamos la línea para que el usuario tenga una shell válida, por ejemplo:

apache:x:48:48:Apache:/var/www:/bin/bash

5. Creamos el directorio “.ssh” en la ruta “/var/www/” y le damos permisos para el usuario “apache”:

mkdir /var/www/.ssh
chown apache /var/www/.ssh

6. Ejecutaremos, como root:

su apache

7. Generaremos la clave SSH para la conexión contra la máquina remota. Ejecutamos el comando:

ssh-keygen 

Y aceptamos con enter las preguntas que nos haga:



Exec-server-3.jpg

8. Antes de acceder por SSH al “Exec server” (que será un servidor de pandora o un satellite server en linux), debemos crear en esa máquina, un usuario específico, llamado “pandora_exec_proxy” y, además, creamos la carpeta "/home/pandora_exec_proxy/.ssh/":

sudo useradd pandora_exec_proxy -m
mkdir /home/pandora_exec_proxy/.ssh/

NOTA: El usuario no lleva password, de forma que no se pueda usar para conectar remotamente.

9. Copiaremos desde la consola de Pandora al servidor “exec server” el contenido de la llave pública, generada en el paso anterior. Para ello copiaremos el contenido del fichero /var/www/.ssh/id_rsa.pub y nos lo llevaremos (copiando y pegando el contenido) al fichero: /home/pandora_exec_proxy/.ssh/authorized_keys'' y cambiamos los permisos de ese fichero:

chown -R pandora_exec_proxy /home/pandora_exec/.ssh/

10. Una vez creado este usuario, desde la máquina donde esta corriendo la consola, y con el usuario “apache”, ejecutaremos manualmente el siguiente comando para verificar que puede entrar sin introducir password (sustituyendo la IP por el hostname/ip del Exec server que hemos configurado en los pasos anteriores)

 ssh pandora_exec_proxy@ip_address

11. Después de que todos estos pasos sean correctos, volveremos a editar (en la consola), el fichero /etc/pass para dejar el usuario apache como estaba al principio (sin shell local):

apache:x:48:48:Apache:/var/www:/sbin/nologin

12. Para finalizar, solo tenemos que probar la configuración en la sección de edición de nuestro servidor proxy, dentro de la consola de pandora, y si el indicador de prueba se vuelve verde, ya lo tendremos operativo y funcional.



Exec-server-4.png

1.10.2 Uso de la funcionalidad de los exec servers

A partir de ahora, en el explorador MIB, en los wizard SNMP de agente y en los event responses podremos escoger desde donde lanzamos la petición, si desde la consola local, o desde el Exec server configurado:



Exec-server-5.png

Y lo mismo con los Wizard WMI, el de interfaces SNMP y el wizard de agente SNMP (no disponible para servidores satélite )



Exec-server-6.png

Dependiendo el servidor que tengamos seleccionado a la hora de lanzar el Wizard se crearán los módulos adaptados para servidor o satélite server

Para las ejecuciones de “event response” primero debemos configurar una event response nueva, que utilice nuestro nuevo exec server:



Exec-server-7.png

Y luego desde un evento, la lanzamos:



Exec-server-8.png



1.11 Monitorización de rutas

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.


Para utilizar este sistema necesitamos:

  • Un agente software en el punto de origen de la ruta que queremos analizar
  • Poder alcanzar vía ICMP el punto destino desde el punto de origen.


El analizador de rutas de Pandora FMS utiliza un plugin de agente para mapear la ruta. Este plugin de agente usa varios métodos para la recolección de información, reportando al servidor de Pandora la información estructurada.

Nota: Opcionalmente, si desea hacer escaneos de rutas a través de internet, recomendamos que despliegue la aplicación mtr en el equipo origen de ruta. Más información en:

https://en.wikipedia.org/wiki/MTR_%28software%29

http://www.bitwizard.nl/mtr/


1.11.1 Configuración

A partir de la versión 7.0 OUM715, el plugin viene incluído dentro del agente. Para configurarlo deberá activar la ejecución del plugin desde la consola de Pandora FMS, una vez habilitada la configuración remota del agente.


Acceda a la pestaña de configuración de plugins en su agente y agregue la siguiente línea (si la versión del agente es anterior a 7.0 715, o no ha desplegado el plugin en la carpeta util, deberá indicar la ruta completa al plugin para su ejecución)

route_parser -t direccion_objetivo


Donde dirección objetivo puede ser una dirección IP v4 o un nombre de dominio FQDN.



Route conf2.png



1.11.2 Visualización

Una vez el sistema esté configurado y reportando, aparecerá una nueva pestaña en la vista del agente con la ruta que han seguido las comunicaciones para alcanzar el objetivo:

Vista de ejemplo de ruta hacia una máquina en una red distinta a la de origen (conexiones LAN)


Route view1.png




Vista de ejemplo de ruta hacia 8.8.8.8 (Google's DNS) (conexiones WAN)


Route view2.png




Volver a Indice de Documentacion Pandora FMS