Monitorización con Agentes Software

Volver al Índice de Documentación Pandora FMS

Los Agentes Software se encuentran en ejecución en los sistemas operativos de los cuales recogen información. Cada uno de los chequeos que hacen sobre el sistema, como uso de CPU, memoria libre o espacio en disco, corresponde a un módulo. Así, por cada módulo se recoge un único dato en cada ejecución.

Las directivas propias del Agente Software sirven para recoger ciertos datos directamente del sistema operativo (ej. uso de CPU, memoria, eventos, etcétera), ejecutando comandos propios del sistema operativo siguiendo instrucciones de scripts predefinidos. También es posible ejecutar estos comandos de manera directa así como cualquier otro software siempre y cuando devuelvan datos de una manera estándar.

El Dataserver Pandora FMS procesa y almacena en la base de datos toda la información generada por los agentes software, que le hacen llegar sus datos en un fichero XML.

Esquema lógico de un agente/agente físico.

Toda la configuración y los parámetros se encuentran almacenados en el fichero pandora_agent.conf, el cual está instalado también localmente junto a su Agente Software. La configuración básica está tratada en "Configuración de los Agentes Pandora FMS", a continuación se expone la configuración avanzada.

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

module_begin
module_name <your module name>
module_type generic_data
module_exec <your command>
module_description <your description>
module_end

• module_name: Nombre del módulo.
• module_exec: Comando a ejecutar.
• module_description: Descripción de la tarea a monitorizar.

Ejemplo 1

module_begin
module_name Files in var spool
module_type generic_data
module_exec ls /var/spool | wc -l
module_description Number of files incoming dir
module_end

En entornos *nix el comando ls lista ficheros de un directorio y es ejecutado con la línea module_exec para entregar el valor al comando wc que contará el números de palabras recibidas para igual número de archivos. El valor devuelto por esa última ejecución será el dato que obtendrá el módulo y será mostrado en la monitorización.

Ejemplo 2

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

El comando vmstat reporta estadísticas de la memoria virtual, en este ejemplo son dos los comandos adicionales para “refinar” la información deseada. Se recomienda primero lanzar el comando manualmente y analizar la salida.

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

Si el resultado satisface el requerimiento se podrá agregar al fichero de configuración; posteriormente el valor devuelto por la ejecución mediante el Agente Software será almacenado en el XML como dato del módulo.

Ejemplo 3

Cualquier comando o software puede ser ejecutado mediante module_exec mientras la salida sea compatible con los valores aceptados por Pandora FMS (numérico, alfanumérico o booleano), por lo que es posible indicar scripts personalizados:

module_exec myScript.pl --h 127.0.0.1 -v cpu

De nuevo el agente ejecutará el comando en la shell y recogerá el resultado, igual que si fuera ejecutado por un operador:

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

En la versión Enterprise es posible gestionar remotamente los ficheros de los Agentes Software desde la Consola Web de Pandora FMS. Esto permite la administración centralizada de todos los agentes software sin necesidad de acceder físicamente a los sistemas donde se encuentran instalados.

La configuración de cada agente se almacena en el servidor de Pandora FMS en dos ficheros: <md5>.conf y <md5>.md5, donde <md5> es el hash del nombre del Agente software. Estos ficheros son almacenados respectivamente en:

 /var/spool/pandora/data_in/conf

y

/var/spool/pandora/data_in/md5

La Consola se encarga de mantener sincronizados dichos ficheros en el servidor Pandora FMS y los respectivos locales donde esté instalado cada Agente Software.

Para habilitar la configuración remota solo hay que habilitar el parámetro correspondiente en el fichero de configuración local del agente en primer lugar. A partir de este momento todos los cambios deberán hacerse desde la consola de Pandora FMS:

remote_config 1

Los campos personalizados permiten añadir información adicional al agente. Puede crear campos personalizados en ►Resources → Custom fields.

De manera predeterminada los campos Display up front y Enabled combo vienen deshabilitados:

• Al activar el campo Display up front la información del campo personalizado se mostrará en la vista general del agente. Además, será necesario activar este token para enviar la información de los Custom Fields a la Metaconsola y poder mostrarla en la vista de la Metaconsola y trabajar en la Custom Field View con estos datos:

• Enabled combo: Una vez activado, en la ventana de configuración del custom field correspondiente aparecerá un nuevo campo para introducir los valores del combo separados por comas. Este parámetro permite activar la configuración de parámetros seleccionables desde un desplegable.

Los custom fields también se pueden pasar desde el fichero de configuración del agente, utilizando el siguiente token de configuración, por ejemplo:

 custom_field1_name Model
 custom_field1_value i386

Parámetros más importantes para la configuración básica del agente (mayores detalles en Agentes software de Pandora FMS):

• server_ip: Dirección IP del servidor de Pandora FMS.
• server_path: Ruta de la carpeta de entrada incoming del servidor Pandora FMS, por defecto /var/spool/pandora/data_in.
• temporal: Carpeta, por defecto /tmp.
• 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 segundos.
• agent_name: Nombre, por defecto el hostname.
• remote_config: Activación de la configuración remota. Deshabilitada (0) por defecto. Solamente para la versión Enterprise.
• debug: Al estar activado (valor 1) fija el modo de depuración debug, de esta manera, se crea una copia de los XML que se envían al servidor y se almacenan en el directorio temporal para su análisis. Además, en sistemas MS Windows® se crea un archivo .debug en la ruta de instalación del Agente con un log detallado de la ejecución de cada Módulo. En versiones Enterprise, el modo debug activo deshabilita la configuración remota desde la Consola al Agente Software.

Ejemplo en entornos *nix:

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

Ejemplo en entorno MS Windows®:

server_ip       192.168.1.1
server_path     /var/spool/pandora/data_in
temporal        "%ProgramFiles%\pandora_agent\temp"
logfile         "%ProgramFiles%\pandora_agent\pandora_agent.log"
interval        300
debug           0
agent_name      box02
server_port     41121
transfer_mode   tentacle
remote_config   1

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 agente a un grupo 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.

Es posible 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.

Ejemplo

Para configurar una contraseña para un grupo, vaya al editor de grupos y haga clic en editar, introduzca la contraseña del grupo y guarde sus cambios:

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>

En función del tipo de dato devuelto:

• generic_data: datos numéricos y de coma flotante.
• generic_data_inc: tipo de datos numéricos crecientes. Almacena la diferencia entre el dato anterior y el dato actual dividida por el tiempo transcurrido en segundos, mostrando la tasa por segundo. Se utiliza para contar los ciclos por segundo (Hertz) de algo, como por ejemplo, entradas en un log/seg, bytes recibidos/seg, conexiones entrantes/seg, etc.
• 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, sin importar el factor tiempo. Este tipo de datos se utiliza para contar el número de veces de algo, como por ejemplo, entradas en un log, bytes totales recibidos, cantidad de conexiones entrantes, etc.
• generic_proc: tipo de datos booleano, cero (0) significa Falso o incorrecto (preconfigurado como “estado crítico”) y valores por encima de cero significan Cierto o correcto.
• generic_data_string: tipo de datos alfanuméricos (texto).
• async_data: contiene un valor generic_data pero solo se actualizan cuando existe un cambio. Los tipos de datos asíncronos no tienen una periodicidad de tiempo definida.
• async_string: igual que async_data pero con dato tipo generic_string. Útil para monitorizar búsquedas dentro de logs o visores de eventos.
• async_proc: igual que async_data pero con dato tipo generic_proc (booleano).
• Modulo de imagen: utilizan como base un módulo de tipo cadena de texto (generic_data_string o async_string). Si el dato que contiene el módulo es una imagen codificada en base64,(encabezado “data:image”) será identificado como una imagen y habilitará en las vistas un enlace a una ventana para recuperar la imagen. Además se mostrarán en su respectivo histórico un contenido de las distintas imágenes que conforman las cadenas almacenadas.

Los módulos locales (o de agente software) tienen todos como “base” el intervalo de su agente. Sin embargo, pueden tomar valores múltiplos de esa base si modifica el parámetro module_interval con un multiplicar entero mayor que cero; por ejemplo:

module_interval 2

Si un agente tiene un intervalo de 300, el módulo del intervalo será de 300×2 (600).

La creación de módulos locales en la consola se realiza mediante un formulario donde, además de la configuración común de todo módulo (umbrales, tipo, grupo, etcétera) dispone de una caja de texto donde especificar los datos de configuración a establecer en el fichero de configuración del Agente Software.

• Al hacer clic en el botón Load basic (template), se borrará el contenido de Data configuration con una plantilla básica que deberemos modificar de acuerdo a la necesidad de monitorización.
• Una vez modificado, al hacer clic en Check (syntax) verificará que la sintaxis de plantilla siga siendo correcta, sin embargo, el resto de los comando no serán comprobados.

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, ver más información en Plantillas y componentes

El Agente Software soporta la ejecución de comandos y scripts en modo de postcondiciones. Esto quiere decir que se pueden realizar acciones dependiendo del valor obtenido en la ejecución del módulo.

Ejemplo 1

Mediante el parámetro module_condition indicaremos un valor (o rango de valores) y la ejecución a realizar en caso de que el dato obtenido cumpla con la condición (uso de CPU menor al 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

Ejemplo 2

Se pueden especificar múltiples condiciones para un mismo módulo, en un rango y con un umbral mínimo (matemáticamente, se ejecuta una o ninguna de las dos opciones ) :

 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

Ejemplo 3

Similar al ejemplo anterior, pero puede ejecutar ambas condiciones o una o ninguna (probar con valores escogidos: si es 5, 15 ó 30):

 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

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.

Ejemplo 1

Según el uso de CPU, si los procesos activos son más de diez, obtener el porcentaje de uso del CPU y reportar al servidor Pandora FMS:

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

Ejemplo 2

Se pueden especificar múltiples precondiciones para un mismo módulo y se deben cumplir todas:

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

En este caso el módulo se ejecuta solo si hay más de diez procesos activos y si al menos uno de ellos es un proceso importante.

Existen ciertos módulos que tienen una importancia especial, tales como procesos o servicios críticos en ejecución. Para poder tener una monitorización más controlada de estos casos existe la monitorización intensiva.

Consiste en avisar en un intervalo más corto de que ha aparecido un problema serio sin necesidad de reducir el intervalo general del agente.

Configuración en Agente Software:

• interval: obligatorio, tiempo de muestreo del agente en segundos, es el intervalo general para todos los módulos locales.
• intensive_interval: opcional, tiempo en que avisará si existe algún problema.

Configuración en módulo:

• module_intensive_condition = <valor>: si el módulo obtiene como resultado el <valor> indicado en este parámetro, notificará en el intervalo intensivo antes definido.

El servicio sshd es muy importante pues es utilizado para conectar por shell de manera remota, necesitamos monitorizar su funcionamiento:

 intensive_interval 10
 interval 300

 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 está ausente, se notificará en los próximos 10 segundos, si está funcionando notificará cada 5 minutos (intervalo normal, 300 segundos).

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. Un ejemplo de la definición del módulo para que ejecute todos los días lunes entra las 12 y las 15 horas:

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

Para ejecutar en el minuto 10 de cada hora:

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

Cuando el servidor principal de Pandora FMS no tiene acceso para realizar chequeos remotos (generalmente por cuestiones de seguridad), un Agente Software es capaz de tomar su lugar para dichas tareas e incluso puede distribuirlos en agentes broker

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 podría monitorizar el estado de todas las máquina de una forma sencilla.

Unix

Usando los comandos del sistema (todos los parámetros en la “línea de comando” module_exec):

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

Nota: sustituir 192.168.100.54 por la dirección IP a monitorizar.

MS Windows®.

Los parámetros se deben especificar en module_ping_count (número de paquetes, 1 por defecto) y module_ping_timeout (tiempo límite en segundos, 1 por defecto); ejemplo:

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

Nota: module_advanced_options permite opciones avanzadas para ping.exe.

Los chequeos TCP son útiles para verificar que los puertos de una máquina permanecen abiertos y permiten conocer si una aplicación conecta o no a la red.

Unix

Con el comando nmap y sus parámetros de configuración en la línea de comando, a una dirección IP chequeamos si el puerto 80 está abierto (tiempo de espera de respuesta de 5 segundos):

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

MS Windows®.

Los parámetros se deben especificar en:

• module_tcpcheck: dirección IP del dispositivo.
• module_port: número de puerto.
• module_timeout: tiempo de espera para la respuesta.

Ejemplo:

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

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

Utilizando el comando snmpget, por ejemplo:

 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.

MS Windows®.

Configuración de los 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.

Ejemplo que realiza lo mismo que el ejemplo anterior:

 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

Los Agentes Software de Pandora FMS tienen un Modo Proxy que les permite redirigir los ficheros de datos generados por otros Agentes Software al servidor de Pandora FMS. El agente software que actúa en Modo Proxy también puede realizar tareas de monitorización.

El modo proxy fue creado para redes de área local donde un solo ordenador está expuesto al Internet, donde se encuentra el servidor de Pandora FMS. Es necesario monitorizar con Agentes Software el resto de equipos de esa red; los otros equipos se comunicarán con el proxy en lugar de con el server. El Modo Proxy también soporta las características de Configuración Remota y Colecciones de Ficheros.

Configuración de los parámetros:

• server_ip: IP del servidor de Pandora FMS.
• proxy_mode: activado (1) o desactivado (0).
• proxy_max_connection: número de conexiones simultáneas del proxy, por defecto 10.
• proxy_timeout: tiempo de espera de respuesta para el proxy, por defecto 1 segundo.
• proxy_address: dirección en la que escucha el proxy.
• proxy_port: puerto en el que escucha el proxy.

Ejemplo:

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 se debe colocar como dirección del servidor de Pandora FMS la del Agente proxy con el Modo Proxy activado.

Por ejemplo, el Agente Software en Modo Proxy tiene la dirección IP 192.168.100.24, el resto de los Agentes Software deben ser configurados con:

server_ip 192.168.100.24

EL Modo Broker de los Agentes Software permite a un solo agente realizar chequeos y gestionar la configuración como si se tratara de varios distintos.

Cuando se activa el Modo Broker en un Agente Software, se crea un nuevo fichero de configuración. A partir de ese momento, el Agente Software original y el nuevo broker se gestionarán de forma separada con sus ficheros de configuración independientes, como si fuesen dos Agentes Software totalmente separados en la misma máquina.

Finalidades principales:

• 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>. Es posible crear tantos agentes Broker como se quiera, añadiendo las correspondientes líneas broker_agent:

 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 su nombre correspondiente. 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 agentes independientes, 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.

Como ejemplo, existe un Agente Software instalado que realiza monitorización de CPU, memoria y disco de un ordenador que además ejecuta una base de datos. Para realizar monitorización de forma independiente, añadimos la línea:

broker_agent DBApp

Con esto creamos el agente broker con nombre DBApp que genera el archivo de configuración dbapp.conf. Allí agregamos, para monitorizar la base de datos (número de usuarios conectados y número de consultas lentas):

 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

La Consola de Pandora FMS mostrará uno con el nombre de la máquina y los módulos de CPU, memoria y disco y, además, otro llamado DBApp con los módulos Num Users y Num slows queries.

Como ejemplo, existe un Agente Software instalado en una máquina con MS Windows® que monitoriza CPU, memoria y disco. Necesitamos monitorizar un router con IP 192.168.100.54 sin instalar un agente dentro. Para ello creamos un broker con el parámetro:

broker_agent routerFloor5

Con esto creamos el Agente Broker de nombre routerFloor5. Luego al fichero routerFloor5.conf modificar las líneas para albergar los módulos disponibles de ping y snmp:

 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

La Consola web mostrará 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” y “Eth 2 up”.

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

El agente Software en Modo Broker permite enviar los XMLs al servidor de Pandora como si se tratase de varios dispositivos distintos. Para ello añadiremos tantos brokers como dispositivos a monitorizar, por ejemplo:

 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 tal como se ha explicado para cada Agente Software en modo de chequeo remoto.

La capacidad del Servidor Remoto de Pandora FMS está en torno a 2000 agentes, trabajando con Agentes Broker podemos elevar a 3000 y liberar de gran parte del trabajo al servidor principal. En el gráfico, cada una de las redes tiene un Agente Software con el Modo Broker activado, en él crearemos tantos broker como dispositivos tengamos que monitorizar. Por ejemplo, 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, como se ha explicado anteriormente.

El Agente Software de Pandora FMS soporta funciones de inventario tanto de hardware como de software. El 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, como por ejemplo un reemplazo no autorizado de disco duro o la desinstalación de una aplicación.

Para más información visite la sección Inventario local con agentes software.

Un Agente Software es capaz de recibir peticiones remotas y ejecutar órdenes.

Para permitir que el servidor PFMS envie órdenes a los Agentes Software a su cargo, se debe configurar:

• udp_server: cero por defecto, valor en uno (1) para activar esta funcionalidad.
• udp_server_port: puerto de escucha en Agente Software.
• udp_server_auth_address: dirección IP del servidor Pandora FMS

Reinicie el Agente Software para que los cambios se apliquen.

Se debe utilizar el script udp_client.pl, presente en el servidor de Pandora FMS y normalmente ubicado en /usr/share/pandora_server/util. Se puede ejecutar desde línea de comando o bien utilizarlo en una alerta, mediante el comando que viene preconfigurado en la consola “Remote agent control”.

Existe también una acción de alerta por defecto llamada Restart agent sobre este script, empleando la acción REFRESH AGENT.

Luego puede forzar la ejecución de la alerta o bien forzar un estado incorrecto del módulo para que la alerta se dispare y comprobar así la configuración.

Además de la acción de reiniciar servicio de Agente Software, se pueden especificar acciones personalizadas. Para ello se debe añadir una línea por cada comando a ejecutar, con el siguiente esquema (sustituya < order_name > con el nombre de la orden):

process_< order_name >_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, se debe crear una acción de alerta en Pandora FMS 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) e insertar en el campo 1 “START PROCESS sshd”:

