Pandora: Metaconsole: Documentation en: Installation

From Pandora FMS Wiki
Revision as of 14:10, 10 October 2013 by Julia (talk | contribs) (Giving access to the Metaconsole)
Jump to: navigation, search

Go back to Pandora FMS documentation index


1 Installation and Configuration

In this section will be included all the aspects needed in order to install and configure a Metaconsole and their Instances.


1.1 Installation

The installations of the Instances and the Metaconsole requires to be hosted in servers that are communicated in both ways.

In order to do these we should verify that:

  • The Metaconsole can contact with the Instances
  • The Instances can contact with the Metaconsole

Info.png

The Instances don't need to be communicated between them at any moment

 


To understand better this requirement you can take a look to Arquitectura de la Metaconsola.

The timezone setting should see the same. The more synchronized would be the Instances and Metaconsole would be, more exact will be the visualized data.

For example: If an Instance has 5 minutes of difference with the Metaconsole, the visualization of the time that have passed since their events were generated when these data are shown in the Metaconsole they will be false.


1.1.1 Instances

One Instance is a Pandora FMS Enterprise typical installation

One instance is composed of one Server and one Web Console

All details about how to install the Instances will be found in the documentation section Instalación de Pandora FMS

1.1.2 Metaconsole

A Metaconsole is a Pandora FMS Enterprise installation with a metaconsole license.

Info.png

It is not possible to use at the same tame the Pandora FMS console and the Metaconsole

 


The Metaconsole is only the Web Console It doesn't use server so it will not host agent neither monitors

In some cases it could be necessary the server libraries to execute the database maintenance script in the Metaconsole. To simplify it, this is done installing the server but without firing it. More info at:

Configuración adicional de la metaconsola

1.1.3 Additional Configuration of the Metaconsole

The Metaconsole, if the node events replication has been activated, store event data in its own database. For their maintenance these data can be deleted and/or move to the metaconsole history event ddb. THis is done, as in a pandora instance, through the execution of the ddbb maintenance script that is at/usr/share/pandora_server/util/pandora_db.pl. Usually, to launch it the server file is used, only that as it is a metaconsole, there is no server. To do this, get a copy o fhe file /etc/pandora/pandora_server.conf from one of the nodes, edit it, and modify the data related to the DDBB (hostname, DDBB name, user and password) and save the file, for example as:

/etc/pandora/pandora_meta.conf

Create an script at /etc/cron.daily/pandora_meta_db with the following content:

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

And modify the permissions of it through chmod:

chmod 755 /etc/cron.daily/pandora_meta_db

