Pandora: Documentation es: Gestion y Administracion Server

From Pandora FMS Wiki
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Mantenimiento de los servidores de Pandora FMS

1.1 Gestión de la base de datos

La infraestructura de Pandora FMS no necesita mantenimiento externo, pero es muy importante purgar y depurar los datos antiguos, así como mantener la base de datos lo más compacta posible. Por ello, existe una herramienta esencial para el buen funcionamiento de Pandora FMS que se encarga de realizar estas tareas, y la cual está ubicada en:

/usr/share/pandora_server/util/pandora_db.pl

O para la versión Enterprise de Pandora FMS en:

/usr/bin/pandora_db

Esta herramienta, en adelante pandora_db, está incluida en el paquete del servidor de Pandora FMS, por lo que debe ejecutarse desde un sistema donde haya un servidor de Pandora FMS instalado. Si por ejemplo se cuenta con dos sistemas, uno de ellos con el servidor y otro con la consola, pandora_db se deberá ejecutar desde el sistema donde se aloja el servidor de Pandora FMS.

Pandora_db es una herramienta crucial para el correcto funcionamiendo de Pandora FMS, y por ello su ejecución se programa en las tareas cron del sistema con una periodicidad horaria. Su ejecución está configurada dentro del fichero:

/etc/cron.hourly/pandora_db

Esta herramienta realiza todas las tareas de mantenimiento de la base de datos de forma automática, las cuales son:

  • Elimina datos antiguos.
  • Compacta datos existentes, interpolándolos en varios intervalos, de tal modo que los gráficos sean los mismos pero el espacio necesario para almacenarlos sea muchísimo menor (esta es una de las razones por las que Pandora FMS es capaz de procesar tanta información).
  • Verifica la consistencia de la base de datos para módulos no existentes, o para módulos que no se usen porque no pueden ser iniciados (Esos módulos aparecen en la vista tácnica como módulos no inicializados).
  • Elimina la información diaria de contacto del agente. Pandora FMS no necesita más de 24hr de históricos de contacto por agente, y si se acumula, ralentiza mucho el acceso a la base de datos.
  • En la versión enterprise, mueve todos los datos antiguos a la base de datos auxiliar de histórico.

Como mencionábamos, la ejecución de pandora_db se configura en las tareas cron del sistema, y aunque en una instalación del servidor de Pandora FMS se incluye esta ejecución de forma automática, es conveniente revisar que así sea. Para ello el fichero /etc/cron.hourly/pandora_db debe existir y contener la línea:

"/usr/share/pandora_server/util/pandora_db.pl" "/etc/pandora/pandora_server.conf" >/dev/null 2>&1

O en la versión Enterprise de Pandora FMS:

"/usr/bin/pandora_db" "/etc/pandora/pandora_server.conf" >/dev/null 2>&1

También es importante fijarse en los permisos y en el propietario del fichero. Los permisos adecuados del fichero serían "-rwxr-xr-x", es decir 755, los cuales se pueden asignar ejecutando:

chmod 755 /etc/cron.hourly/pandora_db

En cuanto al propietario, debe ser "root" tanto para el usuario como para el grupo, lo cual se puede lograr ejecutando:

chown root:root /etc/cron.hourly/pandora_db

Finalmente, se puede verificar que la ejecución sea correcta manualmente mediante el comando:

"/usr/share/pandora_server/util/pandora_db.pl" "/etc/pandora/pandora_server.conf"

O en la versión Enterprise de Pandora FMS:

"/usr/bin/pandora_db" "/etc/pandora/pandora_server.conf"

Debería mostrar una salida similar a esta (puede que con menos información, en función del nivel de verbosity en el fichero de configuración de Pandora FMS):

Pandora FMS DB Tool 7.0NG.719 PS180221 Copyright (c) 2004-2015 Artica ST
This program is Free Software, licensed under the terms of GPL License v2
You can download latest versions and documentation at http://www.pandorafms.org

Pandora DB now initialized and running (PURGE=7 days, COMPACT=0 days, STEP=1) .

 [*] Pandora FMS Enterprise module loaded.

Starting at 2018-03-12 12:40:54
12:40:55 [PURGE] Deleting old extended session data.
12:40:55 [PURGE] Deleting old inventory data.
12:40:55 [PURGE] No data in tagente_datos_inventory.
12:40:55 [PURGE] No data to purge in tagente_datos.
12:40:55 [PURGE] Deleting old export data from tserver_export_data

