Pandora:Documentation es:Operacion

From Pandora FMS Wiki

Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

Contents

Monitorización con agentes software

Configuración de agentes

Por defecto, los agentes de Pandora FMS llevan una configuración inicial de tipo local.Esto quiere decir, que el mantenimiento de estos se realizará desde la máquina motorizada, modificando su fichero de configuración.

Configuración remota

En la versión Enterprise existe la característica de configuración remota de agentes. Esto permite, de manera centralizada desde la consola del servidor, la gestión de los ficheros de configuración de éstos.

La configuración se compone de dos ficheros, cuyos nombres son <md5>.conf y <md5>.md5 siendo <md5> el código hash del nombre del agente. Estos ficheros se guardan en los directorios "/var/spool/pandora/data_in/conf" y "/var/spool/pandora/data_in/md5" respectivamente.

Los ficheros antes nombrados están en formato de texto plano y se editan desde la consola, que los regenera cada vez que hay cambios. La comunicación es siempre desde el agente hacia el servidor, por lo que el mecanismo es controlado por este primero.



Transferencia de xml


Para habilitar la configuración remota hace falta modificar el parámetro remote_config, poniéndole valor igual a 1, del fichero pandora_agent.conf. Una vez hecho este cambio, el fichero de configuración local del agente se ignorarán, ya que al detectar un cambio en la configuración se bajará la versión del servidor. Una forma de forzar a que se coja la configuración local del agente es borrar los ficheros de configuración del servidor.

Parámetros de configuración comunes

En la sección Agentes software de Pandora FMS puede encontrar una explicación más detallada de la configuración del agente. En este apartado sólo vamos a mencionar los parámetros más usados para configurar el agente.

Los parámetros más usados son:

  • server_ip: Dirección IP del servidor de Pandora FMS.
  • server_path: Ruta de la carpeta incoming del servidor Pandora FMS. Por defecto /var/spool/pandora/data_in.
  • temporal: Carpeta tempora del agente software. Por defecto /var/spool/pandora/data_out.
  • logfile: Archivo de log del agente software. Por defecto /var/log/pandora/pandora_agent.log
  • interval: Intervalo de ejecución del agente. Por defecto 300.
  • intensive_interval: Intervalo de ejecución de los módulos intensivos. Por defecto 300.
  • debug: Modo testeo activado. Por defecto 0 (desactivado).
  • agent_name: Nombre del agente. Por defecto se coge el hostname.
  • server_port: Puerto del servidor tentacle. Por defecto 41121.
  • transfer_mode: Modo de transferencia de archivos. Por defecto tentacle.
  • remote_config: Activación de configuración remota. Por defecto 0 (desactivada).

Un ejemplo de los parámetros generales desde una configuración Unix sería:

server_ip       192.168.1.1 
server_path     /var/spool/pandora/data_in 
temporal        /var/spool/pandora/data_out 
logfile         /var/log/pandora/pandora_agent.log 
interval        300 
debug           0 
agent_name      box01 
server_port     41121 
transfer_mode   tentacle 
remote_config    1 

Un ejemplo de los parámetros generales desde una configuración Windows sería:

server_ip       192.168.1.1 
server_path     /var/spool/pandora/data_in 
temporal        c:\archivos de programa\pandora_agent\temp
logfile         c:\archivos de programa\pandora_agent\pandora_agent.log 
interval        300 
debug           0 
agent_name      box01 
server_port     41121 
transfer_mode   tentacle 
remote_config   1

Custom fields

Los Campos personalizables son una forma fácil de configurar la información del agente. Puedes crear campos personalizables en Resources > Custom fields.



Custom fields1.png


Para crear un campo personalizable hay que hacer clic en el botón "Create field" y en rellenar los campos descritos a continuación:

Custom fields2.png


  • Name: Nombre del campo personalizable.
  • Display on front: Con este campo chequeado la información del campo personalizable se enseñará en la parte de arriba de la vista general del agente, tal como se muestra a continuación:



Custom fields3.png


Monitorización con agente software

Los datos recogidos por los agentes software se almacenan en pequeñas piezas de información llamadas «módulos». Cada módulo almacena sólo un tipo de dato. El valor de cada módulo es el valor de una variable supervisada. Una vez que el agente comience a enviar la información, los datos empezarán a consolidarse en la base de datos y se podrá tener acceso a los mismos.

Consulte la sección de instalación de los agentes software para obtener más información acerca de éstos.


Agent-monitoring.png


Los agentes software de Pandora FMS utilizan los comandos propios del sistema operativo para obtener la información. El servidor de datos de Pandora FMS almacena y procesa los datos generados por estos comandos y transmitidos al servidor dentro de un fichero XML. La información devuelta por esos comandos está contenida en lo que llamamos «Módulos».

PandoraAgent logical schema.png


En el archivo de configuración del agente los módulos están definidos con la siguiente estructura de texto:

module_begin 
module_name cpu_user
module_type generic_data
module_exec vmstat 1 2 | tail -1 | awk '{ print $13 }'
module_description User CPU Usage (%)
module_end

El parámetro que indica cómo coger la información para el módulo es module_exec. En este parámetro se especifica la instrucción que tiene que ejecutar el agente para recoger la información del sistema. Un ejemplo de comando podría ser:

module_exec vmstat 1 2 | tail -1 | awk '{ print $13 }'

Para recoger la información el agente ejecutará el comando en la shell igual que si lo hiciera un operador:

$> vmstat 1 2 | tail -1 | awk '{ print $13 }'

Entonces recoge el valor devuelto por el comando y lo añade al XML como el dato del módulo de monitorización. Por supuesto el agente puede ejecutar cualquier tipo de programa o script que devuelva un valor necesario de monitorizar. Por ejemplo el campo module_exec podría contener lo siguiente:

module_exec myScript.pl --h 127.0.0.1 -v cpu

De nuevo el agente ejecutaría el comando en la shell y recogería el resultado, igual que si un operador escribiera en la shell:

$> myScript.pl --h 127.0.0.1 -v cpu

Cuando el agente software se ejecuta por primera vez, envía un XML al servidor de datos de Pandora FMS, que lo recibe a través de tentacle, SSH o FTP en el directorio de entrada del servidor. El servidor de datos revisa ese directorio cada X tiempo y cuando encuentra un fichero, lo procesa. Al abrir ese fichero de datos, consistente en un XML, identifica el agente por su nombre, de forma única, es decir, cada agente tiene que tener un nombre completamente único, donde las mayúsculas y las minúsculas son diferenciadas por Pandora FMS. El servidor, por defecto, crea automáticamente todos los agentes de los cuales recibe datos y no están dados de alta en la BBDD. De la misma manera, si el agente se ha añadido en modo «aprendizaje», los módulos enviados que no estén definidos previamente en el agente, serán creados por el servidor automáticamente.

Template warning.png

La codificación del archivo de configuración del agente es muy importante y siempre debe ser la misma que la codificación establecida en el parámetro encoding del propio archivo de configuración. Con esto evitaremos recibir datos con caracteres mal codificados

 


Tipos de módulos

Existen varios tipos, principalmente clasificados en dos: datos con origen en agentes software y datos con origen en módulos de red ejecutados por un servidor de red. Aquellos identificados como «generic» son módulos con origen en agentes software y aquellos con identificados como «remote» son módulos de red.

generic_data

Tipo de datos numéricos. Sirve para almacenar datos numéricos (enteros y de coma flotante) obtenidos mediante un módulo de un agente de Pandora FMS.

generic_data_inc

Tipo de datos numéricos crecientes. Almacena la diferencia entre el dato anterior y el dato actual divida por el tiempo transcurrido en segundos. Este tipo de datos se utiliza para contar "nº de veces por segundo" de algo, como por ejemplo, entradas en un log/seg, bytes recibidos/seg, conexiones entrantes/seg, etc. Todos los módulos terminados en «inc» son de tipo incremental.

generic_data_inc_abs