Luego 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 enviará y el Agente software iniciará el servicio.

Se caracterizan por realizar comprobaciones avanzadas complejas desde los agentes software, pudiendo devolver como resultado varios módulos en lugar de un único valor. A diferencia de los plugins de servidor, que se ejecutan por el servidor de Pandora FMS, los de Agente Software devuelven sus datos en un XML, reportando uno o varios módulos a la vez.

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

Ejemplos:

module_plugin cscript.exe //B "%ProgramFiles%\pandora_agent\util\logevent_log4x.vbs" Aplication 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

El Agente Software para Windows trae diversos plugins listos para utilizarse.

Los plugins de Unix se buscan por defecto en el directorio del agente, en /etc/pandora/plugins, por lo que se invocan y a continuación se le pasan los parámetros que sean necesarios:

  module_plugin grep_log /var/log/syslog Syslog .
  module_plugin pandora_df tmpfs /dev/sda1

El agente software Unix trae varios plugins listos para funcionar.

En la versión Enterprise es posible administrar sin editar directamente el fichero de configuración. Al tener la configuración remota activada, un Agente Software en su vista de administración dispondrá de la pestaña del editor de plugins.

Este apartado muestra el listado de los plugins activos en el agente, y 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.

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

Los plugin para el agente software puede devolver un dato o un grupo de ellos. Un ejemplo de plugin que devuelve un dato es ps.vbs en ambiente Windows, el cual comprueba si un proceso se encuentra en ejecución.

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>
     <data><![CDATA[1]]></data>
 </module>