12:40:55 [PURGE] Deleting old session data from tsessions_php

12:40:55 [PURGE] No data in tagente_datos_log4x.
12:40:55 [PURGE] No data in tagente_datos_string.
12:40:55 [PURGE] Deleting old event data at tevento table (More than 7 days).
12:40:55 [PURGE] Deleting old audit data (More than 7 days).
12:40:55 [PURGE] Deleting old SNMP traps (More than 7 days).
12:40:55 [ENTERPRISE] Deleting old policy queue entries (More than 7 days)...
12:40:55 [ENTERPRISE] Deleting invalid service elements...
12:40:55 [PURGE] Deleting old GIS data (More than 7 days).
12:40:55 [PURGE] Deleting pending delete modules (data table).
12:40:55 [PURGE] Deleting pending delete modules (status, module table).
12:40:55 [PURGE] Deleting old access data (More than 24hr)
12:40:55 [PURGE] No agent access data to purge.
12:40:55 [PURGE] Delete contents in report that have some deleted modules.
12:40:55 [PURGE] Delete contents in report that have some deleted agents.
12:40:55 [PURGE] Delete empty contents in report (like SLA or Exception).
12:40:55 [PURGE] Delete autodisabled agents where last contact is bigger than 30 days.
12:40:55 [PURGE] Deleting old netflow data.
12:40:55 [PURGE] Deleting old log data.
12:40:55 [PURGE] Deleting log data older than 90 days.
12:40:55 [PURGE] Deleting old special days.
12:40:55 [CHECKDB] Ignoring not-init data.
12:40:55 [CHECKDB] Checking database consistency (Missing status).
12:40:55 [CHECKDB] Checking database consistency (Missing module).
12:40:55 [CHECKDB] Updating empty aliases.
12:40:55 [INTEGRITY] Cleaning up group stats.
12:40:55 [INTEGRITY] Deleting orphan alerts.
12:40:55 [INTEGRITY] Deleting orphan modules.
[HISTORYDB] Moving data older than 5 days to the history DB...
[HISTORYDB] Moving events older than 5 days to the history DB...
12:40:55 [ENTERPRISE] Moving SNMP modules back to the Enterprise SNMP Server.
12:40:55 [ENTERPRISE] Dynamically updating critical min and max values.
Ending at 2018-03-12 12:40:55

1.2 Ejecución manual de la herramienta de mantenimiento

Si se considera necesario, es posible lanzar la ejecución de pandora_db manualmente tal y como veíamos en el apartado anterior. Basta con ejecutar desde una consola shell el comando:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf

O en la versión Enterprise de Pandora FMS:

/usr/bin/pandora_db /etc/pandora/pandora_server.conf

Template warning.png

En sistemas sobrecargados esto puede llevar horas, por lo que se recomienda dejar el proceso en segundo plano

 


Para ejecutar manualmente la herramienta de mantenimiento y dejarla en segundo plano, se debe ejecutar:

nohup /usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf

O en la versión Enterprise de Pandora FMS:

nohup /usr/bin/pandora_db /etc/pandora/pandora_server.conf

El proceso llevará algún tiempo hasta que se cargue completamente en segundo plano, después se podrá cerrar la ventana de la consola shell sin problemas, mientras que el proceso se seguirá ejecutando.

Info.png

En algunas instalaciones el directorio de las herramientas puede variar, el más común es:

/usr/share/pandora_server/util/

En las versiones anteriores de Pandora FMS, puede encontrarse en:

/usr/share/pandora/util/

 


Template warning.png

Es importante que se asegure de utilizar la versión actual de la herramienta, y no la de una versión anterior. Si ejecuta el programa sin argumentos, se mostrará la versión de la herramienta en la cabecera del mensaje

 


1.3 Respaldo (Backup) de la base de datos

Mediante el comando mysqldump podemos realizar un volcado completo de la base de datos, tanto de la estructura de las tablas como de los contenidos de las mismas. Este comando tiene varias opciones para la realización de backups, aunque nos limitaremos a ver su uso más estándar, es decir, realizar un volcado desde el mismo sistema en el que se aloja la base de datos. Para ello deberemos indicar el nombre de la base de datos de la que se hará el backup y las credenciales de acceso a la misma:

mysqldump -u <usuario> -p <base_de_datos>