Tipo de datos numéricos crecientes absolutos. Almacena la diferencia entre el dato anterior y el dato actual, sin realizar la división entre los segundos transcurridos, por lo que el valor corresponderá al incremento total entre las dos ejecuciones, y no al incremento por segundo. Este tipo de datos se utiliza para contar número de veces de algo, como por ejemplo, entradas en un log, bytes totales recibidos, cantidad de conexiones entrantes, etc. Todos los módulos terminados en «inc_abs» son de tipo incremental absoluto.

generic_proc

También llamados genéricamente "monitores". Es un tipo de datos booleano. Donde un valor 0 significa Falso o «Valor malo», y valores por encima de cero significan Cierto o «Valor correcto». Los tipos «Generic Proc» también se llaman monitores, porque pueden indicar si algo está bien o mal sin necesidad de interpretarlo o establecer alertas sobre él. Se despliegan en la vista del agente como pequeñas luces. Rojo si es cero, verde si es mayor que cero. Todos los módulos acabados en «proc» son monitores.

generic_data_string

Tipo de datos alfanumérico (texto).

Modulo de imagen

Si el dato que contiene el módulo es una imagen base64, es decir, si parte de la cadena de texto tiene "data:image", será identificado como una imagen y habilitará en las vistas que lo listen un enlace a una ventana para visualizar la imagen, además de mostrarse en su respectivo histórico un contenido de las distintas imágenes que formarían las cadenas almacenadas.

async_data

Tipo de datos numéricos asíncronos. Igual que generic_data pero para datos asíncronos, que sólo se actualizan cuando existe un cambio. Los tipos de datos asíncronos no tienen una periodicidad definida de cuando podemos obtener datos.

async_string

Tipo de datos alfanuméricos asíncronos. Igual que generic_string pero para datos asíncronos, que sólo se actualizan cuando existe un cambio. Es el tipo de datos que deberíamos usar para monitorizar búsquedas dentro de logs, o visores de eventos, ya que podemos tener un dato por segundo o no tener uno en varios días.

Modulo de imagen

Si el dato que contiene el módulo es una imagen base64, es decir, si parte de la cadena de texto tiene "data:image", será identificado como una imagen y habilitará en las vistas que lo listen un enlace a una ventana para visualizar la imagen, además de mostrarse en su respectivo histórico un contenido de las distintas imágenes que formarían las cadenas almacenadas.

async_proc

Tipo de datos booleano asíncronos. Igual que generic_proc pero para datos asíncronos, que sólo se actualizan cuando existe un cambio.

El agente software ya viene configurado para enviar ciertos datos del sistema en el que se instala; éstos suelen ser (dependiendo de la versión):

  • CPU de sistema
  • Espacio libre en disco
  • Memoria libre
  • Monitor del estado de programas y/o servicios.

Dependiendo de si el agente software es para un sistema operativo u otro, suelen tener más módulos, o diferentes comprobaciones.

Toda esta información se encuentra en el fichero pandora_agent.conf. Este fichero se encuentra en el directorio /etc/pandora/ en GNU/Linux y en el directorio de instalación de Windows predeterminado (C:/Archivos de Programa/pandora_agent/ o C:/Program Files/pandora_agent/, o similares).

A continuación se explican los datos para algunos de los módulos: Uso de CPU en porcentaje en GNU/Linux:

# CPU usage percentage (GNU/Linux)
module_begin
module_name cpu_user
module_type generic_data
module_interval 1
module_exec vmstat 1 2 | tail -1 | awk '{ print $13 }'
module_max 100
module_min 0
module_description User CPU Usage (%)
module_end

Se ve que el tipo de módulo es generic_data, y que ejecuta un comando de consola de GNU/Linux para obtener el resultado (module_exec). Se sabe que el máximo es 100 y el mínimo 0. El intervalo (module_interval) representa el número de iteraciones entre la ejecución de cada módulo, si es distinto de 1, el módulo sólo se ejecutará cada ése número de veces la ejecución del agente. Es decir, si el tiempo de ejecución del agente es 300 y el intervalo del módulo es 3, el módulo se ejecutará cada 3 * 300 = 900 segundos.

Uso de CPU en porcentaje en Windows:

# CPU usage percentage (Windows)
module_begin
module_name CPUUse
module_type generic_data
module_cpuusage all
module_description CPU#0 usage
module_end


Se puede comprobar que el módulo es completamente distinto en Windows y en GNU/Linux. En el caso de Windows se trata de un comando interno del agente, donde module_cpuusage all representa el consumo de CPU en todas las CPU. Utilizando module_cpuusage 0 calcularía el uso de CPU exclusivamente en la CPU #0. El resto de campos son opcionales.

Para añadir un módulo más consulte la configuración del agente y cree un bloque de módulo válido. Una vez hecho esto guarde el archivo de configuración del agente y reinicie el agente, ya sea el demonio de UNIX o el servicio de Windows.

Interfaz de creación de módulos

La creación de módulos locales en la consola se realiza mediante un formulario donde, además de la configuración común con los módulos remotos (umbrales, tipo, grupo...) se dispone de una caja de texto donde especificar los datos de configuración que irán en el fichero de configuración del agente software.

Creación de un modulo con el remote config del agente habilitado:



Local module editor.png



Junto a esa caja de texto hay dos botones, uno para crear una estructura básica de configuración y otro para comprobar que los datos de configuración son correctos. Esta comprobación se refiere a los parámetros básicos, comprobando que comience por module_begin, termine por module_end, tenga un tipo válido y un nombre. Otros parámetros podrían estar configurados erróneamente y no sería detectado.



Local module editor basic.png





Local module editor check wrong.png





Local module editor check right.png



El campo nombre y el combo tipo están ligados a los parámetros module_name y module_type de los datos de configuración. Por lo que al cambiar el nombre del módulo en el campo nombre, se cambiará automáticamente el nombre en la configuración y viceversa. Igualmente al seleccionar un tipo en el combo se cambiará el tipo de los datos de configuración y cuando se escriba un tipo correctamente en la caja de configuración se seleccionará el mismo en el combo.

Cuando un módulo es cargado desde un componente local, puede tener macros. Si tiene macros, la caja de configuración estará oculta y aparecerá un campo por cada macro. Esta característica se explica en profundidad en la sección de Plantillas y componentes

Monitorización condicionada

El agente software de Pandora FMS soporta la ejecución de scripts a modo de postcondiciones dependiendo del valor del módulo ejecutado. Además tiene una característica que permite evaluar una precondición antes de ejecutar el propio módulo. En esta sección se explican las dos características con ejemplos.

Postcondiciones

El parámetro module_condition permite definir postcondiciones a la ejecución de un módulo, es decir, comandos que se ejecutarán dependiendo del valor que devuelva la ejecución del modulo. La definición en el archivo de configuración es así:

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition < 20 add_processes.sh
module_end

Se pueden especificar múltiples condiciones para un mismo módulo. Por ejemplo:

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition (90, 100) remove_processes.sh
module_condition < 20 add_processes.sh
module_end

Ejemplos:

Ejecución cuando el valor del módulo es menor de 20:

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition < 20 add_processes.sh
module_end

Supongamos que el script get_cpu_usage.pl devuelve 18, en este caso el agente software ejecutará el script add_proceses.sh. En otro caso no lo ejecutará.

Ejecución con dos postcondiciones:

module_begin
module_name CPU_Usage_Condition
module_type generic_data
module_exec get_cpu_usage.pl
module_condition < 10 start_new_server.sh
module_condition < 20 add_processes.sh
module_end

Supongamos que el dato es 15, en este caso el agente sólo ejecutará el script add_processes.sh. Si el valor del dato fuera 6, entonces el agente ejecutaría los dos scripts start_new_server.sh y add_processes.sh

Precondiciones

El parámetro module_precondition permite evaluar una condición antes de la ejecución del módulo y con el resultado decidir si el módulo se debe ejecutar o no. La definición en el archivo de configuración es:

module_begin
module_name CPU_Usage
module_type generic_data
module_exec get_cpu_usage.pl
module_precondition > 10 number_active_processes.sh
module_end

