Difference between pages "Pandora: Documentation es: Configuracion Agentes" and "Pandora: Documentation es: Monitorizacion logs"

From Pandora FMS Wiki
(Difference between pages)
Jump to: navigation, search
 
(Instalación y configuración de LogStash)
 
Line 1: Line 1:
 
[[Pandora:Documentation|Volver a Indice de Documentacion Pandora FMS]]
 
[[Pandora:Documentation|Volver a Indice de Documentacion Pandora FMS]]
  
= Agentes software de Pandora FMS =
+
= Recolección de logs =
  
== Qué es un agente software ==
+
==Introducción==
  
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.
+
Hasta ahora Pandora FMS no tenía una solución a este problema, pero con la versión 5.0 '''Pandora FMS Enterprise''' ofrece una solución para poder gestionar cientos de megabytes de datos diarios. Esta solución permite reutilizar los mismos agentes de la monitorización para la recolección específica de datos de logs, utilizando una sintaxis muy similar a la actual para la monitorización de logs.
  
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.
+
La monitorización de logs en Pandora FMS se plantea de dos formas diferentes:
 +
#'''Basada en módulos''': representa logs en Pandora FMS como monitores asíncronos, pudiendo asociar alertas a las entradas detectadas que cumplan una serie de condiciones preconfiguradas por el usuario. La representación modular de los logs nos permite:
 +
##Crear módulos que cuenten las ocurrencias de una expresión regular en un log.
 +
##Obtener las líneas y el contexto de los mensajes de log
 +
#'''Basada en visualización combinada''': permite al usuario visualizar en una única consola toda la información de logs de múltiples orígenes que se desee capturar, organizando la información secuencialmente utilizando la marca de tiempo en que se procesaron los logs.
  
Cada uno de los chequeos individuales es denominado ''Módulo''.
+
A partir de la versión 7.0NG 712, Pandora FMS incorpora '''ElasticSearch''' para almacenar la información de logs, lo que implica una mejora sustancial del rendimiento.
 +
<br><br>
  
== Introducción a la configuración del agente ==
+
== Cómo funciona ==
 +
El proceso es simple:
  
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.
+
<center><br><br>
 +
[[Image:LogsEsquema.png|650px]]
 +
</center><br><br>
  
El fichero de configuración contiene todos los parámetros de funcionamiento y los módulos de ese agente.
+
* Los logs analizados por los agentes ('''eventlog''' o ficheros de texto), son reenviados hacia el servidor de Pandora FMS, en forma "literal" (RAW) dentro del XML de reporte del agente:
  
== Parámetros generales del agente ==
+
* El servidor de Pandora FMS (DataServer) recibe el XML del agente, que contiene información tanto de monitorización como de logs.
  
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.  
+
* Cuando el DataServer procesa los datos del XML identifica la información de los logs, guardando en la base de datos principal las referencias del agente que ha reportado y el origen del log, enviando automáticamente la información a ElasticSearch.
  
{{warning|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: '''versión''', '''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'''}}
+
* Pandora FMS almacena los datos en índices de ElasticSearch generando diariamente un índice único por cada instancia de Pandora FMS.
  
 +
* El servidor de Pandora FMS dispone de una tarea de mantenimiento que elimina los índices en el intervalo definido por el administrador del sistema (por defecto, 90 días).
  
{{warning|'''La codificación del archivo de configuración del agente es UTF-8''' tanto en sistemas Linux como Windows. Si realiza ediciones a mano de este fichero verifique que la codificación es correcta antes de sobreescribirlo. Si la codificación no es UTF-8 y usted utiliza símbolos (como tildes o símbolos extendidos), el agente interpretará erróneamente estos, no pudiendo garantizar una correcta interpretación de su configuración.}}
+
== Configuración ==
  
 +
=== Configuración del servidor ===
  
===server_ip===
+
El nuevo sistema de almacenamiento de logs, basado en ElasticSearch, requiere configurar los diferentes componentes.
  
Dirección IP o nombre del servidor de Pandora FMS al que se enviarán los datos.
+
{{Warning|A partir de la versión 745 de Pandora FMS ya no es necesario el uso de LogStash, ya que el servidor de Pandora FMS se comunica directamente con el servidor de ElasticSearch, por lo que las configuraciones relativas a LogStash no deberán aplicarse.}}
  
===server_path===
+
==== Requisitos para el servidor ====
  
Ruta del servidor donde este recibe los ficheros de datos enviados por los agentes. Por defecto ''/var/spool/pandora/data_in''.
+
Es posible distribuir cada componente (Pandora FMS Server, ElasticSearch) en servidores independientes.
  
===temporal===
+
Si decide alojar ElasticSearch y LogStash en el mismo servidor, recomendamos:
  
Ruta donde el agente almacena los ficheros de datos antes de que sean enviados al servidor y eliminados localmente.
+
* Centos 7.
 +
* Al menos 4GB de RAM, aunque se recomiendan 6GB de RAM por cada instancia de ElasticSearch.
 +
* Al menos 2 CPU cores.
 +
* Al menos 20 GB de espacio en disco para el sistema.
 +
* Al menos 50 GB de espacio en disco para los datos de ElasticSearch (el número puede variar dependiendo de la cantidad de datos que se desee almacenar).
 +
* Conectividad desde el servidor y la consola de Pandora FMS a la API de ElasticSearch (por defecto puerto 9200/TCP ).
  
===description===
+
<br><br>
 +
==== Instalación y configuración de ElasticSearch ====
 +
Antes de empezar con la instalación de estos componentes es necesaria la instalación de Java en la máquina:
  
Envía la descripción del agente en el XML, y Pandora FMS importa esta descripción cuando crea el agente.
+
yum install java
  
===group===
+
Una vez instalado Java, instalar ElasticSearch siguiendo la documentación oficial: https://www.elastic.co/guide/en/elasticsearch/reference/7.6/install-elasticsearch.html
  
Si existe un grupo con el nombre indicado en este parámetro, el agente se creará dentro de este grupo a no ser que el servidor fuerce la creación de todos los agentes en un grupo determinado.
+
En caso de una instalación en sistemas CentOS/Red Hat, la instalación recomendada es por medio de rpm: https://www.elastic.co/guide/en/elasticsearch/reference/7.6/rpm.html
  
===temporal_min_size===
+
Configurar el servicio:
  
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.
+
Configuraremos las opciones de red y, opcionalmente, las ubicaciones de datos (y logs del propio ElasticSearch) en el fichero de configuración ubicado en ''/etc/elasticsearch/elasticsearch.yml''
  
===logfile===
+
# ---------------------------------- Network -----------------------------------
 +
# Set the bind address to a specific IP (IPv4 or IPv6):
 +
http.host: 0.0.0.0
 +
# Set a custom port for HTTP:
 +
http.port: 9200
 +
# ----------------------------------- Paths ------------------------------------
 +
# Path to directory where to store the data (separate multiple locations by comma):
 +
path.data: /var/lib/elastic
 +
# Path to log files:
 +
path.logs: /var/log/elastic
  
Ruta del log del agente de Pandora FMS.
 
  
===interval===
+
Será necesario descomentar y definir también las siguientes líneas como siguen:
  
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.
+
cluster.name: elkudemy
 +
node.name: ${HOSTNAME}
 +
bootstrap.memory_lock: true
 +