El plugin df.vbs en ambiente Windows devuelve el espacio libre en cada dispositivo de almacenamiento con la siguiente orden:

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

Resultado:

 <module>
     <name><![CDATA[C:]]></name>
     <description><![CDATA[Drive C: free space in MB]]></description>
     <data><![CDATA[805000]]></data>
 </module>
 
 <module>
     <name><![CDATA[D:]]></name>
     <description><![CDATA[Drive D: free space in MB]]></description>
     <data><![CDATA[90000]]></data>
 </module>

Es posible agregar un token en la configuración de los plugins de agente que al ser habilitado permite la opción de 'encapsular' las definiciones de plugins dentro de las etiquetas module_begin y module_end.

Este token habilitado permite insertar bloques de configuración como module_interval o module_crontab, entre otros.

Para habilitar este token basta con desplazarse en la gestión de los agentes al ítem plugins de agente y en la parte superior de la configuración lo encontraremos bajo el nombre de Advanced.

Los plugin pueden ser creados en cualquier lenguaje de programación. Solo se debe tener en cuenta las normas generales y las normas específicas para su desarrollo.

#!/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

' df.vbs
' Returns free space for available drives.
' --------------------------------------

Option Explicit
On Error Resume Next

' Variables
Dim objWMIService, objItem, colItems, argc, argv, i