Se pueden especificar múltiples precondiciones para un mismo módulo. Por ejemplo:

module_begin
module_name CPU_Usage
module_type generic_data
module_exec get_cpu_usage.pl
module_precondition > 10 number_active_processes.sh
module_precondition = 1 important_service_enabled.sh
module_end

Ejemplos:

Ejecución del módulo sólo cuando la precondición es mayor de 10:

module_begin
module_name CPU_Usage
module_type generic_data
module_exec get_cpu_usage.pl
module_precondition > 10 number_active_processes.sh
module_end

En este ejemplo primero se ejecuta el script number_active_processes.sh si el valor devuelto es mayor de 10 entonces se ejecuta el script del módulo. Si el valor devuelto es menor de 10 el módulo nunca se ejecuta.

Ejecución del módulo cuando se cumplen dos precondiciones:

module_begin
module_name CPU_Usage
module_type generic_data
module_exec get_cpu_usage.pl
module_precondition > 10 number_active_processes.sh
module_precondition = 1 important_service_enabled.sh
module_end

En este ejemplo tenemos dos precondiciones. Para que el módulo se ejecute se deben cumplir todas las precondiciones, en este caso dos, por ello el módulo sólo se ejecutara cuando el script number_active_processes.sh devuelva un número mayor que 10 y el script important_service_enabled.sh devuelva un 1.

Monitorización intensiva

(Sólo disponible a partir de la versión 5.0 o superior)

Para algunos modulos algunos valores son muy importantes, mientras que otros no. Por ejemplo, cuando se monitoriza un servicio del sistema querrá ser notificado tan pronto como sea posible de que el servicio está caido, pero no necesita que le recuerden cada diez segundos que el servicio está levantado.

Para esto se utilizan los módulos intensivos. Los módulos intensivos corren con un intervalo de intensive_interval segundos mientras se cumplan las condiciones intensivas, el resto del tiempo corren con un intervalo de interval segundos como el resto de módulos.

Por ejemplo, si quiere comprobar si el servicio del sistema sshd está corriendo cada 10 segundos, pero quiere que se le notifique cada 10 minutos si está levantado, puede configurar el agente de la siguiente manera:

intensive_interval 10
interval 600
module_begin
module_name SSH Daemon
module_type generic_data
module exec ps aux | grep sshd | grep -v grep | wc -l
module_intensive_condition = 0
module_end

Si el servicio se cae, se le notificará en los próximos 10 segundos, pero si el servicio está levantado se le notificará en los próximos 10 minutos.

Esto puede suponer un ahorro de espacio considerable en la base de datos de Pandora FMS.

Monitorización programada

El agente software soporta la definición de módulos programados que se ejecutan en los instantes definidos. La sintaxis usada es la misma que la del fichero crontab http://es.wikipedia.org/wiki/Cron_(Unix)#Sintaxis. Un ejemplo de la definición del módulo en sería:

module_begin
module_name crontab
module_type generic_data
module_exec script.sh
module_crontab * 12-15 * * 1
module_end

En este ejemplo el módulo se ejecuta una sola vez, todos los Lunes entre las 12 y las 15 horas.

Si queremos que se ejecute mientras dure el intervalo podemos utilizar la opción module_cron_interval 0 de la siguiente manera:

module_begin
module_name crontab
module_type generic_data
module_exec script.sh
module_crontab * 12-15 * * 1
module_cron_interval 0
module_end

Si por ejemplo queremos ejecutar el módulo, a la hora y 10 minutos la definición del módulo sería:

module_begin module_name crontab module_type generic_data module_exec script.sh module_crontab 10 * * * * module_cron_interval 0 module_end

Monitorización específica para Windows

El agente software para plataformas Windows tiene funcionalidades específicas para esta plataforma que ayudan a realizar la monitorización de una forma más sencilla. A continuación explicaremos las funcionalidades y aplicaremos unos ejemplos de las mismas.

Monitorización de procesos y watchdog de procesos

Monitorización de procesos

El parámetro module_proc comprueba si un determinado nombre de proceso está operando en esta máquina. La definición del módulo sería:

module_begin
module_name CMDProcess
module_type generic_proc
module_proc cmd.exe
module_description Process Command line
module_end


Si el nombre del proceso contiene espacios en blanco no use «" "». El nombre del proceso debe ser el mismo que muestra el Administrador de Tareas (taskmngr) de Windows incluyendo la extensión .exe, es importante respetar mayúsculas y las minúsculas.

Si queremos que el agente software de Windows nos avise inmediatamente cuando un proceso deja de funcionar tenemos que añadir el parámetro module_async yes, la definición del módulo quedaría así:

module_begin
module_name CMDProcess
module_type generic_proc
module_proc cmd.exe
module_async yes
module_description Process Command line
module_end
Watchdog sobre procesos

La funcionalidad de watchdog del agente software de Pandora para Windows permite actuar inmediatamente ante la caída de un proceso, levantando de nuevo. Es importante decir que el watchdog sólo funciona si el módulo es asíncrono.

La definición de un módulo con watchdog sería parecida a esta:

module_begin
module_name Notepad
module_type generic_data
module_proc notepad.exe
module_description Notepad
module_async yes
module_watchdog yes
module_start_command c:\windows\notepad.exe
module_startdelay 3000
module_retrydelay 2000
module_retries 5
module_end

En el ejemplo anterior el watchdog se activará cada vez que el proceso notepad.exe este desactivado y se ejecutará el comando c:\windows\notepad.exe, además si vemos los otros parámetros de configuración del watchdog veremos que el la reactivación del proceso se intentará 5 veces con un tiempo de espera inicial de 3 segundos y con un tiempo de espera entre reintentos de 2 segundos.

Monitorización de servicios y watchdog de servicios

Monitorización de servicios

El parámetro module_service comprueba si un determinado servicio se está ejecutando en la máquina. La definición de un módulo usando este parámetro sería:

module_begin
module_name Service_Dhcp
module_type generic_proc
module_service Dhcp
module_description Service DHCP Client
module_end

Si el nombre del servicio contiene espacios en blanco no use «" "». Para encontrar el nombre del servicio puede mirar el que aparece como Service Name en el gestor de servicios de Windows, es importante respetar mayúsculas y las minúsculas.

Igual que con los procesos si queremos que el agente software de Pandora nos avise inmediatamente cuando un servicio se cae tenemos que añadir el parámetro module_async yes, la definición del módulo quedaría así:

module_begin
module_name Service_Dhcp
module_type generic_proc
module_service Dhcp
module_description Service DHCP Client
module_async yes
module_end
Watchdog de servicios

Igual que para los procesos para los servicios existe un modo watchdog que permite inicializar un servicio cuando está caido. Un ejemplo de definición de módulo con watchdog para servicios sería:

module_begin
module_name ServiceSched
module_type generic_proc
module_service Schedule
module_description Service Task scheduler
module_async yes
module_watchdog yes
module_end

La definición del watchdog para servicios no requiere ningún parámetro adicional como el de procesos porque esa información ya está dentro de la definición del servicio.

Monitorización de recursos básicos

Este apartado muestra cómo monitorizar las variables básicas de una máquina Windows.

Monitorizando la CPU

Para monitorizar la CPU puede usar el parámetro module_cpuusage que devuelve el porcentaje de CPU en uso.

Es posible monitorizar las cpu por id con la siguiente definición de módulo:

module_begin
module_name CPU_1
module_type generic_data
module_cpuusage 1
module_description CPU usage for CPU 1
module_end

También puede monitorizar la media de uso de todas las CPUs del sistema con el módulo:

module_begin
module_name CPU Usage
module_type generic_data
module_cpuusage all
module_description CPU Usage for all system
module_end
Monitorizando la memoria

Para monitorizar la memoria existen dos parámetros: module_freememory que devuelve la cantidad de memoria libre del sistema, y module_freepercentmemory que devuelve el porcentaje de memoria libre del sistema.

Un módulo de ejemplo usando module_freememory sería:

module_begin
module_name FreeMemory
module_type generic_data
module_freememory
module_description Non-used memory on system
module_end

Un módulo de ejemplo usando module_freepercentmemory sería:

module_begin
module_name FreePercentMemory
module_type generic_data
module_freepercentmemory
module_end
Monitorizando el disco

Para monitorizar el disco disponemos de dos parámetros: module_freedisk que devuelve la cantidad de espacio libre y module_freepercentdisk que devuelve el porcentaje de espacio libre. Ambos módulos requieren como parámetro la unidad de disco a monitorizar, no olvide el caracter «":"».

Un módulo que usa el parámetro module_freedisk se define así:

module_begin
module_name FreeDisk
module_type generic_data
module_freedisk C:
module_end

Un ejemplo de módulo que usa el parámetro module_freepercentdisk se define así:

module_begin
module_name FreePercentDisk
module_type generic_data
module_freepercentdisk C:
module_end

Consultas WMI

El agente software de Pandora permite extraer información a través de consultas WMI, que es una fuente de información ampliamente utilizada para guardar información del sistema y externa a este.

Consultas WMI

Usando el parámetro module_wmiquery el agente software permite ejecutar localmente cualquier consulta WMI. Para realizar la consulta se define la query WMI en el parámetro module_wmiquery y la columna que contiene la información a monitorizar con el parámetro module_wmicolumn.

Por ejemplo, podemos obtener una lista de los servicios instalados:

module_begin
module_name Services
module_type generic_data_string
module_wmiquery Select Name from Win32_Service
module_wmicolumn Name
module_end

Usando WMI también podemos obtener la carga actual de CPU:

module_begin
module_name CPU_Load
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end

Chequeos remotos con el agente software

Los chequeos remotos realizados con el agente software facilitan la monitorización de redes complejas y con requisitos especiales por ejemplo relacionados con la seguridad. En esta sección se explica cómo utilizar esta característica de los agentes software.

Chequeos ICMP

Los chequeos ICMP o ping son muy útiles para saber si una máquina está conectada o no a una red. De esta forma un solo agente software prodría monitorizar el estado de todas las máquina de una forma sencilla.

Unix

Usando el agente Linux podemos usar los comandos del sistema para crear un módulo que realice que chequeo ping, la definición del módulo sería:

module_begin
module_name Ping
module_type generic_proc
module_exec ping -c 1 192.168.100.54 >/dev/null 2>&1; if [ $? == 0 ]; then echo 1; else echo 0; fi
module_end

En este ejemplo realizamos un ping al host 192.168.100.54, si queremos comprobar otros hosts sólo tenemos que cambiar la IP

Windows

El agente software para Windows soporta unos parámetros de configuración especiales para configurar el chequeo ping y son los siguientes:

  • module_ping_count x: Número de paquetes ECHO_REQUEST a enviar (1 por defecto).
  • module_ping_timeout x: Timeout en segundos de espera para cada respuesta (1 por defecto).
  • module_advanced_options: Opciones avanzadas para ping.exe.

Un ejemplo de configuración de módulo podría ser:

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 5
module_end

En este ejemplo realizamos el mismo chequeo que antes, pero desde el agente software para Windows.

Chequeos TCP

Los chequeos TCP son útiles para verificar que los puertos de una máquina permanecen abiertos. Esto puede ser interesante para saber si una aplicación esta conectada o no a la red.

Unix

Con el agente software para Unix podríamos realizar un chequeo TCP usando el siguiente módulo:

module_begin
module_name PortOpen
module_type generic_proc
module_exec nmap 192.168.100.54 -p 80 | grep open > /dev/null 2>&1; echo $?; if [ $? == 0 ]; then echo 1; else echo 0; fi
module_timeout 5
module_end

Con este módulo comprobamos que el puerto 80 del host 192.168.100.54 esta abierto o cerrado.

Windows

Si usamos el agente software para Windows disponemos de unos parámetros para configurar el módulo. Los parámetros son:

  • module_tcpcheck: Host al que queremos comprobar
  • module_port: Puerto que queremos comprobar
  • module_timeout: Timeout para el chequeo

Un ejemplo de definición del módulo sería:

module_begin
module_name PortOpen
module_type generic_proc
module_tcpcheck 192.168.100.54
module_port 80
module_timeout 5
module_end

Este módulo sería el equivalente para el agente software de Windows para realizar la comprobación del puerto 80 sobre el host 192.168.100.54.

Chequeos SNMP

Los chequeos SNMP son muy comunes en la monitorización de dispositivos de red para comprobar el estado de interfaces, bytes de entrada/salida, etc.

Unix

Si usamos el agente software para Unix podemos crear un módulo que use el comando snmpget como el siguiente:

module_begin
module_name SNMP get
module_type generic_data
module_exec snmpget 192.168.100.54 -v 1 -c public .1.3.6.1.2.1.2.2.1.1.148 | awk '{print $4}'
module_end

Este módulo devuelve el valor del OID .1.3.6.1.2.1.2.2.1.1.148 del host 192.168.100.54.

Windows

Para el agente software de Windows disponemos de los siguientes parámetros:

  • module_snmpversion [1,2c,3]: Versión de SNMP (1 por defecto).
  • module_snmp_community <community>: Comunidad SNMP (public por defecto).
  • module_snmp_agent <host>: Agente SNMP objetivo.
  • module_snmp_oid <oid>: OID objetivo.
  • module_advanced_options: Opciones avanzadas para snmpget.exe.

Un módulo de ejemplo podría ser:

module_begin
module_name SNMP get
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.148
module_end

Este módulo sería el equivalente Windows para el chequeo anterior realizado con el agente software para Unix.

Modo Proxy

Template warning.png

Para usar el modo proxy del agente de Pandora FMS en Linux/Unix no puede ser ejecutado por el usuario root, por ello es necesario una instalación especial del agente de Pandora FMS. Puede ver cómo instalar el agente de forma personaliza en la sección Instalación personalizada del Agente

 


Los agentes software de Pandora FMS tienen un Modo Proxy que les permite actuar como un proxy redirigiendo la comunicación de varios agentes al servidor de Pandora FMS. El agente software que actua en Modo Proxy también puede realizar tareas de monitorización.


Proxy-mode.png


El Modo Proxy es muy útil cuando nos encontramos con una red en la que sólo una máquina puede comunicarse con el servidor de Pandora FMS. En esta situación los agentes instalados en las máquinas sin acceso al servidor de Pandora FMS envían los ficheros XML al agente software que actua como proxy y este los redirige al servidor de Pandora FMS.

Además del envío de datos a través de XML, el Modo Proxy soporta las características de Configuración Remota y Colecciones de Ficheros

Con todas estas funcionalidades el Modo Proxy ofrece un funcionamiento transparente de los agentes software en redes con conectividad limitada.

Para activar el Modo Proxy en un agente software tiene configurar los parámetros:

  • server_ip: IP del servidor de Pandora FMS. Con el Modo Proxy activado no puede tomar valores como: 127.0.0.1, locahost, 0.0.0.0, o similares.
  • proxy_mode: Si vale 1 activa el Modo Proxy. Por defecto vale 0, desactivado.
  • proxy_max_connection: Número de conexiones simultaneas del proxy, por defecto 10.
  • proxy_timeout: Timeout para el proxy, por defecto 1 segundo.


Un ejemplo de configuración podría ser:

server_ip 192.168.100.230
proxy_mode 1
proxy_max_connection 20
proxy_timeout 3

Para redirigir la conexión de un agente software sólo tendremos que poner como dirección del servidor de Pandora la del agente con el Modo Proxy activado. Por ejemplo:

Nuestro agente en Modo Proxy tiene la IP: 192.168.100.24

En el agente software que no se puede conectar directamente al servidor de Pandora configuramos el parámetro server_ip así:

server_ip 192.168.100.24

Con esta configuración el agente software con conmunicación limitada usará el agente software en Modo Proxy para comunicarse con el servidor de Pandora.

Modo Broker