network.host: ["127.0.0.1", “IP"]
  
===disable_logfile===
+
* <b>cluster.name</b>: Será el nombre que recibirá el cluster.
 +
* <b>node.name</b>: Para nombrar el nodo, con ${HOSTNAME} tomará el nombre del host.
 +
* <b>bootstrap.memory_lock</b>: Siempre deberá ser "true".
 +
* <b>network.host</b>: La IP del servidor.
  
Inhabilita la escritura en pandora_agent.log. Solo para Windows.
+
Habrá que determinar las opciones de recursos asignados a ElasticSearch, ajustando los parámetros disponibles en el fichero de configuración ubicado en ''/etc/elasticsearch/jvm.options''. Se recomienda utilizar al menos 2GB de espacio en XMS.  
  
===debug===
+
# Xms represents the initial size of total heap space
 +
# Xmx represents the maximum size of total heap space
 +
-Xms2g
 +
-Xmx2g
  
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.
+
La asignación de recursos se asignará en función del uso que se quiera dar a ElasticSearch. Recomendamos seguir la documentación oficial de ElasticSearch: https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html
  
===agent_name===
+
Iniciar el servicio:
  
Permite establecer un nombre personalizado. Si no se encuentra habilitado, el nombre del agente será el hostname de la máquina.
+
systemctl start elasticsearch
  
===(>=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 línea solo se utilizará la primera.
+
<b>Nota:</b> Si el servicio no consigue iniciarse, revise los logs ubicados en /var/log/elasticsearch/
  
===(>=7.0) agent_alias_cmd===
+
Para comprobar la instalación de ElasticSearch bastará con ejecutar el siguiente comando:
  
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 línea solo se utilizará la primera.
+
curl -q http://{IP}:9200/
  
===address===
+
Que debería ofrecer una respuesta similar a la siguiente:
  
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.
+
{
 +
  "name" : "3743885b95f9",
 +
  "cluster_name" : "docker-cluster",
 +
  "cluster_uuid" : "7oJV9hXqRwOIZVPBRbWIYw",
 +
  "version" : {
 +
    "number" : "7.6.2",
 +
    "build_flavor" : "default",
 +
    "build_type" : "docker",
 +
    "build_hash" : "ef48eb35cf30adf4db14086e8aabd07ef6fb113f",
 +
    "build_date" : "2020-03-26T06:34:37.794943Z",
 +
    "build_snapshot" : false,
 +
    "lucene_version" : "8.4.0",
 +
    "minimum_wire_compatibility_version" : "6.8.0",
 +
    "minimum_index_compatibility_version" : "6.0.0-beta1"
 +
  },
 +
  "tagline" : "You Know, for Search"
 +
}
  
===encoding===
 
  
Instala el tipo de codificación del sistema local, como por ejemplo iso-8859-15, o utf-8.
+
<br><br>
  
===server_port===
+
==== Instalación y configuración de LogStash ====
  
Puerto en el que el Tentacle del servidor de Pandora FMS escucha para recibir los archivos de datos. 41121 por defecto.
+
{{Warning|A partir de la versión 745 de Pandora FMS <b>no</b> es necesaria la instalación de LogStash.}}
  
===transfer_mode===
+
Instalar LogStash 5.6.2 desde el RPM descargable de la página web del proyecto ElasticSearch:  https://artifacts.elastic.co/downloads/logstash/logstash-5.6.2.rpm
  
Modo de transferencia de los archivos de datos al servidor de Pandora FMS. Tentacle por defecto.
+
Una vez descargado el paquete, lo instalamos ejecutando:
  
=== (>= 6.0) transfer_timeout ===
+
rpm -i logstash-X.X.X.rpm
  
Timeout para la transferencia de ficheros, si se supera el número de segundos indicado sin completar la transferencia, esta será cancelada.
+
Configurar el servicio:
  
===server_pwd===
+
Dentro de la configuración de Logstash existen tres bloques de configuración:
 +
* Input: indica cómo le llega la información a Logstash, formato, puerto y un identificador que se utilizará para almacenar la información internamente en Elastic.
 +
* Filter: es posible agregar un post-procesado aquí, pero para nuestro caso no será necesario, por lo que lo dejaremos vacío.
 +
* Output: aquí viene la configuración de la IP y puerto donde estará escuchando ElasticSearch; es el sitio donde se guardará la información procesada por Logstash.
  
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.
+
Fichero de configuración:
 
===server_ssl===
 
  
Específica para el modo de transferencia Tentacle. Permite habilitar (1) o deshabilitar (0) el cifrado de las conexiones mediante SSL.  
+
/etc/logstash/conf.d/logstash.conf
  
===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.
+
Ejemplo de fichero de configuración:
  
Desde la versión 3.2 de los agentes, el cliente de Tentacle soporta una opción 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 opción (ejemplo):
+
# This input block will listen on port 10514 for logs to come in.
 +
# host should be an IP on the Logstash server.
 +
# codec => "json" indicates that we expect the lines we're receiving to be in JSON format
 +
# type => "rsyslog" is an optional identifier to help identify messaging streams in the pipeline.
 +
input {
 +
  tcp {
 +
    host  => "0.0.0.0"
 +
    port  => 10516
 +
    codec => "json"
 +
    type  => "pandora_remote_log_entry"
 +
  }
 +
}
 +
# This is an empty filter block.  You can later add other filters here to further process
 +
# your log lines
 +
filter { }
 +
output {
 +
  elasticsearch { hosts => ["0.0.0.0:9200"] }
 +
}
  
server_opts -y user:[email protected].inet:8080
+
En los apartados de "host" debemos introducir la IP del servidor en lugar de “0.0.0.0”.
  
Esta opción 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:
+
En el archivo "logstash-sample.conf" deberemos cambiar también "localhost", donde debe introducirse la IP del servidor.
  
server_opts -y 192.168.1.2:9000
+
Iniciar el servicio:
  
===delayed_startup===
+
systemctl start logstash
  
En segundos, tiempo de espera hasta que el agente empieza a funcionar una vez iniciado. Deshabilitado por defecto. Sólo válido en agentes Linux/Unix.
 
  
===pandora_nice===
+
<b>Nota</b> Si está intentando instalar LogStash en Centos 6 en contra de nuestra recomendación, puede iniciarlo con el siguiente comando:
  
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.
+
initctl start logstash
  
===autotime===
+
==== Parámetros de configuración en Pandora FMS Server ====
  
Si está habilitado (1) envía 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.
+
{{Warning|A partir de la versión 745 de Pandora FMS no será necesario configurar el fichero de configuración del servidor, ya que toda la configuración se realizará desde la consola al habilitar la recolección de logs.}}
  
===cron_mode===
+
Será necesario agregar la siguiente configuración al archivo de configuración de Pandora FMS Server (/etc/pandora/pandora_server.conf) para que Pandora FMS DataServer procese la información de logs.
  
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.
+
'''Importante''': Todo log que llegue a Pandora FMS sin tener activa esta configuración será '''descartado'''.
  
===remote_config===
+
logstash_host eli.artica.lan
 +
logstash_port 10516
  
(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.
 
  
===xml_buffer===
+
==== Pandora FMS SyslogServer ====
  
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.
+
A partir de la actualización 717 de Pandora FMS 7.0NG aparece un nuevo componente: SyslogServer.
  
===timezone_offset===
+
Este componente permite a Pandora FMS analizar el syslog de la máquina donde está ubicado, analizando su contenido y almacenando las referencias en nuestro servidor de ElasticSearch.
  
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.  
+
La ventaja principal del SyslogServer consiste en complementar la unificación de logs. Apoyándose en las características de exportado de Syslog de los entornos Linux y Unix, SyslogServer permite la consulta de logs independientemente del origen, buscando en un único punto común (visor de logs de la consola de Pandora FMS).
  
# Timezone offset: Difference with the server timezone
+
La instalación de Syslog se realizará tanto en cliente como en servidor, y para ejecutarla será necesario lanzar el siguiente comando:  
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-5, timezone_offset debería ser 6 = 1 - (-5).
+
yum install rsyslog
  
===parent_agent_name===
+
Una vez instalado Syslog en los equipos con los que queramos trabajar, será importante tener en cuenta que habrá que acceder al fichero de configuración para habilitar el input '''TCP''' y '''UDP'''.
  
Indica el padre del agente software. Debe ser el nombre de un agente existente en Pandora FMS.
+
/etc/rsyslog.conf
  
===agent_threads===
+
Tras realizar este ajuste será necesario detener y volver a arrancar el servicio '''rsyslog'''.
  
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.  
+
Una vez el servicio vuelva a estar corriendo, podemos realizar una comprobación de puertos para ver que el '''514''' está accesible.  
 
# Number of threads to execute modules in parallel
 
agent_threads 4
 
  
===include <fichero>===
+
netstat -ltnp
  
Permite incluir un fichero de configuración adicional. Este archivo puede incluir módulos y colecciones adicionales a las del archivo principal. El fichero lo podrán subir aquellos usuarios que tengan permisos de, al menos, escritura sobre agentes(AW).
+
Después de activar el servicio y comprobar los puertos, debemos configurar el cliente para que pueda enviar los logs al servidor. Para ello accederemos una vez más al fichero de configuración de '''rsyslog'''.  
  
===broker_agent <nombre>===
+
/etc/rsyslog.conf
  
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:
+
Será necesario localizar y habilitar la línea que permite configurar el host remoto. Habrá que especificar qué queremos enviar, con lo que quedará como sigue:  
  
  broker_agent Nombre_broker
+
  *.* @@remote-host:514
 
+
<br>
===pandora_user <usuario>===
+
{{Tip|El envío de logs genera un agente contenedor con el nombre del cliente por lo que se recomienda crear los agentes con '''alias as name'''” haciendo que coincida con el hostname del cliente, así se evitará duplicidad en los agentes.}}
 
 
Este parámetro es opcional y permitirá ejecutar el agente con el usuario del sistema que se especifique. Este usuario deberá contar con los permisos para poder ejecutar el agente y sus recursos asociados.
 
 
 
===(>= 5.X) custom_id===
 
 
 
Id personalizado del agente para aplicaciones externas.
 
 
 
===(>= 5.X) url_address===
 
 
 
URL personalizada para abrirla desde el agente en la consola.
 
 
 
===(>= 5.X) custom_fieldX_name===
 
 
 
Nombre de un campo personalizado de agentes que ya exista en el sistema. Si no existe, se ignorará.
 
 
 
Ejemplo:
 
 
 
custom_field1_name Model
 
 
 
===(>= 5.X) custom_fieldX_value===
 
 
 
Valor para el custom field X definido en el parámetro anterior.
 
 
 
Ejemplo:
 
 
 
custom_field1_value C1700
 
 
 
=== (> 5.1 Unix agent only) macro<macro> <value> ===
 
 
 
Define una macro de ejecución local que se puede utilizar en la definición de un módulo. Estas macros se utilizan en el sistema de la Metaconsola y en el sistema de componentes de módulos locales para "abstraer" la dificultad de usar un módulo editando directamente el código, 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 ejecución locales comienzan por _fieldx_
 
 
 
Ejemplo:
 
 
 
<pre>
 
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
 
</pre>
 
 
 
=== (>= 6.0SP5) group_password <contraseña> ===
 
Contraseña para el grupo del agente. Dejar comentado si el grupo no está protegido por contraseña.
 
 
 
=== (>= 7.0) ehorus_conf <path> ===
 
 
 
Ruta absoluta a un fichero de configuración válido de un agente de [https://ehorus.com/es eHorus]. El agente creará un campo personalizado llamado ''eHorusID'' que contiene la clave de identificación del agente de eHorus.
 
 
 
 
 
 
 
=== (>= 7.0OUM713) transfer_mode_user <usuario> ===
 
 
 
Usuario de los ficheros copiados en el modo de transferencia local. En las carpetas de la consola este usuario debe tener permisos de lectura y escritura para que funcione correctamente la configuración remota. Por defecto es ''apache''.
 
 
 
=== (>= 7.0OUM721) secondary_groups <grupos secundarios> ===
 
 
 
Nombre de los grupos secundarios asignados al agente. Se pueden especificar varios grupos secundarios separados por comas. Si alguno de los grupos no existe en el servidor al que se envía la información, no se asignará ese grupo, pero no se verá afectada la creación del agente.
 
 
 
=== (>= 7.0OUM728) standby <1|0> ===
 
 
 
Si un agente tiene modo standby 1, el agente no realizará ningún chequeo ni enviará ni generará ningún XML. Esta directiva de configuración tiene sentido en instalaciones Enterprise donde hay configuración remota. Gracias a ello, se puede silenciar un agente a voluntad con solo deshabilitarlo.
 
 
 
El modo debug sobreescribe esta funcionalidad y el agente se ejecuta normalmente.
 
 
 
== Servidor Secundario ==
 
 
 
Se puede definir un servidor secundario 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
 
 
 
== 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.
 
 
 
== 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.
 
 
 
=== Elementos comunes de todos los módulos ===
 
 
 
{{warning|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.}}
 
 
 
==== module_begin ====
 
 
 
Etiqueta de inicio de un módulo. Obligatorio.
 
 
 
==== module_name <nombre> ====
 
 
 
Nombre del módulo. No pueden existir dos módulos con el mismo nombre en el mismo agente. Obligatorio.
 
 
 
==== 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.
 
  
==== module_min <valor> ====
+
Para más información de la configuración de rsyslog, visitar la web oficial: https://www.rsyslog.com/
  
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.
+
Para activar esta funcionalidad simplemente tendremos que habilitarlo en la configuración, agregando a pandora_server.conf el siguiente contenido:
  
==== 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.
+
# Enable (1) or disable (0) the Pandora FMS Syslog Server (PANDORA FMS ENTERPRISE ONLY).
 +
syslogserver 1
 +
# Full path to syslog's output file (PANDORA FMS ENTERPRISE ONLY).
 +
syslog_file /var/log/messages
 +
# Number of threads for the Syslog Server (PANDORA FMS ENTERPRISE ONLY).
 +
syslog_threads 2
 +
# Maximum number of lines queued by the Syslog Server's producer on each run (PANDORA FMS ENTERPRISE ONLY).
 +
syslog_max 65535
  
==== module_min_warning <valor> ====
 
  
Valor mínimo del umbral warning.
+
Necesitará un servidor LogStash/ElasticSearch habilitado y configurado; por favor, revise los puntos precedentes para saber cómo configurarlo.
  
==== module_max_warning <valor> ====
+
'''syslogserver''' Booleano, habilita (1) o deshabilita (0) el motor de análisis de SYSLOG local.
  
Valor máximo del umbral warning.
+
'''syslog_file''' Ubicación del fichero donde se están entregando las entradas de los SYSLOG.
  
==== module_min_critical <valor> ====
+
''' syslog_threads''' Número de hilos máximo que se utilizarán en el sistema productor/consumidor del SyslogServer.
  
Valor mínimo del umbral crítico.
+
'''syslog_max''' Es la ventana de procesado máxima para SyslogServer; será el número máximo de entradas del SYSLOG que se procesarán en cada iteración.
  
==== module_max_critical <valor> ====
+
{{Warning|Es necesario que modifique la configuración de su dispositivo para que los logs se envíen al servidor de Pandora FMS.}}
  
Valor máximo del umbral crítico.
+
==== Recomendaciones ====
  
==== module_disabled <valor> ====
+
===== Rotación de logs para ElasticSearch y Logstash =====
  
Indica si el módulo esta habilitado (0) o deshabilitado (1).
+
'''Importante''': como recomendación, crear una nueva entrada para el demonio de rotado de logs en /etc/logrotate.d, para evitar que los logs de ElasticSearch o LogStash crezcan sin medida:
  
==== module_min_ff_event <valor> ====
+
cat > /etc/logrotate.d/elastic <<EOF
 +
/var/log/elastic/elaticsearch.log
 +
/var/log/logstash/logstash-plain.log {
 +
        weekly
 +
        missingok
 +
        size 300000
 +
        rotate 3
 +
        maxage 90
 +
        compress
 +
        notifempty
 +
        copytruncate
 +
}
 +
EOF
  
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.
+
===== Purgado de índices =====
  
==== (>= 6.0 SP4) module_each_ff <value> ====
+
Puede consultar en todo momento el listado de índices y el tamaño que ocupan lanzando una petición cURL contra su servidor ElasticSearch:
  
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.
+
curl -q <nowiki>http://elastic:9200/_cat/indices?</nowiki>
  
==== (>= 6.0 SP4) module_min_ff_event_normal <value> ====
+
Donde "elastic" se refiere a la IP del servidor.
  
Valor de la protección ''flip flop'' para paso a estado normal.
+
Para eliminar cualquiera de estos índices puede ejecutar la orden DELETE:
  
==== (>= 6.0 SP4) module_min_ff_event_warning <value> ====
+
curl -q -XDELETE <nowiki>http://elastic:9200/{index-name}</nowiki>
  
Valor de la protección ''flip flop'' para paso a estado warning.
+
Donde "elastic" se refiere a la IP del servidor, e "{index-name}" es el fichero de salida del comando anterior.
  
==== (>= 6.0 SP4) module_min_ff_event_critical <value> ====
+
Esta operación liberará el espacio utilizado por el índice eliminado.
  
Valor de la protección ''flip flop'' para paso a estado crítico.
+
=== Configuración de la consola ===
 +
Para activar el sistema de visualización de logs deberá activar la siguiente configuración:
  
==== (>= 6.0 SP4) module_ff_timeout <seconds> ====
+
<br><center>
 +
[[image:Logs1.JPG|850px]]
 +
<br></center>
  
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.
+
Luego podemos configurar el comportamiento del visor de logs en la pestaña 'Log Collector':
  
==== (>= 734) module_ff_type <valor> ====
+
<br><center>
 +
[[image:Logs2.JPG|850px]]
 +
<br></center>
  
Se trata de una opción avanzada del Flip Flop para el control de estado de un módulo. Mediante “keep counters” estableceremos unos valores de contador para pasar de un estado a otro dependiendo, en lugar del valor, del estado del módulo con el valor recibido.
+
En esta pantalla podremos configurar:
  
Indica si Keep counters esta habilitado (1) o deshabilitado (0).
+
* Dirección IP o FQDN del servidor que aloja el servicio ElasticSearch
  
==== module_description <texto> ====
+
* Puerto a través del que se está prestando el servicio ElasticSearch
  
Texto libre con información sobre el módulo.
+
* Número de logs mostrados: Para agilizar la respuesta de la consola se ha añadido la carga dinámica de registros. Para usarla, el usuario debe hacer scroll hasta el final de la página, lo que obliga a cargar el siguiente grupo de registros disponible. El tamaño de estos grupos se puede configurar en este campo como el número de registros por grupo.
  
==== module_interval <factor> ====
+
* Días para purgado: Para evitar que el tamaño del sistema se sobrecargue, se puede definir un número máximo de días que se almacenará la información de logs; a partir de esa fecha se borrarán automáticamente en el proceso de limpieza de Pandora FMS.
  
Intervalo individual de módulo. Este valor es un factor multiplicador del intervalo del agente, no un tiempo libre.
+
== Migración al sistema LogStash + ElasticSearch ==
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).
 
  
{{Warning|Para que el module_interval funcione en agentes broker, debe tener el mismo intervalo que el del agente del cual proviene. En caso contrario, puede fallar su funcionamiento.}}
+
Una vez configurado el nuevo sistema de almacenamiento de logs, puede migrar todos los datos almacenados previamente en Pandora FMS, en forma distribuída en directorios al nuevo sistema.
  
==== 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.
+
Para migrar al nuevo sistema, deberá ejecutar el siguiente script que puede encontrar en /usr/share/pandora_server/util/
  
==== module_postprocess <factor> ====
 
  
Valor numérico por el que se multiplicará el dato devuelto por el módulo. Útil para realizar conversiones de unidades.
+
# Migrate Log Data < 7.0NG 712 to >= 7.0NG 712
 +
/usr/share/pandora_server/util/pandora_migrate_logs.pl /etc/pandora/pandora_server.conf
  
==== module_save <nombre de variable> ====
+
== Visualización y búsqueda ==
  
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.
+
En una herramienta de colección de logs nos interesan principalmente dos cosas: buscar información -filtrando por fecha, fuentes de datos y/o palabras clave- y ver esa información dibujada en ocurrencias por unidad de tiempo. En este ejemplo, estamos buscando todos los mensajes de log de todos los orígenes en la última hora:
  
Por ejemplo:
+
<br><center>
 +
[[image:LogsVistaNew.png|850px]]
 +
<i>Vista de ocurrencias a lo largo del tiempo</i>
 +
<br></center>
  
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ódulo mostrará el contenido de la variable "$ECHO_1", siendo "41121".
 
 
En agentes Windows el módulo tendría que formarse con %var% en lugar de $var.
 
Siguiendo el ejemplo:
 
 
module_begin
 
module_name echo_2
 
module_type generic_data
 
module_exec echo %ECHO_1%
 
module_end
 
 
==== module_crontab <minuto> <hora> <día> <mes> <día de la semana> ====
 
 
Desde la versión 3.2 se pueden programar los módulos para que se
 
ejecuten en determinadas fechas.
 
 
Para ello hay que definir el '''module_crontab''' utilizando un formato
 
similar al del fichero crontab: (http://es.wikipedia.org/wiki/Cron_(Unix)#Sintaxis)
 
 
module_crontab <minuto> <hora> <día> <mes> <día de la semana>
 
 
Siendo:
 
 
* Minuto 0-59
 
* Hora 0-23
 
* Día del mes 1-31
 
* Mes 1-12
 
* Día de la semana 0-6 (0 es Domingo)
 
 
También es posible especificar intervalos utilizando el carácter '''-'''
 
como separador.
 
 
Por ejemplo, para que un módulo se ejecute todos los lunes entre las 12
 
y las 15 podríamos utilizar la siguiente configuración:
 
 
module_begin
 
module_name crontab_test
 
module_type generic_data
 
module_exec script.sh
 
module_crontab * 12-15 * * 1
 
module_end
 
 
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_end
 
 
==== 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
 
 
==== 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
 
 
==== (>= 5.x) module_unit <value> ====
 
 
Unidades que queremos mostrar junto al valor obtenido por el módulo.
 
 
Ejemplo:
 
 
module_unit %
 
 
==== (>= 5.x) module_group <value> ====
 
 
Permite indicar el grupo de módulos al que será asignado el módulo.
 
 
Ejemplo:
 
 
module_group Networking
 
 
==== (>= 5.x) module_custom_id <value> ====
 
 
Esta directiva es un identificador personalizado del módulo.
 
 
Ejemplo:
 
 
module_custom_id host101
 
 
==== (>= 5.x) module_str_warning <value> ====
 
 
Permite indicar una expresión regular para definir el umbral warning en módulos de tipo alfanumérico (string).
 
 
Ejemplo:
 
 
module_str_warning .*NOTICE.*
 
 
==== (>= 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.*
 
 
==== (>= 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
 
 
==== (>= 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
 
 
==== (>= 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
 
 
==== (>= 5.x) module_tags <value> ====
 
 
Tags que se desean asignar al módulo, separadas por comas.
 
 
Ejemplo:
 
 
module_tags tag1,tag2,tag3
 
 
==== (>= 5.x) module_warning_inverse <value> ====
 
 
Permite activar (1) el intervalo inverso para el umbral warning.
 
 
Ejemplo:
 
 
module_warning_inverse 1
 
 
==== (>= 5.x) module_critical_inverse <value> ====
 
 
Permite activar (1) el intervalo inverso para el umbral crítico.
 
 
Ejemplo:
 
 
module_critical_inverse 1
 
 
==== (>= 5.x) module_native_encoding <value> ====
 
 
(Win32 únicamente)
 
 
Este token de configuración solo afecta a los módulos que se ejecutan mediante una directiva de comandos, es decir, hay un module_exec presente.
 
 
Windows maneja tres codificaciones para sus procesos: la codificación de la línea de comandos (OEM), la codificación del sistema (ANSI) y UTF-16. Ambas codificaciones coinciden en los caracteres básicos, pero difieren en aquellos menos comunes, como podrían ser las tildes. Con este token, el agente de Pandora FMS convierte la salida del comando a la codificación especificada en el encoding del archivo de configuración.
 
 
module_native_encoding tiene cuatro valores válidos:
 
* module_native_encoding OEM: Para la codificación de la línea de comandos
 
* module_native_encoding ANSI: Para la codificación del sistema
 
* module_native_encoding UTFLE: Para UTF-16 little-endian
 
* module_native_encoding UTFBE: Para UTF-16 big-endian
 
 
Si no aparece module_native_encoding, no se realizará ninguna recodificación.
 
 
==== (>= 5.x) module_quiet <value> ====
 
 
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
 
 
==== (>= 5.x) module_ff_interval <value> ====
 
 
Permite indicar un umbral ''flip flop'' en el módulo.
 
 
Ejemplo:
 
 
module_ff_interval 2
 
 
==== module_macro<macro> <value> ====
 
 
Solo aplicable en componentes locales desde la consola. No tiene utilidad en el fichero de configuración.
 
 
====  module_alert_template <template_name> ====
 
 
Esta macro asigna al módulo creado la plantilla de alerta correspondiente al nombre introducido como parámetro (ver [http://wiki.pandorafms.com/index.php?title=Pandora:Documentation_es:Alertas#Plantilla_de_alerta 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>
 
<nowiki><data><![CDATA[92]]></data></nowiki>
 
</module>
 
 
==== module_end ====
 
 
Etiqueta de final de módulo. Es obligatorio.
 
 
=== Directivas específicas para obtener información ===
 
 
A continuación se describen las directivas específicas que se pueden especificar en cada módulo '''para obtener información''' como tal. En cada módulo solo se puede utilizar uno de estos tipos.
 
 
==== 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.
 
 
En Linux, el comando se ejecutará mediante el intérprete de comandos por defecto. Cuál es el intérprete por defecto viene determinado por el enlace simbólico de '''/bin/sh'''. Normalmente el enlace apunta a ''bash'', pero en sistemas como Ubuntu no es así (en este caso apunta a ''dash''). Por ello, puede ocurrir que se pruebe un comando en la terminal y luego dé error cuando el agente lo ejecute. Una solución que funcionará en la mayoría de ocasiones será forzar la ejecución del comando en bash de la siguiente forma:
 
 
module_exec bash -c "<comando>"
 
 
{{Warning|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.
 
 
==== 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.
 
 
<br><br>
 
<center>
 
[[image:Service_name_id.png|center]]
 
</center>
 
 
<br>
 
<br>
'' Modo asíncrono ''
 
 
<br>
 
<br>
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 FMS, tardaremos al menos otros 300 segundos en saber que se ha caído. Los módulos asíncronos hacen que Pandora FMS 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.
+
Existe una serie de opciones para filtrar la información que muestra el visor:
 
+
* Filtro de tipo de búsqueda: Podemos buscar por coincidencia exacta, todas las palabras o cualquier palabra.
module_async yes
+
* Filtro por contenido del mensaje: Busca en el contenido del mensaje el texto indicado.
 
+
* Filtro por origen de log (source id).
Esta funcionalidad no está soportada en los agentes broker.
+
* Filtro por agente: limita los resultados de búsqueda a los generados por el agente seleccionado.
 
+
* Filtro por grupo: limita la selección de agentes en el filtro por agente.
{{Warning|En las versiones de Windows Home Edition esta funcionalidad asíncrona no está soportada y, solamente en estas versiones, el agente de Pandora FMS realiza una consulta periódica para saber si el servicio está corriendo o no. Esto puede consumir bastantes recursos así que se recomienda usar la versión síncrona si se monitoriza un número elevado de servicios.}}
+
* Filtro por fecha.
 
 
'' 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'''
+
El campo más importante -y útil- para nosotros será la cadena de búsqueda (search en la captura). Esto puede ser una simple cadena de texto, como en el caso anterior, o una expresión comodín, como por ejemplo una dirección IP:
  
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:
+
192.168*
  
module_begin
+
<b>Nota</b>: Las búsquedas deben realizarse utilizando palabras completas o subcadenas iniciales de las palabras a buscar. Algunos ejemplos:
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.
+
192.168.80.14
 +
192.168*
 +
Alerta en sistema
 +
Alerta en sis
 +
Error
  
==== module_proc <proceso> ====
+
Debemos seleccionar uno de los 3 tipos de búsqueda:
  
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.  
+
* <b>Coincidencia exacta</b>: búsqueda de cadena literal.
  
Este sería un ejemplo de la monitorización de proceso cmd.exe:
+
<br><center>
 +
[[image:LogsVistaNew2.png|850px]]
 +
<br></center>
  
module_begin
+
* <b>Todas las palabras</b>: búsqueda de todas las palabras indicadas, independientemente del orden en una misma línea, teniendo en cuenta que cada palabra está separada por espacios.
module_name CMDProcess
 
module_type generic_proc
 
module_proc cmd.exe
 
module_description Process Command line
 
module_end
 
  
'''En Unix'''
+
<br><center>
 +
[[image:LogsVistaNew4.png|850px]]
 +
<br></center>
  
En Unix funciona exactamente igual que el modulo module_service. Tampoco soporta modo asíncrono ni watchdog.
+
* <b>Cualquier palabra</b>: búsqueda de cualquier palabra indicada, independientemente del orden, teniendo en cuenta que cada palabra está separada por espacios.
  
'' Modo asíncrono ''
+
<br><center>
 +
[[image:LogsVistaNew5.png|850px]]
 +
<br></center>
  
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:
+
Si marcamos la opción de ver el contexto del contenido filtrado, obtendremos una vista general de la situación con información de otras líneas de logs relacionadas con nuestra búsqueda:
  
module_begin
+
<br><center>
module_name Notepad
+
[[image:LogsVistaNew3.png|850px]]
module_type generic_proc
+
<br></center>
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''
+
=== Visualización y búsqueda avanzadas ===
  
Un Watchdog es un sistema que permite actuar inmediatamente ante la caída de un proceso, generalmente, levantando el proceso que se ha caído. El agente de Windows de Pandora FMS, puede actuar como Watchdog ante la caída de un proceso.
+
A partir de Pandora FSM 7.0NG OUM727 están disponibles las opciones avanzadas para visualización de datos de log.
  
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:
+
Con esta característica podremos graficar las entradas de log, clasificando la información en base a '''modelos de captura de datos'''.
  
module_begin
+
Estos modelos de captura de datos son básicamente expresiones regulares e identificadores, que nos permitirán analizar los orígenes de datos y mostrarlos como un gráfico.
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 límite 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.
+
Para acceder a las opciones avanzadas pulse en ''Advanced options''. Se mostrará un formulario donde podrá elegir el tipo de vista de resultados:
  
* '''module_user_session''': Controla en qué sesión se desea que se lance el proceso. Si se configura a 'no' el proceso se iniciará en la sesión de los servicios y, por lo tanto, permanecerá en segundo plano (opción por defecto). En caso contrario, si se configura a 'yes', el proceso se lanzará en la sesión del usuario y será visible desde el escritorio del pc.
+
- Mostrar entradas de log (texto plano).
 +
- Mostrar gráfica de log.
  
{{Warning|Para versiones anteriores a Windows Vista el token module_user_session puede configurarse de manera general habilitando 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:
 
<br><br>
 
 
<center>
 
<center>
[[image:Service_interactive.png|center]]
+
[[Image: graph_log.png|800px]]
 
</center>
 
</center>
<br><br>}}
 
 
De igual modo, es necesario entender que Pandora FMS, como servicio, se ejecuta bajo la cuenta "SYSTEM" y que el proceso ejecutado lo hará bajo ese usuario y con ese entorno, de forma que si quiere ejecutar algún proceso determinado que requiera ser usado con un determinado usuario, deberá encapsular en un script (.bat o similar) los procesos previos para inicializar el entorno, variables de entorno, etc), y ejecutar ese script como acción del watchdog.
 
 
==== module_cpuproc <process> ====
 
 
''(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
 
 
==== 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
 
 
==== 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
 
 
<pre>
 
module_begin
 
module_name freedisk
 
module_type generic_data
 
module_freedisk C:
 
module_end
 
</pre>
 
 
<pre>
 
module_begin
 
module_name disk_var
 
module_type generic_data
 
module_freedisk /var
 
module_end
 
</pre>
 
 
==== 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)
 
 
<pre>
 
module_begin
 
module_name freepercentdisk
 
module_type generic_data
 
module_freepercentdisk C:
 
module_end
 
</pre>
 
 
<pre>
 
module_begin
 
module_name disk_var
 
module_type generic_data
 
module_freepercentdisk /var
 
module_end
 
</pre>
 
 
==== module_occupiedpercentdisk <letra_de_la_unidad:>|<volumen> ====
 
 
(Sólo Unix)
 
 
Este módulo devuelve el porcentaje de disco ocupado en un volumen Unix (p.e: /var)
 
 
module_begin
 
module_name disk_var
 
module_type generic_data
 
module_occupiedpercentdisk /var
 
module_end
 
 
==== module_cpuusage [<cpu id>] ====
 
 
Devuelve el uso de CPU en un número de CPU. Si sólo existe una CPU no establezca ningún 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:
 
  
 +
Bajo la opción ''mostrar gráfica de log'' podemos seleccionar el modelo de captura.
  
module_begin
+
El modelo por defecto, ''Apache log model'', ofrece la posibilidad de parsear logs de Apache en formato estándar (access_log), pudiendo extraer gráficas comparativas de tiempo de respuesta, agrupando por página visitada y código de respuesta:
module_name UsoCPU
 
module_type generic_data
 
module_cpuusage all
 
module_description Uso medio de CPU
 
module_end
 
  
Para comprobar el uso de la CPU en la CPU #1:
 
 
module_begin
 
module_name CPU_1
 
module_type generic_data
 
module_cpuusage 1
 
module_description Uso medio de CPU de la CPU #1
 
module_end
 
 
==== module_freememory ====
 
 
Funciona tanto en Unix como en Windows. Devuelve la memoria libre en todo el sistema.
 
 
module_begin
 
module_name FreeMemory
 
module_type generic_data
 
module_freememory
 
module_description Non-used memory on system
 
module_end
 
 
==== module_freepercentmemory ====
 
 
Funciona tanto en Unix como en 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
 
 
==== module_tcpcheck ====
 
(Solo 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
 
 
==== 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:  [http://www.regular-expressions.info/reference.html]
 
 
 
==== module_wmiquery ====
 
 
(Solo 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 líneas como resultado, que serán insertados como varios datos.
 
* '''module_wmicolumn''': Nombre de la columna que se va a usar como fuente de datos.
 
 
Por ejemplo, podemos obtener una lista de los servicios instalados:
 
 
module_begin
 
module_name Services
 
module_type generic_data_string
 
module_wmiquery Select Name from Win32_Service
 
module_wmicolumn Name
 
module_end
 
 
O de la carga actual de CPU:
 
 
module_begin
 
module_name CPU_speed
 
module_type generic_data
 
module_wmiquery SELECT LoadPercentage FROM Win32_Processor
 
module_wmicolumn LoadPercentage
 
module_end
 
 
==== module_perfcounter ====
 
 
(Solo 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):
 
 
<br><br>
 
 
<center>
 
<center>
[[image:Perfcounter_screen1.png|center|450px]]
+
[[Image: graph_log2.png|800px]]
 
</center>
 
</center>
<br><br>
 
  
Es posible añadir contadores de rendimiento nuevos mediante la herramienta del sistema. Su configuración tiene estructura jerárquica con elementos y subelementos. En este caso ''Procesador'', ''% de tiempo de procesador'' y ''_Total'':
+
Al pulsar en el botón de editar, editaremos el modelo de captura seleccionado. Con el botón de crear agregaremos un nuevo modelo de captura.
 +
 
  
<br><br>
 
 
<center>
 
<center>
[[image:Perfcounter_screen2.png|center]]
+
[[Image: graph_log3.png]]
 
</center>
 
</center>
<br><br>
 
 
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.
+
En el formulario que aparece, podremos elegir:
  
==== module_inventory DEPRECATED====
+
;Título: un nombre para el modelo de captura.
 +
;Una expresión regular de captura de datos: cada campo a extraer se identifica con la subexpresión entre los paréntesis ''(expresión a capturar)''.
 +
;Los campos: en el orden en que los hemos capturado con la expresión regular. Los resultados se agruparán por la concatenación de los campos clave, que son aquellos cuyo nombre no esté entre guiones bajos:
  
{{Warning|Actualmente esta funcionalidad ha sido sustituida por inventario desde plugins de agente tanto en sistemas Windows como Linux/Unix.}}
+
clave, _valor_
  
''(Win32 únicamente. En linux/unix está implementado 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.
+
clave1,clave2,_valor_
  
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).
+
clave1,_valor_,clave2
* '''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.  
+
''Observación:'' Si no especificamos un campo valor, será automáticamente el conteo de apariciones que coinciden con la expresión regular.
  
Un ejemplo de uso de este módulo sería el siguiente:
+
''Observación 2:'' Si especificamos una columna ''valor'' podremos elegir entre representar el valor acumulado (comportamiento por defecto) o marcar el checkbox para representar el promedio.
  
module_begin
+
''Ejemplo''
module_name Inventory
 
module_interval 7
 
module_type generic_data_string
 
module_inventory RAM Patches Software Services
 
module_description Inventory
 
module_end
 
  
==== module_logevent ====
+
Si quisiéramos extraer entradas de un log con el siguiente formato:
  
(Solo Windows)
+
Sep 19 12:05:01 nova systemd: Starting Session 6132 of user root.
 +
Sep 19 12:05:01 nova systemd: Starting Session 6131 of user root.
  
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:
+
Para contar el número de veces que se ha iniciado sesión, agrupando por usuario, usaremos:
  
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.
+
Expresión regular
  
module_logevent acepta los siguientes parámetros (todos ellos case-sensitive):
+
Starting Session \d+ of user (.*?)\.
  
* '''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:  
+
Campos:
  
  module_begin
+
  username
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:
+
Este modelo de captura nos devolverá el número de inicios de sesión por usuario del intervalo de tiempo que seleccionemos.
  
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:
 
<br><br>
 
 
<center>
 
<center>
[[Image:Event sample.png|center|450px]]
+
[[Image: graph_log4.png]]
 
</center>
 
</center>
<br>
 
  
module_begin
+
== Configuración de los agentes ==
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
 
  
==== module_logchannel ====
+
La recolección de logs se hace mediante los agentes, tanto en el agente Windows como en los agentes Unix (Linux, MacOsX, Solaris, HPUX, AIX, BSD, etc). En el caso de los agentes Windows, también se puede obtener información del visor de eventos de Windows, utilizando los mismos filtros que en el módulo de monitorización del visor de eventos.
  
(Solo Windows. A partir de 7.0OUM715)
+
Veamos dos ejemplos para capturar información de logs, en Windows y en Unix:
  
Tipo de módulo que permite obtener información de los canales de logs de Windows. Si bien ''module_logevent'' solo tiene acceso a los logs de los Registros de Windows, este tipo de módulo permite extraer datos de otros ficheros de logs que estén configurados como canales. De esta forma, es posible obtener los logs englobados en los Registros de aplicaciones y servicios.
+
=== En Windows ===
 
 
El formato general de este módulo es el siguiente:
 
  
 
  module_begin
 
  module_begin
  module_name MyEvent
+
  module_name Eventlog_System
  module_type async_string
+
  module_type log
  module_logchannel
+
  module_logevent
  module_source <logChannel>
+
  module_source System
module_eventtype <event_type/level>
+
  module_end  
module_eventcode <event_id>
 
module_application <source>
 
module_pattern <text substring to match>
 
module_description <description>
 
  module_end
 
 
 
Para evitar mostrar información repetida, sólo se tienen en cuenta aquellos eventos que hayan tenido lugar desde el momento en el que se inicia el agente.
 
 
 
module_logchannel acepta los siguientes parámetros (todos ellos case-sensitive):
 
 
 
* '''module_source''': Canal del evento. Con el comando ''' wevtutil.exe enum-logs ''' se obtiene un listado de todos los canales de logs locales de la máquina. Campo obligatorio.
 
* '''module_eventtype''': Tipo de evento (''critical'', ''error'', ''warning'', ''info'' o ''verbose''). 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, definiríamos el siguiente módulo para mostrar todos los eventos del canal ''Microsoft-Windows-TaskScheduler/Operational'', de tipo ''information'', con código ''201'' y que en el texto del log apareciera el texto ''code 0'':
 
  
 
  module_begin
 
  module_begin
  module_name New logs
+
  module_name PandoraAgent_log
  module_type async_string
+
  module_type log
  module_logchannel
+
  module_regexp C:\archivos de programa\pandora_agent\pandora_agent.log
  module_description Successfully completed tasks
+
  module_description This module will return all lines from the specified logfile
module_source Microsoft-Windows-TaskScheduler/Operational
+
  module_pattern .*
module_eventtype information
 
module_eventcode 201
 
  module_pattern code 0
 
 
  module_end
 
  module_end
  
Con esta configuración de módulo, el agente de Pandora FMS recogería el siguiente log:
+
En ambos casos, la única diferencia de un módulo de monitorización a la definición de una fuente de log, es:
 
 
<center>
 
[[Image:Logchannel example.png|center|700px]]
 
</center>
 
<br>
 
 
 
==== 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 versión 3.1 o superior)
 
 
 
module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\df_percent.vbs"
 
 
 
==== module_ping <host> ====
 
 
 
(Solo 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
 
 
 
==== module_snmpget ====
 
 
 
(Solo 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
 
 
 
== Configuración automática de agentes ==
 
===Introducción===
 
A partir de la versión 725 de Pandora FMS, puede establecer una serie de reglas para que sus agentes se configuren de manera automática.
 
 
 
El proceso de autoconfiguración de agentes funciona de la siguiente manera:
 
 
 
'''1-''' Se preparan las configuraciones automáticas en su Pandora FMS Console o Pandora FMS Metaconsole.
 
 
 
'''2-''' Se instalan los agentes reportando contra su Pandora FMS (si tiene una única consola, apunte el agente contra su servidor Pandora FMS, si tiene una Metaconsola con el sistema de aprovisionamiento automático configurado, establezca como servidor la propia Metaconsola).
 
 
 
'''3-''' Pandora FMS Server recibirá un XML (.data) con los datos del agente por primera vez.
 
 
 
'''4-''' Se evaluarán las reglas para determinar la configuración automática a aplicar.
 
 
 
'''5-''' El agente recogerá la nueva configuración y reportará en el siguiente ciclo con la configuración actualizada.
 
 
 
=== Creación/edición de autoconfiguración ===
 
 
 
Puede acceder al formulario que administra las configuraciones automáticas a través de:
 
 
 
<b>Consola</b>
 
Administración > Administrar configuración automática de agente
 
 
 
<center>[[Image:autoconf_menu_console.png‎‎]]</center>
 
 
 
<b>Metaconsola</b>
 
Avanzado > Administración de agentes > Configuración automática de agentes
 
 
 
<center>[[Image:Autoconf1.png‎‎]]</center>
 
 
 
Una vez accede a la página de administración puede crear nuevas configuraciones automáticas presionando el botón "Crear configuración automática".
 
 
 
Deberá elegir un nombre y una descripción para su configuración automática.
 
 
 
 
 
<center>[[Image:Autoconf_new.png‎‎]]</center>
 
 
 
 
 
Una vez creada la nueva configuración automática, puede mostrar los formularios de configuración pulsando en la sección que necesite:
 
 
 
 
 
<center>[[Image:Autoconf_options.png‎‎]]</center>
 
 
 
 
 
==== Reglas ====
 
 
 
Para definir los agentes sobre los que se aplicará la configuración automática, puede agregar reglas para identificarlos.
 
 
 
Despliegue el apartado de reglas dentro de su configuración automática, y seleccione "Agregar nueva regla".
 
 
 
 
 
Podrá elegir en el selector de reglas una serie de opciones, para identificar los agentes que se vayan a configurar.
 
 
 
<center>[[Image:autoconf_rules1.png||750px‎‎]]</center>
 
 
 
'''Server name:''' Coincidencia en nombre de servidor.
 
 
 
''' Group name: '''Coincidencia en nombre de grupo.
 
 
 
'''OS:''' Coincidencia en nombre de sistema operativo (usa expresiones regulares).
 
 
 
'''Custom field:''' Coincidencia por clave/valor en base a un campo personalizado reportado por el agente, indique el nombre del campo personalizado y el valor que debe tener.
 
 
 
'''IP range:''' Coincidencia por rango de IP (red), utilice la notación IP/máscara, por ejemplo:
 
 
 
192.168.1.0/24
 
 
 
'''Script output (> 0):''' Pensado para ejecutar un script cuyo resultado de la ejecución se evalua como válida cuando la salida standard sea mayor que 0.
 
 
 
La llamada al script de reglas admite las siguientes macros en el campo 'argumentos':
 
 
 
* ''' _agent_ :''' Se sustituirá por el nombre del agente.
 
 
 
* ''' _agentalias_ : '''Se sustituirá por el alias del agente.
 
 
 
* '''_address_ :''' Se sustituirá por la dirección IP principal reportada por el agente.
 
 
 
* ''' _agentgroup_ :''' Se sustituirá por el nombre del grupo reportado por el agente.
 
 
 
* ''' _agentos_ :''' Se sustituirá por el sistema operativo del agente.
 
 
 
 
 
Puede elegir entre operadores <i>AND</i> y <i>OR</i> para modificar la lógica de las reglas.
 
 
 
<center>[[Image:autoconf_rules2.png||750px‎‎]]</center>
 
 
 
 
 
<b>Nota:</b> Si no agrega ninguna regla, la configuración automática no se aplicará.
 
 
 
Si necesita una única configuración para todos los agentes, puede utilizar la expresión regular siguiente para que coincida con cualquier <i>alias</i>
 
 
 
.*
 
 
 
==== Configuraciones ====
 
 
 
Desde esta sección podremos configurar:
 
 
 
; Grupo del agente: Podremos mantenerlo sin cambios o forzarlo a ser uno específico.
 
; Grupos secundarios: Los grupos seleccionados aquí se agregarán como grupos secundarios al agente.
 
; Políticas: Podemos seleccionar políticas para que se apliquen automáticamente cuando el agente alcance el servidor.
 
; Bloque de configuración: Agrega la configuración extra en bruto al fichero de configuración del agente.
 
 
 
 
 
<center>[[File:autoconf_config.png]]</center>
 
 
 
<b>Nota:</b> Si intenta acceder a la administración de configuraciones automáticas desde un nodo que pertenece a una Metaconsola, con la administración centralizada activa, la vista será de sólo lectura:
 
 
 
<center>[[File:autoconf_ro.png]]</center>
 
 
 
 
 
 
 
==== Acciones extra ====
 
 
 
Desde esta sección puede asociar otras acciones a la autoconfiguración, como por ejemplo:
 
 
 
#Lanzar un evento personalizado
 
#Ejecutar una acción de alerta
 
#Ejecutar un script
 
 
 
 
 
<center>[[File:autoconf_actions.png]]</center>
 
 
 
 
 
El sistema admite las siguientes macros:
 
; _agent_ : Se sustituirá por el nombre del agente
 
; _agentalias_ : Se sustituirá por el alias del agente;
 
; _address_ : Se sustituirá por la dirección IP principal reportada por el agente
 
; _agentgroup_ : Se sustituirá por el nombre del grupo reportado por el agente
 
; _agentos_ : Se sustituirá por el sistema operativo del agente
 
; _agentid_ : Se sustituye por el ID del agente.
 
 
 
== Agentes Unix/Linux ==
 
 
 
 
 
 
 
=== 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''.
 
 
 
=== 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.
 
 
 
=== 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:
 
 
 
# Verifique que las líneas terminan en ";"
 
# Verifique que los comandos están encerrados entre comillas simples: ' '
 
# 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}\'
 
 
 
== Agentes Windows de Pandora FMS ==
 
 
 
=== 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 del agente.
 
 
 
== Despliegue automático de agentes software ==
 
 
 
Puede desplegar agentes software utilizando la '''central de despliegues''' a través del sistema Discovery, más información en [https://pandorafms.com/docs/index.php?title=Pandora:Documentation_es:Discovery#Despliegue_autom.C3.A1tico_de_agentes este enlace]
 
 
 
 
 
== 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.
 
{{Tip|La herramienta pandora_update necesita el módulo de perl Digest::MD5 para funcionar. A partir de la versión 5.14 de Perl, este módulo está integrado por defecto, pero en versiones anteriores deberá instalarse manualmente.}}
 
Esto funciona del siguiente modo:
 
 
 
1. Los agentes reciben nuevos binarios en el directorio de entrada de las colecciones.
 
 
 
Ejemplo en Windows:
 
 
 
c:\program files\pandora_agent\collections\fc_1\PandoraAgent.exe
 
 
 
Ejemplo en Linux:
 
 
 
/etc/pandora/collections/fc_1/pandora_agent
 
 
 
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 binario del agente (no el instalador entero), comparará el binario 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.
 
 
 
Para actualizar diferentes arquitecturas se deberá establecer una colección diferente para cada arquitectura. Por ejemplo, si se desean actualizar agentes de Windows de 32 y 64 bits, habrá que crear dos colecciones y en cada una de ellas incluir el binario ''PandoraAgent.exe'' correspondiente.
 
 
 
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
 
 
 
== 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.
 
 
 
<center>
 
<br><br>
 
[[File:Learning mode.png]]
 
<br><br>
 
</center>
 
 
 
=== Datos que se incorporan en la creación 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.
 
* Modo de agente: Aprendizaje, Normal, Auto-deshabilitado.
 
 
 
=== Datos que se actualizan del agente al recibir un XML (modo aprendizaje activado) ===
 
  
* Dirección IP del agente.
+
module_type log
* Padre del agente.
 
* Versión SO.
 
* Versión agente.
 
* Zona horaria.
 
* Custom fields.
 
  
{{tip|Los datos GIS se actualizan siempre (si están habilitados) sin importar si el learning mode esta desactivado}}
+
Esta nueva sintaxis solo la entiende el agente de la versión 5.0, por lo que debe actualizar los agentes si quiere utilizar esta nueva funcionalidad Enterprise.
  
Además, con ''modo aprendizaje'' activado se crearán nuevos módulos en Pandora FMS al ser recibidos a través de XMLs.
+
{{Warning|Para definir módulos de log en Windows será necesario hacerlo directamente en el fichero de configuración del agente. Si se crean directamente desde la consola, los módulos se quedarán en estado no inicializado.}}
  
=== Datos que se incorporan en la creación de un módulo ===
+
=== Sistemas Unix ===
  
Los datos que se incorporan en el módulo la primera vez que se recibe un XML son los siguientes:
+
En Unix se utiliza un nuevo plugin, que viene con el agente de la versión 5.0. Su sintaxis es bien sencilla:
  
* Nombre.
+
module_plugin grep_log_module /var/log/messages Syslog \.\*
* 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.
 
  
=== Datos que se actualizan de un módulo ya existente al recibir un XML ===
+
Similar al plugin de parseo de logs (grep_log), el plugin grep_log_module envía la información procesada del log al colector de logs con el nombre de "Syslog" como origen del log. Utiliza la expresion regular \.\* (en este caso "todo") como patrón a la hora de elegir qué líneas enviamos y cuáles no.
  
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.
 
  
 
[[Pandora:Documentation|Volver a Indice de Documentacion Pandora FMS]]
 
[[Pandora:Documentation|Volver a Indice de Documentacion Pandora FMS]]
  
[[Category:Pandora FMS]]
+
[[Category: Pandora FMS]]
 
[[Category:Documentation]]
 
[[Category:Documentation]]

Revision as of 14:55, 11 May 2020

Volver a Indice de Documentacion Pandora FMS

1 Recolección de logs

1.1 Introducción

Hasta ahora Pandora FMS no tenía una solución a este problema, pero con la versión 5.0 Pandora FMS Enterprise ofrece una solución para poder gestionar cientos de megabytes de datos diarios. Esta solución permite reutilizar los mismos agentes de la monitorización para la recolección específica de datos de logs, utilizando una sintaxis muy similar a la actual para la monitorización de logs.

La monitorización de logs en Pandora FMS se plantea de dos formas diferentes:

  1. Basada en módulos: representa logs en Pandora FMS como monitores asíncronos, pudiendo asociar alertas a las entradas detectadas que cumplan una serie de condiciones preconfiguradas por el usuario. La representación modular de los logs nos permite:
    1. Crear módulos que cuenten las ocurrencias de una expresión regular en un log.
    2. Obtener las líneas y el contexto de los mensajes de log
  2. Basada en visualización combinada: permite al usuario visualizar en una única consola toda la información de logs de múltiples orígenes que se desee capturar, organizando la información secuencialmente utilizando la marca de tiempo en que se procesaron los logs.

A partir de la versión 7.0NG 712, Pandora FMS incorpora ElasticSearch para almacenar la información de logs, lo que implica una mejora sustancial del rendimiento.

1.2 Cómo funciona

El proceso es simple:



LogsEsquema.png



  • Los logs analizados por los agentes (eventlog o ficheros de texto), son reenviados hacia el servidor de Pandora FMS, en forma "literal" (RAW) dentro del XML de reporte del agente:
  • El servidor de Pandora FMS (DataServer) recibe el XML del agente, que contiene información tanto de monitorización como de logs.
  • Cuando el DataServer procesa los datos del XML identifica la información de los logs, guardando en la base de datos principal las referencias del agente que ha reportado y el origen del log, enviando automáticamente la información a ElasticSearch.
  • Pandora FMS almacena los datos en índices de ElasticSearch generando diariamente un índice único por cada instancia de Pandora FMS.
  • El servidor de Pandora FMS dispone de una tarea de mantenimiento que elimina los índices en el intervalo definido por el administrador del sistema (por defecto, 90 días).

1.3 Configuración

1.3.1 Configuración del servidor

El nuevo sistema de almacenamiento de logs, basado en ElasticSearch, requiere configurar los diferentes componentes.

Template warning.png

A partir de la versión 745 de Pandora FMS ya no es necesario el uso de LogStash, ya que el servidor de Pandora FMS se comunica directamente con el servidor de ElasticSearch, por lo que las configuraciones relativas a LogStash no deberán aplicarse.

 


1.3.1.1 Requisitos para el servidor

Es posible distribuir cada componente (Pandora FMS Server, ElasticSearch) en servidores independientes.

Si decide alojar ElasticSearch y LogStash en el mismo servidor, recomendamos:

  • Centos 7.
  • Al menos 4GB de RAM, aunque se recomiendan 6GB de RAM por cada instancia de ElasticSearch.
  • Al menos 2 CPU cores.
  • Al menos 20 GB de espacio en disco para el sistema.
  • Al menos 50 GB de espacio en disco para los datos de ElasticSearch (el número puede variar dependiendo de la cantidad de datos que se desee almacenar).
  • Conectividad desde el servidor y la consola de Pandora FMS a la API de ElasticSearch (por defecto puerto 9200/TCP ).



1.3.1.2 Instalación y configuración de ElasticSearch

Antes de empezar con la instalación de estos componentes es necesaria la instalación de Java en la máquina:

yum install java

Una vez instalado Java, instalar ElasticSearch siguiendo la documentación oficial: https://www.elastic.co/guide/en/elasticsearch/reference/7.6/install-elasticsearch.html

En caso de una instalación en sistemas CentOS/Red Hat, la instalación recomendada es por medio de rpm: https://www.elastic.co/guide/en/elasticsearch/reference/7.6/rpm.html

Configurar el servicio:

Configuraremos las opciones de red y, opcionalmente, las ubicaciones de datos (y logs del propio ElasticSearch) en el fichero de configuración ubicado en /etc/elasticsearch/elasticsearch.yml

# ---------------------------------- Network -----------------------------------
# Set the bind address to a specific IP (IPv4 or IPv6):
http.host: 0.0.0.0
# Set a custom port for HTTP:
http.port: 9200
# ----------------------------------- Paths ------------------------------------
# Path to directory where to store the data (separate multiple locations by comma):
path.data: /var/lib/elastic
# Path to log files:
path.logs: /var/log/elastic


Será necesario descomentar y definir también las siguientes líneas como siguen:

cluster.name: elkudemy
node.name: ${HOSTNAME}
bootstrap.memory_lock: true
network.host: ["127.0.0.1", “IP"]
  • cluster.name: Será el nombre que recibirá el cluster.
  • node.name: Para nombrar el nodo, con ${HOSTNAME} tomará el nombre del host.
  • bootstrap.memory_lock: Siempre deberá ser "true".
  • network.host: La IP del servidor.

Habrá que determinar las opciones de recursos asignados a ElasticSearch, ajustando los parámetros disponibles en el fichero de configuración ubicado en /etc/elasticsearch/jvm.options. Se recomienda utilizar al menos 2GB de espacio en XMS.

# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space
-Xms2g
-Xmx2g

La asignación de recursos se asignará en función del uso que se quiera dar a ElasticSearch. Recomendamos seguir la documentación oficial de ElasticSearch: https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html

Iniciar el servicio:

systemctl start elasticsearch


Nota: Si el servicio no consigue iniciarse, revise los logs ubicados en /var/log/elasticsearch/

Para comprobar la instalación de ElasticSearch bastará con ejecutar el siguiente comando:

curl -q http://{IP}:9200/

Que debería ofrecer una respuesta similar a la siguiente:

{
  "name" : "3743885b95f9",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "7oJV9hXqRwOIZVPBRbWIYw",
  "version" : {
    "number" : "7.6.2",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "ef48eb35cf30adf4db14086e8aabd07ef6fb113f",
    "build_date" : "2020-03-26T06:34:37.794943Z",
    "build_snapshot" : false,
    "lucene_version" : "8.4.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}




1.3.1.3 Instalación y configuración de LogStash

Template warning.png

A partir de la versión 745 de Pandora FMS no es necesaria la instalación de LogStash.

 


Instalar LogStash 5.6.2 desde el RPM descargable de la página web del proyecto ElasticSearch: https://artifacts.elastic.co/downloads/logstash/logstash-5.6.2.rpm

Una vez descargado el paquete, lo instalamos ejecutando:

rpm -i logstash-X.X.X.rpm

Configurar el servicio:

Dentro de la configuración de Logstash existen tres bloques de configuración:

  • Input: indica cómo le llega la información a Logstash, formato, puerto y un identificador que se utilizará para almacenar la información internamente en Elastic.
  • Filter: es posible agregar un post-procesado aquí, pero para nuestro caso no será necesario, por lo que lo dejaremos vacío.
  • Output: aquí viene la configuración de la IP y puerto donde estará escuchando ElasticSearch; es el sitio donde se guardará la información procesada por Logstash.

Fichero de configuración:

/etc/logstash/conf.d/logstash.conf


Ejemplo de fichero de configuración:

# This input block will listen on port 10514 for logs to come in.
# host should be an IP on the Logstash server.
# codec => "json" indicates that we expect the lines we're receiving to be in JSON format
# type => "rsyslog" is an optional identifier to help identify messaging streams in the pipeline.
input {
 tcp {
    host  => "0.0.0.0"
    port  => 10516
    codec => "json"
    type  => "pandora_remote_log_entry"
 }
}
# This is an empty filter block.  You can later add other filters here to further process
# your log lines
filter { }
output {
  elasticsearch { hosts => ["0.0.0.0:9200"] }
}

En los apartados de "host" debemos introducir la IP del servidor en lugar de “0.0.0.0”.

En el archivo "logstash-sample.conf" deberemos cambiar también "localhost", donde debe introducirse la IP del servidor.

Iniciar el servicio:

systemctl start logstash


Nota Si está intentando instalar LogStash en Centos 6 en contra de nuestra recomendación, puede iniciarlo con el siguiente comando:

initctl start logstash

1.3.1.4 Parámetros de configuración en Pandora FMS Server

Template warning.png

A partir de la versión 745 de Pandora FMS no será necesario configurar el fichero de configuración del servidor, ya que toda la configuración se realizará desde la consola al habilitar la recolección de logs.

 


Será necesario agregar la siguiente configuración al archivo de configuración de Pandora FMS Server (/etc/pandora/pandora_server.conf) para que Pandora FMS DataServer procese la información de logs.

Importante: Todo log que llegue a Pandora FMS sin tener activa esta configuración será descartado.

logstash_host eli.artica.lan
logstash_port 10516


1.3.1.5 Pandora FMS SyslogServer

A partir de la actualización 717 de Pandora FMS 7.0NG aparece un nuevo componente: SyslogServer.

Este componente permite a Pandora FMS analizar el syslog de la máquina donde está ubicado, analizando su contenido y almacenando las referencias en nuestro servidor de ElasticSearch.

La ventaja principal del SyslogServer consiste en complementar la unificación de logs. Apoyándose en las características de exportado de Syslog de los entornos Linux y Unix, SyslogServer permite la consulta de logs independientemente del origen, buscando en un único punto común (visor de logs de la consola de Pandora FMS).

La instalación de Syslog se realizará tanto en cliente como en servidor, y para ejecutarla será necesario lanzar el siguiente comando:

yum install rsyslog

Una vez instalado Syslog en los equipos con los que queramos trabajar, será importante tener en cuenta que habrá que acceder al fichero de configuración para habilitar el input TCP y UDP.

/etc/rsyslog.conf

Tras realizar este ajuste será necesario detener y volver a arrancar el servicio rsyslog.

Una vez el servicio vuelva a estar corriendo, podemos realizar una comprobación de puertos para ver que el 514 está accesible.

netstat -ltnp

Después de activar el servicio y comprobar los puertos, debemos configurar el cliente para que pueda enviar los logs al servidor. Para ello accederemos una vez más al fichero de configuración de rsyslog.

/etc/rsyslog.conf

Será necesario localizar y habilitar la línea que permite configurar el host remoto. Habrá que especificar qué queremos enviar, con lo que quedará como sigue:

*.* @@remote-host:514


Info.png

El envío de logs genera un agente contenedor con el nombre del cliente por lo que se recomienda crear los agentes con “alias as name” haciendo que coincida con el hostname del cliente, así se evitará duplicidad en los agentes.

 


Para más información de la configuración de rsyslog, visitar la web oficial: https://www.rsyslog.com/

Para activar esta funcionalidad simplemente tendremos que habilitarlo en la configuración, agregando a pandora_server.conf el siguiente contenido:


# Enable (1) or disable (0) the Pandora FMS Syslog Server (PANDORA FMS ENTERPRISE ONLY).
syslogserver 1
# Full path to syslog's output file (PANDORA FMS ENTERPRISE ONLY).
syslog_file /var/log/messages
# Number of threads for the Syslog Server (PANDORA FMS ENTERPRISE ONLY).
syslog_threads 2
# Maximum number of lines queued by the Syslog Server's producer on each run (PANDORA FMS ENTERPRISE ONLY).
syslog_max 65535


Necesitará un servidor LogStash/ElasticSearch habilitado y configurado; por favor, revise los puntos precedentes para saber cómo configurarlo.

syslogserver Booleano, habilita (1) o deshabilita (0) el motor de análisis de SYSLOG local.

syslog_file Ubicación del fichero donde se están entregando las entradas de los SYSLOG.

syslog_threads Número de hilos máximo que se utilizarán en el sistema productor/consumidor del SyslogServer.

syslog_max Es la ventana de procesado máxima para SyslogServer; será el número máximo de entradas del SYSLOG que se procesarán en cada iteración.

Template warning.png

Es necesario que modifique la configuración de su dispositivo para que los logs se envíen al servidor de Pandora FMS.

 


1.3.1.6 Recomendaciones

1.3.1.6.1 Rotación de logs para ElasticSearch y Logstash

Importante: como recomendación, crear una nueva entrada para el demonio de rotado de logs en /etc/logrotate.d, para evitar que los logs de ElasticSearch o LogStash crezcan sin medida:

cat > /etc/logrotate.d/elastic <<EOF
/var/log/elastic/elaticsearch.log
/var/log/logstash/logstash-plain.log {
       weekly
       missingok
       size 300000
       rotate 3
       maxage 90
       compress
       notifempty
       copytruncate
}
EOF
1.3.1.6.2 Purgado de índices

Puede consultar en todo momento el listado de índices y el tamaño que ocupan lanzando una petición cURL contra su servidor ElasticSearch:

curl -q http://elastic:9200/_cat/indices?

Donde "elastic" se refiere a la IP del servidor.

Para eliminar cualquiera de estos índices puede ejecutar la orden DELETE:

curl -q -XDELETE http://elastic:9200/{index-name}

Donde "elastic" se refiere a la IP del servidor, e "{index-name}" es el fichero de salida del comando anterior.

Esta operación liberará el espacio utilizado por el índice eliminado.

1.3.2 Configuración de la consola

Para activar el sistema de visualización de logs deberá activar la siguiente configuración:


Logs1.JPG


Luego podemos configurar el comportamiento del visor de logs en la pestaña 'Log Collector':


Logs2.JPG


En esta pantalla podremos configurar:

  • Dirección IP o FQDN del servidor que aloja el servicio ElasticSearch
  • Puerto a través del que se está prestando el servicio ElasticSearch
  • Número de logs mostrados: Para agilizar la respuesta de la consola se ha añadido la carga dinámica de registros. Para usarla, el usuario debe hacer scroll hasta el final de la página, lo que obliga a cargar el siguiente grupo de registros disponible. El tamaño de estos grupos se puede configurar en este campo como el número de registros por grupo.
  • Días para purgado: Para evitar que el tamaño del sistema se sobrecargue, se puede definir un número máximo de días que se almacenará la información de logs; a partir de esa fecha se borrarán automáticamente en el proceso de limpieza de Pandora FMS.

1.4 Migración al sistema LogStash + ElasticSearch

Una vez configurado el nuevo sistema de almacenamiento de logs, puede migrar todos los datos almacenados previamente en Pandora FMS, en forma distribuída en directorios al nuevo sistema.


Para migrar al nuevo sistema, deberá ejecutar el siguiente script que puede encontrar en /usr/share/pandora_server/util/


# Migrate Log Data < 7.0NG 712 to >= 7.0NG 712
/usr/share/pandora_server/util/pandora_migrate_logs.pl /etc/pandora/pandora_server.conf

1.5 Visualización y búsqueda

En una herramienta de colección de logs nos interesan principalmente dos cosas: buscar información -filtrando por fecha, fuentes de datos y/o palabras clave- y ver esa información dibujada en ocurrencias por unidad de tiempo. En este ejemplo, estamos buscando todos los mensajes de log de todos los orígenes en la última hora:


LogsVistaNew.png Vista de ocurrencias a lo largo del tiempo




Existe una serie de opciones para filtrar la información que muestra el visor:

  • Filtro de tipo de búsqueda: Podemos buscar por coincidencia exacta, todas las palabras o cualquier palabra.
  • Filtro por contenido del mensaje: Busca en el contenido del mensaje el texto indicado.
  • Filtro por origen de log (source id).
  • Filtro por agente: limita los resultados de búsqueda a los generados por el agente seleccionado.
  • Filtro por grupo: limita la selección de agentes en el filtro por agente.
  • Filtro por fecha.

El campo más importante -y útil- para nosotros será la cadena de búsqueda (search en la captura). Esto puede ser una simple cadena de texto, como en el caso anterior, o una expresión comodín, como por ejemplo una dirección IP:

192.168*

Nota: Las búsquedas deben realizarse utilizando palabras completas o subcadenas iniciales de las palabras a buscar. Algunos ejemplos:

192.168.80.14
192.168*
Alerta en sistema
Alerta en sis
Error

Debemos seleccionar uno de los 3 tipos de búsqueda:

  • Coincidencia exacta: búsqueda de cadena literal.

LogsVistaNew2.png


  • Todas las palabras: búsqueda de todas las palabras indicadas, independientemente del orden en una misma línea, teniendo en cuenta que cada palabra está separada por espacios.

LogsVistaNew4.png


  • Cualquier palabra: búsqueda de cualquier palabra indicada, independientemente del orden, teniendo en cuenta que cada palabra está separada por espacios.

LogsVistaNew5.png


Si marcamos la opción de ver el contexto del contenido filtrado, obtendremos una vista general de la situación con información de otras líneas de logs relacionadas con nuestra búsqueda:


LogsVistaNew3.png



1.5.1 Visualización y búsqueda avanzadas

A partir de Pandora FSM 7.0NG OUM727 están disponibles las opciones avanzadas para visualización de datos de log.

Con esta característica podremos graficar las entradas de log, clasificando la información en base a modelos de captura de datos.

Estos modelos de captura de datos son básicamente expresiones regulares e identificadores, que nos permitirán analizar los orígenes de datos y mostrarlos como un gráfico.


Para acceder a las opciones avanzadas pulse en Advanced options. Se mostrará un formulario donde podrá elegir el tipo de vista de resultados:

- Mostrar entradas de log (texto plano). - Mostrar gráfica de log.

Graph log.png

Bajo la opción mostrar gráfica de log podemos seleccionar el modelo de captura.

El modelo por defecto, Apache log model, ofrece la posibilidad de parsear logs de Apache en formato estándar (access_log), pudiendo extraer gráficas comparativas de tiempo de respuesta, agrupando por página visitada y código de respuesta:

Graph log2.png

Al pulsar en el botón de editar, editaremos el modelo de captura seleccionado. Con el botón de crear agregaremos un nuevo modelo de captura.


Graph log3.png


En el formulario que aparece, podremos elegir:

Título
un nombre para el modelo de captura.
Una expresión regular de captura de datos
cada campo a extraer se identifica con la subexpresión entre los paréntesis (expresión a capturar).
Los campos
en el orden en que los hemos capturado con la expresión regular. Los resultados se agruparán por la concatenación de los campos clave, que son aquellos cuyo nombre no esté entre guiones bajos:
clave, _valor_


clave1,clave2,_valor_


clave1,_valor_,clave2


Observación: Si no especificamos un campo valor, será automáticamente el conteo de apariciones que coinciden con la expresión regular.

Observación 2: Si especificamos una columna valor podremos elegir entre representar el valor acumulado (comportamiento por defecto) o marcar el checkbox para representar el promedio.

Ejemplo

Si quisiéramos extraer entradas de un log con el siguiente formato:

Sep 19 12:05:01 nova systemd: Starting Session 6132 of user root.
Sep 19 12:05:01 nova systemd: Starting Session 6131 of user root.


Para contar el número de veces que se ha iniciado sesión, agrupando por usuario, usaremos:


Expresión regular

Starting Session \d+ of user (.*?)\.


Campos:

username


Este modelo de captura nos devolverá el número de inicios de sesión por usuario del intervalo de tiempo que seleccionemos.


Graph log4.png

1.6 Configuración de los agentes

La recolección de logs se hace mediante los agentes, tanto en el agente Windows como en los agentes Unix (Linux, MacOsX, Solaris, HPUX, AIX, BSD, etc). En el caso de los agentes Windows, también se puede obtener información del visor de eventos de Windows, utilizando los mismos filtros que en el módulo de monitorización del visor de eventos.

Veamos dos ejemplos para capturar información de logs, en Windows y en Unix:

1.6.1 En Windows

module_begin
module_name Eventlog_System
module_type log
module_logevent
module_source System
module_end 
module_begin
module_name PandoraAgent_log
module_type log
module_regexp C:\archivos de programa\pandora_agent\pandora_agent.log
module_description This module will return all lines from the specified logfile
module_pattern .*
module_end

En ambos casos, la única diferencia de un módulo de monitorización a la definición de una fuente de log, es:

module_type log 

Esta nueva sintaxis solo la entiende el agente de la versión 5.0, por lo que debe actualizar los agentes si quiere utilizar esta nueva funcionalidad Enterprise.

Template warning.png

Para definir módulos de log en Windows será necesario hacerlo directamente en el fichero de configuración del agente. Si se crean directamente desde la consola, los módulos se quedarán en estado no inicializado.

 


1.6.2 Sistemas Unix

En Unix se utiliza un nuevo plugin, que viene con el agente de la versión 5.0. Su sintaxis es bien sencilla:

module_plugin grep_log_module /var/log/messages Syslog \.\*

Similar al plugin de parseo de logs (grep_log), el plugin grep_log_module envía la información procesada del log al colector de logs con el nombre de "Syslog" como origen del log. Utiliza la expresion regular \.\* (en este caso "todo") como patrón a la hora de elegir qué líneas enviamos y cuáles no.


Volver a Indice de Documentacion Pandora FMS