Pandora:Documentation es:Operacion

Volver al Índice de Documentación Pandora FMS

1 Monitorización con Agentes Software

1.1 Monitorización con Agente Software

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.

Si ejecutan versiones anteriores a 7 NG consulte acerca del nombrado de los Agentes Software a final de este artículo.

1.1.1 Configuración de Agentes Software

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.

1.1.1.1 Configuración local

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

1.1.1.1.1 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 ambiente *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.

1.1.1.1.2 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.

1.1.1.1.3 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

1.1.1.2 Configuración remota

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

Una vez que la configuración remota del agente está activada, cualquier cambio que se haga localmente en el fichero de configuración será sobreescrita por la configuración almacenada en la consola. Para volver a la administración local del Agente Software, detenga su servicio, restablezca remote_config a cero e inicie el servicio de nuevo.

1.1.1.2.1 Custom fields

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

Es posible incluir enlaces en los custom fields usando las etiquetas [url]enlace[/url] o [url=enlace]Nombre web[/url].

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.

Si se activa el parámetro "Enabled combo", "Password type" quedará inhabilitado.

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_vale i386

1.1.1.3 Parámetros de configuración comunes

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.
• debug: Al estar activado (valor 1) fija el modo de depuración debug, así no envía los XML al servidor para poder analizar el XML generado.
• agent_name: Nombre, por defecto el hostname.

Ejemplo en ambiente *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 ambiente MS Windows®:

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

1.1.1.4 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 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.

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

Recuerde reiniciar el servicio del Agente Software para hacer efectivos los cambios. Luego el agente debe crearse correctamente en la Consola de Pandora FMS.

1.1.2 Módulos en Agentes y Agentes Software

1.1.2.1 Tipos de módulos

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.

1.1.2.2 Intervalos en los módulos locales

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 300x2 (600).

1.1.2.3 Interfaz de creación de módulos

Funcionalidad solo para versión Enterprise; la configuración remota del Agente Software respectivo debe estar habilitada.

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

1.1.3 Monitorización condicionada

1.1.3.1 Postcondiciones

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.

1.1.3.1.1 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

1.1.3.1.2 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

1.1.3.1.3 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

1.1.3.2 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.

Se debe hacer la abstracción mental de asignar el valor a module_precondition y luego comparar con la condición

1.1.3.2.1 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

1.1.3.2.2 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.

1.1.4 Monitorización intensiva

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.

1.1.4.1 Ejemplo

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).

1.1.5 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. 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

Si utilizamos un intervalo que ocasione que el módulo no reporte datos, este módulo se pondrá en estado "desconocido". Para estos casos utilice módulos asíncronos.

1.2 Chequeos remotos con el agente software

Cuando 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

1.2.1 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 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 segudos, 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.

1.2.2 Chequeos TCP

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 PortOpen
module_type generic_proc
module_tcpcheck 192.168.100.54
module_port 80
module_timeout 5
module_end

1.2.3 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

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

1.3 Modo Proxy

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. Para ello consulte la Instalación personalizada del Agente

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 172.17.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

1.4 Modo Broker

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.

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

1.4.1 Ejemplos de uso del modo Broker

1.4.1.1 Monitorizar una base de datos local como otro agente

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.

1.4.1.2 Monitorizar dispositivos de forma remota usando brokers

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".

1.4.1.3 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.

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.

1.4.1.4 Distribuir la carga de monitorización con brokers

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.

1.5 Inventario con agente software

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.

1.6 Acciones remotas por UDP

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

Tenga presente que UDP es por naturaleza inseguro (pero eficiente para enviar mensajes sin comprometer una respuesta cierta).

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.

Aunque puede establecerse a 0.0.0.0 para que acepte desde todos los orígenes, dicha práctica no es recomendada. Si tiene varios Servidores PFMS y/o utiliza IPv6 puede colocar diferentes direcciones IP separadas por comas. Por ejemplo si tiene en IPv6 2001:0db8:0000:130F:0000:0000:087C:140B, su abreviatura es 2001:0db8:0:130F::87C:140B utilice ambas separadas por comas.

.

1.6.1 Cómo solicitar reinicio de servicio de Agentes Software

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.

1.6.2 Acciones remotas personalizadas

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:

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

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

1.7 Plugins en agentes software

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.

1.7.1 Ejecución en sistemas Windows

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

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

1.7.2 Ejecución en sistemas Unix

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.

1.7.3 Gestión de plugins de Agente Software desde la Consola

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.

1.7.4 Ejemplo 1

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>

1.7.5 Ejemplo 2

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>

1.7.6 Cómo crear plugins personalizados para Agente Software

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.

1.7.7 Utilizando plugins de Nagios desde Agente Software

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"]]>

1.8 Monitorización con KeepAlive

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.

El módulo KeepAlive se puede crear solo desde la consola (aunque no tengamos configuración remota habilitada) y no deja ninguna traza en el fichero pandora_agent.conf

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

Funcionamiento en estado "NORMAL" (verde):

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):

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. 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 como informes, mapas, etcétera.

1.9 Monitorización de capturas de comandos (Command snapshots)

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.

Para que esto funcione así, hay que configurar adecuadamente tanto la consola de Pandora (setup) como el agente que recoge esa información, asegurándose de que es texto sin tratar.

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

1.10 Monitorización y visualización de imágenes

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>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 <vía completo al fichero>

1.11 Monitorización específica para Windows

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:

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.

El Watchdog sólo funciona si el módulo es asíncrono.

1.11.1 Monitorización de procesos y watchdog de procesos

1.11.1.1 Monitorización de procesos

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

1.11.1.2 Watchdog sobre procesos

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 c:\windows\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 c:\windows\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.

1.11.2 Monitorización de servicios y watchdog de servicios

1.11.2.1 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

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

1.11.2.2 Watchdog de servicios

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.

1.11.3 Monitorización de recursos básicos

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

1.11.3.1 Monitorizando la CPU

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

1.11.3.2 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.

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

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

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

1.12 Versiones anteriores a 7 NG

1.12.1 Nombre de los agentes

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