EL Modo Broker de los agentes software permite a un solo agente realizar chequeos y gestionar la configuración cómo si se tratara de varios.


Modo-broker.png


El agente software con el Modo Broker activado tiene una configuración auxiliar, similar a la configuración del agente software, para cada uno de los brokers configurados. De esta forma es como si hubiera varios agentes software instalados en la misma máquina, es decir cada broker funciona igual que un agente software. Esta característica es muy útil para gestionar varios dispositivos de forma remota con un solo agente software instalado, de esta forma es posible monitorizar distintos dispositivos con distintos archivos de configuración pero instalando un solo agente software.

Las funcionalidades principales del Modo Broker son:

  • Enviar datos locales como otro agente. Muy útil para monitorizar instancias software como agente independientes.
  • Enviar datos recolectados de chequeos remotos a otras máquinas como si hubiera un agente software instalado en ella.

Para crear un broker sólo tiene que añadir una línea con el parámetro broker_agent <nombre_broker> como estas:

broker_agent dev_1
broker_agent dev_2

Una vez creados los brokers se crearán sus archivos de configuración dev_1.conf y dev_2.conf con el mismo contenido que el agente software original, pero con el nombre cambiado. Añadiendo o quitando módulos de los archivos de configuración dev_1.conf y dev_2.conf podemos personalizar los chequeos realizados por los brokers.

En la consola de Pandora FMS los brokers se ven y gestionan como los demás agentes de forma que si tenemos un agente software instalado con dos brokers en la consola veremos tres agentes diferentes con sus módulos, configuraciones, etc.

NOTA: las instancias del modo broker no pueden utilizar colecciones. Si desea utilizar colecciones, debe distribuirlas y/o usarlas en el agente "real" que se utiliza como base en al agente broker, no en una de sus instancias.

NOTA: los módulos que guardan datos en memoria entre ejecuciones (module_logevent y module_regexp en Windows) no funcionan cuando hay agentes broker configurados.

Ejemplos de uso

Monitorizar una base de datos local como otro agente

En una máquina queremos monitorizar los parámetros básicos (CPU, memoria y disco) y además tenemos instalada una base de datos que queremos monitorizar de forma independiente.

Para realizar la monitorización usaremos la siguiente estructura:

  • Agente software instalado: monitoización de CPU, memoria y disco.
  • Broker base de datos: monitorización de estado interno de la base de datos.

Para ello instalamos un agente software en la máquina que monitorizará los parámetros de CPU, memoria y disco. Además en la configuración del agente software añadimos la línea:

broker_agent DBApp

Con esto creamos el agente broker con nombre DBApp y por tanto aparecerá el archivo de configuración dbapp.conf. En este archivo añadimos los módulo para realizar los chequeos en la base de datos:

module_begin
module_name Num Users
module_type generic_data
module_exec get_db_users.pl
module_end

module_begin
module_name Num slows queries
module_type generic_data
module_exec get_db_slows_queries.pl
module_end

Con este ejemplo aparecerían dos agente en la consola de Pandora uno con el nombre de la máquina y los módulos de CPU, memoria y disco y otro llamado DBApp con los módulos Num Users y Num slows queries.

Monitorizar dispositivos de forma remota usando brokers

Para este ejemplo tenemos un agente software instalado en una máquina Windows monitorizando (CPU, memoria y disco) y necesitamos monitorizar un router con IP 192.168.100.54 sin instalar un agente dentro. Para solucionar el problema podemos usar los brokers.

Creamos un broker con el parametro:

broker_agent routerFloor5

Con esto creamos el agente broker con nombre routerFloor5 y como tenemos un agente software instalado en una máquina Windows podemos monitorizar el router usando los módulos de ping y snmp disponibles. Para ello modificaremos el archivo routerFloor5.conf con las líneas:

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name Eth 1 up
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.1
module_end

module_begin
module_name Eth 2 up
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.2
module_end

En este ejemplo la consola web de Pandora FMS muestra dos agentes, uno es la máquina Windows con los módulos de CPU, memoria y disco y otro es routerFloor5 con los módulos: Ping, Eth 1 up, Eth 2 up.

Monitorización remota de redes inaccesibles

En algunas situaciones es necesario monitorizar dispositivos de forma remota, pero el Servidor Remoto de Pandora FMS no puede acceder directamente a ellos.



Broker example no access.png


En este ejemplo tenemos que monitorizar de forma remota los dispositivos de una de las sedes de nuestra empresa desde la sede central. El servidor de Pandora FMS está en la sede central conectado por medio de una VPN al resto de sedes y debido a una serie de restricciones el servidor de Pandora FMS no puede acceder remotamente a las máquinas. Para poder monitorizar las sedes usaremos el Modo Broker que permite al agente software enviar XMLs al servidor de Pandora como si fuera varios dispositivos distintos.

En el archivo de configuración del agente software añadiremos tantos brokers como dispositivos a monitorizar, un ejemplo de configuración sería:

broker_agent device_1
broker_agent device_2
broker_agent device_3
broker_agent device_4
...

Una vez creados los brokers podemos personalizar la monitorización para cada dispositivo accediendo a los archivos de configuración de cada broker, por ejemplo la configuración para la máquina Windows con nombre device_1 es:

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name CPU_Load
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end

module_begin
module_name Mem_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Memory
module_wmicolumn FreeMemory
module_end

module_begin
module_name Disk_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Disk
module_wmicolumn FreeSpace
module_end

Con esta configuración conseguimos realizar una configuración remota y enviar los archivos al servidor de Pandora FMS a pesar de las restricciones de comunicación entre las sedes de la empresa.

Distribuir la carga de monitorización con brokers

El Modo Broker también es muy útil para distribuir la carga de monitorización en varios puntos de la red.



Broker scalation example.png


En este ejemplo nuestra arquitectura se compone de varias redes con nombres de la A a la Z con 1000 dispositivos cada una. La capacidad del Servidor Remoto de Pandora FMS está en torno a 2000 agentes, por ello decidimos usar agentes software en Modo Broker para distribuir la carga de monitorización. Estos agentes software en Modo Broker monitorizan de forma remota todos los dispositivos de la red y envían los datos en formato XML al servidor central de Pandora FMS.

En cada una de las redes tenemos una agente con el Modo Broker activado, en él crearemos tantos broker como dispositivos tengamos que monitorizar, la configuración para el agente Broker_Agent_Net_A sería:

broker_agent device_1
broker_agent device_2
broker_agent device_3
broker_agent device_4
...

Además para cada uno de los brokers añadiríamos los módulos correspondientes para monitorizar los dispositivos. Por ejemplo el broker device_1 que es un router tendría estos módulos:

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name Eth 1 up
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.1
module_end

module_begin
module_name Eth 2 up
module_type generic_data
module_snmpget
module_snmpversion 1
module_snmp_community public
module_snmp_agent 192.168.100.54
module_snmp_oid .1.3.6.1.2.1.2.2.1.1.2
module_end

Otro ejemplo sería el broker device_2 monitoriza una máquina Windows con los siguientes módulos:

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.100.54
module_ping_count 2
module_ping_timeout 500
module_end

module_begin
module_name CPU_Load
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end

module_begin
module_name Mem_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Memory
module_wmicolumn FreeMemory
module_end

module_begin
module_name Disk_Free
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Disk
module_wmicolumn FreeSpace
module_end

Usando los agentes software en Modo Broker podemos distribuir la carga de monitorización y así poder recoger datos de miles de dispositivos de una forma sencilla.

Inventario con agente software

El agente software de Pandora FMS soporta funciones de inventario tanto hardware como software. Es sistema de inventario permite mantener un histórico de CPU, tarjetas, Memoria RAM, parches, software, etc … usados en los servidores de la compañía. Además es posible generar alertas ante cambios en el inventario por ejemplo un reemplazo no autorizado de disco duro o la desintalación de una aplicación.

Puede encontrar más información en la sección Inventario local con agentes software.

Acciones remotas por UDP

Cómo solicitar información al agente bajo demanda