' Parse command line parameters
argc = Wscript.Arguments.Count
Set argv = CreateObject("Scripting.Dictionary")
For i = 0 To argc - 1
    argv.Add Wscript.Arguments(i), i
Next

' Get drive information
Set objWMIService = GetObject ("winmgmts:\\.\root\cimv2")
Set colItems = objWMIService.ExecQuery ("Select * from Win32_LogicalDisk")

For Each objItem in colItems
	If argc = 0 Or argv.Exists(objItem.Name) Then
		If objItem.FreeSpace <> "" Then
			Wscript.StdOut.WriteLine "<module>"
			Wscript.StdOut.WriteLine "    <name><![CDATA[" & objItem.Name & "]]></name>"
			Wscript.StdOut.WriteLine "    <description><![CDATA[Drive " & objItem.Name & " free space in MB]]></description>"
			Wscript.StdOut.WriteLine "    <data><![CDATA[" & Int(objItem.FreeSpace /1048576) & "]]></data>"
			Wscript.StdOut.WriteLine "</module>"
            Wscript.StdOut.flush
		End If
	End If
Next

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 la salida descriptiva que tienen algunos plugin para Nagios.

Para ello fue creado el wrapper de plugins de Nagios que lidia con esta situación. El wrapper viene por defecto con el agente de Unix 3.2, en ambiente Windows debe descargar un equivalente desde la librería de recursos de Pandora FMS.

Funcionamiento general

El wrapper ejecuta el plugin de Nagios, utilizando sus parámetros originales y convirtiendo su salida en datos útiles para Pandora FMS. Contiene dos tipos de información:

• Información acerca del estado teniendo en cuenta los niveles de error de Nagios: NORMAL (1), CRITICAL (0), WARNING (2), UNKNOWN () y otras (4). Por defecto, utilizarán un módulo 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, por ejemplo:

<![CDATA["OK: successfully logged in"]]>

Un módulo singular en Pandora FMS es el tipo llamado keep_alive, utilizado para alertar si un Agente Software ha dejado de enviar información (véase anteriormente Acciones remotas por UDP). Dicha alerta ocurre cuando no ha actualizado su fecha de último contacto en el doble de tiempo de su intervalo, disparándose y marcando el monitor en estado Critical.

Creación de un nuevo módulo de tipo KeepAlive:

Funcionamiento en estado “NORMAL” (verde), “NO INICIALIZADO” (azul):

Si el agente deja de enviar datos (para este ejemplo tenía un intervalo de 1 minuto), entonces automáticamente saltará y cambiará a estado CRITICAL (rojo). Para visualizar este tipo de módulos puede ir al menú lateral izquierdo y seleccionar Monitoring → Views → Monitor detail (interfaz de Pandora FMS)y en el diálogo de filtro, campo Data type seleccione KeepAlive y luego haga clic en el botón Show:

KeepAlive se comporta como cualquier otro módulo: se le puede asociar una alerta y se puede usar para cualquier otro elemento como informes, mapas, etcétera.

Comandos que presenten salidas extensas, como top o netstat -n pueden ser capturados completamente por un módulo y reproducidos tal cual. El módulo debe configurarse como tipo texto.