Por ejemplo, para realizar un backup de la base de datos "pandora" y volcando el resultado a un fichero podríamos ejecutar:

mysqldump -u root -p pandora > /backup/pandoradb_backup.sql

De esta forma tendríamos una copia de nuestra base de datos en el fichero /backup/pandoradb_backup.sql.

A partir de un backup realizado de esta forma, podemos hacer una restauración completa de nuestra base de datos. El proceso es sencillo, basta con iniciar sesión en MySQL, crear la base de datos que se restaurara y cargar el backup en esa base de datos. Siguiendo el ejemplo anterior, bastaría con ejecutar estos comandos:

[[email protected] ~]# mysql -u root -p
mysql> create database pandora;
mysql> use pandora;
mysql> source /backup/padnoradb_backup.sql

Finalmente, sería necesario establecer de nuevo los permisos del usuario configurado tanto en la consola de Pandora FMS como en el servidor para que ambos tengan acceso total a la base de datos:

grant all privileges on pandora.* to [email protected] identified by 'mypassword';

Template warning.png

Es importante recordar que esto SOLO realiza un backup/restauración de la de base de datos

 


1.4 Respaldo y recuperación completa de Pandora FMS

En el apartado anterior hemos visto como realizar un backup completo de la base de datos de Pandora FMS, y en este apartado veremos los pasos para realizar un backup completo de todo Pandora FMS y como restaurarlo.

Existe un script en la distribución del servidor de Pandora FMS que sirve para hacer un backup y una restauración completa de todo Pandora FMS. Este script esta pensado para hacer copias y restauración en sistemas donde el servidor y la consola se ubican en la misma máquina. Si en su entorno hay diferentes componentes, deberá utilizar la herramienta con los parámetros mas adecuados para su uso o modificarlos para que se adapten a sus circunstancias.

Para que pueda hacer sus tareas, este script necesita ejecutarse como root.

Este script está ubicado en:

/usr/share/pandora_server/util/pandora_backup.sh

Si lo ejecutamos sin parámetros nos dará una ayuda:

Pandora FMS Command line backup tool. http://www.pandorafms.org
(c) 2009-2015 Sancho Lerena <[email protected]>, Artica Soluciones Tecnologicas

Syntax:
                -c Path to Pandora FMS console, p.e: /srv/www/htdocs/pandora_console
                -d Destination path for backup file. p.e: /tmp
                -s Source filename for backup restore. p.e: /tmp/pandorafms
                -f Restore also files
                -q Quiet. No output message (used for scripts/cron)
                -b No database backup/restore


Please BE SURE TO USE RESTORE (-s) option. This will OVERWRITE ALL your
PandoraFMS install, including files, configuration and data. Please backup first!

Este script está diseñado para hacer copias de seguridad y restauración de los siguientes componentes:

  • Fichero(s) de configuración del servidor.
  • Ficheros(s) pendientes de ejecución, así como ficheros de configuración remotos de los agentes.
  • BBDD completa.
  • Consola WEB completa.

Opciones de origen y destino de la copia

Este script obtiene las credenciales de acceso a la BBDD directamente de la configuración de la consola WEB, por ello hay que pasar, con el parámetro -c la ruta completa a la consola WEB. Ese mismo parámetro sirve también para que realice el backup de la propia consola web.

El destino del backup se especifica con el parámetro -d. En esa ruta dejará el fichero de backup, comprimido, con un nombre similar a pandorafms_backup_xxxxxxx.tar.gz.

De esta forma con el siguiente comando se puede realizar un backup de todo el entorno:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -d /tmp/

Con el parámetro -b se puede indicar que no se realice backup de la base de datos, quedando la ejecución así:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -d /tmp/ -b

Restauración de la base de datos

Para restaurar la base de datos con el script, simplemente tenemos que sustituir el parámetro -d por -s, indicando en este caso la ruta al backup realizado:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -s /tmp/pandorafms_backup_2018-03-12-15-16-53.tar.gz

Esta es la restauración por defecto, sin incluir los ficheros.

Restauración de la base de datos y los ficheros

La opción -f permite restaurar también los ficheros (sobreescribiendo los actuales) de una copia de seguridad. Dado que sobreescribir los ficheros actuales de configuración puede tener consecuencias serias, es necesario utilizar -f si queremos proceder a una recuperación de un backup y queremos que restaure todos los ficheros de Pandora (Consola y servidor).

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -s /tmp/pandorafms_backup_2018-03-12-15-16-53.tar.gz -f