Hasta la versión 3.2, no existía ninguna manera de pedir información al agente de software remoto. Deberá esperar a que el agente alcance su límite de intervalo y esperar a que envíe su información. El agente de Windows 3.0 tiene una funcionalidad no muy conocida llamada "Servidor UDP", que permite recibir comunicaciones desde el exterior para solicitar información y forzar al agente a refrescar su ciclo, forzandolo a que envíe la información al servidor.

Ahora, en la versión 3.2 hemos implementado la misma funcionalidad: REFRESH AGENT también en el agente Unix, y hemos incluído una plantilla de alerta "por defecto" y un comando para hacerlo más fácil. Ahora puede configurar sus agentes (Windows y Unix) para recibir órdenes desde la consola para enviar datos inmediatamente, sin tener que esperar a su intervalo.

Esta funcionalidad es muy sencilla. Lo primero que necesita hacer es configurar su agente (Windows o Linux) para aceptar conexiones externas sobre un puerto UDP concreto, desde una dirección específica IP (ó 0.0.0.0. para cualquiera). En Windows, usted también puede definir otros posibles elementos que el agente pueda ejecutar, como resultado de un comando remoto. En Unix, la única operación comtemplada (de momento) es "REFRESH AGENT". Esto tendrá como resultado una ejecución inmediata del agente, saltándose su intervalo.

Este es un ejemplo de las configuraciones del servidor UDP en el agente software de Unix v3.2:

udp_server 1
udp_server_port 41122
udp_server_auth_address 0.0.0.0

Active el servidor con 1 y desactívelo con 0 en la opción "udp_server". Configure 0.0.0.0.como dirección ip fuente para activar cualquier dirección IP.

Este es un ejemplo de las configuraciones del servidor UDP en el agente software de Windows v3.x:

udp_server 1
udp_server_port 41122
udp_server_auth_address 192.168.1.23

Es exactamente lo mismo, y en este caso, usamos la dirección 192.168.1.23 como la única dirección IP autorizada para refrescar este agente.

El servidor de Pandora FMS tiene un pequeño script, que envía la orden al agente. En el comando que hemos creado por defecto, es completamente operativo y está listo para ser utilizado. Se trata de un script Perl que actúa como un cliente pequeño para comunicarse con el servidor UDP sencillo que está integrado en el agente y que envía comandos que son transmitidos en la línea de comandos.




Remote agent command.png



Es posible limitar los valores de un campo definiendo una lista valor/etiqueta. En este caso, el campo sera un combo de seleccion. El formato es el que se muestra a continuación:



Fields.png


También proporcionamos una plantilla de alerta por defecto para asignar alertas "manuales" a un agente, lo que quiere decir, que una alerta nunca se disparará automáticamente. Usted debera utilizar "alertas manuales" para forzar manualmente la ejecución utilizando el botón redondo de vista principal del agente, para forzar la ejecución del comando de alerta.




Alert template manual.png



Hemos creado una acción de alerta por defecto llamada "Restart agent", que llama al comando del agente remoto. Esta acción pasa el comando REFRESH AGENT al comando y utiliza la dirección IP principal del agente que queremos alcanzar, utilizando el puerto por defecto para el servidor UDP (41122/UDP):



Agent restart action.png


Siga estos pasos para habilitar la opción de refresco del agente remoto de software:

1. Configurar las opciones en el fichero de configuración para el agente software (Unix o Windows). Por favor tenga cuidado de la dirección IP autorizada (¿está el servidor de Pandora FMS bajo un NAT?), o ponga 0.0.0.0. para permitir que cualquier dirección IP fuerce refrescar el agente.

2. Reinicie el agente software.

3. Necesita configurar la dirección IP en el item de su agente en la consola de Pandora FMS. La acción de alerta utilizará la dirección IP para conectar el agente software que corre en le sistema remoto.

4. Instale una alerta para cualquiera de los módulos de ese agente (no importa cual), utilizando esta pantalla como guía de ejemplo:



Alert restart combinationsettings.png


5. Ahora está listo para forzar un refresco para aquel agente utilizando la vista principal. Haga click en el botón redondo verde que está a la izquierda de la alerta que acaba de definir:



Agent refresh button.png


Cada vez que desee obtener información del agente "en seguida" sin tener que esperar al intervalo del agente, sólo tiene que hacer click en el botón y esperar unos segundos. El agente será contactado y forzado a ejecutarse, el XML se transferirá a su servidor de Pandora FMS y será procesado,y dependiendo de la carga de su sistema, será procesado de 1 a 5 segundos y desplegado en la consola.


Acciones remotas personalizadas

Además de la acción de refrescar agente, podemos especificar acciones personalizadas que realizar en los agentes por medio de órdenes UDP desde el servidor de Pandora.

En caso de querer hacerlo, hay que hacer una pequeña configuración extra en el archivo pandora_agent.conf. Además, por supuesto, de activar el servicio UDP y configurarlo para que reciba las órdenes del servidor:

udp_server 1
udp_server_port 41122
udp_server_auth_address <IP del servidor>

Deberemos añadir una línea por cada comando que queremos ejecutar, con el siguiente esquema:

process_nombredelaorden_start comando

Por ejemplo, si queremos una orden remota para iniciar el servicio sshd:

process_sshd_start /etc/init.d/sshd start

A continuación, deberemos crear una acción de alerta en Pandora Console para cada comando remoto que hayamos creado. El comando a utilizar será "Remote agent control" (creado por defecto, está preparado para mandar órdenes UDP). En el campo 1 escribiremos "START PROCESS sshd". Ahora sólo hay que crear una nueva alerta manual con la nueva acción en el agente cuyo servicio sshd deseemos iniciar. Al forzar la alerta, la orden se lanzará y el agente iniciará el servicio.


Info.png

También pueden crearse órdenes que llamen a scripts. Esto permite realizar una gran cantidad de acciones remotas en un agente con sólo pulsar un botón.

 


Usar plugins en agentes software

Los plugins de agente se ejecutan mediante el agente software de Pandora FMS, y pueden devolver diferente information (modulos) a la vez. Cada plugin funciona de una manera diferente, y deberia probar primero como funciona antes de usarlo. La instalación por defecto de Pandora FMS viene con un pequeño conjunto de plugins. Por supuesto, los plugins Unix y Windows son diferentes, aunque alguno de ellos es bastante parecido.

En sistemas Windows

En la versión 3.2, los agentes windows agent vienen con los siguientes plugins:

  • df.vbs: Devuelve el espacio libre en disco (en bytes). Devuelve un módulo diferente por cada unidad de disco encontrado en el sistema. Si se quiere obtener información únicamente de una unidad o unidades en concreto se pueden pasar como parámetros al plugin.
  • df_percent.vbs: Es muy similar al anterior, pero devuelve el espacio libre de forma porcentual (%). Generará modulos con un nombre del tipo "DiskFree_C". Tanto este modulo como el anterior "autodescubren" las unidades en la maquina.
  • logevent_log4x.vbs: Lee eventos del eventlog y genera información de tipo "log4x".
  • ps.vbs: Es un plugin que necesita pasar como argumentos los procesos a verificar. Devolverá un modulo con cada uno de ellos, indicando si está corriendo o no.

En windows, todos los plugins por defecto están programados en VBScript, para ejecutarlos es necesario usar el intérprete adecuado indicando la ruta completa.

Estos son algunos ejemplos de como usar los plugins anteriores:

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\logevent_log4x.vbs" Aplicacion System 300

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\df.vbs"

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\ps.vbs" iexplore.exe myapp.exe

En sistemas Unix