En la Consola, se debe activar la opción:

Este método permite definir módulos de tipo cadena (generic_data_string o async_string) 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 al hacer clic en el icono especial para las capturas de imágenes:

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. Ejemplo:

#!/bin/bash
echo "<module>"
echo "<name>Actual leader</name>"
echo "<type>async_string</type>"
echo "<data><![CDATA[data:image/jpeg;base64,/9j/4AAQSkZ....]]></data>"
echo "</module>"

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

Grabe ese contenido a un archivo en el agente (o distribúyalo con colecciones de ficheros) y ejecútelo de la siguiente manera (sustituya “< complete path to the file >” con la ruta completa al fichero):

module_plugin < complete path to the file >

El Agente Software para sistemas 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. Normas comunes:

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

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

Para que avise inmediatamente cuando un proceso deja de funcionar se debe añadir el parámetro module_async yes (ver normas comunes al principio de sección Windows):

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

La funcionalidad de Watchdog del Agente Software de Pandora FMS para MS Windows® permite actuar inmediatamente ante el fin abrupto de un proceso, iniciándolo de nuevo.

Ejemplo:

 module_begin
 module_name Notepad
 module_type generic_data
 module_proc notepad.exe
 module_description Notepad
 module_async yes
 module_watchdog yes
 module_user_session yes
 module_start_command "%SystemRoot%\notepad.exe"
 module_startdelay 3000
 module_retrydelay 2000
 module_retries 5
 module_end

Cada vez que el programa bloc de notas deje de funcionar, el Watchdog ejecutará el comando:

%SystemRoot%\notepad.exe

(ver normas comunes al principio de sección Windows). 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 en la sesión activa del usuario.

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

Para que avise inmediatamente cuando un proceso deja de funcionar se debe añadir el parámetro module_async yes (ver normas comunes al principio de sección Windows):

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

Funciona de manera similar al Watchdog de procesos. Ejemplo:

 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.

Este apartado muestra cómo monitorizar los recursos básicos de una máquina Windows.

El parámetro module_cpuusage 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

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.

Módulo de ejemplo para module_freememory:

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

Módulo de ejemplo para module_freepercentmemory:

 module_begin
 module_name FreePercentMemory
 module_type generic_data
 module_freepercentmemory
 module_end

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, recuerde agregar el caracter : , ejemplo:

 module_begin
 module_name FreeDisk
 module_type generic_data
 module_freedisk C:
 module_end

Ejemplo de módulo para module_freepercentdisk:

 module_begin
 module_name FreePercentDisk
 module_type generic_data
 module_freepercentdisk C:
 module_end

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 obtener información del sistema y externa a este.

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, 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

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

A partir de la versión 7 de Pandora FMS los agentes tienen un alias y un nombre (o identificador único). Un agente configurado por defecto generará un nombre (o identificador) basado en una cadena hexadecimal pseudoaleatoria, y un alias (o nombre visible) basado en el hostname de la máquina.

En versiones anteriores solo existía el “nombre” de la máquina, y el sistema anterior es totalmente compatible con las versiones más modernas de Pandora FMS, solo que si en una misma instalación de Pandora FMS encuentra dos agentes con el mismo identificador (o nombres) los datos de ambos agentes se mezclarán y/o pisarán. Por eso introdujimos a partir de la versión 7 la posibilidad que agentes con diferente nombre pudieran tener el mismo alias.

Para cambiar este comportamiento se utilizan los token de configuración siguientes:

 pandora_agent
 pandora_alias

Por defecto, el fichero de configuración no utiliza ninguno de los dos, de forma que obtiene el hostname de la máquina como alias y un numero hexadecimal aleatorio muy grande como nombre o identificador. El nombre del agente no es ya visible (excepto en la vista detallada del agente) y NO se puede cambiar. El Alias del agente se puede cambiar en cualquier momento, sin tener que preocuparse de la configuración del agente software, ya que el que se usa para identificar unívocamente al agente es el “nombre” de agente.

Volver al Índice de Documentación Pandora FMS