Pandora:Documentation es:Configuracion

From Pandora FMS Wiki

Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

Contents

Configuración de Pandora FMS

Pandora FMS tiene tres componentes básicos que se deben configurar para una correcta operación. Los dos primeros son el servidor y la consola web, que deben interactuar entre ellos y la base de datos para poder introducir, procesar y mostrar la información recogida. Luego están los agentes software que envían los datos al servidor de Pandora FMS.

En este capítulo se explicarán los archivos de configuración de los tres elementos, así como otros elementos importantes para un correcto funcionamiento de los componentes de la aplicación.

Servidor

El servidor de Pandora FMS tiene un archivo de configuración que permite ajustar multitud de parámetros de la aplicación para obtener un rendimiento óptimo. El fichero de configuración pandora_server.conf está ubicado, de forma predeterminada, en el directorio /etc/pandora/.

Elementos del fichero de configuración

El fichero de configuración de Pandora FMS es un fichero en texto plano estándar de UNIX, donde las variables que no se usan o los comentarios van precedidos de un carácter almohadilla (#). Los comentarios deben comenzar la linea y es para toda ella, no puede haber lineas mixtas de configuración y comentario.

A continuación se explican todos los parámetros de ajustes:

servername

Nombre del servidor para Pandora FMS. Si se comenta se usará el nombre del equipo o host. Por favor, no cambie el nombre del servidor una vez lo ha arrancado, puesto que los agentes y los modulos remotos quedan vinculados al nombre del servidor que los arrancó por primera vez, y deberia cambiar en cada agente el servidor al que está asignado si quiere que funcionen de nuevo.

incomingdir

Directorio de entrada de los paquetes de datos XML. De forma predeterminada es /var/spool/pandora/data_in/. Se puede optimizar Pandora FMS utilizando un disco RAM o un disco especial más rapido, ya que este direccion actúa como "buffer" de entrada.

log_file

Fichero de registro (log) de Pandora FMS. De forma predeterminada es /var/log/pandora/pandora_server.log. Este es el log principal del servidor, muy importante para hacer debug y localizar problemas.

snmp_logfile

Fichero de registro (log) de la consola SNMP de Pandora FMS. De forma predeterminada es /var/log/pandora/pandora_snmptrap.log. Este es un fichero especial que almacena los traps antes de que Pandora los procese. Este fichero es generado automáticamente y no se deberia alterar o modificar.

errorlog_file

Fichero de registro de errores (log) de Pandora FMS. De forma predeterminada es /var/log/pandora/pandora_server.error. Este log almacena todos los errores no capturados y la informacion de herramientas usadas por el servidor que no ha sido capturada en el log principal.

dbname

Nombre de la base de datos a la que se conectará el servidor. De forma predeterminada es pandora.

dbengine

Motor de base de datos empleado (oracle, postgres or mysql). Mysql por defecto.

dbuser

Nombre de usuario para la conexión contra la base de datos de Pandora FMS. De forma predeterminada es pandora.

dbpass

Contraseña para la conexión contra la base de datos de Pandora FMS.

dbhost

Dirección IP o nombre del equipo que alberga la base de datos de Pandora FMS. En instalaciones reducidas suele ser el mismo equipo donde está el servidor, esto es localhost.

dbport

(Opcional) Puerto TCP donde escucha el motor de base de datos.

daemon

Indica si el servidor de Pandora FMS se ejecuta en forma de demonio o no. Si se lanza el servidor con la opción –D, entonces también se ejecuta como demonio.

verbosity

Nivel de detalle para los mensajes del servidor y de error, los ficheros de registro o logs. 0 es el predeterminado, 1 es detallado, 2 es depuración, 3-10 ruidoso. Cuando tenga problemas con Pandora FMS pruebe a poner este valor a 10 para que le de el máximo nivel de detalle. Valores altos aqui (como 10) tienen un impacto muy grande en el rendimiento del sistema, asi que no se recomienda en sistemas de produccion de forma continuada.

master

Prioridad de servidor maestro. El servidor con el valor más alto que esté en ejecución será el maestro. Los empates se resuelven al azar. Si se configura a 0, este servidor nunca se convertirá en maestro. Vea el capítulo Alta disponibilidad (HA) para más información.

snmpconsole

1 indica que la consola de recepción de traps SNMP está activada en la configuración. 0 que no lo está. La consola depende del servicio de UNIX snmptrapd y lo para y arranca cuando Pandora se inicia. Antes de arrancar Pandora, verifique que el proceso snmptrapd no está iniciado en el sistema.

networkserver

1 indica que el servidor de red de Pandora FMS está activado en la configuración. 0 que no lo está.

dataserver

1 indica que el servidor de datos de Pandora FMS está activado en la configuración. 0 que no lo está. Este proceso además de procesar los ficheros .XML de los agentes realiza más tareas, debería tener siempre este servidor funcionando.

reconserver

1 indica que el servidor de reconocimiento de red de Pandora FMS está activado en la configuración. 0 que no lo está. Si no va a usar el reconserver, desactívelo.

pluginserver

1 indica que el servidor de complementos de Pandora FMS está activado en la configuración. 0 que no lo está.

predictionserver

1 indica que el servidor de predicción de Pandora FMS está activado en la configuración. 0 que no lo está. El Prediction Server gestiona, entre otros, los Servicios y los módulos sintéticos.

wmiserver

1 indica que el servidor de WMI de Pandora FMS está activado en la configuración. 0 que no lo está.

inventoryserver

(sólo Pandora FMS Enterprise)

1 indica que el servidor de inventario remoto de Pandora FMS está activado en la configuración. 0 que no lo está. Los datos de inventario enviados por los agentes se procesan con el data server y no hace falta activar el servidor de inventario remoto.

exportserver

(sólo Pandora FMS Enterprise)

1 indica que el servidor de exportación (export server) de Pandora FMS está activado en la configuración. 0 que no lo está.

webserver

(sólo Pandora FMS Enterprise)

1 para activar el servidor de chequeos WEB (Webserver o tb conocido como Goliat Server). 0 que no lo está.

eventserver

(Sólo Pandora FMS Enterprise)

Activa (1) o desactiva (0) el servidor de correlación de eventos (1 por defecto).

icmpserver

(sólo Pandora FMS Enterprise)

Activa (1) o desactiva (0) el servidor ICMP Enterprise (0 por defecto).

El servidor ICMP Enterprise utiliza Nmap para realizar peticiones ICMP en bloque. La salida XML de versiones más antiguas de Nmap no devuelve el tiempo de ida y vuelta. Instale una version 5.51 o superior. Si todos los módulos de latencia ICMP devuelven 0 ponga esta variable de configuración a 0 o instale una version superior de NMAP. Si no está seguro, puede ejecutar nmap y comprobar si devuelve el round-trip time:

nmap -nsP -PE -oX - www.pandorafms.com | grep srtt

snmpserver

(sólo Pandora FMS Enterprise)

Activa (1) o desactiva (0) el servidor SNMP Enterprise (0 por defecto). El servidor SNMP Enterprise utiliza una utilidad externa llamada braa para llevar a cabo peticiones SNMP en bloque. Los módulos que no puedan ser procesados por braa se marcarán como no inicializados y el servidor de Red se ocupará de ellos. Si experimenta problemas adicionales con braa ponga esta variable de configuración a 0.

network_timeout

Indica, en segundos, el tiempo de expiración de red para las conexiones con los módulos de red ICMP de los agentes. De forma predeterminada su valor es 2. Si va a realizar chequeos contra host en una red WAN, debería incrementar este valor o probablemente tenga valores erróneos ya que las pruebas de PING abortarán pasado ese tiempo.

server_keepalive

El tiempo antes del que declarar al servidor como caído. En segundos. De forma predeterminada su valor es 45.

server_threshold

El número de segundos del bucle principal, en segundos. De forma predeterminada su valor es 5. Este es un valor muy importante para la configuración del servidor, define cuantas veces Pandora buscará para ver si hay datos pendientes en la base de datos o en el disco duro (Para buscar ficheros XML). 5/15 es un valor válido para la mayoria de las ocasiones. Si se pone a 1 el consumo de CPU subirá mucho. Se puede usar el valor 1 para ocasiones especiales, como cuando por ejemplo, Pandora ha estado parado durante algun tiempo y hay muchos ficheros XML y tareas de red pendientes procesar. Se puede poner a 1, procesará algo más rápido las tareas pendientes, pero cuando acabe se debería poner entre 5 y 15. porque con valores muy bajos y gran carga, se produce un efecto de "sobrecalentamiento" que hace que aumente progresivamente el consumo de CPU y memoria del servidor.

Este valor junto con los parámetros de _thread de los servidores y el parámetro max_queue_files se usan para configurar el rendimiento del servidor.

network_threads

Número de hilos para el servidor de red. Indica cuántas comprobaciones se pueden hacer en paralelo, pero al aumentar requiere mucha mayor capacidad de procesamiento. Su valor predeterminado es 5. No suba el número de hilos por encima de 25, ya que en la mayoría de sistemas no notará mejoras de rendimiento y su sistema se puede volver inestable.

icmp_checks

Define el número de pings para cada tipo de módulo icmp_proc. Al menos una de esas comprobaciones debe devolver 1 para que se de el módulo como correcto. Su valor predeterminado es 1. Si pone 5 aqui, y el primer ping tiene éxito, el resto no se hacen.

(> 5.1SP2) icmp_packets

Define el número de paquetes que se envían en cada petición de ping. 1 por defecto.

tcp_checks

Número de reintentos TCP si el primero falla. El valor predeterminado es 1.

tcp_timeout

Tiempo de expiración específico para las conexiones TCP. El valor predeterminado es 30.

snmp_checks

Número de reintentos SNMP si el primero falla. El valor predeterminado es 1.

snmp_timeout

Tiempo de expiración específico para las conexiones SNMP. El valor predeterminado es 3.

snmp_proc_deadresponse

Devuelve DOWN si no se puede contactar con un módulo SNMP booleano (proc) o bien si recibe NULL. Si se establece a 0 se ignora.

plugin_threads

Número de hilos para el servidor de complementos. Indica cuántas comprobaciones se pueden hacer en paralelo. Su valor predeterminado es 3.

plugin_timeout

Tiempo de expiración de las comprobaciones con complementos. Después de este tiempo se mostrará el estado del módulo como desconocido. Su valor predeterminado es 5, probablemente le interese subirlo a un valor más alto. Si el plugin tiene un timeout superior, se aplica este valor.

wmi_timeout

Tiempo de expiración de las comprobaciones WMI. Después de este tiempo se mostrará el estado del módulo como desconocido. Su valor predeterminado es 10.

wmi_threads

Número de hilos para el servidor WMI. Indica cuántas comprobaciones se pueden hacer en paralelo. Su valor predeterminado es 2.

prediction_threads

Número de hilos para el servidor de predicción.

recon_threads

Número de hilos para el servidor de reconocimiento de red. Indica cuántas comprobaciones se pueden hacer en paralelo. Su valor predeterminado es 2.

dataserver_threads

Número de hilos para el servidor de datos. Indica cuántos hilos del procesador de ficheros XML hay en paralelo. Su valor predeterminado es 2. El número máximo de hilos recomendado es 4.

inventory_threads

(Sólo Pandora FMS Enterprise)

Número de hilos asignados al servidor de inventario remoto. Indica cuantos hilos simultáneos se asignan a este componente.

export_threads

(sólo Pandora FMS Enterprise)

Número de hilos asignados al servidor de exportación. Indica cuantos hilos simultáneos se asignan a este componente.

web_threads

(sólo Pandora FMS Enterprise)

Número de hilos asignados al servidor de pruebas WEB. Indica cuantos hilos simultáneos se asignan a este componente.

web_engine

(sólo Pandora FMS Enterprise)

Poner a "curl" para utilizar Curl en vez de LWP para la monitorización web. El binario de Curl deberá estar instalado y en el PATH.

mta_address

Dirección IP del servidor de correo electrónico (Mail Transfer Agent).

mta_port

Puerto del servidor de correo electrónico. Por defecto el puerto 25.

mta_user

Usuario para el servidor de correo electrónico (en caso de ser necesario).

mta_pass

Contraseña para el servidor de correo electrónico (en caso de ser necesaria).

mta_auth

Sistema de autenticación del servidor de correo electrónico (en caso de ser necesario; los valores válidos son: LOGIN PLAIN CRAM-MD5 DIGEST-MD)

mta_from

Dirección de correo electrónico desde la que se enviarán los correos. De forma predeterminada es pandora@localhost.

mail_in_separate

Por defecto 1. Si se establece en 1, repartir el correo por separado para cada destino. Si se establece en 0, el correo será compartido entre todos los destinos.

xprobe2

Si se proporciona, se usa para descubrir el sistema operativo de los equipos remotos asignados a los agentes, cuando se lanza una tarea de reconocimiento de red. La ruta predeterminada es /usr/bin/xprobe2. Si no se define, se usa en su lugar NMAP que es mucho menos preciso.

snmpget

Necesario para las comprobaciones SNMP. De forma predeterminada está en /usr/bin/snmpget. Hace referencia a la ubicación del cliente snmp standard del sistema. Se recomienda no tocarlo a no ser que se sepa exactamente lo que se hace.

nmap

Necesario para el recon server. De forma predeterminada está en /usr/bin/nmap. Se recomienda no tocarlo a no ser que se sepa exactamente lo que se hace. Tambien se utiliza para el ICMP server enterprise.

(> 5.1) nmap_timing_template

Un valor que especifica cómo de agresivo debe ser nmap de 1 a 5. 1 significa más lento pero más fiable, 5 significa más rápido pero menos fiable. 2 por defecto.

(> 5.1) recon_timing_template

Como nmap_timing_template, pero aplicado a los escaneos de red del Servidor Satélite y el Servidor Recon.

plugin_exec

Indica la ruta absoluta al programa que ejecuta los plugins de forma controlada en el tiempo. Por defecto /usr/bin/timeout y se recomienda no tocarlo a no ser que se sepa exactamente lo que se hace. Si su sistema base no dispone de este comando, debe utilizar en su lugar /usr/bin/pandora_exec, que si bien no es tan eficiente, es compatible con su sistema ya que viene incluido con Pandora FMS.

autocreate_group

Identificador numérico del grupo predeterminado para los nuevos agentes creados con el servidor de datos, a través de la recepción de ficheros de datos. Su valor predeterminado es 2.

autocreate

Si se establece a 1 se autocrearán agentes cuando se reciban ficheros de datos XML para los que no existan agentes. Si se establece a 0 no se crearán y necesitará crear primero el agente en la consola (ojo, sensible a mayúsculas).

max_log_size

Tamaño máximo del fichero de registro de Pandora FMS, en bytes. Cuando se alcance este tamaño, se moverá el fichero a pandora_server.log.old y se seguirá trabajando sobre el original. El tamaño predeterminado es 65536Bytes.

max_queue_files

Número máximo de ficheros de datos XML leídos por el Servidor de Datos de Pandora FMS del directorio especificado por incomingdir. Esto evita que el Servidor de Datos intente leer demasiados ficheros, lo que afectaría al rendimiento del servidor. El valor por defecto es 5000.

Template warning.png

Puede que los módulos incrementales no funcionen correctamente si este valor no es lo suficientemente grande como para contener todos los ficheros de datos XML.

 


use_xml_timestamp

Por defecto desactivado. Si está activado (valor 1) utiliza el timestamp del fichero XML, generado con la fecha y hora del servidor en el momento de la recepción del mismo, en lugar del timestamp que lleva internamente el fichero XML y que fue generado por el servidor. Esto sirve para desactivar globalmente el uso de las fechas generadas por los agentes y usar la fecha/hora (timestamp) del servidor como referencia para todos los datos. En sistemas con problemas con la sincronizacion, sistemas con fecha/hora incorrecta, es una opción que puede solucionar prácticamente todos los problemas.

auto_restart

Por defecto deshabilitado. Si está activado (valor en segundos), fuerza al servidor a hacer un reinicio interno cada X segundos (1 dia = 86400). Esta opción es útil si observa degradación por ĺa caída no controlada de algún hilo o servidor específico de Pandora FMS.

restart

Por defecto desactivado. Ante un error crítico el servidor reiniciará después de un número de segundos dado.

restart_delay

Por defecto 60. Número de segundos que esperará el servidor antes de reiniciar tras un error crítico si restart está activado.

self_monitoring

El servidor tiene un modo para auto-monitorizarse, que crea un agente virtual en el servidor que monitoriza la mayoría de los parámetros importantes de un servidor de Pandora FMS. Para activarlo, el parámetro self-monitoring debe fijarse en 1.

(>= 5.1SP1) self_monitoring_interval

Intervalo de tiempo para self_monitoring en segundos.

update_parent

El servidor también tiene ahora un parámetro para definir si el agente puede actualizar su padre enviando el nombre del padre en el XML, pero si el parámetro no está definido o es 0, entonces la información del agente será ignorada. Si no es este el caso, cuando el servidor recibe un XML con el atributo parent_name, busca un agente con este nombre, y si lo encuentra, actualiza el padre del agente del XML.

icmp_threads

(sólo Pandora FMS Enterprise)

Número de hilos del servidor ICMP Enteprise (3 por defecto).

snmp_threads

(sólo Pandora FMS Enterprise)

Número de hilos del servidor SNMP Enteprise (3 por defecto).

block_size

(Sólo Pandora FMS Enterprise)

Tamaño del bloque de los servidores productor/consumidor en bloque, es decir, número de módulos por bloque (15 por defecto).

braa

(Sólo Pandora FMS Enterprise)

Ubicación del binario braa, utilizado por el servidor SNMP enterprise (/usr/bin/braa por defecto).

braa_retries

(Sólo Pandora FMS Enterprise)

Número de reintentos antes de que braa le pase el módulo al Servidor de Red en caso de error.

event_window

(Sólo Pandora FMS Enterprise)

Es el tiempo de ventana (en segundos) dentro del cual el servidor de correlacion de eventos mirará por eventos, por ejemplo, si se configura a 3600, el motor comparará y buscará eventos en la última hora.

wmi_client

Cliente WMi empleado por defecto. No deberia cambiar este valor.

activate_gis

Para activar el GIS en el servidor (Información de posicion en agentes), por defecto está desactivado.

location_error

Margen/Radio de error en metros para considerar dos ubicaciones GIS la misma ubicación.

recon_reverse_geolocation_mode

Modo de geolocalización inversa [disabled, sql, file]

  • disabled - El recon task no intenta localizar inversamente la IP.
  • sql - La tarea recon intentará consultar la base de datos para la IP descubierta (hay que cargar los datos previamente en la BBDD).
  • file - La tarea recon intentará descubrir la información de la IP descubierta en el fichero indicado en el parámetro recon_reverse_geolocation_file.

recon_reverse_geolocation_file

Fichero con información sobre la geolocalización inverta. Este fichero debe tener el formato MaxMind GPL GeoLiteCity.dat.

recon_location_scatter_radius

Radio (en metros) para el "circulo" dentro del cual se ubicarán los agentes que se descubran por una tarea de red. El centro del círculo se intentara calcular en base a geolocalizar la IP descubierta.

google_maps_description

Esto activa la conversión de coordenadas GPS en una descripción textual de la dirección (geolocalización inversa). Para ello se utilizará la API de Google Maps. Para poder usar esta funcionalidad se necesita acceso a internet, y puede tener penalizaciones de rendimiento procesando la inforamación GIS debido a la velocidad de conexión contra la API de Google desde el servidor de Pandora FMS. AVISO: La API de Google Maps es un servicio de pago y requiere credenciales, necesitará obtener la API KEY y pagar, sino el servicio se suspende al cabo de un par de días de uso.

openstreetmaps_description

Esto activa la conversión de coordenadas GPS en una descripción textual de la dirección (geolocalización inversa). Para ello se utilizará la API de Open Street Maps. Este servicio no es tan exacto como el de Google Maps, pero es gratuito. Además tiene la ventaja que puede -mediante unas modificaciones del código- modificarse para conectarse a un servidor local.

Si se usa con conexión directa a internet (por defecto), se necesita acceso a internet, y puede tener penalizaciones de rendimiento procesando la inforamación GIS debido a la velocidad de conexión contra la API de OpenStreetMaps desde el servidor de Pandora FMS.

event_file

Esta opción de configuración permite especificar un fichero de texto en el que se escribirán los eventos generados por Pandora FMS en formato CSV.

Por ejemplo:

event_file /var/log/pandora/pandora_events.txt

La primera línea del fichero de texto es una cabecera que contiene una lista con los nombres de los campos. El contenido del fichero pandora_events.txt podría ser:

id_agente,id_grupo,evento,timestamp,estado,utimestamp,event_type,id_agentmodule,id_alert_am,criticity,user_comment,tags,source,id_extra,id_usuario,critical_instructions,warning_instructions,unknown_instructions,ack_utimestamp
Agent_1,Servers,Module Connections opened (136.00) is going to NORMAL,2013-07-01 19:00:57,1,1372698057,going_down_normal,Connections  opened,,2,,,Pandora,,,,,,1372698057
Agent_2,Servers,Alert recovered (Critical condition) assigned to (Network Traffic (Outgoing)),2013-07-01 19:00:59,0,1372698059,alert_recovered,Network Traffic (Outgoing),Critical condition,4,,,Pandora,,,,,,0

snmp_storm_protection

La Consola SNMP de Pandora FMS no procesará más de este número de traps SNMP desde una sola fuente en un intervalo de tiempo definido. Si se alcanza este número se genera un evento.

snmp_storm_timeout

Intervalo de tiempo para snmp_storm_protection en segundos.

Por ejemplo, para evitar que una sola fuente envíe más de 1000 traps cada 10 minutos:

snmp_storm_protection 1000
snmp_storm_timeout 600

text_going_down_normal

Texto para el evento que se genera cuando un módulo se pone en estado normal. Soporta las macros _module_ y _data_.

text_going_down_normal Module '_module_' is going to NORMAL (_data_)

text_going_up_critical

Texto para el evento que se genera cuando un módulo se pone en estado crítico.

text_going_up_warning

Texto para el evento que se genera cuando un módulo se pone en advertencia desde el estado normal.

text_going_down_warning

Texto para el evento que se genera cuando un módulo se pone en advertencia desde el estado crítico.

text_going_unknown

Texto para el evento que se genera cuando un módulo se pone en estado desconocido.

event_expiry_time

Los eventos más viejos que el tiempo dado (en segundos) se validarán de forma automática. Poner a 0 para deshabilitar esta característica.

Por ejemplo, para auto-validar los eventos 10 horas después de que se hayan generado:

event_expiry_time 36000

event_expiry_window

Este parámetro se utiliza para reducir el impacto de event_expiry_time de modo que no haya que comprobar la tabla de eventos al completo. Sólo los eventos más recientes que la ventana de tiempo especificada (en segundos) se auto-validarán. Este valor debe ser mayor que event_expiry_time.

El valor por defecto es un día:

event_expiry_window 86400

(>= 5.X) snmp_forward_trap

Activa (1) o desactiva (0) el reenvío de traps SNMP al host indicado en snmp_forward_ip

(>= 5.X) snmp_forward_ip

Dirección IP del host al que se reenviarán los traps.

Template warning.png

Tener especial cuidado para no introducir una dirección de reenvío al propio servidor de Pandora, pues se originaría un bucle de reenvío y podrá colapsar el servidor de monitorización.

 


(>= 5.X) snmp_forward_version

Versión de SNMP a utilizar en el envío de traps. Este parámetro puede tomar sólo los siguientes valores:

  • 1
  • 2c
  • 3

(>= 5.X) snmp_forward_secName

Exclusivo de SNMP versión 3. Especifica el nombre de seguridad para la autenticación. Más información en el manual de snmpcmd

(>= 5.X) snmp_forward_engineid

Exclusivo de SNMP versión 3. Especifica el ID Engine autorizado. Más información en el manual de snmpcmd

(>= 5.X) snmp_forward_authProtocol

Exclusivo de SNMP versión 3. Especifica el protocolo de autenticación. Este parámetro puede tomar sólo los siguientes valores:

  • MD5
  • SHA

Más información en el manual de snmpcmd

(>= 5.X) snmp_forward_authPassword

Exclusivo de SNMP versión 3. Especifica la contraseña de autenticación. Más información en el manual de snmpcmd

(>= 5.X) snmp_forward_privProtocol

Exclusivo de SNMP versión 3. Especifica el protocolo de privacidad. Este parámetro puede tomar sólo los siguientes valores:

  • DES
  • AES

Más información en el manual de snmpcmd

(>= 5.X) snmp_forward_privPassword

Exclusivo de SNMP versión 3. Especifica la contraseña de privacidad. Más información en el manual de snmpcmd

(>= 5.X) snmp_forward_secLevel

Exclusivo de SNMP versión 3. Especifica el nivel de seguridad. Este parámetro puede tomar sólo los siguientes valores:

  • noAuthNoPriv
  • authNoPriv
  • authPriv

(>= 5.1) claim_back_snmp_modules

Si se configura a 1, los módulos SNMP que se ejecutan en el Servidor de Red serán devueltos al Servidor SNMP Enterprise cuando se ejecute el script de mantenimiento de la base de datos (pandora_db).

(> 5.1) snmpconsole_threads

Número de hilos de la Consola SNMP. Cada hilo procesa un trap SNMP. Configurado a '1' por defecto.

(> 5.1) translate_enterprise_strings

(Sólo Pandora FMS Enterprise)

Si se configura a 1 la consola SNMP intentará traducir los enterprise strings cuando procese traps SNMP. Configurado a '1' por defecto.

(> 5.1) translate_variable_bindings

(Sólo Pandora FMS Enterprise)

Si se configura a 1 la consola SNMP intentará traducir los variable bindings cuando procese traps SNMP. Configurado a '0' por defecto.

(>= 5.1SP1) async_recovery

Si se configura a 1, los módulos asíncronos que no reciban datos durante dos veces su intervalo pasarán a normal. Configurar a 0 para deshabilitarlo.

(>= 6.0) console_api_url

Dirección de la api de la consola. Normalmente la dirección del servidor y la consola terminada con la ruta /include/api.php.

(>= 6.0) console_api_pass

Contraseña de la api de la consola. Esta contraseña se encuentra en la sección general de la configuración de la consola y puede estar vacía.

(>= 6.0) console_user

Usuario de la consola con permisos para realizar las acciones requeridas, como obtener una gráfica de un módulo para incrustar en un email de una alerta.

(>= 6.0) console_pass

Contraseña del usuario introducido anteriormente.

(>= 6.0) unknown_interval

Intervalo de tiempo (como un múltiplo del intervalo de el módulo) antes de que el módulo se ponga en desconocido. Dos veces el intervalo del módulo por defecto.

(>= 6.0) global_alert_timeout

Indica, en segundos, el tiempo máximo que una alerta puede estar procesándose. Pasado ese tiempo, la ejecución se interrumpe. Por defecto tiene un valor de 15 segundos. Para que el servidor de Pandora ignore este timeout y nunca finalice la ejecución de la alerta prematuramente, hay que poner este parámetro a 0.

(>= 6.0) remote_config

Este parámetro controla si es posible configurar el server remotamente desde la consola en la vista de servidores. Funciona por Tentacle de forma similar a la configuración remota de los agentes. Por defecto está desactivado. Este parámetro, al igual que todos los relacionados con la configuración remota, solo funciona correctamente en la versión Enterprise de Pandora FMS.

(>= 6.0) remote_config_address

Dirección IP de la máquina donde se quiere enviar la configuración remota. Por defecto es localhost.

(>= 6.0) remote_config_port

Puerto de Tentacle para la configuración remota. Por defecto se usa el 41121.

(>= 6.0) remote_config_opts

Permite pasar parámetros adicionales al cliente de Tentacle para configuraciones avanzadas. Deben ir entre comillas (por ejemplo, "-v -r 5")

(> 6.0) warmup_event_interval

No se generarán eventos de cambio de estado de módulo ni se ejecutarán alertas de módulos hasta que hayan pasado el número de segundos especificado desde el arranque del servidor (deshabilitado por defecto). Se generarán eventos del sistema cuando el intervalo de warmup empiece y termine, pero los eventos de finalización se retrasarán hasta que se produzca un cambio de estado o se compruebe una alerta.

(> 6.0) warmup_unknown_interval

Los módulos no se pondrán en estado desconocido (de modo que no se generarán eventos de tipo desconocido) y los módulos de keepalive no se pondrán a 0 hasta que hayan pasado el número de segundos especificado desde el arranque del servidor (5 minutos por defecto). Se generarán eventos del sistema cuando el intervalo de warmup empiece y termine.

(> 6.0SP4) enc_dir

Path a un directorio que contiene ficheros .enc adicionales para el parser de XML. Estosficheros serán cargados por el Data Server de forma automática.

Configuración de SNMPTRAPD

La Consola SNMP de Pandora FMS utiliza snmptrapd para recibir los traps SNMP. snmptrapd es una herramienta estándar, presente en casi todos los sistemas UNIX, para recibir los traps y escribir un archivo de registro. Pandora FMS configura snmptrapd para escribir un fichero de registro personalizado y lo lee cada x segundos.

Anteriormente, snmptrapd aceptaba traps por defecto, sin configurar nada de forma explícita. A partir de la version 5.3, la configuración para el control de acceso es mas restrictiva y por defecto no permite recibir traps de cualquiera.

Si snmptrapd se ejecuta sin una configuración personalizada, no se reciben traps y Pandora FMS no puede mostrarlos en la consola, porque el sistema los rechaza.

Lo más probable es que necesite configurar su fichero /etc/snmp/snmptrapd.conf. Si no existe, mire el fichero /var/log/pandora/pandora_snmp.log para ver que errores hay.

Una configuración básica del fichero snmptrapd.conf sería la siguiente

authCommunity log public

Si no funciona en su distribución de Linux, por favor revise la sintaxis de la versión de su sistema snmptrapd para permitir la recepción de los traps en su demonio de snmptrapd con el comando:

man snmptrapd.conf

Configuración de Tentacle

Los agentes software de Pandora FMS por defecto envían los paquetes de datos al servidor mediante el protocolo Tentacle (puerto 41121/tcp asignado por IANA [1]). También se puede reconfigurar el agente para que envíe los datos de maneras alternativas: transferencia local (NFS, SMB), SSH ó FTP, etc. Si se desea que envíen los paquetes de datos a través del protocolo Tentacle, entonces habrá que configurar un servidor de Tentacle donde se vayan a recibir esos datos. Por defecto al instalar Pandora FMS server, se instala un servidor de Tentacle en la misma máquina.

Si es necesario ajustar algunos parámetros de configuración del servidor de Tentacle, se puede hacer modificando directamente el script lanzador del demonio de Tentacle Server que está en:

/etc/init.d/tentacle_serverd

A continuación se enumeran las diferentes opciones de configuración de Tentacle Server:

PANDORA_SERVER_PATH

Ruta al directorio de entrada de los datos. De forma predeterminada es /var/spool/pandora/data_in

TENTACLE_DAEMON

Demonio de tentacle. De forma predeterminada es tentacle_server.

TENTACLE_PATH

Ruta al binario de Tentacle. De forma predeterminada es /usr/bin.

TENTACLE_USER

Usuario con el que se lanzará el demonio de Tentacle. De forma predeterminada es pandora.

TENTACLE_ADDR

Dirección de la que escuchar los paquetes de datos. Si se establece 0.0.0.0 se escucharán en todas. De forma predeterminada se escucha en todas las direcciones, esto es, su valor es 0.0.0.0.

TENTACLE_PORT

Puerto de escucha para la recepción de paquetes. De forma predeterminada es 41121 (Puerto oficial asignado por IANA).

TENTACLE_EXT_OPTS

Opciones adicionales con las que ejecutar el servidor de Tentacle. Aqui puede configurar Tentacle para usar autenticación con password simétrica o certificados.

Configuración segura de Tentacle

Tanto el servidor como los agentes pueden utilizar una comunicación segura con certificados y contraseña a través de Tentacle. Bien comunicación directa agente -> servidor, o bien mediante un tentacle proxy.

Algunas de las opciones contempladas son:

Transferencia simple con autenticación basada en contraseña:

Parámetros extra en el servidor:

 -x password

Parámetros extra en el cliente (TENTACLE_EXT_OPTS)

 -x password

Transferencia segura, sin certificado cliente:

Parámetros extra en el servidor:

 -e cert.pem -k key.pem 

Transferencia segura con certificado de cliente

Parámetros extra en el servidor:

 -e cert.pem -k key.pem -f cacert.pem

Parámetros extra en el cliente (TENTACLE_EXT_OPTS)

 -e cert.pem -k key.pem 

Transferencia segura con certificado de cliente y autenticación adidicional con contraseña:

Parámetros extra en el servidor:

 -x password -e cert.pem -k key.pem -f cacert.pem

Parámetros extra en el cliente (TENTACLE_EXT_OPTS)

 -x password -e cert.pem -k key.pem


Configuración segura, caso práctico

Vamos a explicar paso a paso cómo configurar tanto los agentes como el servidor de Tentacle para una comunicación segura, utilizando también un Tentacle proxy.

En primer lugar, es muy recomendable realizar pruebas a mano desde los terminales para asegurarnos de que la configuración, parámetros y certificados son correctos.

Para pruebas manuales:

1. Levantar tentacle_server manualmente:

 sudo -u user tentacle_server -x password -e tentaclecert.pem -k tentaclekey.pem -f cacert.pem -s /tmp -v

2. Levantar proxy manualmente (sólo si se va a utilizar proxy de tentacle, si no, omitir este paso):

 sudo -u user tentacle_server -b ip_server -g 41124

3. Lanzar tentacle_client manualmente:

 sudo -u user tentacle_client -a ip_proxy/ip_server -x password -e tentaclecert.pem -k tentaclekey.pem -v /bin/ls (o cualquier archivo)


Template warning.png

Es necesario SIEMPRE indicar en los parámetros las rutas absolutas donde se encuentren los certificados, por ejemplo /home/tentaclecert.pem

 


Cuando hayamos comprobado que el envío del archivo ha tenido éxito, podemos proceder a configurar permanentemente el tentacle_server y los clientes.

Para configurar el tentacle_server con las opciones de certificado, hay que editar script de arranque del servicio tentacle_serverd, comúnmente ubicado en /etc/init.d/tentacle_serverd, lo mismo para configurar un punto intermedio para que actúe como proxy. Para configurar los agentes para que utilicen la comunicación segura de tentacle, hay que editar los ficheros de configuración pandora_agent.conf, comúnmente ubicados en /etc/pandora/pandora_agent.conf.

Configuración permanente:

1. Arrancar el server con SSL. Modificar el script de arranque /etc/init.d/tentacle_serverd. Buscar la línea TENTACLE_EXT_OPTS, y añadir "-x password -e tentaclecert.pem -k tentaclekey.pem -f cacert.pem". Quedando así:

 TENTACLE_EXT_OPTS="-i.*\.conf:conf;.*\.md5:md5;.*\.zip:collections -x password -e /home/tentaclecert.pem -k /home/tentaclekey.pem -f /home/cacert.pem"

2. Levantar proxy. Modificar script de arranque /etc/init.d/tentacle_serverd de la máquina que va a actuar como proxy. Del mismo modo que en el anterior punto, buscar la línea TENTACLE_EXT_OPTS, y añadir "-b ip_server -g 41121". Quedando así:

 TENTACLE_EXT_OPTS="-i.*\.conf:conf;.*\.md5:md5;.*\.zip:collections -b 192.168.70.208 -g 41121"

3. Arrancar el agente con las opciones correspondientes. Modificar el archivo pandora_agent.conf, buscar la línea server_opts y añadir "-x password -e /home/tentaclecert.pem -k /home/tentaclekey.pem". No hay que olvidar que el token server_ip hay que configurarlo apuntando a la IP del proxy en lugar de la del servidor principal, en caso de que se vaya a utilizar. Quedaría así:

 server_opts -x password -e /home/tentaclecert.pem -k /home/tentaclekey.pem


Info.png

Si no se quiere utilizar alguna de las opciones, como por ejemplo la contraseña, basta con no utilizar el parámetro correspondiente.

 


Consola WEB

La consola web de Pandora FMS tiene un fichero de configuración que generalmente se crea y configura durante la instalación. Si la instalación se hace desde los paquetes DEB o RPM, o desde el CD de instalación de Pandora FMS, ésta se configura de forma automática. Si se instala de forma manual, con el paquete tarball. Se puede configurar desde el asistente web mediante la dirección http://ip_instalacion_consola/pandora_console/install.php

El fichero de configuración config.php está en el directorio /include/ dentro del directorio de instalación de la consola, que puede ser /var/www/pandora_console (Debian, Ubuntu) o /srv/www/htdocs/pandora_console/ (SUSE, RH, Fedora...) o incluso otro, dependiendo de la distribución.

Fichero de configuración config.php

Las opciones de configuración en el archivo están en la cabecera del mismo, y son las siguientes:

$config["dbname"]

Nombre de la base de datos a la que conectarse. De forma predeterminada es Pandora.

$config["dbuser"]

Nombre de usuario para la conexión contra la base de datos de Pandora FMS. De forma predeterminada es pandora.

$config["dbpass"]

Contraseña para la conexión contra la base de datos de Pandora FMS.

$config["dbhost"]

Dirección IP o nombre del equipo que alberga la base de datos de Pandora FMS. En instalaciones reducidas suele ser el mismo *equipo donde está el servidor, esto es localhost.

$config["homedir"]

Directorio donde está instalada la consola web de Pandora FMS. Suele ser /var/www/pandora_console o /srv/www/htdocs/pandora_console.

$config["homeurl"]

Directorio base para Pandora FMS. Suele ser /pandora_console.

$config["public_url"]

Este variable tiene el valor de la url del servidor interno para cuando usa un proxy inverso como por ejemplo mod_proxy de Apache.

Redirección hacia /pandora_console desde /

Si sólo tiene instalado un Pandora FMS en su servidor Apache, puede que le interese redirigir automáticamente a /pandora_console cuando los usuarios se conecten con la URL / de su servidor. Para ello puede crear el siguiente fichero index.html y ponerlo en el directorio raíz del servidor web (/var/www ó /srv/www/htdocs):

 <html>
 <head>
 <meta HTTP-EQUIV="REFRESH" content="0; url=pandora_console/index.php">
 </head>
 </html>

Agentes software de Pandora FMS

Qué es un agente

Los agentes software de Pandora FMS recogen todos los datos de los sistemas. Se ejecutan en cada sistema local, aunque también pueden recoger información remota mediante la instalación de sistemas de monitorización para el agente en varias máquinas diferentes.

Están desarrollados para trabajar con una plataforma fija, haciendo uso de las herramientas específicas del lenguaje que se emplea: VBSCript/Windows scripting para plataformas Microsoft (Windows 2000, Windows XP, Windows 2003 y Windows Vista), ShellScripting para UNIX —incluye GNU/Linux, Solaris, AIX, HP-UX y BSD, así como el IPSO de Nokia. Los agentes de Pandora FMS se pueden desarrollar en cualquier lenguaje, siempre que sea un sistema con una API sencilla y que sea de código abierto. Existen modalidades del proyecto de Pandora FMS que han sido iniciadas para la creación de agentes en Posix C, Perl y Java para aquellos sistemas que requieren agentes cerrados.

Los agentes de Pandora FMS son 100% código abierto, por ejemplo en el modo en que los agentes recogen y envían información está documentado y puede analizar y/o modificar el código para que se adecue a sus necesidades. Un agente podrá volverse a crear en cualquier lenguaje de programación, y puede ser actualizado fácilmente, para mejorar aspectos del programa que no habían sido cubiertos completamente.

Este documento describe la instalación de agentes en máquinas que funcionan con los sistemas operativos Windows y UNIX.

Rol genérico de los Agentes Software

El rol genérico de los agentes software se basa en obtener información del sistema operativo en el que están instalados, recopilar esta información y luego enviársela al servidor.

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 se llama «Módulo». Si el agente se ha añadido en modo «aprendizaje», los módulos enviados que no estén definidos previamente en el agente lógico, serán creados por el servidor automáticamente.

Introducción a la configuración del agente

El agente se controla mediante un único fichero de configuración que tiene una sintaxis prácticamente igual en sistemas UNIX y sistemas Windows, este fichero se llama pandora_agent.conf y se encuentra en el directorio de instalación del agente (en sistemas Windows) y en /etc/pandora/pandora_agent.conf en sistemas Unix.

Este fichero de configuración es un fichero de texto plano con diferentes opciones que puede ser modificado por el administrador, para modificar el comportamiento del mismo, configurar a donde va a enviar los datos y qué cosas va a monitorizar y de qué manera.

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

 


A continuación se describen los parámetros generales del Agente Software y los módulos de monitorización que son los que definen como y qué se monitoriza localmente con el Agente Software.

Parámetros generales del agente

Los parámetros generales del agente de configuración aparecen definidos en esta sección. Algunos de estos son comunes para todos los sistemas y otros son específicos para Windows o para Unix. Los parámetros generales son:


Template warning.png

La primera vez que se reciben datos del agente se guarda toda la información en la base de datos. Para sucesivos envíos de información (y dependiendo si está habilitado el modo aprendizaje) sólo se actualizarán los siguientes campos del XML: version, fecha y versión de SO, así como los siguientes parámetros del archivo de configuración gis_exec, latitude, longitude, altitude, parent_agent_name, timezone_offset, address, custom_field

 


server_ip

Es la dirección IP o el nombre del anfitrión del servidor de Pandora FMS, donde se almacenarán los datos. El servidor deberá estar preparado para recoger los datos bien por SSH (escuchando en el puerto 22), por Tentacle (puerto 41121), FTP (puerto 21), SMB o NFS.

server_path

La ruta del servidor es la ruta completa del fichero donde el servidor almacena los datos enviados por el agente. Habitualmente es: /var/spool/pandora/data_in.

temporal

Este es la ruta completa de la carpeta donde el agente almacena los datos localmente antes de enviarlos al servidor.

Nótese que los paquetes de datos, por defecto, se borran una vez que el agente intenta contactar con el servidor de Pandora FMS, sin importar si la comunicación se produjo con éxito o no (aunque este comportamiento se puede cambiar, como veremos más adelante).

Esto se hace para evitar un sobrecarga en el disco duro del sistema anfitrión donde corre el agente. La ubicación del fichero local varía según la arquitectura del sistema anfitrión. En los sistemas UNIX está generalmente en /var/spool/pandora/data_out, y en los sistemas Windows C:\program files\pandora_agent\temp. El instalador de Windows por defecto creará este directorio, dependiendo de donde decida instalar Pandora FMS.

description

Envia la descripción del agente en el XML, y Pandora FMS importa esta descripción cuando crea el agente.

group

Envía el nombre del grupo al que queremos que pertenezca el agente, solo empleado en el momento de creación del agente. Pandora FMS server automáticamente utilizará ese grupo para colocar el agente en el grupo especificado.

temporal_min_size

Si el espacio libre (en mega bytes) de la partición en la que se encuentra el directorio temporal es menor que este valor, no se siguen generando paquetes de datos. De este modo se evita que se llene el disco si por alguna razón se pierde la conexión con el servidor durante un intervalo de tiempo prolongado.

logfile

La ruta al fichero del registro de sucesos del agente de Pandora FMS. El fichero se puede emplear para comprobar el sistema y para investigar otras posibles cuestiones.

interval

Este es el intervalo de tiempo, en segundos, en el que el agente recolectará datos del sistema anfitrión y enviará los paquetes de datos al servidor. Los rangos de valores recomendados son, desde 300 (5 minutos) a 600 (10 minutos). Este número puede ser más grande, aunque es importante considerar el impacto de un número mayor en la base de datos. Por debajo de 30-60 segundos no está recomendado su ejecución.

disable_logfile

Inhabilita la escritura logs en pandora_agent.log. Solo para Windows.

debug

Este parámetro se emplea para comprobar la generación de los datos de los ficheros de modo que se puedan comprobar los contenidos de datos de los ficheros. No se destruye ningún dato cuando se finaliza el proceso, así pues, los datos de los ficheros estarán en el directorio temporal. La actividad está registrada en el fichero del registro. El fichero de registro es pandora_agent.log (ver logfile más arriba).

Antes de la versión 6.0, un agente en modo debug no reportaba datos al servidor.

agent_name

Este es un nombre alternativo del anfitrión. Este parámetro es opcional ya que no ha sido declarado sino obtenido directamente del sistema. El parámetro se puede usar para sobreescribir el nombre del anfitrión por otro cualquier en caso de que haya algún conflicto. Si tiene dos agentes con el mismo nombre, todos sus datos se volcarán en el mismo agente de la consola de Pandora, lo cual puede producir resultados impredecibles y confusos.

(>=5.1SP2) agent_name_cmd

Define el nombre del agente utilizando un comando externo. Si agent_name_cmd está definido agent_name se ignora. El comando deberá devolver el nombre del agente por STDOUT. Si devuelve varias más de una linea sólo se utilizará la primera.

address

Este es la dirección IP asociada al agente software. Puede ser una IP con el formato X.X.X.X, un nombre de dominio como 'localhost' o 'auto'. Si es una IP o nombre de dominio, este se añadirá a la colección de direcciones del agente y se establecerá como principal. Si es 'auto', se obtendrá la dirección IP de la máquina y se añadirá al agente del mismo modo que en el caso anterior.

encoding

Instala el tipo de codificación del sistema local, como por ejemplo iso-8859-15, o utf-8. Ésta opción está disponible para los agentes de UNIX y para los de Windows desde Pandora FMS 2.0.

server_port

Este parámetro permite identificar el puerto remoto del servidor que está a la espera. De forma predeterminada es 41121 para Tentacle. En caso de que no se use Tentacle o que el servidor esté instalado en otro puerto, es aquí donde se debe cambiar.

transfer_mode

Este parámetro especifica el modo de transferencia que instalar para enviar los datos del agente al servidor. Los modos disponibles son: SSH (usando SCP), Tentacle, FTP o local. El modo local es sólo para sistemas donde el agente se ejecuta en la misma máquina que el servidor, porque es básicamente una copia entre directorios. El modo local está disponible únicamente para agentes GNU/Linux.

(>= 6.0) transfer_timeout

Este parámetro especifica el tiempo de espera en segundos para la ejecución de la transferencia de archivos. el valor por defecto es 30 segundos si no está definido.

server_pwd

Específica para la contraseña del FTP de Windows y para el modo de transferencia Tentacle, aunque la contraseña en este último es opcional. Contraseña del servidor para la autenticación con contraseña.

server_ssl

Específica para el modo de transferencia Tentacle. Permite habilitar (1) o deshabilitar (0) el cifrado de las conexiones mediante SSL.

server_opts

Es una opción específica para el modo de transferencia Tentacle. Permite pasar parámetros adicionales al cliente de Tentacle para configuraciones avanzadas. Por ejemplo: server_opts -v -r 5

Desde la version 3.2 de los agentes, el cliente de tentacle soporta una opcion para poder usar un proxy HTTP para enviar los datos al servidor. Este proxy HTTP debe tener habilitado el método CONNECT. Para poder usar la salida a través de un proxy, usamos la siguiente opcion (ejemplo):

server_opts -y user:pass@proxy.inet:8080

Esta opcion fuerza al cliente de tentacle a enviar los datos a través de un proxy situado en proxy.inet y que usa el puerto 8080, usando el usuerio "user" y el password "pass" para autenticarse en dicho proxy. Si por ejemplo, es preciso usar un proxy sin autenticacion, en un servidor en 192.168.1.2 y con el puerto 9000, la opción sería asi:

server_opts -y 192.168.1.2:9000

delayed_startup

Este parámetro permite configurar el agente de Pandora FMS para que comience a funcionar después de cierto tiempo (en minutos) después de ejecutarlo manualmente. Puede ser útil para sistemas con muchos lotes de carga. De forma predeterminada está deshabilitado, esto es, el agente de Pandora FMS comenzará a funcionar desde que se ejecutes manualmente. Esta opción sólo es válida para agentes UNIX.

pandora_nice

Este parámetro permite especificar la prioridad que el proceso del agente de Pandora FMS tendrá en el sistema. Sólo está disponible para agentes Unix/Linux.

autotime

Si está habilitado (1) envia un timestamp de ejecución especial (AUTO) que hace que el servidor utilice la fecha / hora local del servidor para establecer la hora de los datos, ignorando la hora enviada por el agente. Esto es necesario en aquellos agentes que por la razón que sea, tienen una hora incorrecta o muy diferente de la del servidor.

cron_mode

Con este parámetro es posible hacer que el agente use el propio crontab de Linux para ejecutarse en un intervalo determinado en vez de usar el propio sistema interno del agente para ejecutarse cada cierto tiempo. Está desactivado por defecto y no se recomienda su uso a menos que sea estrictamente necesario.

remote_config

Este parámetro controla si es posible configurar el agente remotamente desde la consola o no. 1: Se activa la configuración remota, 0: No se permite la configuración remota. Por defecto está desactivado. Este parámetro aunque se puede activar en los agentes, sólo funciona correctamente en la versión Enterprise de Pandora FMS y utilizando Tentacle como modo de tranferencia.

xml_buffer

Por defecto 0. Estando a 1 el agente guardará los XML de datos que no haya podido enviar para intentarlo de nuevo más adelante.

En Unix, si está en un entorno seguro debería considerar cambiar el directorio temporal, ya que /tmp tiene permisos de escritura para todos los usuarios.

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 
interval        300 
debug           0 
agent_name      box01 
server_port     41121 
transfer_mode   tentacle 
remote_config   1 

timezone_offset

Ahora el agente puede instalar su timezone offset con el servidor. Esto le permite al servidor hacer un desplazamiento de la hora recogida por el agente, de forma que "concuerde" con la hora local del servidor.

# Timezone offset: Difference with the server timezone
timezone_offset 3

Se calcula restándole la zona horaria del agente a la zona horaria del servidor. Por ejemplo, si el servidor está en la zona horaria UTC+1 y el agente está en la zona horaria UTC-6, timezone_offset debería ser 6 = 1 - (-5).

parent_agent_name

También ahora es posible (si el servidor lo permite) actualizar el padre de un agente enviando en XML el nombre del agente padre.

#Parent agent_name
parent_agent_name parent_name

agent_threads

Número de hilos que lanzará el agente para ejecutar módulos en paralelo. Por defecto los módulos se ejecutan uno tras otro sin lanzar ningún hilo adicional. Sólo está disponible para agentes Unix/Linux.

# Number of threads to execute modules in parallel
agent_threads 4

include <fichero>

Permite incluir un fichero de configuración adicional. Este archivo puede incluir módulos y colecciones adicionales a las del archivo princiapl. Este parámetro opcional. En relación al agente Perl, decir que permite comodines en el nombre de archivos.

broker_agent <nombre>

Este token es opcional. Gestiona configuraciones y recolección de datos desde un agente como si fueran varios. Un nuevo fichero de configuración será creado por cada agente broker añadido en el fichero de configuración principal con el nombre que le hayamos asignado. Este token será tenido en cuenta en el agente broker y no en los nuevos agentes creados por este. Ver más abajo como funciona el modo broker.

pandora_user <usuario>

Este parámetro es opcional y permitirá ejecutar el agente con el usuario del sistema que se especifíque. Este usuario deberá contar con los permisos para poder ejecutar el agente y sus recursos asociados.

Como se puede comprobar, la mayoría de parámetros de un agente windows y de un agente unix son idénticos.

(>= 5.X) custom_id

Id personalizado del agente para aplicaciones externas.

(>= 5.X) url_address

URL personalizada para abrirla desde el agente en la consola.

(>= 5.X) custom_fieldX_name

Nombre de un campo personalizado de agentes que ya exista en el sistema. Si no existe, se ignorará.

Ejemplo:

custom_field1_name Model

(>= 5.X) custom_fieldX_value

Valor para el custom field X definido en el parámetro anterior.

Ejemplo:

custom_field1_value C1700

(> 5.1 Unix agent only) macro<macro> <value>

Define una macro de ejecución local que se puede utilizar en la definicion de un módulo. Estas macros se utilizan en el sistema de la metaconsola y en el sistema de componentes de modulos locales para "abstraer" la dificultad de usar un modulo editando directamente el codigo, presentando a un usuario menos avanzado, una interfaz local que permita "rellenar" valores. Estos valores se emplean por debajo, usando un sistema de macros, relativamente similar al sistema de macros de los plugins locales.

Las macros de ejecucion locales comienzan por _fieldx_

Example:

module_begin
module_name Particion_opt
module_type generic_data
module_exec df -kh _field1_ | tail -1 |  awk '{ print $5}' | tr -d "%"
module_macro_field1_ /opt
module_end

(>= 6.0SP5) group_password <contraseña>

Contraseña para el grupo del agente. Dejar comentado si el grupo no está protegido por contraseña.

(>= 7.0) ehorus_conf <path>

Ruta absoluta a un fichero de configuración válido de un agente de eHorus. El agente creará un campo personalizado llamado eHorusID que contiene la clave de identificación del agente de eHorus.

Servidor Secundario

Un tipo especial de parámetro de configuración general es la definición de un servidor secundario. Esto permite definir un servidor al que se le envían los datos, de forma complementaria al servidor definido de forma estándar. El modo de servidor secundario funciona de dos formas:

  • on_error: Envía datos al servidor secundario solo si no puede enviarlas al primario.
  • always: Siempre envía datos al servidor secundario, independientemente si puede contactar o no con el servidor principal.

Ejemplo de configuración:

secondary_server_ip     192.168.1.123
secondary_server_path   /var/spool/pandora/data_in
secondary_mode          on_error
secondary_transfer_mode tentacle
secondary_server_port   41121

Servidor UDP

El agente de Pandora, permite configurar el propio agente para la escucha de comandos remotos. Este servidor escucha en un puerto UDP especificado por el usuario, y permite recibir órdenes desde un sistema remoto, idealmente, desde la consola de Pandora FMS, mediante la ejecución de alertas en el servidor.

Para configurar el servidor remoto UDP, existen las siguientes opciones en pandora_agent.conf

  • udp_server: Para activar el servidor UDP ponerlo a 1. Por defecto está desactivado.
  • udp_server_port: Puerto en el que escucha.
  • udp_server_auth_address: Direcciones IP autorizadas para enviar órdenes. Para especificar varias direcciones, hay que separarlas por comas. Si se configura con 0.0.0.0, acepta órdenes de cualquier dirección. No obstante, por seguridad, restrinja el acceso a este agente a IPs seguras.
  • process_<name>_start <command>: Comando que arrancará un proceso definido por el usuario.
  • process_<name>_stop <command>: Comando que parará el proceso.
  • service_<name> 1: Permite que el servicio <name> sea parado o arrancado remotamente desde el servidor UDP.

Ejemplo de configuración:

udp_server 1
udp_server_port 4321
udp_server_auth_address 192.168.1.23
process_firefox_start firefox
process_firefox_stop killall firefox 
service_messenger 1 

El servidor acepta los siguientes comandos:

* <START|STOP> SERVICE <nombre del servicio>: Inicia o para un servicio.
* <START|STOP> PROCESS <nombre del proceso>: Crea o mata un proceso.
* REFRESH AGENT <nombre del agente>: Fuerza una ejecución del agente, refrescando los datos.

En la version 5.0, el agente de Unix solo soporta el comando REFRESH AGENT.

Por ejemplo:

STOP SERVICE messenger
START PROCESS firefox
REFRESH AGENT 007

Existe un script en el servidor, en /util/udp_client.pl que es el usado por Pandora FMS Server como comando de una alerta, para arrancar procesos, o servicios. Tiene esta sintaxis:

./udp_client.pl <address> <port> <command>


Por ejemplo, para reiniciar un agente:

./udp_client.pl 192.168.50.30 41122 "REFRESH AGENT"

Para más información, vea el capítulo de configuración de alertas.

Definición de los módulos

Cada fragmento de información que se recopile debe definirse con precisión en cada módulo, empleando la sintaxis exacta. Se pueden implementar tantos valores como sea preciso para ser recogidos, añadiendo, al final de los parámetros generales, tantos módulos como el número de valores para compilar. Cada módulo está compuesto de varias directivas. La lista de abajo es una lista descriptiva de todas las señales de módulos disponibles para agentes UNIX (casi todas ellas también se pueden aplicar al agente Windows).

La sintaxis general es la siguiente:

module_begin
module_name NombreDelMódulo
module_type generic_data
.
.
.
module_description Ejecución del comando
module_interval Número
module_end 

Existen diferentes tipos de módulos, con diferentes subopciones, pero todos los módulos tienen una estructura similar a esta. Los parámetros module_interval y module_description son opcionales, y el resto completamente obligatorios. Vamos a ver primero los elementos comunes de todos los módulos:

Elementos comunes de todos los módulos

Template warning.png

Los campos del módulo (salvo el dato del módulo, la descripción y la información extendida) sólo se actualizan en la creación del módulo, nunca se actualizarán una vez que el módulo está creado. Este comportamiento se mantiene aunque el modo aprendizaje del agente este activado

 


module_begin

Define el inicio del módulo. Obligatorio.

module_name <nombre>

Nombre del módulo. Este es el ID del módulo, elija un nombre sin espacios en blanco y no demasiado largo. No hay limitación específica (máx. 250 caracteres), pero será más sencillo de manejar un nombre corto. Este nombre NO PUEDE estar duplicado con un nombre similar en el mismo agente. Este nombre podrá estar duplicado con otros módulos en otros agentes. Como casi todo en Pandora FMS es sensible a la diferencia entre mayúsculas y minúsculas.

Es obligatorio.

module_type <tipo>

El tipo de datos que manejará el módulo. Hay varios tipos de datos para los agentes:

  • Numérico (generic_data). Datos numéricos sencillos, en coma flotante o enteros. Si los valores son de tipo flotante, estos serán truncados a su valor entero.
  • Incremental (generic_data_inc). Dato numérico igual a la diferencia entre el valor actual y el valor anterior divida por el número de segundos transcurridos. Cuando esta diferencia es negativa, se reinicia el valor, esto significa que cuando la diferencia vuelva a ser positiva de nuevo se tomará el valor anterior siempre que el incremento vuelva a dar un valor positivo.
  • Absolute incremental (generic_data_inc_abs). Dato numérico igual a la diferencia entre el valor actual y el valor anterior, sin realizar la división entre el número de segundos transcurridos, para medir incremento total en lugar de incremento por segundo. Cuando esta diferencia es negativa, se reinicia el valor, esto significa que cuando la diferencia de nuevo vuelva a ser positiva, se empleará el último valor desde el que el actual incremento obtenido da positivo.
  • Alfanumérico (generic_data_string). Recoge cadenas de texto alfanuméricas.
  • Monitores (generic_proc). Útil para medir el estado de un proceso o servicio. Este tipo de datos se llama monitor porque asigna 0 a un estado «Erróneo» y cualquier valor por encima de 1 a cualquier estado «Correcto».
  • Alfanumérico asíncrono (async_string). Recoge cadenas de texto alfanuméricas que pueden llegar en cualquier momento, sin una periodidicad fija. El resto de parámetros (generic*) tienen un funcionamiento síncrono, es decir, esperan la llegada de datos cada XX tiempo, y si no llegan se dice que están en estado desconocido (unknown). Los módulos de tipo asíncrono no pueden estar en ese estado.
  • Monitor asíncrono (async_proc). Similar a generic_proc pero asíncrono.
  • Numérico asíncrono (async_data). Similar a generic_data pero asíncrono.

Es ogligatorio.

module_min <valor>

Este el valor mínimo válido para los datos generados en este módulo. Si el módulo no ha sido definido todavía en la consola web, este valor se podrá tomar desde este directorio. Esta directiva no es obligatoria. Este valor no elimina el valor definido en el agente. Si el módulo no existe en la consola de mandos, será creada automáticamente cuando se emplea el modo de aprendizaje.

module_max <valor>

Este es el valor máximo válido para los datos generados en este módulo. Si el módulo no ha sido definido en la consola web, este valor se podrá tomar desde este directorio. Esta directiva no es obligatoria y no está respaldada por el agente Windows. Este valor no elimina el valor definido en el agente. Si el módulo no existe en la consola de mandos, será creada automáticamente cuando se emplea el modo de aprendizaje.

module_min_warning <valor>

Este es el valor mínimo para que el módulo pase a estado de advertencia. Esta directiva no es obligatoria. Si el módulo no existe en la consola de mandos, será creado automáticamente cuando se emplea el modo de aprendizaje.

module_max_warning <valor>

Este es el valor máximo para que el módulo esté en estado de advertencia. Esta directiva no es obligatoria. Utiliza un operador <= (menor o igual).

module_min_critical <valor>

Este es el valor mínimo para que el módulo pase a estado crítico. Esta directiva no es obligatoria. Utiliza un operador > (mayor que) para la comparación.

module_max_critical <valor>

Este es el valor máximo para que el módulo esté en estado crítico. Esta directiva no es obligatoria. Si el módulo no existe en la consola de mandos, será creado automáticamente cuando se emplea el modo de aprendizaje.

module_disabled <valor>

Indica si el módulo esta habilitado (0) o deshabilitado (1). Esta directiva no es obligatoria. Si el módulo no existe en la consola de mandos, será creado automáticamente cuando se emplea el modo de aprendizaje.

module_min_ff_event <valor>

Este es el intervalo en el que se filtrarán nuevos cambios de estado en el módulo evitando fluctuaciones excesivas en los estados del módulo. Esta directiva no es obligatoria. Si el módulo no existe en la consola de mandos, será creado automáticamente cuando se emplea el modo de aprendizaje.

(>= 6.0 SP4) module_each_ff <value>

Si está habilitado (1), se utilizarán los flip flop thresholds por estado en vez de module_min_ff_event (module_min_ff_event_normal, module_min_ff_event_warning y module_min_ff_event_critical). Poner a 0 para deshabilitar.

(>= 6.0 SP4) module_min_ff_event_normal <value>

Flip flop thresholds por estado. Ver module_min_ff_event y module_each_ff.

(>= 6.0 SP4) module_min_ff_event_warning <value>

Flip flop thresholds por estado. Ver module_min_ff_event y module_each_ff.

(>= 6.0 SP4) module_min_ff_event_critical <value>

Flip flop thresholds por estado. Ver module_min_ff_event y module_each_ff.

(>= 6.0 SP4) module_ff_timeout <seconds>

Reinicia el contador de flip flop threshold después del número de segundos dado. Esto implica que module_min_ff_event cambios de estado deberán producirse en un intervalo de module_ff_timeout segundos antes de que el estado cambie.

module_description <texto>

Esta directiva se emplea para añadir un comentario al módulo. Esta directiva no es obligatoria. Este valor no sobreescribe el valor definido por el agente. Si el módulo no existe en la consola de mandos, será creado automáticamente cuando se emplea el modo de aprendizaje.

module_interval <factor>

Desde que Pandora 1.2 introdujo este nuevo tipo, se puede, para cada módulo, fijar su propio intervalo. Este intervalo se calcula como un factor multiplicador para el intervalo del agente. Por ejemplo, si el agente tiene intervalo 300 (5 minutos), y se quiere un módulo que sea procesado sólo cada 15 minutos, se debe añadir esta línea: module_interval 3. Así, este módulo será procesado cada 300sec x 3 = 900sec (15 minutos).


module_timeout <secs>

En la version 3.1, Pandora FMS soporta especificar en cada módulo, de forma independiente, cuantos segundos esperará a la ejecución del módulo, de forma que si tarda más de XX segundos, aborta la ejecución del módulo (para evitar quedarse "muerto" en la ejecución de un módulo).

module_postprocess <factor>

Igual que en la definición de postproceso de un módulo que se realiza desde la consola, aquí se puede definir un valor numérico de coma flotante que pasará este valor a su vez a Pandora FMS para que lo emplee el servidor para multiplicar el valor recibido (en crudo) por al agente. Si quiere multiplicar por 1024 el valor que devuelve el agente, ponga aquí "1024" si lo quiere es dividirlo por 1024, ponga aquí 1/1024, es decir 0,000976563.

module_save <nombre de variable>

Desde la versión 3.2 es posible guardar el valor devuelto por un módulo en una variable de entorno de modo que pueda ser utilizado más adelante en otros módulos. Es importante tener en cuenta que los valores se actualizan según se ejecutan los módulos, es decir, en el orden en que están definidos.

Por ejemplo:

module_begin
module_name echo_1
module_type generic_data
module_exec echo 41121
module_save ECHO_1
module_end
module_begin
module_name echo_2
module_type generic_data
module_exec echo $ECHO_1
module_end
module_crontab <minuto> <hora> <día> <mes> <día de la semana>

Desde la versión 3.2 se pueden programar los módulos para que se ejecuten en determinadas fechas.

Para ello hay que definir el module_crontab utilizando un formato similar al del fichero crontab: (http://es.wikipedia.org/wiki/Cron_(Unix)#Sintaxis)

module_crontab <minuto> <hora> <día> <mes> <día de la semana>

Siendo:

  • Minuto 0-59
  • Hora 0-23
  • Día del mes 1-31
  • Mes 1-12
  • Día de la semana 0-6 (0 es Domingo)

También es posible especificar intervalos utilizando el carácter - como separador.

Por ejemplo, para que un módulo se ejecute todos los Lunes entre las 12 y las 15 podríamos utilizar la siguiente configuración:

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

El módulo sólo se ejecutará una vez durante el intervalo. 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_test2
module_type generic_data
module_exec script.sh
module_crontab * 12-15 * * 1
module_cron_interval 0
module_end

Para ejecutar un comando cada hora, a la hora y 10 minutos:

module_begin
module_name crontab_test3
module_type generic_data
module_exec script.sh
module_crontab 10 * * * *
module_cron_interval 0
module_end
module_condition <operación> <comando>

Desde la versión 3.2 es posible definir comandos que se ejecutarán cuando el módulo devuelva determinados valores. Es necesario especificar una de las siguientes operaciones:

  • > [valor]: Ejecuta el comando cuando el valor del módulo es mayor que el valor dado.
  • < [valor]: Ejecuta el comando cuando el valor del módulo es menor que el valor dado.
  • = [valor]: Ejecuta el comando cuando el valor del módulo es igual al valor dado.
  • != [valor]: Ejecuta el comando cuando el valor del módulo es distinto al valor dado.
  • =~ [expresión regular]: Ejecuta el comando cuando el valor del módulo concuerda con la expresión regular dada.
  • (valor, valor): Ejecuta el comando cuando el valor del módulo está comprendido entre los valores dados.

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

module_begin
module_name condition_test
module_type generic_data
module_exec echo 2.5
module_condition (1, 3) script_1.sh
module_condition > 5.5 script_2.sh
module_end

Ejemplos:

module_begin
module_name MyProcess
module_type generic_data
module_exec tasklist | grep MyProcess | wc -l
module_condition > 2 taskkill /IM MyProcess* /F
module_end
module_begin
module_name PandoraLogSize
module_type generic_data
module_exec ls -la "c:\Archivos de programa\pandora_agent\pandora_agent.log" | gawk "{ print $5 }"
module_condition > 10000 del "c:\Archivos de programa\pandora_agent\pandora_agent.log"
module_end
module_begin
module_name Service_Spooler
module_type generic_proc
module_service Spooler
module_condition = 0 net start Spooler
module_end


  • NOTA: En el sistema operativo Windows es recomendable anteponer cmd.exe /c al comando para asegurar que se ejecuta de forma adecuada. Por ejemplo:
module_begin
module_name condition_test
module_type generic_data
module_exec echo 5
module_condition (2, 8) cmd.exe /c script.bat
module_end
module_precondition <operación> <comando>

Se ejecutará el módulo si se cumple la precondición. Al igual que las condiciones, es necesario especificar una de las siguientes operaciones:

  • > [valor]: Ejecuta el comando cuando el valor del módulo es mayor que el valor dado.
  • < [valor]: Ejecuta el comando cuando el valor del módulo es menor que el valor dado.
  • = [valor]: Ejecuta el comando cuando el valor del módulo es igual al valor dado.
  • != [valor]: Ejecuta el comando cuando el valor del módulo es distinto al valor dado.
  • =~ [expresión regular]: Ejecuta el comando cuando el valor del módulo concuerda con la expresión regular dada.
  • (valor, valor): Ejecuta el comando cuando el valor del módulo está comprendido entre los valores dados.

Un ejemplo de módulo con precondiciones sería el siguiente:

module_begin
module_name Precondition_test1
module_type generic_data
module_precondition (2, 8) echo 5
module_exec monitoring_variable.bat
module_end

Al igual que con las postcondiciones es posibles poner varias, sólo se ejecutará si se cumplen todas:

module_begin
module_name Precondition_test2
module_type generic_data
module_precondition (2, 8) echo 5
module_precondition < 3 echo 5
module_exec monitoring_variable.bat
module_end
  • NOTA: En el sistema operativo Windows es recomendable anteponer cmd.exe /c al comando para asegurar que se ejecuta de forma adecuada. Por ejemplo:
module_begin
module_name Precondition_test3
module_type generic_data
module_precondition (2, 8) cmd.exe /c script.bat
module_exec monitoring_variable.bat
module_end
(>= 5.x) module_unit <value>

Esta directiva es la unidad del valor devuelto por el módulo.

Ejemplo:

module_unit %

(>= 5.x) module_group <value>

Esta directiva es el nombre del grupo del módulo. Si el grupo no existe el módulo se creará sin grupo asignado.

Ejemplo:

module_group Networking

(>= 5.x) module_custom_id <value>

Esta directiva es un identificador personalizado del módulo.

Ejemplo:

module_custom_id host101

(>= 5.x) module_str_warning <value>

Esta directiva es una expresión regular para definir el estado Warning en los módulos de tipo string.

Ejemplo:

module_str_warning .*NOTICE.*

(>= 5.x) module_str_critical <value>

Esta directiva es una expresión regular para definir el estado Critical en los módulos de tipo string.

Ejemplo:

module_str_critical .*CRITICAL.*

(>= 5.x) module_warning_instructions <value>

Esta directiva son instrucciones para el operador cuando el módulo pase a estado Warning.

Ejemplo:

module_warning_instructions Subir prioridad incidencia

(>= 5.x) module_critical_instructions <value>

Esta directiva son instrucciones para el operador cuando el módulo pase a estado Critical.

Ejemplo:

module_critical_instructions Llamar a departamento de sistemas

(>= 5.x) module_unknown_instructions <value>

Esta directiva son instrucciones para el operador cuando el módulo pase a estado Unknown.

Ejemplo:

module_unknown_instructions Abrir incidencia

(>= 5.x) module_tags <value>

Esta directiva son las tags que se desean asignar al módulo separadas por comas. Solo se asignarán si existen en el sistema.

Ejemplo:

module_tags tag1,tag2,tag3

(>= 5.x) module_warning_inverse <value>

Esta directiva es un flag (0/1) que cuando está activado indica que el umbral de Warning es el inverso al definido.

Ademas si usas intervalos negativos, como por ejemplo activar el estado de warning cuando sea inferior a -50, seria setear min_warning a -50 y este parámetro.

Ejemplo:

module_critical_inverse 0

(>= 5.x) module_critical_inverse <value>

Esta directiva es un flag (0/1) que cuando está activado indica que el umbral de Critical es el inverso al definido

Ademas si usas intervalos negativos, como por ejemplo activar el estado de critical cuando sea inferior a -75, seria setear min_crticial a -75 y este parámetro.

Ejemplo:

module_critical_inverse 1

(>= 5.x) module_native_encoding <value>

(Win32 únicamente)

Este token de configuración solo afecta a los módulos que se ejecutan mediante una directiva de comandos, es decir, hay un module_exec presente.

Windows maneja tres codificaciones para sus procesos: la codificación de la línea de comandos (OEM), la codificación del sistema (ANSI) y UTF-16. Ambas codificaciones coinciden en los caracteres básicos, pero difieren en aquellos menos comunes, como podrían ser las tildes. Con este token, el agente de Pandora convierte la salida del comando a la codificación especificada en el encoding del archivo de configuración.

module_native_encoding tiene cuatro valores válidos:

  • module_native_encoding OEM: Para la codificación de la línea de comandos
  • module_native_encoding ANSI: Para la codificación del sistema
  • module_native_encoding UTFLE: Para UTF-16 little-endian
  • module_native_encoding UTFBE: Para UTF-16 big-endian

Si no aparece module_native_encoding, no se realizará ninguna recodificación.

(>= 5.x) module_quiet <value>

Esta directiva es un flag (0/1) que cuando está activado indica que el módulo está en modo silencioso: no genera eventos ni alertas, y tampoco almacenará histórico de datos, por lo que los informes y el SLA no se verán afectados.

Ejemplo:

module_quiet 1

(>= 5.x) module_ff_interval <value>

Esta directiva es el umbral flip flop de ejecución del módulo (en segundos)

Ejemplo:

module_ff_interval 2

(>= 5.x) module_macro<macro> <value>

Esta es una macro generada por la consola con el sistema de macros de los componentes. Establecer este parámetero en el fichero de configuración es inútil porque es solamente para módulos creados con componentes locales.

Ejemplo:

module_macro_field1_ 8080

(>= 5.1 SP4) module_alert_template <template_name>

Esta macro asigna al módulo creado la plantilla de alerta correspondiente al nombre introducido como parámetro (ver Plantillas de alerta).

Ejemplo:

<module>
<name><![CDATA[CPU usage]]></name>
<type>generic_data</type>
<module_interval>1</module_interval>
<min_critical>91</min_critical>
<max_critical>100</max_critical>
<min_warning>70</min_warning>
<max_warning>90</max_warning>
<alert_template><![CDATA[Critical condition]]></alert_template>
<![CDATA[92]]>
</module>
module_end

Define el final del módulo. Es obligatorio.

Directivas específicas para obtener información

A continuación se describen las directivas específicas que se pueden especificar en cada módulo para obtener información. En cada módulo solo se puede utilizar un tipo de estos.

module_exec <comando>

Este es la directiva general de «comando a ejecutar». Tanto para el agente UNIX como para el de Windows sólo hay una directiva para obtener datos de un modo genérico, ejecutando un sólo comando (se pueden usar tuberías para redireccionar la ejecución a otro comando). Esta directiva ejecuta un comando y almacena el valor devuelto. Este método también está disponible en los agentes para Windows. Este es el método de propósito general para ambos agentes.

Template warning.png

Si la ejecución del comando devuelve un código de error (return code) diferente de 0, se interpretará que el comando da error y se descartará el dato obtenido.

 


En algunos casos -cuando esté seguro que el comando devuelve información válida, aunque el código de error != 0-, puede encadenar la salida con un comando "inocuo" para limpiar el código de error de ejecución, por ejemplo:

top -n 1 

Le dará errorcode 1 (verifiquelo con echo $?). Para "limpiar" ese error, utilice este método:

top -n 1 | grep ""


Para un agente Windows existen más directivas para obtener datos, éstas se describen a continuación.

module_service <servicio>

Comprueba si un determinado servicio se está ejecutando en la máquina. Recuerde usar los caracteres «" "» si el nombre del servicio contiene espacios en blanco.

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

El servicio se identifica con el nombre corto del servicio (Service name), tal como aparece en el gestor de servicios de Windows. Existe otro identificador, llamado "display name", mas largo y generalmente mas descriptivo, pero ese no es el empleado por Pandora FMS para identificar el proceso. Tampoco lo es el proceso asociado al servicio. En esta captura podemos ver el nombre corto (Service name) del servicio monitorizado en el ejemplo anterior. Es importante resaltar que las mayúsculas y las minúsculas se diferencian y no es lo mismo DHCP que Dhcp.

Service name id.png


Modo asíncrono
Pandora FMS por lo general ejecuta una batería de pruebas (cada una de ellas definida en un módulo) cada X segundos (300 seg. = 5 min. por defecto) de forma que si un servicio se cae justo después de una ejecución de Pandora, tardaremos al menos otros 300 segundos en saber que se ha caído. Los módulos asíncronos hacen que Pandora notifique instantáneamente de la caída de ese servicio. A esto le llamamos modo de operación asíncrono. Para ello basta con agregar la directiva

module_async yes

Watchdog de servicios

Existe un modo watchdog para los servicios, de tal forma que el agente puede iniciarlos de nuevo si estos se paran. En este caso, el servicio reiniciado no requiere ningún parámetro porque Windows ya sabe cómo hacerlo. En este caso la configuración es más sencilla y éste podría ser un 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

En Unix

En Unix funciona igual que en Windows, solo que para Unix proceso y servicio es el mismo concepto, por ejemplo para ver si el proceso sshd está activo en el sistema, bastará con ejecutar:

module_begin
module_name Service_sshd
module_type generic_proc
module_service sshd
module_description Process SSHD running
module_end

El modo watchdog y la detección asíncrona no son posibles en el agente de Unix.

module_proc <proceso>

Comprueba si un determinado nombre de proceso está operando en esta máquina. Si el nombre del proceso contiene espacios en blanco no use «" " ». Tenga en cuenta que el nombre del proceso debe tener la extensión .exe. El módulo devolverá el número de procesos que se estén ejecutando con este nombre. Es importante, igual que en otros casos, que el nombre del proceso sea exactamente igual que el mostrado por el administrador de tareas (taskmgr) de Windows, incluyendo espacios mayúsculas/minúsculas, por ejemplo no será lo mismo cmd.exe que CMD.exe

Este sería un ejemplo de la monitorización de proceso cmd.exe:

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


En Unix

En Unix funciona exactamente igual que el modulo module_service. Tampoco soporta modo asíncrono ni watchdog.

Modo asíncrono

De una forma similar a los servicios, monitorizar procesos puede ser crítico en algunos casos. Ahora el agente de Windows soporta comprobaciones asíncronas para el módulo module_proc. En este caso, el agente notifica inmediatamente cuando el proceso cambia de estado, sin esperar a que el agente "ejecute" de nuevo la verificación según esta configurado en el intervalo del agente. De esta forma, puede conocer la caída de procesos críticos casi al instante de que ocurran. Este sería un ejemplo de monitorización asíncrona de procesos:

module_begin
module_name Notepad
module_type generic_proc
module_proc notepad.exe
module_description Notepad
module_async yes
module_end

La diferencia está en token de configuración "module_async yes".

Watchdog de procesos

Un Watchdog es un sistema que permite actuar inmediatamente ante la caída de un proceso, generalmente, levantando el proceso que se ha caído. El agente de Windows de Pandora FMS, puede actuar como Watchdog ante la caída de un proceso, a esto le llamamos modo watchdog para procesos:

Dado que ejecutar un proceso puede requerir algunos parámetros, hay algunas opciones adicionales de configuración para este tipo de módulos. Es importante destacar que el modo watchdog solo funciona cuando el tipo de módulo es asíncrono. Veamos un ejemplo de configuración de un module_proc con watchdog:

module_begin
module_name Notepad
module_type generic_proc
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

Esta es la definición de los parámetros adicionales para module_proc con watchdog:

  • module_retries: Número de intentos consecutivos que el módulo intentará lanzar el proceso antes de desactivar el watchdog. Si el limite es alcanzado, el mecanismo del watchdog para este módulo se desactivará y nunca más intentará lanzar el proceso, incluso si el proceso es recuperado por el usuario. (al menos hasta que se reinicie el agente). Por defecto no hay límite para el nº de reintentos del watchdog.
  • module_startdelay: Número de milisegundos que el módulo esperará antes de lanzar el proceso por primera vez. Si el proceso tarda mucho en arrancar, es bueno decirle al agente por medio de este parámetro que "espere" antes de empezar a comprobar de nuevo si el proceso se ha levantado. En este ejemplo espera 3 segundos.
  • module_retrydelay: Similar al anterior pero para caídas/reintentos posteriores, después de detectar una caída. Cuando Pandora detecta una caída, relanza el proceso, espera el nº de milisegundos indicados en este parámetro y vuelve a comprobar si el proceso ya esta levantado.

Es importante destacar que Pandora FMS se ejecuta como servicio y que si se quiere utilizar la funcionalidad de Watchdog para ejecutar procesos que necesiten interactuar con el escritorio, habrá que habilitar, en las propiedades del servicio de Pandora FMS la casilla "Acceso interactivo con el escritorio", tal y como se muestra en la captura de pantalla siguiente:

Service interactive.png



De igual modo, es necesario entender que Pandora FMS, como servicio, se ejecuta bajo la cuenta "SYSTEM" y que el proceso ejecutado lo hará bajo ese usuario y con ese entorno, de forma que si quiere ejecutar algún proceso determinado que requiera ser usado con un determinado usuario, deberá encapsular en un script (.bat o similar) los procesos previos para inicializar el entorno, variables de entorno, etc), y ejecutar ese script como acción del watchdog.

module_cpuproc <process>

(Unix only)

Devuelve el uso de CPU específico de un proceso.

module_begin
module_name myserver_cpu
module_type generic_data
module_cpuproc myserver
module_description Process Command line
module_end
module_memproc <process>

(Unix only)

Devuelve el consumo de memoria específico de un proceso.

module_begin
module_name myserver_mem
module_type generic_data
module_memproc myserver
module_description Process Command line
module_end
module_freedisk <letra_de_la_unidad:>|<volumen>

Comprueba el espacio libre en la unidad (no olvide «":"» después de letra_de_la_unidad en WIndows). En Unix sería simplemente el volumen a comprobar, como por ejemplo /var

module_freepercentdisk <letra_de_la_unidad:>|<volumen>

Este módulo devuelve el porcentaje de disco libre en una unidad lógica (C:) o un volumen Unix (p.e: /var)

module_begin
module_name freepercentdisk
module_type generic_data
module_freepercentdisk C:
module_end
module_begin
module_name disk_var
module_type generic_data
module_freepercentdisk /var
module_end
module_occupiedpercentdisk <letra_de_la_unidad:>|<volumen>

(Sólo Unix)

Este módulo devuelve el porcentaje de disco ocupado en un volumen Unix (p.e: /var)

module_begin
module_name disk_var
module_type generic_data
module_occupiedpercentdisk /var
module_end
module_cpuusage [<cpu id>]

Devuelve el uso de CPU en un número de CPU. Si sólo existe una CPU no establezca ningun valor o utilice el valor "all". Funciona igual en Windows o en Unix.

También es posible obtener el promedio de uso de todas las CPU en un sistema multiprocesador:


module_begin
module_name UsoCPU
module_type generic_data
module_cpuusage all
module_description Uso medio de CPU
module_end
module_begin
module_name CPU_1
module_type generic_data
module_cpuusage 1
module_description Uso medio de CPU de la CPU 1
module_end
module_freememory

Funciona tanto en Unix como en Windows. Devuelve la memoria libre en todo el sistema.

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

Funciona tanto en Unix como en Window. Este módulo devuelve el porcentaje de memoria libre en un sistema:

module_begin
module_name freepercentmemory
module_type generic_data
module_freepercentmemory
module_end
module_tcpcheck

(Win32 únicamente)

Este módulo intenta conectarse con la dirección IP y puerto especificados. Devuelve 1 si tuvo éxito y 0 de otra forma. Se debe especificar un tiempo de expiración.

module_begin
module_name tcpcheck
module_type generic_proc
module_tcpcheck www.artica.es
module_port 80
module_timeout 5
module_end
module_regexp

(Win32 únicamente)

Este módulo monitoriza un fichero de registro (log) buscando coincidencias usando expresiones regulares, descartando las líneas ya existentes al iniciar la monitorización. Los datos devueltos por el módulo dependen del tipo de módulo:

  • generic_data_string, async_string: Devuelve todas las líneas que coincidan con la expresión regular.
  • generic_data: Devuelve el número de líneas que coincidan con la expresión regular.
  • generic_proc: Devuelve 1 si existe alguna coincidencia, 0 de otra forma.
  • module_noseekeof: Por defecto a 0, con este token de configuración activo, en cada ejecución, independientemente de las modificaciones en el fichero del log, el módulo reinicia su comprobación sin buscar el flag EOF del archivo, con lo que siempre sacará en el XML todas aquellas líneas que coincidan con nuestro patrón de búsqueda.
module_begin
module_name regexp
module_type generic_data_string
module_regexp C:\WINDOWS\my.log
module_pattern ^\[error\].*
module_noseekeof 1
module_end

Para obtener más información acerca de la sintaxis de las expresiones regulares, consulte el siguiente enlace: [2]

module_wmiquery

(Win32 únicamente)

Los módulos WMI permiten ejecutar localmente cualquier query WMI sin utilizar una herramienta externa. Se configura por medio de dos parámetros:

  • module_wmiquery: WQL query empleada. Se pueden obtener varias lineas como resultado, que serán insertados como varios datos.
  • module_wmicolumn: Nombre de la columna que se va a usar como fuente de datos.

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

O de la carga actual de CPU:

module_begin
module_name CPU_speed
module_type generic_data
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
module_wmicolumn LoadPercentage
module_end
module_perfcounter

(Win32 únicamente)

Obtiene los datos del contador de rendimiento (performance counter http://msdn.microsoft.com/en-us/library/aa373083(v=vs.85).aspx Performance Counters (Documentación en ingles Performance Counters Documentación en ingles) a través de la interfaz de PDH (La librería pdh.dll debe de estar instalada en el sistema. PDH.DLL es una librería de Windows, si no la tiene instalada tendrá que instalar la herramienta de análisis de rendimiento de Windows (que suele venir por defecto)).

module_begin
module_name perfcounter
module_type generic_data
module_perfcounter \Memory\Pages/sec
module_end

El monitor de rendimiento de Windows es una herramienta muy potente y que dispone de cientos de parámetros que se pueden usar para monitorizar. Cada fabricante además, incorpora sus propios monitores, de forma que es una herramienta muy potente, versátil y fácil de utilizar para monitorizar parámetros del sistema y aplicativos que corren sobre él.

La sintaxis de los elementos del perfcounter es dependiente del idioma, es decir, en un Windows en versión alemán, tendrá unas cadenas de identificación y en un Windows en versión en Inglés tendrá otras diferentes. Eso dificulta su uso en sistemas con idiomas heterogéneos.

Para explorar los diferentes valores que se pueden usar, se puede usar la herramienta de "Rendimiento" (Performance) de Windows para ver que cadenas de rendimiento puedo monitorizar.

En esta captura se ve el monitor de rendimiento de Windows

Perfcounter screen1.png



Y en esta captura, se como el interfaz que nos muestra cuando queremos añadir un elemento de monitorizacion nuevo. Aqui se visualiza (en español) varios parámetros del objeto Procesador (en español en el original), y que tiene diferentes subelementos, de los cuales tenemos señalado % de tiempo de procesador y en varios subsubelementos, en este caso nos interesa el total, _Total.

Perfcounter screen2.png



De esta forma, navegando con la propia herramienta del SO, podemos capturar diferentes elementos de rendimiento del sistema, para este ejemplo concreto, el módulo seria:

module_begin
module_name Processor_Time
module_type generic_data_inc
module_perfcounter \Procesador(_Total)\% de tiempo de procesador
module_end

Por defecto se muestra el valor en crudo del contador, para obtener el valor cocinado se puede añadir el parámetro module_cooked 1:

module_begin
module_name Disk_E/S_Seg
module_type generic_data
module_cooked 1
module_perfcounter \DiscoFísico(_Total)\E/S divididas por seg.
module_end

Muchos de los datos que devuelve son contadores, por lo que deberá usar generic_data_inc como tipo de datos. También puede devolver valores en escalas de datos muy altas (varios millones), por lo que puede reducir esos valores usando el postproceso del módulo, con valores tales como 0.000001 o similares.

module_inventory

(Win32 únicamente. En linux/unix está implemetado como plugin de agente)

Usando consultas WMI predefinidas y búsquedas sobre el registro, este módulo obtiene información acerca de los diferentes aspectos de una máquina, desde software hasta hardware.

El módulo puede recibir diferentes parámetros para marcar qué tipo de información se obtiene. Aquí está la lista de parámetros y el tipo de información que proporcionan:

  • cpu: Obtiene información acerca de las CPU del sistema (nombre del procesador, frecuencia del reloj y descripción).
  • CDROM: Obtiene información acerca de los CD-ROM (nombre, descripción y letra de la unidad).
  • Video: Obtiene información acerca de las tarjetas de vídeo (descripción, RAM y procesador).
  • HDs: Obtiene información acerca de los discos duros (modelo, tamaño y nombre en el sistema).
  • NICs: Obtiene información acerca de los controladores de interfaces de red (descripción, dirección MAC y dirección IP).
  • Patches: Obtiene información acerca de los parches instalados (identificador, descripción y comentarios).
  • Software: Obtiene información acerca de los paquetes MSI instalados (nombre y versión).
  • RAM: Obtiene información acerca de los módulos de RAM (etiqueta, capacidad y nombre).
  • Services: Obtiene información acerca de los servicios intalados. El nombre corto mostrado en la primera columna es el nombre del servicio que usa Pandora FMS para poder monitorizar servicios.

Parámetros adicionales del módulo:

  • module_interval: Este módulo tiene una línea adicional que se usa para especificar el intervalo, en días, en el que obtener la información para el módulo.

Un ejemplo de uso de este módulo sería el siguiente:

module_begin
module_name Inventory
module_interval 7
module_type generic_data_string
module_inventory RAM Patches Software Services
module_description Inventory
module_end
module_logevent

(Win32 únicamente)

Éste nuevo módulo, permite obtener información del archivo log de eventos de Windows. Devuelve aquellos eventos que concuerdan con un patrón dado, permitiendo además filtrar en función de la fuente y el tipo de evento. Se ha mejorado el módulo existente en la version 2.0, utilizando ahora la API nativa de Win32 para acceder a los eventos desde fichero, en vez de usar el subsistema WMI (Mucho mas lento). Este método es mucho mas rapido y permite trabajar en sistemas con muchos eventos. Se ha probado de forma exhaustiva en Windows 2003 y Windows 2008 (que utiliza el nuevo sistema de eventos basado en XML) y debería funcionar en el resto de versiones. Además la nueva implementación permite filtrar por más campos que la versión anterior.

El formato general de este módulo es el siguiente:

module_begin
module_name MyEvent
module_type async_string
module_logevent
module_source <logName>
module_eventtype <event_type/level>
module_eventcode <event_id>
module_application <source>
module_pattern <text substring to match>
module_description
module_end

Para evitar mostrar información repetida, sólo se tienen en cuenta aquellos eventos que hayan tenido lugar durante desde la última vez que se ejecutó el agente, como ocurre con otros módulos (regexp, p.e).

module_logevent acepta los siguientes parámetros (todos ellos case-sensitive):

  • module_source: Origen del evento (System, Application, Security). Este campo es obligatorio.
  • module_eventtype: Tipo de evento (error, information...). Es un campo opcional.
  • module_pattern: Patrón a buscar (subcadena). Es un campo opcional.
  • module_eventcode: Es un ID numerico del evento, p.e: 5112. Es un campo opcional.
  • module_application: Aplicación origen del evento, ojo, no confundir con module_source que indica el nombre de la fuente o fichero log de donde se buscan los eventos.

Por ejemplo, para mostrar todos los eventos del sistema de tipo error definiríamos el siguiente módulo:

module_begin
module_name log_events
module_type generic_data_string
module_description System errors
module_logevent
module_source System
module_eventtype error
module_end


Para mostrar todos los eventos que contengan la palabra PandoraAgent:

module_begin
module_name log_events_pandora
module_type async_string
module_description PandoraAgent related events
module_logevent
module_source System
module_pattern PandoraAgent
module_end

Otro ejemplo, filtrando el evento mostrado en la captura:

Event sample.png


module_begin
module_name MyEvent
module_type async_string
module_source Application
module_eventtype Information
module_eventcode 6000
module_application Winlogon
module_pattern unavailable to handle
module_description
module_end


Es esencial entender que Pandora FMS no es un sistema de recoleccion de logs y que esta herramienta se debe usar para seleccionar aquellos eventos criticos o importantes para la monitorización, y que recoger todos los eventos, sin clasificar, de una fuente comun, como puede ser "System" solo traerá problemas a la larga, ya que se saturará la BBDD y el sistema funcionará muy degradado. Es vital entender que la recogida de eventos con Pandora FMS debe hacerse teniendo en cuenta este hecho y no utilizar Pandora FMS como un recolector de eventos genérico.

module_plugin

Es un parámetro para definir que el dato se obtiene como salida de un plugin de agente. Es un caso especial de módulo, que construye todo su XML y que no requiere de ningun otro delimitador, tipo module_begin, module_type, etc. Siguen el siguiente formato:

module_plugin plugin_filename parámetro_1 parámetro_2 parámetro_3

Para configurar parámetros adicionales para el plugin, utilice la sintáxis estándar:

module_begin
module_plugin plugin_filename parameter_1 parameter_2 parameter_3
module_interval 2
module_condition (0, 1) script.sh
module_end

Cada plugin tiene su propia sintaxis. Vamos a describir uno de los plugins que vienen por defecto con el Agente, el plugin de expresiones regulares:

module_plugin grep_log /var/log/syslog Syslog ssh

En este ejemplo, el nombre del plugin se llama, "grep_log" y buscará en el fichero "/var/log/syslog" la expresion regular "ssh" y lo guardará en un módulo llamado "Syslog"

Un ejemplo de llamada a un plugin en un agente windows (solo version 3.1 o superior)

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

Colecciones de ficheros y plugins

Cuando se usan colecciones de ficheros, el funcionamiento es el mismo, pero sabiendo donde se guardan las colecciones, en funcion del "handle" o nombre corto de la coleccion (que se crea en el momento de crear la coleccion y que tiene formato fc_x), veamos varios ejemplos de llamadas a plugins usando colecciones de ficheros:

Unix:

module_plugin /etc/pandora/collections/fc_1/always_1.sh 

Windows:

module_plugin cscript //B "%ProgramFiles%\pandora_agent\collections\fc_2\df_percent.vbs"

Es importante destacar que la salida de la ejecución del plugin puede devolver uno o varios módulos, ya que devuelve un XML completo, por ejemplo, esta es la salida del plugin de windows df.vbs:

<module>
    <name><![CDATA[C:]]></name>
    <description><![CDATA[Drive C: free space in MB]]></description>
    <![CDATA[2361]]>
</module>
<module>
    <name><![CDATA[D:]]></name>
    <description><![CDATA[Drive D: free space in MB]]></description>
    <![CDATA[32020]]>
</module>
<module>
    <name><![CDATA[Z:]]></name>
    <description><![CDATA[Drive Z: free space in MB]]></description>
    <![CDATA[10168]]>
</module>
module_ping <host>

(Desde la versión 4.0.1 en adelante, sólo Windows)

Este módulo hace un ping al host dado y devuelve 1 si está arriba, 0 en cualquier otro caso. Es un envoltorio para ping.exe.

Soporta los siguientes parámetros de configuración:

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

Ejemplo:

module_begin
module_name Ping
module_type generic_proc
module_ping 192.168.1.1
module_ping_count 2
module_ping_timeout 500
module_end
module_snmpget

(Desde la versión 4.0.1 en adelante, sólo Windows)

Este módulo ejecuta una consulta SNMP get y devuelve el valor solicitado. Es un envoltorio para snmpget.exe.

Soporta los siguientes parámetros de configuración:

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

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

Ejemplos

Ejemplo de un módulo Windows, comprobando si el servicio EventLog funciona, podría ser:

module_begin
module_name ServicioReg
module_type generic_proc
module_service Eventlog
module_description Eventlog service availability
module_end

Un ejemplo de módulo Unix sería:

module_begin
module_name cpu_user
module_type generic_data
module_exec vmstat | tail -1 | awk '{ print $14 }'
module_min 0
module_max 100
module_description User CPU
module_end
Tipos de agentes software

Configuración específica por tecnologías

Es posible monitorizar cualquier sistema con Pandora FMS. Esto se puede hacer, bien con un agente Software instalado en la maquina, que recoge los datos directamente desde el sistema para ser monitorizado, o empleando un Agente Satélite, que consiste en un agente que se ejecuta en un servidor y monitoriza ciertos parámetros de sistemas que tiene adyacentes, mediante SNMP o comandos definidos por el usuario.

Los agentes software pueden ser agentes Windows o UNIX. Los agentes pueden instalarse usando cualquiera de los agentes descritos en las siguientes líneas. Para utilizar un agente satélite, basta con instalar un agente software y definir módulos configurados para recoger datos desde un sistema externo mediante, por ejemplo, la herramienta snmpget o mediante ping.

Agentes Unix/Linux

Unix tiene multitud de herramientas de línea de comando que permiten que sacar datos a través de la ejecución de comandos sea algo muy sencillo, los agentes Unix están basados en esta premisa. Existen dos tipos de agentes Unix:

  • ShellScript: Con un shellscript definido para cada tipo de SO, basado en bash, ksh o csh. En los sistemas Unix clásicos (Solaris, AIX, HPUX) no están implementadas todas las funcionalidades. En Linux y MAC sí.
  • Perl: Existe un único agente multiplataforma, basado en Perl 5.8 que funciona por igual en todos los sistemas Unix. Necesariamente deben disponer de un sistema Perl 5.8 o superior para operar.

Los agentes shellscript han sido diseñados para funcionar aun incluso en las versiones más antiguas de UNIX: HPUX11.0, AIX 4.1, Solaris 6... Funcionan pero están limitados respecto a algunas características, como no disponer del cliente de Tentacle y tener que utilizar el sistema FTP o SSH para subir los datos de monitorización al servidor.

Configuración de los agentes Unix de Pandora FMS

Apenas existe diferencia entre AIX, Solaris y GNU/Linux, por citar algunos. Vamos a describir algunos de sus parámetros y paths mas importantes

Después de poner en funcionamiento el instalador el directorio principal o directorio "home" del agente es /usr/share/pandora_agent/ donde se instala el agente de Pandora FMS. En los sistemas donde por políticas esto no se permita, se recomienda crear un enlace a esta ruta desde la ruta real de instalacion, p.e /opt/pandora -> /usr/share/pandora_agent .

Las otras carpetas importantes son:

  • /var/spool/pandora/data_out: Carpeta donde se almacenan los datos recolectados por los agentes.
  • /etc/pandora/pandora_agent.conf: Fichero principal de configuración del agente. Ahi se definen los datos que serán recogidos, junto con el comando que se empleará para la recolección de datos.
  • /usr/local/bin/pandora_agent: El agente de Pandora FMS actual. Esta fichero es un shellscript que recoge los datos configurados *en los ficheros pandora_agent.conf. También transfiere los paquetes de datos al servidor de Pandora FMS. Generalmente tiene un enlace a /usr/bin/pandora_agent
  • /usr/local/bin/tentacle_client: El agente incorpora el cliente de Tentacle para poder enviar los ficheros de datos al servidor. Este es un cliente en Perl 5.8. Generalmente tiene un enlace a /usr/bin/tentacle_client.
  • /etc/init.d/pandora_agent_daemon: Script de inicio/parada. Éste hace un llamamiento a pandora_agent. Ofrece dos opciones, inicio y parada (start/stop). En los sistemas AIX el demonio es /etc/rc.pandora_agent_daemon .
  • /var/log/pandora/pandora_agent.log: Fichero de texto donde se guarda la actividad del agente de Pandora FMS, cuando el agente se ejecuta en modo de depuración.
  • /etc/pandora/plugins: Directorio que contiene los plugins de agente. Está enlazado al directorio /usr/share/pandora_agent/plugins
Ejecución inicial del agente Unix

Al arrancar el agente de Pandora FMS, este debería copiar el fichero de datos al servidor de Pandora FMS mediante el sistema de envío especificado en el fichero de configuración /etc/pandora/pandora_agent.conf. Este sistema de envío (Tentacle, SSH, FTP) ha de ser configurado previamente.

Para iniciar el agente es únicamente necesario ejecutar:

/etc/init.d/pandora_agent_daemon start

Para sistemas IPSO el agente se lanzará con una prioridad de -10, por tanto, se convierte en el proceso con la prioridad más baja en la CPU del sistema. Será ejecutado cuando otros procesos con una mayor prioridad estén esperando en la cola del sistema CPU. El agente IPSO tiene un parámetro especial (harmless_mode ) para un manejo especial del proceso CPU en los sistemas Checkpoint/NOKIA. Este es un caso muy especial.

En los sistemas BSD la máxima prioridad es +20 y la mínima -20.

Para detener el agente, ejecute:

/etc/init.d/pandora_agent_daemon stop


Configuración avanzada para el agente Unix

El poder real de Pandora FMS reside en la capacidad de los agentes para poner en marcha los scripts definidos del usuario. Esto se puede emplear para recoger datos específicos o para realizar una operación que devuelva cualquier valor deseado. Este es el propósito de la estructura de plugins de agente. Para más información consulte con el Anexo de construcción de plugins de Agente.

Ejemplos de implementación para agentes Unix

Ejemplo #1: calcular el número de visualizaciones de la página principal del servidor Web de Apache (podría degradar el funcionamiento de registros enormes):

module_begin
module_name WEB_Hits
module_type generic_data_inc
module_exec cat /var/log/apache/access.log | grep "index" | wc -l
module_end


Ejemplo #2: comprueba si el proceso del servidor DNS (named) está activo o se ha caído:


module_begin
module_name DNS_Daemon
module_type generic_proc
module_exec ps -Af | grep named | grep -v "grep" | wc -l
module_end


Modificar la forma en que los agentes Unix obtienen información del sistema

Esto sólo es válido para agentes Unix Perl (a partir de la version 3.2 o superior).

Hay algunos módulos en los agentes Unix que funcionan como "cajas negras", es decir, hacen cosas que el usuario no sabe exactamente cómo suceden. Estos módulos son:

  • module_procmem
  • module_freedisk
  • module_freepercentdisk
  • module_cpuproc
  • module_proc
  • module_procmem
  • module_cpuusage
  • module_freememory
  • module_freepercentmemory

Los módulos como el módulo module_cpuusage, por ejemplo, devuelven un % del uso actual de CPU del sistema. El usuario no necesita saber que comando usar (eso si, siempre puede hacerlo si quiere). Pandora ya "sabe por el" que hacer, en Windows y ahora en sistemas Unix (a partir de la 3.2). Esto es simplemente por facilitarle la vida en los casos mas habituales de modulos de recursos del sistema.

Los agentes unix de Pandora tienen una serie de comandos "predefinididos" para hacer, por ejemplo, operaciones como obtener el espacio de disco, la memoria restante o ver si un proceso está en el sistema. Para hacer estas operaciones, muy específicas, dependemos de cada tipo de SO e incluso de versión y/o distribución. Por ejemplo, estos son los comandos predefinidos para obtener el uso de CPU:

	linux => 'vmstat 1 2 | tail -1 | awk \'{ print $13 }\,
	solaris => 'vmstat 1 2 | tail -1 | awk \'{ print $21 }\,
	hpux => 'vmstat 1 2 | tail -1 | awk \'{ print $16 }\

Puede ocurrir que en su sistema, no funciona así y que el comando no sea válido y no devuelva la información esperada. Puede usar su propio comando, con un modulo module_exec, o puede redefinir el comando interno que obtiene esa información. Para hacerlo, necesita alterar un poco el código del agente Unix de Pandora, pero no se preocupe, es código Perl y es una modificación muy sencilla.

El agente de Pandora FMS está ubicado generalmente en /usr/bin/pandora_agent. Edítelo con el editor vi o nano (editores muy comunes para la consola) y busque la siguiente cadena de texto: "Commands to retrieve". Ahi empieza el código que redefine los comandos internos:

# Commands to retrieve total memory information in kB
use constant TOTALMEMORY_CMDS => {
	linux => 'cat /proc/meminfo  | grep MemTotal: | awk \'{ print $2 }\,
	solaris => 'MEM=`prtconf | grep Memory | awk \'{print $3}\'` bash -c \'echo $(( 1024 * $MEM ))\,
	hpux => 'swapinfo -t | grep memory | awk \'{print $2}\
};

Este es un trozo de código que define como Pandora obtiene información del sistema, concretamente la memoria libre del sistema. El sistema AIX no está definido aquí porque no teníamos información de como se hacía en ese tipo de sistemas. Un poco más abajo verá este otro código para obtener el espacio libre en los diferentes volúmenes de disco:

# Commands to retrieve partition information in kB
use constant PART_CMDS => {
	# total, available, mount point
	linux => 'df -P | awk \'NR > 1 {print $2, $4, $6}\,
	solaris => 'df -k | awk \'NR > 1 {print $2, $4, $6}\,
	hpux => 'df -P | awk \'NR > 1 {print $2, $4, $6}\,
	aix => 'df -kP | awk \'NR > 1 {print $2, $4, $6}\
};

Esto obtiene información del disco para varios valores (total, libre y nombre del punto de montaje).

Para cambiar cualquiera de los comandos predefinidos, simplemente edite el código para modificar el comando, pero tenga cuidado con los siguientes aspectos:

  1. Verifique que las lineas terminan en ";"
  2. Verifique que los comandos están encerrados entre comillas simples: ' '
  3. Verifique que cualquier comilla simple que quiera usar en el comando, esté escapada previamente con el carácter \, es decir \', por ejemplo, este comando que normalmente sería:
df -P | awk 'NR > 1 {print $2, $4, $6}'

Se escribiría como:

df -P | awk \'NR > 1 {print $2, $4, $6}\'

Ese comando se usa en el trozo de código que se ha escrito más arriba, asi que puede ver como quedaría en su formato final.

Agentes Windows de Pandora FMS

Comprobación del funcionamiento del agente de Windows

Se puede comprobar la salida del agente Windows de Pandora FMS en el fichero C:\archivos de programa\pandora_agent\pandora_agent.log, fichero de texto plano que incluye información acerca del flujo de ejecución del agente.

Para comprobar que Tentacle o SSH esté funcionando correctamente, se puede usar el comando tentacle_client o el parámetro --test-ssh sobre el binario. El primer comando dará un error ya que no se especifica ni la dirección ni el fichero para enviar, pero se comprueba que el cliente de Tentacle, tentacle_client está presente en el sistema. El segundo comando obligará a Pandora FMS a conectar usando SSH internamente y copiar un fichero llamado ssh.test. Recuerde que debe configurar correctamente SSH si quiere usarlo, generando las llaves necesarias e importándolas en el servidor.

Control del servicio del Agente de Pandora FMS

Pandora FMS ha sido meticulosamente revisada y debugeada para evitar todo tipo de leaks de memoria, de handles de procesos, ficheros o puertos TCP/IP. Es estable y ha sido probada concienzudamente en todas las plataformas Windows donde tiene que operar, no obstante, en algunos sistemas puede ocurrir que el servicio se caiga muy de vez en cuando. Por ello hemos procurado dar varias soluciones a aquellos usuarios que requieren de un sistema de reinicio o control suplementario del agente.

Existen dos formas de tener un mayor control sobre el agente. La primera es forzar el reinicio del agente cada X días mediante el programador interno de tareas de Windows, mediante el comando AT.

Reinicio con AT

En ingles

Para programar un reinicio Lunes y Viernes:

at 00:00 /every:Monday,Friday "c:\program files\pandora_agent\scripts\restart_pandora_agent.bat"

En castellano

Por ejemplo, para programar un reinicio diario:

at 00:00 /every:L,M,Mi,J,V,S,D "c:\archivos de programa\pandora_agent\scripts\restart_pandora_agent.bat"

Para ver una lista de las tareas programadas, escriba en la linea de comando

at

Esto le dará la lista de tareas programadas.

Control automático del servicio ante caídas

Windows proporciona una manera adicional de reinicio controlado del servicio si este, por la razón que sea, cae. Esto permite decirle al servicio de Windows que si este cae, lo levante automáticamente de nuevo. Para ello hay que ir al panel de control de servicios de Windows, ir al agente de Pandora FMS y hacer click en propiedades. En la solapa "Recuperación", cambiaremos los valores por defecto por los siguientes:

Service control restart.png


Esto básicamente hace que si el servicio se cae, lo reinicie automáticamente, pero sólo una vez por día, de forma que si se cae más no lo levante, evitando así que el sistema se vea sobrecargado o esté forzando la ejecución de un servicio que cae con demasiada facilidad y que puede ser síntoma de un problema en el sistema, ya que Pandora FMS jamás debería caerse, y mucho menos más de una vez al día. En cualquier caso, puede ajustar estos parámetros para hacer que el servicio de Pandora FMS cuando caiga, sea controlado por el sistema y así asegurarse de que siempre tendrá el agente corriendo.

Configuración del agente de Windows de Pandora FMS

Toda la instalación se hace a través del fichero pandora_agent.conf. Este fichero es una lista de pares de claves/valores que se han descrito anteriormente. Aquí hay un ejemplo de este fichero.

# General Parameters
# ==================
 
server_ip mypandoraserver.host.com
server_path /var/spool/pandora/data_in
temporal "c:\windows\temp"
interval 300
agent_name myagent_name
 
# Module Definition
# =================
 
# Counting OpenedConnections (check language string)
module_begin
module_name OpenNetConnections
module_type generic_data
module_exec netstat -na | grep ESTAB | wc -l | tr -d " "
module_description Conexiones abiertas (interval 2)
module_interval 2
module_end
 
# Is Eventlog service running ?
module_begin
module_name ServicioReg
module_type generic_proc
module_service Eventlog
module_description Servicio Registro de sucesos
module_end
 
# Is lsass.exe process alive ?
module_begin
module_name Proc_lsass
module_type generic_proc
module_proc lsass.exe
module_description LSASS.exe process.
module_end
 
# Received packets.
# Please notice that "Paquetes recibidos" string must be replaced by
# the correct string in your Windows system language.
module_begin
module_name ReceivedPackets
module_type generic_data
module_exec netstat -s | grep  "Paquetes recibidos  " |  tr -d " " | cut -f 2 -d "=" | tr -d "\n"
module_description Conexiones abiertas (interval 2)
module_end
 
# Free space on disk
module_begin
module_name FreeDiskC
module_type generic_data
module_freepercentdisk C:
module_description Free space on drive C:
module_end

module_begin
module_name FreeMemory
module_type generic_data
module_freepercentmemory
module_description Amount of free memory.
module_end


Extendiendo la funcionalidad de los agentes con codigo VBS

Los agentes Windows tienen plugins, como los agentes Unix, y al igual que estos, podemos extender su funcionalidad con scripts utilizando las herramientas propias del SO. De esta manera tenemos la posibilidad de ejecutar scripts externos, basados en VBScript. Veamos este código VBS que obtiene el uso total CPU de un sistema:

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
   & "{impersonationLevel=impersonate}!\\" _
   & strComputer & "\root\cimv2")
   Set object1 = objWMIService.Get( _
   "Win32_PerfRawData_PerfOS_Processor.Name='_Total'")
   N1 = object1.PercentProcessorTime
   D1 = object1.TimeStamp_Sys100NS
   Wscript.Sleep(1000)
   set object2 = objWMIService.Get( _
   "Win32_PerfRawData_PerfOS_Processor.Name='_Total'")
   N2 = object2.PercentProcessorTime
   D2 = object2.TimeStamp_Sys100NS
   ' CounterType - PERF_100NSEC_TIMER_INV
   ' Formula - (1- ((N2 - N1) / (D2 - D1))) x 100
   PercentProcessorTime = (1 - ((N2 - N1)/(D2-D1)))*100
   Wscript.Echo PercentProcessorTime

Lo guardamos en un fichero llamado "CPUTotal.vbs" y ubicado en c:\program files\pandora_agent\util.

Ahora creamos un nuevo módulo de tipo module_exec con este contenido:

cscript.exe /NoLogo c:\program_filespandora_agent\util\CPUTotal.vbs

Ya tenemos un nuevo módulo que devuelve el uso total de CPU, obtenido por medio del script externo en VB. Hay muchisimas cosas que se pueden obtener por medio de VBScript. Microsoft tiene una excelente documentación en linea acerca de VBS que puede consultar en MSDN [3].

Ejecutando el servicio con un usuario diferente a SYSTEM

El agente de Windows de Pandora FMS se puede configurar para arrancar con un usuario a SYSTEM. Para ello hay que configurar el inicio de sesión del agente con un usuario del grupo administradores de la máquina,

En la consola de WMI los usuarios del grupo administradores tienen todos los permisos activos. Hemos encontrado problemas con procesos que son dependientes de la sesión de usuario cuando pretendemos hacer un watchdog de dicho proceso. Para solucionarlo se ha montado un proceso paralelo que hace las funciones de supervisor de procesos.

El agente de Pandora, si detecta problemas en un proceso, hace un kill y el supervisor de procesos levanta el proceso automáticamente. El agente de pandora controla también el estado del supervisor de procesos. En nuestro caso son situaciones muy particulares pero que hemos podido solucionar de esta manera.

Otros motivos por los que hemos tenido que configurar distintos inicios de sesión es por controlar el estado de ubicaciones de red que residen en máquinas en las que no se puede instalar el agente de pandora (tipo san, nas dedicados).

Como ejemplo, se presenta un equipo en el que el agente de Pandora se ha configurado con un usuario del grupo administradores. Estas son las seguridades en la consola de WMI para el espacio ROOT. Por defecto, se heredan los permisos en todas las ramas:


Service image001.png



Service image002.png


Algunos enlaces relacionados con este tema de Microsoft: [4] [5]

Auto-actualización de los agentes software

Pandora FMS 3.2 tiene una nueva funcionalidad llamada "Colección de ficheros". Las colecciones de ficheros se describen algunas secciones más abajo. Son un sistema de distribución de ficheros centralizado para copiar ficheros (binarios, scripts, datos) desde la consola a los agentes poniendo en funcionamiento el agente software de Pandora FMS.

Utilizando ese mecanismo y una herramienta especial, podemos proporcionar una manera de "auto-actualizar" los agentes software. Esto funciona del siguiente modo:

1. Los agentes reciben nuevos binarios en el directorio de entrada filecollection, por ejemplo:

c:\program files\pandora_agent\collections\fc_1\pandoraAgent.exe

2. El agente utiliza un módulo especial para ejecutar la herramienta pandora_update. Esta herramienta recibe un único parámetro: el FileCollection handle (o nombre corto). En este escenario es fc_1. Compruebe un fichero llamado pandoraagent.exe (o pandora_agent en Unix) y vea el tamaño y contenidos ( usando un HASH) de ambos ficheros: el agente_pandora que esta corriendo y el binario proporcionado en la collección de ficheros. Si ambos son diferentes, pandora_update detiene el agente. Reemplaze el binario y reinicie el agente de nuevo utilizando el nuevo binario.

3. Pandora_update también escribe a un log pequeño el evento actualizado, para ser capaz de recuperar en la siguiente ejecución y avisar al usuario, mediante el uso de un módulo async_string, acerca del proceso de actualización del agente.

Esto implica que los módulos utilizados para completar el proceso de actualización podrán ser configurados para tener un intervalo alto.

Unix instalación estandar

module_begin
module_name Pandora_Update
module_type async_string
module_interval 20
module_exec nohup /etc/pandora/plugins/pandora_update fc_1 2> /dev/null && tail -1 nohup.out 2> /dev/null
module_description Module to check new version of pandora agent and update itself
module_end

Unix instalación personalizada

module_begin
module_name Pandora_Update
module_type async_string
module_interval 20
module_exec nohup /var/opt/PandoraFMS/etc/pandora/plugins/pandora_update fc_1 /var/opt/PandoraFMS 2> /dev/null && tail -1 nohup.out 2> /dev/null
module_description Module to check new version of pandora agent and update itself
module_end

NOTA: El comando pandora_update acepta como segundo parámetro el path del directorio de instalación de Pandora FMS no siendo necesario especificarlo si la instalación se realizó en el path por defecto.

Windows

module_begin
module_name Pandora_Update
module_type async_string
module_interval 20
module_exec pandora_update.exe fc_1
module_description Module to check new version of pandora agent and update itself
module_end

Procedimiento para auto-actualizar agentes de versiones anteriores a la version 3.2

Primero debemos conseguir los ejecutables del agente de Pandora FMS y de la herramienta pandora_update (pandoraAgent.exe y pandora_update.exe en windows, y pandora_agent y pandora_update en Unix).

Muchos de los pasos que vamos a dar aqui suponen los siguientes puntos:

1. Tiene una forma de copiar ficheros a las maquinas que quiere actualizar. Este es un mecanismo que provee la version 3.2 de Pandora FMS (File Collection) pero ahora precisamente quiere migrar a la version 3.2, porque no tiene esa funcionalidad. Se asume que dispone de otro mecanismo alternativo.

2. La gestión remota de la configuración de los agentes está activada y funcionando. Esto será util ya que tendrá que crear varios directorios y configurar un módulo nuevo en la configuración de su agente Pandora FMS.

Plataformas Windows

Debemos copiar pandora_update a un directorio del path del sistema o a la carpeta /util de nuestro pandora (en windows).

Suponiendo que tengamos instalado Pandora FMS en:

C:\Archivos de programa\pandora_agent

Copiaremos pandora_update.exe en el directorio

C:\Archivos de programa\pandora_agent\util

Crearemos dos directorios:

C:\Archivos de programa\pandora_agent\collections
C:\Archivos de programa\pandora_agent\collections\fc_1

Copiaremos el binario del nuevo agente al ultimo directorio que hemos creado:

C:\Archivos de programa\pandora_agent\collections\fc_1\PandoraAgent.exe

Crearemos un modulo en el agente como el que sigue:

module_begin
module_name Pandora_Update
module_type async_string
module_interval 20
module_exec pandora_update.exe fc_1
module_description Module to check new version of pandora agent and update itself
module_end

Este módulo especial que usa el ejecutable pandora_update, ejecuta una herramienta especial (pandora_update) que compara el ejecutable actual por el que existe en el directorio /collections/xxxx donde xxxx es un parámetro que se le pasa al módulo. Esa ubicación es la que se especifica con las file_collections. Más adelante, ya usando la version 3.2, la distribución de los nuevos .exe del agente, se realizarán mediante filecollections y ese identificador será necesario para "ubicar" en que File Collection va nuestro ejecutable.

Plataformas UNIX

De forma muy similar a las plataformas Windows, hay que copiar el ejecutable del agente de Unix y la utilidad pandora_update. Si tiene una instalacion no-standard y tiene rutas personalizadas, tendra que estar muy atento al párrafo anterior donde dice que ficheros modificar.

Tiene que copiar pandora_update en la carpeta /plugins de su agente:

/etc/pandora/plugins/pandora_update

Y ahora crear directorios /collection/fc_1 sobre el directorio base de su /etc/pandora

/etc/pandora/collections/
/etc/pandora/collections/fc_1

La llamada a pandora_update se hará sobre las rutas de su sistema a los plugins, en este caso, el estandard es /etc/pandora/plugins/pandora_update

El modulo en el caso de Unix sería de la siguiente manera:

module_begin
module_name Pandora_Update
module_type async_string
module_interval 20
module_exec nohup /etc/pandora/plugins/pandora_update fc_1 2> /dev/null && tail -1 nohup.out 2> /dev/null
module_description Module to check new version of pandora agent and update itself
module_end

NOTA: Verifique que tanto pandora_update como pandora_agent tienen permisos y propietarios adecuados. Permisos de ejecución y el mismo usuario que el ejecutable de pandora_agent

Pandora FMS Drone Agents

Qué son los Agentes Drone

El agente "drone" de los agentes de Pandora FMS es un modo de ejecución del Agente Software de Pandora FMS, sólo disponible para Windows y Unix.

El modo dron ha sido diseñado para lidiar con entornos complicados en los que el acceso a las máquinas está restringido. Sus dos características principales son:

  • Modo Proxy
  • Modo Broker

Cuando el Agente Software de Pandora FMS se está ejecutando en el modo Drone Agent también puede usar todas las funcionalidades clásicas del agente (gestión remota, plugins, inventario...)

La siguiente imagen es un ejemplo de la arquitectura de Pandora FMS usando Agentes Drone:

Architecture il1.png
Modo Proxy

El Modo Proxy es muy útil para redes que tiene restricciones en las comunicaciones. Con este modo el agente habilita un Tentacle Proxy Server que permite la comunicación entre los demás agentes y el Pandora FMS Server, usando ese agente, en modo proxy, como pasarela para que agentes que no pueden llegar directamente al servidor, puedan conecta.

La nueva versión de tentacle soporta el uso de proxies (en modo HTTP/Connect) de forma que los agentes pueden conectar directamente con el servidor usando un proxy standard. De igual manera existe un componente llamado Tentacle Proxy Server, que permite usar un elemento intermedio que centralize toda la comunicación con el servidor de destino y permita además la gestión de coleción de ficheros (v3.2) y de configuraciones. Puede ver más información más información sobre Tentacle Proxy Server aquí.

Con este modo tiene todas las funcionalidades de un proxy pero gestionadas por el agente de Pandora FMS. Adicionalmente este modo requiere la ejecución del agente por un usuario diferente de root y en caso de que el modo proxy se use con un agente Unix entonces este debe estar instalado con un usuario que no tenga permisos de root (el mismo usuario ejecutará después el agente en modo proxy).

Todos los parámetros para configurar el Tentacle Proxy Server están disponibles a través del archivo de configuración del agente y son los siguientes:

server_ip

Es la dirección IP o el nombre del anfitrión del servidor de Pandora FMS. Tenga cuidado con el Modo Proxy habilitado este parámetro no puede tomar valores como: 127.0.0.1, locahost, 0.0.0.0, o similares.

proxy_mode

Estado del Modo Proxy. Si proxy_mode vale 1 el Proxy del Drone Agent está activado y si proxy_mode vale 0 desactivado. Por defecto el Modo Proxy está desactivado.

proxy_max_connection

Número de conexiones simultaneas del proxy. El valor por defecto es 10.

proxy_timeout

Timeout para el proxy. Por defecto 1 segundo.

Ejemplos de uso

Sólo una máquina se conecta con Pandora FMS Server

Esta situación no es un problema para el Drone Agent. Para configurar el Modo Proxy simplemente ponga en server_ip la dirección IP del Servidor de Pandora FMS y ponga el valor 1 en el parámetro proxy_mode. Si lo necesita también puede configurar otros parámetros como el número máximo de conexiones o el tiemout. Con esta configuración tendrá un agente y el Tentcle Proxy Server corriendo en la misma máquina y conectados Servidor de Pandora FMS.

Para configurar los otros agente sólo ponga en el parámetro server_ip la dirección IP del Agente Drone que tiene le proxy activado y con eso es todo. El agente usará el Agente Drone para conectarse con el Servidor de Pandora FMS.

Tengo que usar dos proxies para conectarme

Si lo necesita puede conectar una Agente Drone a otro Agente Drone, y es muy fácil.

Para realizar el doble proxy necesita configurar un Agente Drone que se conectará al Servidor de Pandora FMS poniendo en el parámetro server_ip la IP del Servidor de Pandora FMS, el parámetro proxy_mode a 1 y si lo necesita también puede configurar los otros parámetros.

Para configurar el segundo Agente Drone simplemente ponga en el parámetro server_ip la dirección IP del primer Agente Drone configurado y por supuesto, active el Modo Proxy poniendo el parámetro proxy_mode a 1.

Con esta configuración, un agente que se conecte al segundo Agente Drone podrá comunicarse con el Servidor de Pandora FMS a través de los dos proxies.

Modo Broker

El Modo Broker está diseñado para gestionar datos y configuración de varios agentes desde un único agente. El agente "broker" ejecuta diferentes configuraciones, como si hubiera varios agentes diferentes instalados en la misma máquina. Cada fichero de configuración independiente puede tener plugins, modulos, inventario y por supuesto, ser gestionado remotamente. A todos los efectos será como otro agente diferente. Esto lo hace idóneo para usar un agente software en una máquina, y crear diferentes configuraciones, de dispositivos remotos a los cuales monitoriza desde el agente software base (en modo broker). Asi puedo monitorizar remotamente decenas de servidores o equipos de comunicacion instalando sólo un agente.

Hay que tener en cuenta que en el fichero de configuración del agente creado por el agente broker, el token broker_agent será ignorado.

Las funcionalidades principales del Modo Broker son:

  • Enviar datos locales como otro agente. Muy útil para monitorizar instancias software como agente independientes.
  • Enviar data recolectada de chequeos remotos a otras máquinas como si hubiera sido recogida por un agente instalado en dichas máquinas. Muy útil para la monitorización de switches o Routers cuando el servidor de Pandora no alcanza estos equipos cuando están detrás de un Firewall o Router ADSL.
Ejemplos de uso

Enviar datos duplicados a un servidor con otro nombre de agente

Añadimos en el fichero de configuración 'pandora_agent.conf' las siguiente líneas:

broker_agent router_1
broker_agent router_2
broker_agent router_3

Se creará un fichero de configuración 'router_1.conf', 'router_2.conf' y 'router_3.conf' que serán una copia exacta del fichero 'pandora_agent.conf' a excepción del nombre de agente que, en este caso, será 'router_1', etc. El fichero .conf del agente broker tampoco admite otros agentes broker.

De este modo, tenemos un total de cuatro agentes con sus ficheros de configuración independientes. Los nuevos agentes 'router_x' comenzarán a reportar a partir de la siguiente ejecución.

Ejemplo de chequeo remoto a otra máquina

Añadimos en el fichero de configuración 'pandora_agent.conf' la siguiente línea:

broker_agent server_1

Se creará un fichero de configuración 'server_1.conf' y lo editamos para incluir módulos que nos interesan:

module_begin
module_name Check SSH Status
module_type generic_proc
module_tcpcheck 192.168.1.1
module_port 22
module_timeout 5
module_end

Esta configuración nos puede interesar a la hora de realizar comprobaciones remotas contra otra máquina que aunque tenga un agente Pandora instalado, es inalcanzable por el servidor.

Esta funcionalidad está disponible desde la version 4.0 de Pandora FMS

Autocreación de agentes y modulos desde XML / Modo aprendizaje

Pandora FMS soporta la creación de los agentes y/o módulos de forma automática cuando viene información desde un XML y lo procesa el data server. Esto sucede de forma automática (a no ser que se desactive en la configuración del servidor con el parámetro autocreate), y sólo funciona la primera vez. Es decir, se crea la información, pero no se actualiza, salvo ciertas excepciones como veremos a continuación.



Learning mode.png

Este comportamiento se puede desactivar completamente si se desactiva el modo aprendizaje del agente. Al desactivar esta funcionalidad no se crearán automáticamente agentes ni módulos cuando venga un XML para ese agente, tampoco se actualizará información alguna de los parámetros de configuración del agente.


Modo Autodisable: A partir de la versión 6.1 los agentes disponen de este tercer modo. En el aspecto de la creación de agentes y módulos se comporta igual que un agente en modo aprendizaje: al llegar el primer XML se crea el agente y, en cada reporte, si hay nuevos módulos también se añaden automáticamente. Sin embargo, cuando todos los módulos de un agente en modo Autodisable están en desconocido, el agente automáticamente se deshabilita. Además, si el agente vuelve a reportar, se vuelve a habilitar por sí mismo.

Datos que se incorporan en la creacion del agente

Los datos que se incorporan al agente en el momento de la creación del mismo son los siguientes:

En la version 4.x

  • Nombre de agente
  • IP de agente
  • Descripcion del agente.
  • Agente padre.
  • Timezone offset.
  • Grupo.
  • Sistema operativo.
  • Intervalo.
  • Agent version

En la version 5.x

Los mismos que en la 4.0.x y además:

  • Custom fields.
  • Custom ID.
  • Dirección URL.


En la versión 6.1

  • Agent mode: (Learning -default-, No-learn, Autodisable);

Datos que se modifican del agente al recibir un XML (modo aprendizaje activado)

  • Dirección IP del agente.
  • Padre del agente ( sí está definido en la configuracion del servidor, para versiones 4.x se actializa siempre )
  • Version SO.
  • Version agente.
  • Zona horaria.
  • Custom fields.


Info.png

Los datos GIS se actualizan siempre( si está habilitado ) sin importar si el learning mode esta desactivado

 


Con learning mode activado se crearán nuevos módulos en Pandora al ser recibidos a través de XMLs.

Datos que se incorporan en la creacion de un módulo

Los datos que se incorporan en el módulo la primera vez que se recibe un XML son los siguientes:

En la versión 4.x

  • Nombre.
  • Tipo.
  • Descripción.
  • Máximo, Mínimo.
  • Post proceso.
  • Intervalo del módulo.
  • Min/max Critical
  • Min/max Warning
  • Desactivado

En la versión 5.x

Los mismos que en la 4.0.x y además:

  • Unidades.
  • Module group.
  • Custom ID.
  • Str. Warning/Critical.
  • Instrucciones para crítico.
  • Instrucciones para warning.
  • Instrucciones para desconocido.
  • Tags.
  • Inversión de critical.
  • Inversión de warning.
  • Modo "silencioso".
  • Min. FF Threshold
  • Alert template (a partir del SP4)

En la versión 6.X

  • Crontab

Datos que se incorporan en la actualización de un módulo ya existente

Cuando se recibe un XML que contiene información de un módulo ya existente, se actualiza parte de esta información. Se actualiza la descripción y la información extendida.

Nota: Los datos GIS se actualizan siempre, a no ser que tenga la actualizacion GIS desactivada en ese agente (esto se configura en la sección GIS del agente).

Información extendida del módulo

De forma avanzada, se pueden enviar XML personalizados (usando su propia aplicación para crear los XML de datos o modificando el agente de Pandora). For ejemplo, este XML:


<module>
    <name><![CDATA[battery_level]]></name>
    <description><![CDATA[The actually device battery level]]></description>
    <type><![CDATA[generic_data]]></type>
    <data><![CDATA[61]]></data>
    <rack_number>2</rack_number>
    <severity>MAJOR</severity>
  </module>

Se verá así en la interfaz de Pandora FMS:



Extended module xml.png

NOTA: Estos campos no guardan valores históricos, sólo almacenan el último valor recogido desde el XML.

Monitorización intensiva

Un módulo remoto (ya sea un módulo de red, un módulo de plug-in etc.) puede devolver datos no fiables por diferentes motivos. Por ejemplo, un módulo de ping puede devolver 0 aunque un host esté arriba si la red está congestionada.

Dependiendo de cómo esté configurado Pandora FMS esto puede desencadenar una serie de eventos no deseados (cambios de estados, disparos de alertas, envíos de emails...).

Para manejar esta situación Pandora FMS permite especificar FF thresholds personalizados para cada módulo. El FF threshold es el número de veces adicionales que se ejecuta un módulo antes de cambiar su estado (un valor de 0 quiere decir que esta característica está deshabilitada). Sólo si la condición de cambio de estado se mantiene durante todos los reintentos se cambiará el estado del módulo. El intervalo de estas ejecuciones adicionales puede especificarse por medio del intervalo de FF.

Todo esto se ve mejor con un ejemplo: Supongamos que tenemos un módulo WMI que devuelve la cantidad de espacio libre en disco en megabytes. Configuramos este módulo para que se vuelva crítico cuando este valor es menor que 100. A continuación configuramos una alerta que mande un email al administrador de sistemas cuando el módulo esté crítico para que éste pueda liberar algo de espacio. Pero, debido a un bug de software, de vez en cuando el módulo devuelve un valor mucho menor que el valor actual. Para solventar este inconveniente, configuramos el FF threshold del módulo a 1 y el intervalo de FF a 30 segundos. Esto significa que la primera vez que el módulo reciba un valor menor que 100, se volverá a ejecutar pasados 30 segundos, y sólo si todavía es menor que 100 se pondrá en estado crítico. De lo contrario continuará su ejecución normal.

Esto funciona bien para los módulos síncronos, pero los módulos asíncronos necesitan un parámetro de configuración adicional. Como no envían datos en intervalos regulares, comprobar valores consecutivos puede no resultar muy útil si están muy separados en el tiempo. En este caso hay que especificar un FF timeout. Lo que quiere decir que el número de valores consecutivos debe tener lugar en el intervalo de tiempo configurado.

Volver a Indice de Documentacion Pandora FMS