In order to could execute it , it is necessary that you have installed the necessary packages to execute (even if it doesn't) the Pandora FMS server and its Enterprise part.

Execute it manually to check that it works and it doesn't report errors:

/etc/cron.daily/pandora_meta_db

1.2 Configuration

In order that Instances could communicate with the Metaconsole and vice versa, you should configure both sides correctly.


1.2.1 Instances

In Instances, there are a serial of parameters to warranty the access of your data with the Metaconsole.


1.2.1.1 Giving access to the Metaconsole

The Metaconsole could have access to one Instance in two different ways:


  • Remote access to the Data Base to see and edit the data stored in the instances.
  • Access to the to the API for some actions like the edition of configuration files or the NetFlow monitoring

The Instance should be configured to guarantee both accesses to the Metaconsole.


1.2.1.1.1 Database

It will be necessary to know the database credentials to configure later the Instance in the Metaconsole.(Host, Database, Users and Password).

Other important thing is to give permissions to the user so he could have remote access to the database.

It is done with the MySQL GRANT command:


GRANT ALL PRIVILEGES on <MetaconsoleDatabaseName>.* to <UserName>@<HostAddress> IDENTIFIED BY <UserPass>;
1.2.1.1.2 API

The access to the Instance API will be guaranteed with the following parameters:

  • User and password: It should be necessary to know a valid user and password in the Instance.
  • API password: It should be necessary to know the access password to the API that is configured in the Instance.
  • IPs List with access to the API: In the Instance configuration, there is an IPs list that could have access to the API. It is possible to use '*' as wildcart to give access to all IPs or to one subnet

1.2.1.2 Auto-autenticación

En algunas partes de la metaconsola hay accesos a la Consola Web de la Instancia.

Por ejemplo, en el visor de eventos al pinchar en el Agente asociado a un evento (si lo hay) nos llevará a la vista de ese agente en la consola de la Instancia a la que pertenece.

Para este acceso se utiliza Auto-autenticación.

Esta autenticación se realiza con un hash para el que se necesita una cadena configurada en la Instancia: La contraseña de auto identificación.

Esta configuración no es necesaria para configurar la Instancia en la Metaconsola, pero sin ella, al pinchar en uno de los enlaces que nos llevan a la Instancia, tendremos que autenticarnos.

1.2.1.3 Replicación de eventos

Para que en la Metaconsola se vean los eventos de las Instancias, estas tienen que tener acceso a la base de datos de la Metaconsola.

Las Instancias replicarán cada cierto tiempo sus eventos almacenando la fecha y hora del último replicado para continuar desde ahí la próxima vez.

Además de replicar los eventos, harán efectiva la autovalidación en la Metaconsola. Esto es, para los eventos que están asociados a un módulo, cuando repliquen el evento a la Metaconsola, validarán todos los eventos anteriores asignados al mismo módulo.

Para configurar la replicación de eventos, en el apartado de Configuración Enterprise de las Instancias activaremos la Replicación de Eventos.

Se configurará:

  • Intervalo: Cada cuantos segundos el servidor replicará los eventos generados desde la última replicación a la base de datos de la Metaconsola.

Info.png

Si se tiene configurado por ejemplo 60 segundos, la primera replicación sucederá a los 60 segundos de haber iniciado el servidor.

 


  • Modo de replicación: Si se replicarán todos los eventos o solo los validados.
  • Mostrar lista de eventos en consola local (solo lectura): Cuando la replicación de eventos está activada, la gestión de los eventos se lleva a cabo en la metaconsola y en la instancia no se tiene acceso a ellos. Con esta opción se tendrá acceso a una vista de los eventos en modo solo lectura.
  • Credenciales de la base de datos de la Metaconsola: Host, Base de datos, Usuario, Contraseña y Puerto (Si el puerto no se indica se utilizará el puerto por defecto)


Replication events setup.png



La replicación de eventos la hace el servidor. En el fichero de configuración debe haber un token habilitado: event_replication 1



Replication events conf token.png



Template warning.png

Para hacer efectivo cualquier cambio de configuración en la replicación de eventos será necesario reiniciar el servidor.

 


1.2.2 Metaconsola

1.2.2.1 Dar acceso a las Instancias

De igual modo que las Instancias dan permisos a la Metaconsola para acceder remotamente a la base de datos, la Metaconsola debe realizar lo mismo para que las Instancias puedan replicar sus eventos.

1.2.2.2 Configuración de las Instancias

En el apartado de Metasetup, se podrá configurar las Instancias con las que se enlazará la Metaconsola.

La configuración de una instancia tiene una serie de parámetros que debemos configurar y obtener de las Instancias:



Configure Instances editor.png



En la vista de las Instancias configuradas veremos que las instancias pueden ser editadas, desactivadas y eliminadas.

Además hay unos indicadores que chequean cierta información de la configuración de cada Instancia. Esos chequeos se hacen al cargar esta vista, pero también se pueden hacer individualmente haciendo click sobre ellos.



Configure Instances list.png



Los indicadores son los siguientes:

  • Base de datos: Si hemos configurado mal la base de datos de la Instancia o no tenemos los permisos necesarios, el indicador estará en rojo y nos dará información del problema.
  • API: Este indicador hará una prueba a la API de la Instancia. Si falla nos dará información del fallo.
  • Compatibilidad: Este indicador hace un chequeo de algunos requisitos que tiene que haber entre Instancia y Metaconsola. El nombre del servidor de la Instancia, por ejemplo, debe coincidir con el nombre que se le dé en su configuración en la Metaconsola.
  • Replicación de eventos: Este indicador indica si la Instancia tiene activada la replicación de eventos y si ya se han recibido eventos de la Instancia hace cuánto tiempo fue la última replicación.

Los tres primeros indicadores deben estar verdes para que la Instancia esté debidamente enlazada y comencemos a ver sus datos. En cambio el indicador de Replicación de eventos sólamente nos da información de esta característica.


Info.png

Una Instancia puede estar bien configurada pero sin replicar sus eventos

 


1.2.2.3 Escalado de índices

La mayor parte de la sincronización entre metaconsola e instancas se realiza por nombre, independientemente del ID interno de los elementos.

Una excepción son los grupos, cuyos IDs es importante que estén sincronizados.

Para asegurar que los IDs de los grupos que se sincronizan desde la metaconsola no existan en las instancias, aumentaremos el valor AUTO_INCREMENT de la tabla tgrupo sensiblemente. De este modo, daremos un margen amplio por si se crean grupos en las instancias por causas ajenas a la metaconsola.

Para ello ejecutaremos en la base de datos de la metaconsola la siguiente consulta:

ALTER TABLE tgrupo AUTO_INCREMENT = 3000;

Info.png

Si se sospecha que el número de grupos de una instancia creados de forma ajena a la metaconsola puede superar los 3000, se puede configurar un valor superior.

 


Go back to Pandora FMS documentation index