En la versión 3.2, los agentes Unix vienen de serie con los siguientes plugins:

  • files_indir: Este plugin recibe como argumento un directorio, por ejemplo /tmp. Devolverá dos modulos, uno llamado FS_/tmp de tipo Booleano, devolviendo 1 (OK) si el diretorio contiene el mismo numero de ficheros que antes y otro modulo "NumFiles_FS_/tmp" de tipo numérico, conteniendo en nº de ficheros que contiene dicho directorio.
  • grep_log: Es un parser de log genérico, se usa para extraer información específica de ficheros de texto. Toma tres argumentos: <fichero_a_procesar> <nombre_modulo> <exp_reg>. Generará un modulo de tipo "async_string" cuando encuentre información (por eso es de tipo asincrono). Creará un módulo con el nombre que se le ha pasado si la expresion regular que se le pasa hace "match" con la información nueva que haya en el fichero pasado como argumento desde que se miró por ultima vez.
  • pandora_df: Es similar al plugin de Windows, mostrará el espacio disponible en todas las particiones del sistema, incluyendo las particiones de red (NFS; SMB, etc). Si se le pasa como argumento el nombre de un volumen, solo mostrará aquellas pasadas como argumento al plugin.

Estos plugins son similares a los plugins de WIndows, pero en este caso no es necesario pasar la ruta completa al plugin, porque los plugins de Unix se buscan por defecto en el directorio "/plugin" del directorio del agente, en /etc/pandora/plugins.

Estos son algunos ejemplos de uso de los plugins:

module_plugin grep_log /var/log/syslog Syslog .

module_plugin pandora_df tmpfs /dev/sda1

Existen otros plugins especiales de Unix:

  • nagios_plugin_wrapper: Este no es un plugin en si mismo, es un "envoltorio" para poder usar plugins de nagios desde el agente. Básicamente permite ejecutar un plugin de nagios, y recoge la salida estándar para meterla como descripcion al modulo, recogiendo tambien la salida de errorlevel para convertirla a un modulo booleano de Pandora. Pasa usarlo simplemente llame al plugin de nagios con todos los parámetros que necesite y automáticamente obtendrá un modulo de pandora. Puede ver información mas detallada un poco más adelante, en este mismo capítulo.
  • inventory: Este plugin se usa en el sistema de inventario con agentes. Creará un XML de inventario con información del sistema. En la documentación (Sección de inventario) puede encontrar mas información.
  • pandora_update: Este plugin especial se usa para autoactualizar el agente, puede consultar la documentación (Seccion de configuracion) para más información.

Ejemplos de uso de plugins

Los plugin para el agente software puede devolver un dato o un grupo de ellos. Un ejemplo de plugin que devuelve un dato puede ser el plugin ps.vbs de Windows. Con la siguiente línea ejecutamos el plugin:

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\ps.vbs" IEXPLORE.EXE

El resultado será un módulo que devuelve 0 si el proceso no está activo y 1 si está activo:

<module>
    <name><![CDATA[IEXPLORE.EXE]]></name>
    <description><![CDATA[Process IEXPLORE.EXE status]]></description>
    <![CDATA[1]]>
</module>

Un ejemplo de plugin que devuelve varios datos puede ser el plugin df.vbs de Windows. La línea para ejecutar el plugin sería:

module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\df.vbs"

El plugin devuelve un módulo por cada disco encontrado, el resultado sería:

<module>
    <name><![CDATA[C:]]></name>
    <description><![CDATA[Drive C: free space in MB]]></description>
    <![CDATA[8050]]>
</module>

<module>
    <name><![CDATA[D:]]></name>
    <description><![CDATA[Drive D: free space in MB]]></description>
    <![CDATA[900]]>
</module>

Editor de plugins de agentes software

A partir de Pandora FMS 5.0, es posible administrar los plugins de agentes software desde la consola sin editar directamente el fichero de configuración.

Si un agente tiene la configuración remota activada, en su vista de administración dispondrá de la pestaña del editor de plugins.



Plugin editor tab.png

El editor muestra el listado de los plugins, permite eliminarlos, añadirlos y desactivarlos. En el caso de los plugins de política puede ser útil desactivarlos porque al volver a aplicar la política se mantendrán desactivados.



Plugin editor.png

Los plugins administrados en este editor pueden ser, a su vez, editados desde el fichero de configuración del agente.



Plugin editor conf.png

Cómo crear plugins de agente propios

Los plugin pueden ser creados en cualquier lenguaje de programación. Sólo tienen que respetar estas restricciones:

  • Independientemente de lo que se quiera hacer, debe ser automático (sin interaccion del usuario), y debe ser hecho desde la línea de comandos (shell). Se puede usar cualquier tipo de lenguage de scripting o lenguage compilado, pero en ese caso hay que distribuir también, además del ejecutable, todas las librerias (o DLL) que sean necesarias para la ejecución del plugin.
  • El plugin debe devolver la información a través de la salida estándar (simplemente usando echo, printf o el equivalente en el lenguaje que se vaya a usar para el plugin), y se debe usar el formato XML de los agentes de Pandora FMS para devolver la información. Este es un ejemplo de un modulo de tipo numérico en XML:
<module>
<name><![CDATA[Sample_Module]]></name>
<type><![CDATA[generic_data]]></type>
<![CDATA[47]]>
<description><![CDATA[47]]></description>
</module>

Los datos que van encerrados en los tags <![CDATA[xxx]]> se usan para proteger el XML de cierta informacion que pueda contener caracteres "indigestos" para el XML, como <,>,& or %.

Antes de probar a crear un plugin, visite la librería de plugins de Pandora FMS en http://pandorafms.org, y si después se decide a crear su propio plugin, remítalo a la librería pública, para que otros puedan usarlo.


Template warning.png

Asegúrate de terminar la salida de tu plugin (si es un script) con un errorlevel 0 o el agente interpretará que el plugin ha tenido un error y no ha podido ejecutar

 


Ejemplo de plugin en Shellscript (Linux/Unix)

#!/bin/bash
# Detect if local Mysql is without password
# First, do we have a running MySQL?
CHECK_MYSQL=`netstat -an | grep LISTEN | grep ":3306 "`
if [ ! -z "$CHECK_MYSQL" ]
then

        CHECK_MYSQL_ROOT=`echo "select 1234" | mysql -u root 2> /dev/null | grep 1234`
        if [ -z "$CHECK_MYSQL_ROOT" ]
        then
        echo "<module>"
        echo "<type>generic_proc</type>"
        echo "<name>mysql_without_pass</name>"
        echo "<data>1</data>"
        echo "<description>MySQL have a password</description>"
        echo "</module>"
        else
        echo "<module>"
        echo "<type>generic_proc</type>"
        echo "<name>mysql_without_pass</name>"
        echo "<data>0</data>"
        echo "<description>MySQL do not have a password</description>"
        echo "</module>"
        fi
fi

exit 0

Utilizando plugins de Nagios desde el agente

Nagios tiene un gran número de plugins que puede utilizar con Pandora FMS. Un modo de hacerlo es utilizar los plugins remotos con el Plugin Server, usando la compatibilidad de Nagios. Pero de este modo, sólo conseguirá sus estados, ya que no utiliza el output descriptivo que tienen algunos plugins para Nagios.

Utilizar el wrapper para usar los plugins de nagios en el agente software resolverá este problema. El wrapper viene por defecto con el agente de Unix 3.2. Un plugin equivalente para los agentes Windows de Pandora FMS puede descargarse desde la web http://pandorafms.org, y en la libreria de recursos de nuestra web en [1]).

¿Qué hace el wrapper de plugins para los plugins de Nagios?

Ejecute el plugin de Nagios, utilizando sus parámetros originales y convirtiendo el output en datos útiles para Pandora FMS. Este tiene dos tipos de información:

  • Información acerca del Status: NORMAL (1), CRITICAL (0), WARNING (2), UNKNOWN () y otras (4). Por defecto, utilizarán un modulo proc, con lo que los valores NORMAL y CRITICAL están trabajando "por defecto"; si usted desea tener información acerca de WARNING y otros valores, deberá configurar los umbrales del módulo de manera manual.
  • Información de tipo descriptivo: generalmente información de cadenas. Se situará en el campo de descripción del módulo. Normalmente algo parecido a "OK: successfully logged in".

Ejemplo