Restauración solo de ficheros (sin base de datos)

Igual que en el primer caso, podemos restaurar únicamente los ficheros, sin incluir la base de datos. Para ello se incluye la opción -b a la ejecución anterior:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -s /tmp/pandorafms_backup_2018-03-12-15-16-53.tar.gz -f -b

1.4.1 Ejemplos de uso

Crear backup

Como ya hemos visto, para crear un backup completo de Pandora FMS basta con ejecutar:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -d /tmp/

Debería devolver una línea como esta:

Backup completed and placed in /tmp//pandorafms_backup_2018-03-12-15-33-13.tar.gz

Indicando la ubicación exacta del backup (en este caso /tmp//pandorafms_backup_2018-03-12-15-33-13.tar.gz).

Restaurar backup

Para restaurar el backup de forma automática, es necesario contar con una consola configurada con las credenciales de autenticación sobre la base de datos. En ese caso, basta con ejecutar:

/usr/share/pandora_server/util/pandora_backup.sh -c /var/www/html/pandora_console/ -s /tmp/pandorafms_backup_2018-03-12-15-33-13.tar.gz -f

Debería devolver una salida como esta:

Detected Pandora FMS backup at /tmp/pandorafms_backup_2018-03-12-15-33-13.tar.gz, please wait...
Dropping current database
Restoring backup database
Restoring files and configuration
Done. Backup in /tmp/pandorafms_backup_2018-03-12-15-33-13.tar.gz restored

Restaurar backup en caso de perdida de la consola

Si ha perdido la consola de Pandora FMS pero conserva un backup generado por esta herramienta, primero tendra que regenrar el directorio de la consola. Para ello, descomprima manualmente su backup:

cd /tmp
tar zxvf pandorafms_backup_2018-03-12-15-33-13.tar.gz

Esto descomprimirá en /tmp el directorio completo de su consola WEB, en el caso del backup generado en el ejemplo anterior, crea un directorio llamado:

/tmp/var/www/html/pandora_console

Copie el contenido de todo ese directorio a su directorio de publicación web, que puede variar en función de la distribución que use:

cp -R /tmp/var/www/html/pandora_console /var/www/html

Luego restaure el backup de manera ordinaria.

1.5 Arranque/parada manual de los servidores de Pandora FMS

Para arrancar y/o parar de forma manual el servidor de Pandora FMS se ha de ejecutar lo siguiente en una consola shell:

  • Parar el demonio:
/etc/init.d/pandora_server stop
  • Iniciar el demonio:
/etc/init.d/pandora_server start
  • Reiniciar el demonio:
/etc/init.d/pandora_server restart

1.6 Watchdog para los servidores de Pandora FMS

En el repositorio de código existe un pequeño script que se utiliza como "perro guardian" (Watchdog), el cual realiza una monitorización de Pandora. De esta forma podemos realizar una operacion de recuperación (intentar levantar Pandora), y si esta falla, podemos avisar del suceso.

1.6.1 pandora_watchdog.sh

#!/bin/bash
# Copyright (c) 2005-2012 Artica ST
# Author: Sancho Lerena <[email protected]> 2009
# Licence: GPL2
#
# daemon_watchdog
#
# Generic watchdog to detect if a daemon is running. If cannot restart, execute
# a custom-user defined command to notify daemon is down and continues in
# standby (without notifying / checking) until daemon is alive again.  

# Default configuration is for Pandora FMS Server daemon 

# =====================================================================
# Configuration begins here. Please use "" if data contain blank spaces 

export DAEMON_WATCHDOG=pandora_watchdog.sh
# DAEMON_WATCHDOG: Name of this script. Used to check if its running already

export DAEMON_CHECK="/usr/bin/pandora_server /etc/pandora/pandora_server.conf"
# DAEMON_CHECK: Daemon monitored, please use full path and parameters like
#               are shown doing a ps aux of ps -Alf

export DAEMON_RESTART="/etc/init.d/pandora_server restart"
# DAEMON_RESTART: Command to try to restart the daemon

export DAEMON_DEADWAIT=90
# DAEMON_DEADWAIT: Time this script checks after detect that
#                  daemon is down before to consider is really down. 

export DAEMON_ALERT="/usr/bin/pandora_alert"
# DAEMON_ALERT: Command/Script executed if after detecting daemon is down,
#               and waiting DAEMON_DEADWAIT, and daemon continues down.

export DAEMON_LOOP=7
# DAEMON_LOOP: Interval within daemon_wathdog checks if daemon is alive.
#              DO NOT use values under 3-5 seconds or could be CPU consuming.
#              NEVER NEVER NEVER use 0 value or gets 100% CPU!.

# Configuration stop here
# =====================================================================

# Check if another instance of this script

RUNNING_CHECK=`ps aux | grep "$DAEMON_WATCHDOG" | grep -v grep |wc -l`
if [ $RUNNING_CHECK -gt 2 ]
then
        echo "Aborting, seems that there are more '$DAEMON_WATCHDOG' running in this system"
        logger $DAEMON_WATCHDOG aborted execution because another watchdog seems to be running
        exit -1
fi


# This value always must be 0 at start. Do not alter
export DAEMON_STANDBY=0

# This function replace pidof, not working in the same way in different linux distros
function pidof_daemon () (
        # This sets COLUMNS to XXX chars, because if command is run
        # in a "strech" term, ps aux don't report more than COLUMNS
        # characters and this will not work.
        COLUMNS=300
        DAEMON_PID=`ps aux | grep "$DAEMON_CHECK" | grep -v grep | tail -1 | awk '{ print $2 }'`
        echo $DAEMON_PID
) 

# Main script 
 
if [ ! -f `echo $DAEMON_CHECK | awk '{ print $1 }'` ]
then
        echo "Daemon you want to check is not present in the system. Aborting watchdog"
        exit
fi

while [ 1 ]
do

        DAEMON_PID=`pidof_daemon`
        if [ -z "$DAEMON_PID" ]
        then

echo "Checkpoint #1 $DAEMON_PID "

                if [ $DAEMON_STANDBY == 0 ]
                then 

                        # Daemon down, first detection
                        # Restart it !

                        logger $DAEMON_WATCHDOG restarting $DAEMON_CHECK
                        $DAEMON_RESTART 2> /dev/null > /dev/null

                        # Just WAIT another DAEMON_DEADWAIT before consider it DEAD 

echo "Going to DAEMON_DEADEWAIT"

                        sleep $DAEMON_DEADWAIT
                        DAEMON_PID=`pidof_daemon`

                        if [ -z "$DAEMON_PID" ]
                        then

                                # Is dead and can't be restarted properly. Execute alert

echo "I cannot startup again the process"

                                logger $DAEMON_WATCHDOG $DAEMON_CHECK is dead, alerting !
                                $DAEMON_ALERT  2> /dev/null > /dev/null 

                                # Watchdog process puts in STANDBY mode until process get alive again
                                logger $DAEMON_WATCHDOG "Entering in Stabdby mode"

                                DAEMON_STANDBY=1
                        fi
                fi
        else

echo "Checkpoint #1B $DAEMON_PID "

                DAEMON_STANDBY=0
        fi

        sleep $DAEMON_LOOP
done

1.6.2 /usr/bin/pandora_alert

En este fichero se debe definir el código que se ejecutará cuando el proceso watchdog no pueda levantar el servidor de Pandora FMS. En nuestro ejemplo, además de avisar mediante un SMS, detiene el servidor de Tentacle:

#!/bin/bash
sendsms +34458474843 "Se ha caido el servidor de Pandora y no se puede levantar"
/etc/init.d/tentacle_serverd stop

Será necesario conceder permisos de ejecución sobre este script:

chmod 750 /usr/bin/pandora_alert

1.6.3 Arranque del watchdog

Para lanzar el watchdog y dejarlo corriendo en segundo plano, podemos ejecutar lo siguiente:

nohup /usr/share/pandora_server/util/pandora_watchdog.sh &

Template warning.png

A la hora de iniciar un watchdog, tenga en cuenta que si por cuestiones de mantenimiento quiere detener manualmente el servidor de Pandora FMS, tendrá que detener también previamente el proceso del watchdog para evitar que de forma automática intente iniciar el servicio continuamente

 


1.7 Base de datos de histórico

Una base de datos de histórico es una base de datos a la que se mueven datos antiguos de módulos para mejorar la respuesta de la base de datos principal de Pandora FMS, dejando esos datos accesibles para la consola de forma transparente al ver informes, gráficas de módulos, etc.

1.7.1 Configurando una base de datos de histórico

Para configurar una base de datos de histórico será necesario contar con un nuevo servidor en el que alojarla (distinto al de la base de datos principal). Una vez contamos en ese servidor con MySQL instalado, basta con seguir estos pasos:

  • Cree la nueva base de datos de histórico:
[[email protected] ~]# mysql -u root -p
mysql> create database pandora_history;
  • Cree el esquema de la base de datos de Pandora FMS. Puede utilizar el script /var/www/html/pandora_console/pandoradb.sql incluido en la consola de Pandora FMS, copiandolo al servidor de la base de datos de histórico:
cat pandoradb.sql | mysql -u root -p -D pandora_history
  • Conceda permisos a un usuario el cual se utilizará desde el servidor y la consola de Pandora FMS para enviar y consultar los datos de histórico:
GRANT ALL PRIVILEGES ON pandora_history.* TO 'user'@'%' IDENTIFIED BY 'password';
  • En la consola de Pandora FMS vaya a Setup > Setup > History database y configure el host, puerto, base de datos, usuario y contraseña para acceder a la base de datos de histórico.


History db.png


Los últimos campos de este formulario (Days, step y delay) definirán la forma en que se enviaran los datos a la base de datos de histórico, es decir, los datos con más Days días de antigüedad se moverán a la base de datos de histórico en bloques de Step filas esperando Delay segundos entre un bloque y el siguiente para evitar sobrecargas.

En esta misma pantalla también se puede decidir si enviar a la base de datos de histórico los eventos con más de Event days días de antigüedad, aunque hay que tener en cuenta que incluir los eventos aumentará considerablemente el ritmo de crecimiento de la base de datos de histórico, y que éstos solo se consultarán a la hora de generar informes, no en la vista de eventos.

Info.png

La base de datos de histórico es una característica de la versión Enterprise que se vale del binario /usr/bin/pandora_db para transferir los datos

 


1.7.2 Configurando la gestion del purgado y compactación de la base de datos de histórico

La base de datos de histórico se supone que contiene "todos los datos" del sistema (sin límite), pero si quiere borrar datos o compactarlos de la base de datos de historico, necesitará ejecutar el script pandora_db usando unos datos "trucados" y un fichero de configuración falso, para hacerle creer al script que está trabajando con una base de datos "normal".

El primer paso es meter algunos datos en la tabla tconfig de su base de datos de histórico. Utilice estas consultas SQL para crear una configuración minima, y configurar el comportamiento de pandora_db al ejecutarse contra la BBDD de histórico. Primero, necesita conectar a su BBDD usando el CLI de MySQL.

Este es un ejemplo, reemplace los valores conforme a sus criterios (pero deje history_db_enabled a cero):

INSERT INTO `tconfig` VALUES (1,'days_purge','180');
INSERT INTO `tconfig` VALUES (2,'history_db_enabled','0');
INSERT INTO `tconfig` VALUES (3,'days_compact','120');
INSERT INTO `tconfig` VALUES (4,'step_compact','1');
INSERT INTO `tconfig` VALUES (5,'event_purge','180');
INSERT INTO `tconfig` VALUES (6,'string_purge','180');

Este ejemplo, es para que la base de datos de histórico almacene en total seis meses desde la fecha de ejecución, y compacte datos con más de 4 meses. Si tiene un mes en su BBDD principal, en total tendrá datos para seis meses, ya que el último mes no tiene datos en la BBDD de histórico pero si en la principal. Puede poner aquí cualquier valor, no hay límite en el almacenamiento de la BBDD de histórico. Simplemente recuerde que la base de datos de histórico debe estar en un servidor físico independiente de la BBDD principal y de Pandora.

El segundo paso es crear un fichero pandora_server.conf adicional. Utilice esta version "reducida" que le proponemos para crear el suyo propio, y llámelo /etc/pandora/pandora_server_history_db.conf :

dbengine mysql
dbname pandora_history
dbuser user
dbpass password
dbhost 192.168.70.140
log_file /var/log/pandora/pandora_db_history.log

Ahora ya puede ejecutar la herramienta pandora_db contra la configuración de la BBDD de histórico y programarla para su ejecución periódica:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server_history_db.conf

Info.png

Este proceso NO DEBERIA afectar a la operacion principal, ya que está ejecutándose contra una BBDD diferente en un servidor diferente

 


Volver a Indice de Documentacion Pandora FMS