Pandora: Documentation es: Configuracion

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

Pandora FMS tiene tres componentes esenciales que es fundamental configurar correctamente para un buen funcionamiento, son la consola web, el servidor y la base de datos.

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.

Contents

1 Servidor

La configuración principal del servidor de Pandora FMS se encuentra en el fichero pandora_server.conf, ubicado de forma predeterminada en la ruta /etc/pandora.

1.1 Elementos del fichero de configuración

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 (#). A continuación se detallan todos los parámetros de configuración existentes en el fichero.

1.1.1 servername

Nombre que tendrá el servidor al visualizarlo en la consola. Por defecto se encuentra comentado y utiliza el nombre de la máquina. Modificar el nombre una vez esté funcionando podría causar que los chequeos remotos dejasen de funcionar, ya que habría que reconfigurar el servidor por defecto en todos los agentes existentes.

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

1.1.3 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 localizar posibles problemas.

1.1.4 snmp_logfile

Fichero de registro (log) de la consola SNMP de Pandora FMS. De forma predeterminada es /var/log/pandora/pandora_snmptrap.log. Muestra los traps que llegan antes de que Pandora FMS los procese.

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

1.1.6 dbname

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

1.1.7 dbengine

Obsoleto: siempre 'Mysql' (valor por defecto).

1.1.8 dbuser

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

1.1.9 dbpass

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

1.1.10 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 127.0.0.1.

1.1.11 dbport

(Opcional) Puerto TCP donde escucha el motor de base de datos. Se empleará 3306 por defecto si el valor está comentado.

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

1.1.13 verbosity

Nivel de detalle para los logs del servidor. Los valores posibles van desde 0 (desactivado) hasta 10 (máximo nivel de detalle). Con valor 10 el log mostrará todas las ejecuciones que el servidor realiza, incluyendo módulos, plugins y alertas. No se recomienda el uso de valores altos de forma continuada debido al gran crecimiento de los ficheros de log, pudiendo ocasionar problemas de rendimiento en el sistema.

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

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

1.1.16 networkserver

Servidor de red de Pandora FMS activado (1) o desactivado (0).

1.1.17 dataserver

Servidor de datos de Pandora FMS activado (1) o desactivado (0).

1.1.18 reconserver

Servidor de autodescubrimiento de red de Pandora FMS activado (1) o desactivado (0).

1.1.19 pluginserver

Servidor de plugins remotos de Pandora FMS activado (1) o desactivado (0).

1.1.20 predictionserver

Servidor de predicción de Pandora FMS activado (1) o desactivado (0).

1.1.21 wmiserver

Servidor WMI de Pandora FMS activado (1) o desactivado (0).

1.1.22 inventoryserver

(sólo Pandora FMS Enterprise)

Servidor de inventario remoto de Pandora FMS activado (1) o desactivado (0).

1.1.23 exportserver

(sólo Pandora FMS Enterprise)

Servidor de exportación de Pandora FMS activado (1) o desactivado (0).

1.1.24 webserver

(sólo Pandora FMS Enterprise)

Servidor de chequeos WEB de Pandora FMS activado (1) o desactivado (0).

1.1.25 eventserver

(Sólo Pandora FMS Enterprise)

Servidor de correlación de eventos de Pandora FMS activado (1) o desactivado (0).

1.1.26 icmpserver

(sólo Pandora FMS Enterprise)

Servidor ICMP Enterprise de Pandora FMS activado (1) o desactivado (0).

El servidor ICMP Enterprise utiliza el binario nmap para realizar peticiones ICMP en bloque. Si este componente no se encuentra habilitado el servidor de red ejecutará los chequeos.

1.1.27 snmpserver

(sólo Pandora FMS Enterprise)

Servidor SNMP Enterprise de de Pandora FMS activado (1) o desactivado (0).

El servidor SNMP Enterprise utiliza el binario braa para ejecutar peticiones SNMP en bloque. Si este componente no se encuentra habilitado el servidor de red ejecutará los chequeos.

1.1.28 transactionalserver

(sólo Pandora FMS Enterprise)

Servidor transaccional de Pandora FMS activado (1) o desactivado (0).

1.1.29 network_timeout

En segundos, timeout para chequeos ICMP. De forma predeterminada su valor es 2. Si va a realizar chequeos en redes WAN, se aconseja incrementar este valor para evitar falsos positivos ya que algunos chequeos podrían requerir más tiempo.

1.1.30 server_keepalive

En segundos, tiempo antes de declarar al servidor como caído.

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

1.1.32 network_threads

Número de hilos para el servidor de red. Indica cuántas comprobaciones se pueden hacer en paralelo. No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.33 icmp_checks

Define el número de pings para cada 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.

1.1.34 (> 5.1SP2) icmp_packets

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

1.1.35 tcp_checks

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

1.1.36 tcp_timeout

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

1.1.37 snmp_checks

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

1.1.38 snmp_timeout

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

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

1.1.40 plugin_threads

Número de hilos para el servidor de plugins remotos. Indica cuántas comprobaciones se pueden hacer en paralelo. No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.41 plugin_timeout

Tiempo de expiración de los chequeos con plugins remotos. 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.

1.1.42 wmi_timeout

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

1.1.43 wmi_threads

Número de hilos para el servidor WMI. Indica cuántas comprobaciones se pueden hacer en paralelo. No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.44 prediction_threads

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

1.1.45 recon_threads

Número de hilos para el servidor de reconocimiento de red. Indica cuántas comprobaciones se pueden hacer en paralelo. No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.46 dataserver_threads

Número de hilos para el servidor de datos. Indica cuántos ficheros XML se pueden procesar en paralelo. No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.47 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. No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.48 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. No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.49 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. No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.50 web_timeout

(sólo Pandora FMS Enterprise)

Tiempo de expiración por defecto en segundos para los módulos de monitorización web.

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

1.1.52 transactional_threads

Por defecto 1. Se presenta este parámetro por convenio, su modificación no alterará el funcionamiento del servidor transaccional.

1.1.53 mta_address

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

1.1.54 mta_port

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

1.1.55 mta_user

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

1.1.56 mta_pass

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

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

1.1.58 mta_from

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

1.1.59 mail_in_separate

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

1.1.60 xprobe2

Si se proporciona, se usa para descubrir el sistema operativo de los equipos remotos cuando se lanza una tarea de reconocimiento de red. La ruta predeterminada es /usr/bin/xprobe2.

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

1.1.62 nmap

Necesario para el recon server. De forma predeterminada está en /usr/bin/nmap. Tambien se utiliza para el ICMP server enterprise.

1.1.63 (> 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.

1.1.64 (> 5.1) recon_timing_template

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

1.1.65 plugin_exec

Indica la ruta absoluta al programa que ejecuta los plugins de forma controlada en el tiempo. Por defecto /usr/bin/timeout. Si su sistema base no dispone de este comando, debe utilizar en su lugar /usr/bin/pandora_exec, que viene incluido con Pandora FMS.

1.1.66 autocreate_group

ID numérico del grupo por defecto para los nuevos agentes creados automáticamente a través de la recepción de ficheros de datos-

1.1.67 autocreate

Si se establece a 1 se autocrearán agentes cuando se reciban ficheros de datos para los que no existan agentes.

1.1.68 max_log_size

Tamaño máximo del fichero log 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.

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

 


1.1.70 use_xml_timestamp

Por defecto desactivado. Si está activado (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 agente. 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.

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

1.1.72 restart

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

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

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

1.1.75 (>= 5.1SP1) self_monitoring_interval

Intervalo de tiempo para self_monitoring en segundos.

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

1.1.77 icmp_threads

(sólo Pandora FMS Enterprise)

Número de hilos del servidor ICMP Enteprise (3 por defecto). No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

1.1.78 snmp_threads

(sólo Pandora FMS Enterprise)

Número de hilos del servidor SNMP Enteprise (3 por defecto). No se recomienda incrementar este valor de forma deliverada ya que podría causar un excesivo consumo de recursos del servidor.

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

1.1.80 braa

(Sólo Pandora FMS Enterprise)

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

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

1.1.82 event_window

(Sólo Pandora FMS Enterprise)

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

1.1.83 wmi_client

Cliente WMi empleado por defecto.

1.1.84 activate_gis

Activar (1) o desactivar (0) las funcionalidades GIS del servidor.

1.1.85 location_error

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

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

1.1.87 recon_reverse_geolocation_file

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

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

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

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

1.1.91 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

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

1.1.93 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

1.1.94 text_going_down_normal

Texto a mostrar en eventos de módulos pasando a estado normal. Soporta las macros _module_ y _data_.

1.1.95 text_going_up_critical

Texto a mostrar en eventos de módulos pasando a estado crítico. Soporta las macros _module_ y _data_.

1.1.96 text_going_up_warning

Texto a mostrar en eventos de módulos pasando a estado de advertencia desde el estado normal. Soporta las macros _module_ y _data_.

1.1.97 text_going_down_warning

Texto a mostrar en eventos de módulos pasando a estado de advertencia desde el estado crítico. Soporta las macros _module_ y _data_.

1.1.98 text_going_unknown

Texto a mostrar en eventos de módulos pasando a estado desconocido. Soporta las macros _module_ y _data_.

1.1.99 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

1.1.100 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

1.1.101 (>= 5.X) snmp_forward_trap

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

1.1.102 (>= 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.

 


1.1.103 (>= 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

1.1.104 (>= 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

1.1.105 (>= 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

1.1.106 (>= 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

1.1.107 (>= 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

1.1.108 (>= 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

1.1.109 (>= 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

1.1.110 (>= 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

1.1.111 (>= 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).

1.1.112 (> 5.1) snmpconsole_threads

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

1.1.113 (> 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.

1.1.114 (> 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.

1.1.115 (>= 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.

1.1.116 (>= 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.

1.1.117 (>= 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.

1.1.118 (>= 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.

1.1.119 (>= 6.0) console_pass

Contraseña del usuario introducido anteriormente.

1.1.120 (>= 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.

1.1.121 (>= 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.

1.1.122 (>= 6.0) remote_config

(Sólo Pandora FMS Enterprise)

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.

1.1.123 (>= 6.0) remote_config_address

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

1.1.124 (>= 6.0) remote_config_port

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

1.1.125 (>= 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")

1.1.126 (> 6.0) warmup_event_interval

En segundos, especifica el tiempo que transcurrirá hasta que se vuelvan a generar eventos de cambios de estado y ejecutar alertas tras un reinicio del servidor.

1.1.127 (> 6.0) warmup_unknown_interval

En segundos, especifica el tiempo que transcurrirá hasta que los módulos puedan pasar a estado desconocido tras un reinicio del servidor.

1.1.128 (> 6.0SP4) enc_dir

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

1.1.129 (>= 7.0) dynamic_updates

Número de veces que se recalculan los umbrales dinámicos por intervalo dinámico.

1.1.130 (>= 7.0) dynamic_warning

Porcentaje relativo a la longitud del intervalo crítico utilizado para calcular los umbrales de warning. Cuanto más bajo, más cerca estarán los intervalos de warning y critical.

1.1.131 (>= 7.0) dynamic_constant

Porcentaje relativo a la media de un módulo que se utiliza para ajustar la desviación estándar de un módulo cuando los datos sean constantes. Un valor más alto resulta en intervalos dinámicos más anchos.

1.2 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

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

1.4 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


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

 


2 Consola WEB

La consola web de Pandora FMS tiene un fichero de configuración que se genera automáticamente durante la instalación. Su ubicación es: /consolepath/include/config.php. Por ejemplo en sistemas CentOS:

/var/www/html/pandora_console/include/config.php

2.1 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 de Pandora FMS. 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 donde se encuentra la base de datos de Pandora FMS. En instalaciones reducidas suele ser el mismo equipo donde está el servidor, esto es 127.0.0.1 o 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"]

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

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

3 Agentes software de Pandora FMS

3.1 Qué es un agente software

Como su nombre indica, son pequeñas piezas de software que se instalan en los sistemas operativos y permanecen ejecutándose en ellos para extraer información de monitorización y enviarla al servidor de Pandora FMS regularmente.

Utilizan los comandos y herramientas propias del sistema operativo en que están instalados para obtener la información. Conforman los datos en un fichero en formato XML y los envían al servidor de datos de Pandora FMS, que los procesa y almacena en la base de datos.

Cada uno de los chequeos individuales es denominado Módulo.

3.2 Introducción a la configuración del agente

El funcionamiento del agente software está determinado por su fichero de configuración, llamado pandora_agent.conf, ubicado en el directorio de instalación en sistemas Windows, y en /etc en sistemas Linux.

El fichero de configuración contiene todos los parámetros de funcionamiento y los módulos de ese agente.

3.3 Parámetros generales del agente

Los parámetros generales del agente de configuración aparecen definidos en esta sección. La mayoría son comunes para sistemas Windows y Linux.

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

 


3.3.1 server_ip

Dirección IP o nombre del servidor de Pandora FMS al que se enviarán los datos.

3.3.2 server_path

Ruta del servidor donde éste recibe los ficheros de datos enviados por los agentes. Por defecto /var/spool/pandora/data_in.

3.3.3 temporal

Ruta donde el agente almacena los ficheros de datos antes de que sean enviados al servidor y eliminados localmente.

3.3.4 description

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

3.3.5 group

Si existe un grupo con el nombre indicado en este parámetro, el agente se creará dentro de este grupo.

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

3.3.7 logfile

Ruta del log del agente de Pandora FMS.

3.3.8 interval

En segundos, tiempo de muestreo del agente. Cada vez que se complete este intervalo el agente recogerá información y la enviará al servidor de Pandora FMS.

3.3.9 disable_logfile

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

3.3.10 debug

Si se encuentra activo (1), los ficheros de datos del agente son almacenados y renombrados en el directorio temporal y no son eliminados tras enviarse al servidor, pudiendo abrir los archivos XML y analizar su contenido.

3.3.11 agent_name

Permite establecer un nombre personalizado. Si no se encuentra habilitado, el nombre del agente será el hostname de la máquina.

3.3.12 (>=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.

3.3.13 (>=7.0) agent_alias_cmd

Define el alias del agente utilizando un comando externo. Si agent_alias_cmd está definido, agent_alias 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.

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

3.3.15 encoding

Instala el tipo de codificación del sistema local, como por ejemplo iso-8859-15, o utf-8.

3.3.16 server_port

Puerto en el que el Tentacle del servidor de Pandora FMS escucha para recibir los archivos de datos. 41121 por defecto.

3.3.17 transfer_mode

Modo de transferencia de los archivos de datos al servidor de Pandora FMS. Tentacle por defecto.

3.3.18 (>= 6.0) transfer_timeout

Timeout para la transferencia de ficheros, si se supera el número de segundos indicado sin completar la transferencia, ésta será cancelada.

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

3.3.20 server_ssl

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

3.3.21 server_opts

Para añadir opciones adicionales al ejecutar el cliente de Tentacle en la transferencia de archivos. Utilizado para configuraciones avanzadas de Tentacle con opciones de seguridad.

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

3.3.22 delayed_startup

En minutos, tiempo de espera hasta que el agente empieza a funcionar una vez iniciado. Deshabilitado por defecto. Sólo válido en agentes Linux/Unix.

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

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

3.3.25 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. Desactivado por defecto.

3.3.26 remote_config

(Sólo Pandora FMS Enterprise)

Habilita (1) o deshabilita (0) la configuración remota de los agentes. Su funcionamiento solo se permite con el modo de transferencia Tentacle.

3.3.27 xml_buffer

Si se habilita (1), el agente guardará en su directorio temporal los ficheros XML que no haya podido enviar al servidor en caso de un problema de conectividad. Serán enviados cuando se restablezcan las comunicaciones.

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

3.3.29 parent_agent_name

Indica el padre del agente software. Debe ser el nombre de un agente existente en Pandora FMS.

3.3.30 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

3.3.31 include <fichero>

Permite incluir un fichero de configuración adicional. Este archivo puede incluir módulos y colecciones adicionales a las del archivo principal.

3.3.32 broker_agent <nombre>

Habilita la funcionalidad de agente broker. Para activarlo únicamente es necesario descomentar el parámetro e indicar el nombre que se asignará al agente broker:

broker_agent Nombre_broker

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

3.3.34 (>= 5.X) custom_id

Id personalizado del agente para aplicaciones externas.

3.3.35 (>= 5.X) url_address

URL personalizada para abrirla desde el agente en la consola.

3.3.36 (>= 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

3.3.37 (>= 5.X) custom_fieldX_value

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

Ejemplo:

custom_field1_value C1700

3.3.38 (> 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

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

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

3.3.40 (>= 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.

3.4 Servidor Secundario

Permite definir un servidor secundatio al que se le enviarán los datos en dos posibles situaciones dependiendo de la configuración:

  • 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

3.5 Servidor UDP

El agente de Pandora FMS puede configurarse 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, habitualmente 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.
  • 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.

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.

3.6 Definición de los módulos

Los módulos de ejecución local se definen en el fichero de configuración pandora_agent.conf. A continuación explicamos todos los parámetros que pueden aceptar.

La sintaxis general es la siguiente:

module_begin
module_name <Nombre Módulo>
module_type generic_data
module_exec <Comando local a ejecutar>
module_end 

Existen multitud de opciones adicionales para los módulos, en este ejemplo únicamente hemos utilizado las líneas comunes y obligatorias para la mayoría de ellos.

3.6.1 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 ya existe.

 


3.6.1.1 module_begin

Etiqueta de inicio de un módulo. Obligatorio.

3.6.1.2 module_name <nombre>

Nombre del módulo. No pueden existir dos módulos con el mismo nombre en el mismo agente. Obligatorio.

3.6.1.3 module_type <tipo>

Tipo de datos que devolverá el módulo. Obligatorio. Los tipos disponibles son:

  • Numérico (generic_data). Datos numéricos sencillos, con coma flotante o enteros.
  • 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.
  • Booleanos (generic_proc). Para valores que solo pueden ser correcto o afirmativo (1) o incorrecto o negativo (0). Útil para comprobar si un equipo está vivo, o un proceso o servicio está corriendo. Un valor negativo (0) trae preasignado el estado crítico, mientras que cualquier valor superior se considerará correcto.
  • Alfanumérico asíncrono (async_string). Para cadenas de texto de tipo asíncrono. La monitorización asíncrona depende de eventos o cambios que pueden ocurrir o no, por lo que este tipo de módulos nunca están en estado desconocido.
  • Booleano asíncrono (async_proc). Para valores booleanos de tipo asíncrono.
  • Numérico asíncrono (async_data). Para valores numéricos de tipo asíncrono.

3.6.1.4 module_min <valor>

Valor mínimo que el módulo debe devolver para que sea aceptado. En caso contrario será descartado y no se mostrará en la consola.

3.6.1.5 module_max <valor>

Valor máximo que el módulo debe devolver para que sea aceptado. En caso contrario será descartado y no se mostrará en la consola.

3.6.1.6 module_min_warning <valor>

Valor mínimo del umbral warning.

3.6.1.7 module_max_warning <valor>

Valor máximo del umbral warning.

3.6.1.8 module_min_critical <valor>

Valor mínimo del umbral critico.

3.6.1.9 module_max_critical <valor>

Valor máximo del umbral crítico.

3.6.1.10 module_disabled <valor>

Indica si el módulo esta habilitado (0) o deshabilitado (1).

3.6.1.11 module_min_ff_event <valor>

Valor de la protección flip flop para falsos positivos. Será necesario que se produzcan el número de cambios de estado indicados en este valor para que el módulo modifique visualmente su estado en la consola web.

3.6.1.12 (>= 6.0 SP4) module_each_ff <value>

Si está habilitado (1), se utilizarán los umbrales flip flop por estado (module_min_ff_event_normal, module_min_ff_event_warning y module_min_ff_event_critical) en vez de module_min_ff_event.

3.6.1.13 (>= 6.0 SP4) module_min_ff_event_normal <value>

Valor de la protección flip flop para paso a estado normal.

3.6.1.14 (>= 6.0 SP4) module_min_ff_event_warning <value>

Valor de la protección flip flop para paso a estado warning.

3.6.1.15 (>= 6.0 SP4) module_min_ff_event_critical <value>

Valor de la protección flip flop para paso a estado crítico.

3.6.1.16 (>= 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 el número de cambios de estado determinado en module_min_ff_event deberá ocurrir en un intervalo de module_ff_timeout segundos antes de que el estado cambie en la consola a nivel visual.

3.6.1.17 module_description <texto>

Texto libre con información sobre el módulo.

3.6.1.18 module_interval <factor>

Intervalo individual de módulo. Este valor es un factor multiplicador del intervalo del agente, no un tiempo libre. 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).

3.6.1.19 module_timeout <secs>

En segundos, tiempo máximo permitido para la ejecución del módulo. Si se supera este tiempo antes de haber finalizado su ejecución, será interrumpida.

3.6.1.20 module_postprocess <factor>

Valor numérico por el que se multiplicará el dato devuelto por el módulo. Útil para realizar conversiones de unidades.

3.6.1.21 module_save <nombre de variable>

Almacena el valor devuelto por el módulo en una variable con el nombre indicado en este parámetro. Este valor podrá ser utilizado posteriormente en otros módulos.

Por ejemplo:

module_begin
module_name echo_1
module_type generic_data
module_exec echo 41121
module_save ECHO_1
module_end

Almacenará el valor "41121" en la variable "ECHO_1".

module_begin
module_name echo_2
module_type generic_data
module_exec echo $ECHO_1
module_end

Este segundo móduo mostrará el contenido de la variable "$ECHO_1", siendo "41121".

3.6.1.22 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

3.6.1.23 module_condition <operación> <comando>

Permite definir acciones que serán ejecutadas por el agente en función del valor devuelto por el módulo. Solo disponible para valores numéricos. La sintaxis es la siguiente:

  • > [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. En el caso siguiente se ejecutará script_1.sh si el valor devuelto por el módulo se encuentra entre 1 y 3, y se ejecutará script_2.sh si el valor del módulo es superior a 5.5, por lo que en este caso, siendo el valor devuelto en la línea module_exec 2.5, se ejecutará únicamente la primera condición script_1.sh:

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 aplicados a posibles casos reales:

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

3.6.1.24 module_precondition <operación> <comando>

Permite determinar si se ejecuta o no el módulo dependiendo del resultado de una ejecución dada. La sintaxis es similar:

  • > [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.

En el siguiente ejemplo, sólo se ejecutará el módulo (monitoring_variable.bat) si el resultado de la ejecución indicada en la precondición se encuentra entre 2 y 8. En este caso el resultado de la ejecución indicada en la línea module_precondition es 5, valor que se encuentra entre 2 y 8, por lo que se ejecutará correctamente monitoring_variable.bat:

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 posible poner varias, y el módulo 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

3.6.1.25 (>= 5.x) module_unit <value>

Unidades que queremos mostrar junto al valor obtenido por el módulo.

Ejemplo:

module_unit %

3.6.1.26 (>= 5.x) module_group <value>

Permite indicar el grupo de módulos al que será asignado el módulo.

Ejemplo:

module_group Networking

3.6.1.27 (>= 5.x) module_custom_id <value>

Esta directiva es un identificador personalizado del módulo.

Ejemplo:

module_custom_id host101

3.6.1.28 (>= 5.x) module_str_warning <value>

Permite indicar una expresión regular para definir el umbral warning en módulos de tipo alfanumérico (string).

Ejemplo:

module_str_warning .*NOTICE.*

3.6.1.29 (>= 5.x) module_str_critical <value>

Permite indicar una expresión regular para definir el umbral crítico en módulos de tipo alfanumérico (string).

Ejemplo:

module_str_critical .*ERROR.*

3.6.1.30 (>= 5.x) module_warning_instructions <value>

A nivel informativo, indica instrucciones que se mostrarán en el evento generado por el módulo al pasar a estado warning.

Ejemplo:

module_warning_instructions Subir prioridad incidencia

3.6.1.31 (>= 5.x) module_critical_instructions <value>

A nivel informativo, indica instrucciones que se mostrarán en el evento generado por el módulo al pasar a estado crítico.

Ejemplo:

module_critical_instructions Llamar a departamento de sistemas

3.6.1.32 (>= 5.x) module_unknown_instructions <value>

A nivel informativo, indica instrucciones que se mostrarán en el evento generado por el módulo al pasar a estado desconocido.

Ejemplo:

module_unknown_instructions Abrir incidencia

3.6.1.33 (>= 5.x) module_tags <value>

Tags que se desean asignar al módulo, separadas por comas.

Ejemplo:

module_tags tag1,tag2,tag3

3.6.1.34 (>= 5.x) module_warning_inverse <value>

Permite activar (1) el intervalo inverso para el umbral warning.

Ejemplo:

module_critical_inverse 0

3.6.1.35 (>= 5.x) module_critical_inverse <value>

Permite activar (1) el intervalo inverso para el umbral crítico.

Ejemplo:

module_critical_inverse 1

3.6.1.36 (>= 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.

3.6.1.37 (>= 5.x) module_quiet <value>

Si se encuentra habilitado (1) el módulo estará en modo silencioso: no generará eventos ni disparará alertas, tampoco almacenará histórico de datos.

Ejemplo:

module_quiet 1

3.6.1.38 (>= 5.x) module_ff_interval <value>

Permite indicar un umbral flip flop en el módulo.

Ejemplo:

module_ff_interval 2

3.6.1.39 module_macro<macro> <value>

Solo aplicable en componentes locales desde la consola. No tiene utilidad en el fichero de configuración.

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

3.6.1.41 module_end

Etiqueta de final de módulo. Es obligatorio.

3.6.2 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 como tal. En cada módulo solo se puede utilizar uno de estos tipos.

3.6.2.1 module_exec <comando>

Línea general de ejecución de comando. Se debe especificar la ejecución deseada para obtener la información en una única línea.

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.

 


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

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



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

Esta funcionalidad no está soportada en los agentes broker.

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 bash está activo en el sistema, bastará con ejecutar:

module_begin
module_name Service_bash
module_type generic_proc
module_service /bin/bash
module_description Process bash running
module_end

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

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

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 parámetro module_proc. En este caso, el agente notifica inmediatamente cuando el proceso cambia de estado, sin esperar a que se cumpla el intervalo de ejecución 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". Esta funcionalidad no está soportada en los agentes broker.

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.

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 hasta que se reinicie el agente. Ilimitado por defecto.
  • module_startdelay: Número de milisegundos que el módulo esperará antes de lanzar el proceso por primera vez.
  • module_retrydelay: Número de milisegundos que el módulo esperará antes de intentar lanzar el proceso en cada reintento.

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.

3.6.2.4 module_cpuproc <process>

(Solo Unix)

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

3.6.2.5 module_memproc <process>

(Solo Unix)

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

3.6.2.6 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_begin
module_name freedisk
module_type generic_data
module_freedisk C:
module_end
module_begin
module_name disk_var
module_type generic_data
module_freedisk /var
module_end

3.6.2.7 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

3.6.2.8 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

3.6.2.9 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

3.6.2.10 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

3.6.2.11 module_freepercentmemory

Funciona tanto en Unix como en Windows. 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

3.6.2.12 module_tcpcheck

(Sólo Windows)

Este módulo intenta conectarse con la dirección IP y puerto especificados. Devuelve 1 si tuvo éxito y 0 en caso contrario. 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

3.6.2.13 module_regexp

(Sólo Windows)

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]


3.6.2.14 module_wmiquery

(Sólo Windows)

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

3.6.2.15 module_perfcounter

(Sólo Windows)

Obtiene los datos del contador de rendimiento (performance counter http://msdn.microsoft.com/en-us/library/aa373083(v=vs.85).aspx) 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. Además cada fabricante incorpora sus propios contadores.

Podemos observar los contadores de rendimiento mediante la herramienta Rendimiento (Performance):



Perfcounter screen1.png



Es posible añadir contadores de rendimiento nuevos mediante la herramienta del sistema. Su configuración tiene estructura gerárquica con elementos y subelementos. En este caso Procesador, % de tiempo de procesador y _Total:



Perfcounter screen2.png



La configuración del módulo para este chequeo en particular sería la siguiente:

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.

3.6.2.16 module_inventory DEPRECATED

Template warning.png

Actualmente esta funcionalidad ha sido sustituida por inventario desde plugins de agente tanto en sistemas Windows como Linux/Unix.

 


(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

3.6.2.17 module_logevent

(Sólo Windows)

Permite obtener información del log de eventos de Windows basándose en los patrones indicados, permitiendo filtrar en función de la fuente y el tipo de evento.

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.

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

  • module_source: Origen del evento (System, Application, Security). Campo obligatorio.
  • module_eventtype: Tipo de evento (error, information...). Campo opcional.
  • module_pattern: Patrón a buscar (subcadena). Campo opcional.
  • module_eventcode: ID numerico del evento, p.e: 5112. 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

3.6.2.18 module_plugin

Para la ejecución de plugins de agente. Es un caso especial ya que no requiere de ninguna otra etiqueta tipo module_begin o module_end, y tampoco indicar el tipo de módulo.

Su formato tendrá este aspecto:

module_plugin plugin_filename parámetro_1 parámetro_2 parámetro_3

No obstante es posible emplearlo entre las etiquetas habituales de módulos para añadir opciones adicionales como condiciones o intervalo:

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

Los parámetros a utilizar serán diferentes para cada plugin, por lo que será necesario remitirse a su documentación particular. Vamos a describir el funcionamiento de uno de los plugins que vienen por defecto con el Agente, el plugin grep_log para buscar coincidencias en un fichero:

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"

3.6.2.19 module_ping <host>

(Sólo Windows)

Este módulo hace un ping al host dado y devuelve 1 si está arriba.

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

3.6.2.20 module_snmpget

(Sólo Windows)

Este módulo ejecuta una consulta SNMP get y devuelve el valor solicitado.

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

3.7 Agentes Unix/Linux

3.7.1 Configuración de los agentes Unix de Pandora FMS

Las rutas y directorios fundamentales a tener en cuenta son:

  • /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
  • /etc/pandora/pandora_agent.conf: Fichero principal de configuración del agente. Los módulos de ejecución local y plugins de agente se configuran aquí.
  • /usr/local/bin/pandora_agent: Binario ejecutable del agente. Generalmente tiene un enlace a /usr/bin/pandora_agent
  • /usr/local/bin/tentacle_client: Binario ejecutable de tentacle, para la transferencia de ficheros hacia el servidor. Generalmente tiene un enlace a /usr/bin/tentacle_client.
  • /etc/init.d/pandora_agent_daemon: Script de inicio/parada/reinicio. 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.
  • /etc/pandora/collections: Directorio que contiene las colecciones desplegadas al agente. Está enlazado al directorio /usr/share/pandora_agent/collections.

3.7.2 Ejecución inicial del agente Unix

Para iniciar el agente es únicamente necesario ejecutar:

/etc/init.d/pandora_agent_daemon start

Para detener el agente, ejecute:

/etc/init.d/pandora_agent_daemon stop

Este script de arranque podrá iniciar o detener el agente de Pandora FMS, que al iniciarse quedará por defecto corriendo en el sistema como un demonio.

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

Como vimos en la sección de configuración, existen algunos módulos que obtienen la información de forma predefinida sin necesidad de indicar un comando con module_exec. Estos módulos son:

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

Es posible modificar el funcionamiento de estos módulos por defecto editando directamente el ejecutable del agente (por defecto /usr/bin/pandora_agent). El agente de Pandora FMS está ubicado generalmente en /usr/bin/pandora_agent. Buscando la cadena "Commands to retrieve" llegamos a la parte de código que contiene los comandos internos. Podemos hacer las modificaciones que necesitemos para adaptarlos a nuestro sistema.

# 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}\
};

# 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}\
};

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}\'

3.8 Agentes Windows de Pandora FMS

3.8.1 Configuración del agente de Windows de Pandora FMS

Las rutas y directorios fundamentales en las instalaciones del agente Windows se encontrarán en el propio directorio donde se haya instalado el agente, por defecto C:\Program Files. Los más importantes a tener en cuenta son:

  • C:\Program Files\pandora_agent: donde se instala el agente de Pandora FMS, su ejecutable y sus directorios.
  • C:\Program Files\pandora_agent\pandora_agent.conf: Fichero principal de configuración del agente. Los módulos de ejecución local y plugins de agente se configuran aquí.
  • C:\Program Files\pandora_agent\PandoraAgent.exe: Binario ejecutable del agente.
  • C:\Program Files\pandora_agent\util\tentacle_client.exe: Binario ejecutable de tentacle, para la transferencia de ficheros hacia el servidor.
  • C:\Program Files\pandora_agent\scripts: Scripts de inicio/parada/reinicio del agente de Pandora FMS.
  • C:\Program Files\pandora_agent\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.
  • C:\Program Files\pandora_agent\util: Directorio que contiene los plugins de agente.
  • C:\Program Files\pandora_agent\collections: Directorio que contiene las colecciones desplegadas al agente.

3.9 Auto-actualización de los agentes software

Utilizando las colecciones de archivos y la herramienta pandora_update 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 ejecuta el plugin pandora_update. Este plugin recibe un único parámetro: el nombre corto de la colección (en este ejemplo, fc_1). Analizará el directorio de la colección buscando el instalador del agente, comparará el instalador ubicado en la colección con el que se encuentra corriendo en ese momento y si son diferentes, pandora_update detiene el agente, reemplaza el binario y reinicia 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

3.10 Monitorización extendida con agentes software

Los agentes software tienen dos modos de trabajo que pueden ayudarnos a extender la monitorización a redes remotas. Estos dos modos de trabajo son:

  • Modo Proxy
  • Modo Broker

Cuando el agente software está funcionando en cualquiera de estos dos modos de trabajo sigue teniendo todas las funcionalidades habituales de cualquier agente software.

La siguiente imagen es un ejemplo de la arquitectura de Pandora FMS usando estas funcionalidades de los agentes (en la imagen Drone Agents):

Architecture il1.png

3.10.1 Modo Proxy

El modo proxy permite establecer un agente software como punto intermedio para que otros agentes software puedan enviar sus ficheros de datos al proxy y que éste los reenvíe al servidor principal de Pandora FMS. Útil en casos en los que los agentes software no tienen comunicación directa con el servidor.

Los parámetros de configuración 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.
Proxy-mode.png


Modelo de despliegue en redes remotas usando el modo proxy del agente


3.10.2 Modo Broker

El modo broker permite separar un único agente software en varios dentro de la misma máquina. Las aplicaciones 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.

Por cada agente broker creado en la máquina aparecerá un nuevo fichero de configuración, desde el que se gestionará cada uno de los broker.

El parámetro de configuración que necesitamos modificar para crear un agente broker a partir de un agente software es:

  • broker_agent: Incluyendo este parámetro tantas veces como necesitemos seguido del nombre que tendrá el agente broker nos permitirá crear los agentes broker que necesitemos.


Modo-broker.png


Modelo de despliegue en redes remotas no accesibles en modo broker


3.11 Autocreación de agentes y modulos desde XML

Los agentes pueden configurarse desde la consola en tres modos de trabajo:

  • Modo aprendizaje: Si el XML recibido del agente software contiene nuevos módulos, éstos serán automáticamente creados. Este es el comportamiento por defecto.
  • Modo normal: No se crearán nuevos módulos que lleguen en el XML si no han sido declarados previamente en la consola.
  • Modo autodeshabilitado: Similar al modo aprendizaje, en este modo, además, si todos los módulos pasan a estado desconocido el agente se deshabilitará automáticamente, pasando a habilitarse de nuevo si recibe nueva información.



Learning mode.png

3.11.1 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 de forma automática al recibir un XML son los siguientes:

  • Nombre de agente
  • IP de agente
  • Descripcion del agente.
  • Agente padre.
  • Timezone offset.
  • Grupo.
  • Sistema operativo.
  • Intervalo.
  • Agent version
  • Custom fields.
  • Custom ID.
  • Dirección URL.
  • Agent mode: Learning, Normal, Autodisable.

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

  • Dirección IP del agente.
  • Padre del agente.
  • Version SO.
  • Version agente.
  • Zona horaria.
  • Custom fields.

Info.png

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

 


Además, con modo aprendizaje activado se crearán nuevos módulos en Pandora al ser recibidos a través de XMLs.

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

  • Nombre.
  • Tipo.
  • Descripción.
  • Máximo, Mínimo.
  • Post proceso.
  • Intervalo del módulo.
  • Min/max Critical.
  • Min/max Warning.
  • Desactivado.
  • 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.
  • Crontab.

3.11.4 Datos que se actualizan de un módulo ya existente al recibir un XML

Cuando se recibe un XML que contiene información de un módulo ya existente, únicamente se actualiza la descripción y la información extendida, además del dato del módulo.

Volver a Indice de Documentacion Pandora FMS