Si tiene un plugin pop3 (en /tmp/check_pop3_login) con los permisos de ejecución, (lo que comprueba si la cuenta pop3 está funcionando sólo con conectarse con un host remoto, enviando un usuario y una contraseña y visualizando que todo esté correcto), entonces, puede ejecutarlo desde la línea de comandos:

/tmp/check_pop3_login  mail.artica.es sanler@artica.es mypass

Devolverá algo parecido a :

OK: successfully logged in.

Y si no es correcto devolverá algo similar a esto:

Critical: unable to log on

Utilizar el wrapper es fácil. Sólo tiene que poner el wrapper y el nombre que desée al módulo antes de ejecutar la llamada:

/etc/pandora/plugins/nagios_plugin_wrapper sancho_test /tmp/check_pop3_login  mail.artica.es sanler@artica.es mypass

Esto generará un XML completo para el plugin de agente.

<module>
<name>sancho_test</name>
<type>generic_proc</type>
0
<description><![CDATA[Critical: unable to log on]]></description>
</module>

O:

<module>
<name>sancho_test</name>
<type>generic_proc</type>
1
<description><![CDATA[OK: successfully logged in.]]></description>
</module>

La entrada completa en el pandora_agent.conf será algo similar a:

module_plugin nagios_plugin_wrapper POP3_artica.es /tmp/check_pop3_login mail.artica.es sanler@artica.es mypass

Esto se verá de manera parecida a esto en el módulo (en el fail event):


Sample plugin wrapper.png

Monitorización con KeepAlive

Existe un módulo especial, tiene un tipo único llamado "keep_alive" y sirve para dar información ante la ausencia de contacto del agente. Sirve para saber cuando un agente ha dejado de enviar información y alertarnos de este hecho.

Cuando hay un modulo, remoto o local, que obtiene información del agente, la fecha de ultimo "contacto" con el agente se actualiza, de forma que siempre que hay datos, aunque solo sea un módulo del total, el agente tendrá actualizado su fecha de ultimo contacto, que sirve para saber si el agente "no responde". Concretamente un agente se da por "muerto" cuando no ha actualizado su fecha en el doble de tiempo de su intervalo, es decir, si tiene un intervalo de 5 minutos, y hace más de 10 minutos que no hay ningún de actualización, el agente se da por muerto.

En este caso, es cuando el módulo keepalive entraría en juego, disparándose y marcando el monitor en estado Critical.

La configuración de este tipo de módulos es muy fácil, basta con crear un nuevo módulo de tipo "dataserver":

Keepalive create.png


Una vez creado, si el agente tiene datos, dentro de su intervalo, siempre estará en estado "NORMAL" (verde):

Keepalive1.png


Si el agente deja de enviar datos (en este ejemplo, tenía intervalo de 1 minuto), entonces automáticamente saltará y se pondrá en estado CRITICAL (rojo):

Keepalive2.png


Cabe destacar que si tenemos un módulo remoto, por ejemplo, un Ping, además de los datos reportados por el agente, el módulo keepalive nunca saltaría, ya que estamos actualizando el agente constantemente mediante el Ping.

El módulo keepalive por lo demás se comporta como cualquier otro módulo, se le puede asociar una alerta y se puede usar para cualquier otro elemento: informes, mapas, etc.

Monitorización de capturas de comandos (Command snapshots)

Esta forma de monitorizar, posible a partir de la version 4.0.3, permite al administrador definir una forma especial de capturar toda la salida del comando, en lugar de un resultado concreto. Esta se almacena como información de texto, y se visualiza de una forma diferente, no como simples datos, sino reconstruyendo la forma original del mensaje, de forma que si es una salida compleja y formateada en columnas, se vea igual.

Como una imagen vale más que mil palabras:


Snapshot 1.png

Esto es como se ve la salida del comando "netstatn -an", capturado por Pandora FMS, al pinchar en el icono especial para las capturas de comandos.


Snapshot 2.png


Así es como se ve la captura del comando a lo largo del tiempo. De esta forma, aunque Pandora recibe los datos, sólo mostrará cuando ha habido cambios o como mínimo una vez al día, aunque no haya cambios (recuerde que el dato sigue siendo un generic_data_string y se comporta como tal). Esto es ideal para que si hay problemas a determinada hora, pueda comprobar como estaba el sistema a esa hora determinada.


Para capturar estos comandos, basta con escribir un plugin que envíe todos los datos, generando los tags XML necesarios, y ejecutando el plugin como tal, con la directiva module_plugin. Veamos el siguiente plugin de ejemplo, que genera la salida del comando netstat, tal como acaba de ver en las capturas anteriores:

#!/bin/bash
echo "<module>"
echo "<name>netstat</name>"
echo "<type>generic_data_string</type>"
echo "<data><![CDATA["
netstat -an | grep LIST
echo "]]></data>"
echo "</module>"

Grabe ese contenido a un archivo en el agente (o distribúyalo con colecciones de ficheros) y ejecútelo de la siguiente manera:

module_plugin <path completo al fichero>

De esta forma generará command snapshots fácilmente para casi cualquier comando. Algunas sugerencias útiles para sistemas Unix son:

* top -b -n 1
* ps aux
* vmstat 1 5
* who 
* last -10

En el caso de sistemas Windows:

* tasklist
* netstat -an
* net start

Info.png

Recuerde que siempre debe hacerlo dentro de un script, generando el XML. Si lo hiciera desde un "module_exec" cada línea se interpretaria como un dato individual, y no se mostraría como uan captura de comando, sino como diferentes líneas de datos.

 


Monitorización y visualización de imágenes

Esta forma de monitorizar, posible a partir de la version 6.0 SP4, permite definir módulos que contengan imágenes en formato texto con una codificación base64, pudiendo mostrar dicha imagen en lugar de un resultado concreto. Esta se almacena como información de texto, y se visualiza de una forma diferente, no como simples datos, sino reconstruyendo una imagen.

Así es como se ve la salida de una cadena de texto con el contenido "data:image" (imagen en base64), capturado por Pandora FMS, al pinchar en el icono especial para las capturas de imágenes:


Snapshot text 1.png


Para capturar estas imágenes, basta con escribir un plugin que envíe todos los datos, generando los tags XML necesarios, y ejecutando el plugin como tal, con la directiva module_plugin. Veamos el siguiente plugin de ejemplo, que genera la salida de una imagen, tal como acaba de ver en la captura anterior:

#!/bin/bash
echo "<module>"
echo "<name>Líder actual de la liga</name>"
echo "<type>async_string</type>"
echo "<data><![CDATA[data:image/jpeg;base64,/9j/4AAQSkZ....]]></data>"

// El dato anterior sería generado por un dispositivo/aplicación dando imágenes en base64.

echo "</module>"

Grabe ese contenido a un archivo en el agente (o distribúyalo con colecciones de ficheros) y ejecútelo de la siguiente manera:

module_plugin <path completo al fichero>

Grupos protegidos por contraseña

Por defecto, cuando un agente envía datos por primera vez al servidor de Pandora FMS se añade de forma automática al grupo que se haya definido en el fichero de configuración del agente. Esto significa que, en la práctica, cualquiera puede añadir un grupo a un agente si conoce el nombre del grupo. Esto podría suponer un problema si varios clientes comparten su instancia de Pandora FMS o si quiere controlar lo que hay en cada grupo.

Desde la versión 6.0SP5, puede configurar de manera opcional una contraseña para un grupo desde la Consola de pandora FMS. Un agente no se añadirá a un grupo a menos que se haya especificado la contraseña correcta en el fichero de configuración del agente. Tenga en cuenta que si un agente ya pertenece a un grupo no se comprobará la contraseña.

Ejemplo

Para configurar una contraseña para un grupo, navege al editor de grupos y haga click en editar:

 <screenshot>

Introduzca la contraseña del grupo y guarde sus cambios:

 <screenshot>

Para añadir un agente nuevo a este grupo, edite su fichero de configuración y añada la siguiente opción de configuración:

 group_password <password>

Finally, restart the agent. You should see the newly created agent in your Pandora FMS Console:

 <screenshot>

Volver a Indice de Documentacion Pandora FMS