Metaconsola

Volver al Índice de Documentación Pandora FMS

Esta sección se conserva debido a propósitos históricos.

Si ya conocía Pandora FMS antes de la versión 5.0, sabrá que ya existía el concepto de Metaconsola.

En esta sección analizaremos las diferencias de la Metaconsola actual con la antigua, los problemas resueltos y las mejoras planteadas.

Antes de la versión 5.0, una instalación normal (Consola + Servidor) de Pandora FMS podía actuar, a la vez, como Metaconsola.

La comunicación entre la Metaconsola y las Instancias era unidireccional. La Metaconsola conectaba con las bases de datos de las Instancias y manejaba todos los datos en memoria.

No almacenaba casi nada en la base de datos propia.

La sincronización se realizaba entre las Instancias.

Por ejemplo:

Supongamos que queremos configurar unas plantillas de alertas para que las tengan todas las Instancias.

Deberemos entrar en una de las Instancias, configurarlas, volver a la Metaconsola y sincronizar las plantillas de esa Instancia con las demás.

La Metaconsola era ineficiente, debido a su arquitectura no centralizada. Se hacían muchas conexiones a diferentes bases de datos y la experiencia del usuario era demasiado pobre.

Las opciones disponibles eran insuficientes para obtener el control deseado de los entornos de las Instancias sin salir de la Metaconsola.

En resumen, la Metaconsola era lenta en cuanto tuviese un poco de carga y el usuario estaba muy limitado por sus opciones.

La Metaconsola, a partir de la versión 5.0, es un entorno especial totalmente independiente e incompatible con la consola.

La comunicación entre la Metaconsola y las Instancias es bidireccional. La Metaconsola conecta con las bases de datos de las Instancias y las Instancias replican parte de sus datos a la base de datos de la Metaconsola.

Otros datos como grupos, plantillas de alertas, tags, etc. son almacenados en la Metaconsola.

La sincronización se realiza en un único sentido: de la Metaconsola a las Instancias.

Por ejemplo:

Supongamos que queremos configurar unas plantillas de alertas para que las tengan varias o todas las Instancias.

Sin salir de la Metaconsola podremos configurar las plantillas y sincronizarlas con las Instancias que deseemos.

La Metaconsola, a partir de la versión 5.0, es una herramienta más centralizada, más rápida y mucho más flexible que su predecesora.

Incluye muchas más vistas y utilidades, así como mejoras en las que ya existían.

No maneja todos los datos en memoria, almacenando parte de la información mejorando así la experiencia de usuario.

En la siguiente tabla se observan las diferencias entre las funcionalidades de la Metaconsola antigua y la nueva:

	Antes de la 5.0	A partir de la 5.0
La Metaconsola puede actuar como Instancia
Sincronización	Descentralizada	Centralizada
Comunicación	Unidireccional	Bidireccional
Configuración de las instancias
Panel de usuario
Vista táctica	Por instancias	General y eventos de la última hora
Buscador de agentes
Vista de grupos
Visor de eventos	(Datos en Instancias)	(Datos en Metaconsola)
Vista de árbol
Vista de alertas
Vista de módulos
Mapa de red
Monitorización de tráfico (Netflow)
Herramientas de sincronización	Usuarios/Perfiles Componentes Políticas Alertas OS Module groups	Usuarios/Perfiles Grupos Componentes Alertas Tags
Mover agentes entre instancias
Plantillas de informes
Editores	Informes Consola visual	Usuarios/Perfiles Grupos Componentes Informes Consola visual Alertas Tags Categorías
Aplicar/Cola de Políticas
Monitors view
Custom fields view
Wizard
Visor de consola visual
Configuración de cronjobs

La Metaconsola tiene herramientas de sincronización de elementos, como pueden ser la sincronización de usuarios y grupos, las cuales son fundamentales para la correcta gestión de las Instancias. La sincronización se basa en pasar toda la información creada en la Metaconsola a las distintas Instancias para gestionar desde la Metaconsola toda la información posible de cada una de ellas.

Por ejemplo, un usuario creado en una Instancia, pero no en la Metaconsola, no podrá ser gestionado desde la Metaconsola. En cambio, si tenemos un usuario creado en la Metaconsola y sincronizamos los usuarios, este usuario estará en las Instancias y podremos gestionarlo desde la Metaconsola.

La Metaconsola tiene herramientas de propagación de elementos, como pueden ser la propagación de componentes o el movimiento de agentes entre Instancias (o nodos). A diferencia de la sincronización, no se trata de una herramienta fundamental para el funcionamiento óptimo de la Metaconsola; solo facilita la disponibilidad de los datos en las Instancias, algo que es necesario si, por ejemplo, utilizamos políticas que se aplican en diferentes Instancias (o nodos)

Por ejemplo, podemos querer mover un agente de la Instancia A a la Instancia B para balancear la carga de las Instancias; a través del conjunto de estas herramientas podríamos lograrlo con suma facilidad.

Las instalaciones de las Instancias y la Metaconsola tienen como requisito estar alojadas en servidores que estén comunicados en ambos sentidos.

Por lo que nos tendremos que asegurar de que:

• La Metaconsola puede contactar con las Instancias
• Las Instancias puedan contactar con la Metaconsola

Para entender mejor este requisito puede echar un vistazo a la Arquitectura de la Metaconsola.

La configuración horaria debe ser la misma. Cuanto más sincronizados estén los relojes de Instancias y Metaconsola más exactos serán los datos visualizados.

Por ejemplo, si una Instancia tiene 5 minutos de diferencia respecto a la Metaconsola, la visualización del tiempo transcurrido desde que se generaron sus eventos, cuando se muestren esos datos en la Metaconsola, será falsa.

Una Instancia o nodo es una instalación típica de Pandora FMS Enterprise, compuesta por un servidor y una consola web

Para saber con detalle cómo instalar una instancia podemos visitar el siguiente enlace.

Una Metaconsola es una instalación de Pandora FMS Enterprise con una licencia de Metaconsola.

Es necesario tener activo un servidor para poder realizar distintas operaciones referentes a la Metaconsola, como la “migración”, “autoprovisionamiento”, ejecución de servicios, etc.

Tras instalar la versión Enterprise de la consola de Pandora FMS, sea cual sea el método de instalación se deberá acceder a la consola de Pandora (http://IP/pandora_console/) y le aparecerá una pantalla de bienvenida para aceptar la licencia.

Para saber más acerca de cómo se activa la licencia puede visitar el siguiente enlace.

A partir de la versión 7.0NG de PandoraFMS disponemos de una licencia única para un entorno con Metaconsola. Se podrán crear tantas Instancias como se quiera, siempre y cuando no se sobrepase el número de agentes total dentro de la Metaconsola.

Esta licencia se aplica en la Metaconsola y se puede sincronizar en tantas Instancias como se quiera, permitiendo así la gestión centralizada de los distintos agentes que se desplegarán en dichas Instancias.

Con esta licencia, si empezamos una instalación desde cero, primero deberemos instalar la Metaconsola validando su metalicencia. Una vez validada, registraremos cada una de las Instancias deseadas (se explica en los siguientes apartados), sincronizando posteriormente la metalicencia para que podamos trabajar sobre todas ellas.

Al margen de fallos puntuales de red, los nodos de Pandora FMS deberán poder contactar con la Metaconsola de Pandora FMS en todo momento. Si necesita soportar nodos que puedan permanecer desconectados por periodos de tiempo arbitrariamente largos, contacte con Ártica en mailto:[email protected].

Para que las Instancias se comuniquen con la Metaconsola y viceversa, hay que configurar ambas partes apropiadamente.

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

Para dar de alta una nueva Instancia debemos conocer una serie de parámetros referentes a la Instancia que queremos manejar. Si se trata del alta de una Instancia que todavía no ha sido registrada con una licencia, los datos por defecto son:

• Server name: localhost.localdomain
• Auth token: vacía
• Console URL: http://IP/pandora_console
• API password: vacía
• DB host: IP de la base de datos
• DB name: pandora
• DB user: pandora
• DB password: pandora
• DB port: 3306
• Control user: admin
• Console password: pandora

Campos avanzados

Para garantizar la conectividad entre nodo y Metaconsola, podemos configurar manualmente los datos de conexión.

• Metaconsole DB host: IP de la base de datos
• Metaconsole DB name: pandora
• Metaconsole DB user: pandora
• Metaconsole DB password: pandora
• Metaconsole DB port: 3306

Estos campos indican la configuración de la conexión que establecerá el nodo contra la Metaconsola.

En caso de ser una instalación de Pandora FMS donde ya hemos incluido una licencia válida en la Instancia, tendremos que obtener dichos datos del setup de la Instancia y la base de datos de la misma.

En la vista de las Instancias configuradas veremos que las Instancias pueden ser modificadas, desactivadas y eliminadas. Existen unos indicadores que chequean cierta información de la configuración de cada Instancia. Esos chequeos se realizan al cargar esta vista, pero también se pueden hacer individualmente haciendo click sobre ellos.

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 muestra 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.
• Caché del agente: Este indicador muestra que los últimos estados de los agentes y módulos del nodo se han guardado correctamente en la base de datos de la Metaconsola. Cuando un cambio se genera, solo ese cambio será modificado en la base de datos.
• Sincronización: Este indicador hace referencia a la posibilidad de poder realizar la sincronización de los distintos elementos desde la Metaconsola a las Instancias.

Los tres primeros indicadores deben aparecer en color verde para que la Instancia esté debidamente enlazada y comencemos a ver sus datos. En cambio, el indicador de Replicación de eventos solamente nos da información de esta característica.

La mayor parte de la sincronización entre la Metaconsola y las Instancias se realiza por nombre, independientemente del ID interno de los elementos, teniendo como excepción los grupos, tags, alertas, sistemas operativos y grupos de módulos, cuyos IDs es importante que estén sincronizados.

Para asegurar que los IDs de los grupos, tags, alertas, sistemas operativos y grupos de módulos que se sincronizan desde la Metaconsola no existan en las instancias, aumentaremos el valor AUTO_INCREMENT de las tablas tgrupo, ttag, talert_templates, talert_actions, talert_commands, tconfig_os y tmodule_group sensiblemente. De este modo, daremos un margen amplio por si se crean elementos 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;
 ALTER TABLE ttag AUTO_INCREMENT = 3000;
 ALTER TABLE talert_templates AUTO_INCREMENT = 3000;
 ALTER TABLE talert_actions AUTO_INCREMENT = 3000;
 ALTER TABLE talert_commands AUTO_INCREMENT = 3000;
 ALTER TABLE tconfig_os AUTO_INCREMENT = 3000;
 ALTER TABLE tmodule_group AUTO_INCREMENT = 3000;

Es preciso instalar los paquetes (Open y Enterprise) del servidor en el sistema donde esté instalada la Metaconsola a fin de poder lanzar el script de mantenimiento de Base de datos (pandora_db). Debe asegurarse de que queda correctamente programado para su ejecución en el cron cada hora (tal y como se detalla en el siguiente enlace.).

Si va a utilizar los informes bajo demanda (enviados por email), necesita programar la ejecución de la extensión cron al igual que se hace en una consola Enterprise normal. Generalmente, esto se hace metiendo en el cron la siguiente línea, ajustando los paths locales que correspondan:

• /5 * * * * <user> wget -q -O - http://x.x.x.x/pandora_console/enterprise/extensions/cron/cron.php » /var/www/pandora_console/log/console.log

Por último, para configurar el SMTP de envío de emails, hay que editar los parámetros correspondientes en la sección de configuración de mail, que por defecto tienen los siguientes valores:

En las Instancias hay una serie de parámetros para garantizar el acceso de sus datos con la Metaconsola.

La Metaconsola accede de dos maneras a una Instancia:

• Acceso remoto a la Base de Datos para ver y editar los datos almacenados en las Instancias.
• Acceso a la API para algunas acciones como la edición de ficheros de configuración o la monitorización NetFlow.

La Instancia deberá configurarse para garantizar ambos accesos a la Metaconsola.

Como hemos mencionado anteriormente, se deberán conocer las credenciales de la base de datos para configurar la instancia en la Metaconsola. (Host, Base de datos, Usuario y Contraseña).

Además de ello, otro punto importante es dar permisos al usuario para que acceda remotamente a la base de datos.

Para MySQL 5.7:

Se hace con el comando GRANT de MySQL:

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

Por ejemplo:

GRANT ALL PRIVILEGES on `PandoraMetaBase.*` to `[email protected]` IDENTIFIED BY `pandora`;

Para MySQL 8:

• $DBROOTPASS: Contraseña de usuario root en MySQL 8.
• $DBUSER: Nombre de usuario en MySQL 8.
• $DBPASS: Contraseña de usuario en MySQL 8.
• $DBPORT: Puerto de conexión para MySQL 8.
• $DBHOST: Dirección IP o FQDN del servidor MySQL 8.
• $DBNAME: Nombre de la base de datos.

Para el uso de estas variables de entorno basta con definirlas antes de ejecutar los grants en la terminal, introduzca lo siguiente:

env TZ='Europe/Madrid' \
 DBHOST='127.0.0.1' \
 DBNAME='pandora' \
 DBUSER='pandora' \
 DBPASS='pandora' \
 DBPORT='3306' \
 DBROOTPASS='pandora'

Introduzca en la terminal:

systemctl restart mysql

Introduzca en la terminal:

export MYSQL_PWD=$DBROOTPASS
echo "CREATE USER  \"$DBUSER\"@'%' IDENTIFIED BY \"$DBPASS\";" | mysql -uroot -P$DBPORT -h$DBHOST
echo "ALTER USER \"$DBUSER\"@'%' IDENTIFIED WITH mysql_native_password BY \"$DBPASS\"" | mysql -uroot -P$DBPORT -h$DBHOST
echo "GRANT ALL PRIVILEGES ON $DBNAME.* TO \"$DBUSER\"@'%'" | mysql -uroot -P$DBPORT -h$DBHOST
 
export MYSQL_PWD=$DBPASS

El acceso a la API de la Instancia se garantizará con los siguientes parámetros:

• Usuario y contraseña: Se deberán conocer un usuario y contraseña válidos en la Instancia.
• Contraseña API: Se deberá conocer la contraseña de acceso a la API configurada en la Instancia.
• Lista de IPs con acceso a la API: En la configuración de la Instancia hay una lista de IPs que pueden acceder a la API. Se puede usar '*' como comodín para dar acceso a todas las IPs o a una subred.

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. Dicha contraseña la ponemos en el campo de “Auth token” de la configuración de la instancia en la Metaconsola.

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 cuántos segundos el servidor replicará los eventos generados desde la última replicación a la base de datos de la Metaconsola.

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

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

Si quiere modificar manualmente la fecha a partir de la cual el nodo va a sincronizar eventos con la Metaconsola (por ejemplo, para forzar a que replique eventos a partir de la fecha actual) tendrá que lanzar la siguiente query contra la BBDD del nodo para versiones de Pandora FMS anteriores a la 5.1SP3:

UPDATE tconfig SET `value` = UNIX_TIMESTAMP() WHERE `token` = "replication_copy_last_utimestamp"

Para versiones posteriores a la 5.1SP3 ejecute la siguiente consulta:

UPDATE tconfig SET `value` = (SELECT MAX(id_evento) FROM tevento) WHERE `token` = "replication_copy_last_id";

A partir de Pandora 7 puede encontrar en el setup de configuración de la Metaconsola la opción de dar de alta el nodo en la Metaconsola.

Además, se puede chequear si se está llegando vía API a la Metaconsola y si el nodo está dado de alta en la misma.

Es necesario indicar las credenciales adecuadas para la conexión con el nodo, la base de datos y la API.

La configuración que se encuentra en “opciones avanzadas” será la que se envíe al nodo para su conexión con la base de datos.

La Metaconsola, si se ha activado la replicación de eventos de los nodos, alberga datos de eventos en su propia base de datos. Para su mantenimiento estos datos se pueden borrar y/o mover a la BBDD de histórico de eventos de la Metaconsola. Esto se hace, como en una Instancia de Pandora FMS, a través de la ejecución del script de mantenimiento de BBDD que se encuentra en /usr/share/pandora_server/util/pandora_db.pl. Generalmente, para lanzarlo se utiliza el fichero del servidor, solo que al ser una Metaconsola no tiene porqué haber servidor. Para ello, coja una copia del fichero /etc/pandora/pandora_server.conf de uno de los nodos, edítelo, y modifique los datos relativos a la BBDD (hostname, nombre de la BBDD, usuario y password) y guarde el fichero, por ejemplo, como :

/etc/pandora/pandora_meta.conf

Cree un script en /etc/cron.daily/pandora_meta_db con el siguiente contenido:

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

Y modifique los permisos de este mediante chmod:

chmod 755 /etc/cron.daily/pandora_meta_db

Para poder ejecutarlo, es necesario que tenga instalados los paquetes necesarios para ejecutar (aunque no lo haga) el servidor de Pandora FMS y su parte Enterprise.

Ejecútelo a mano para comprobar que funciona y no da errores:

/etc/cron.daily/pandora_meta_db

A continuación, vamos a ver un ejemplo de cómo sincronizar la metalicencia entre una Metaconsola y una Instancia.

En primer lugar, tenemos una Instancia con su propia clave generada y correctamente validada:

Una vez tenemos el nodo generado y correctamente validado, a continuación lo configuraremos en la Metaconsola para posteriormente poder sincronizar la licencia:

Cuando ya tenemos estos pasos, iremos a la licencia de la Metaconsola y daremos a “Validate” para sincronizar la metalicencia con la Instancia.

El resultado será que tendremos la metalicencia en la Instancia.

Existen varios sistemas de permisos que restringen lo que un usuario puede ver o administrar.

El sistema de ACLs controla qué elementos puede un usuario ver o administrar en función del grupo al que pertenecen.

Por ejemplo:

• Un usuario puede tener permisos de lectura sobre las plantillas de alerta del grupo Applications y de administración sobre las del grupo Servers.
• Podrá ver y asignar las plantillas de los dos grupos, pero solo tendrá opción de editar o eliminar las del grupo Servers.

Para conocer más información sobre los ACLs haga click en el siguiente enlace.

Un Tag es una etiqueta que se puede asignar a un módulo.

Un usuario puede tener los ACLs en un determinado grupo restringidos por Tags. De ser así, solamente se aplicarán esos ACLs a los módulos que contengan esos Tags.

Por ejemplo:

• Un usuario puede tener permiso de lectura o administración en el grupo Servers restringido al Tag Sistemas.
• Solamente tendrá esos permisos sobre los módulos, que aún perteneciendo a un agente del grupo Servers, tengan asignado el Tag Sistemas.

Para conocer más información sobre los tags haga clic en el siguiente enlace.

Los usuarios tienen asignado un nivel de acceso respecto al Wizard de la Metaconsola. Este nivel puede ser Básico o Avanzado. A su vez, las plantillas de alerta y los componentes de módulos (locales y de red) también tendrán este nivel de acceso.

Los usuarios de acceso Básico solo podrán ver en el Wizard las alertas correspondientes a las plantillas de alerta con nivel Básico y los módulos creados desde componentes de nivel Básico.

Los usuarios de acceso Avanzado verán en el Wizard las alertas y módulos tanto de nivel Básico como Avanzado.

Aparte de la visibilidad, el nivel de acceso también afecta a la configuración de los módulos y sus alertas.

En el apartado de Operación (Monitoring Wizard)se explica con detalle la diferencia entre la configuración de un monitor Básico y Avanzado.

El apartado Avanzado contiene las opciones de administración de la Metaconsola, entre ellas:

• La sincronización de datos entre Metaconsola e Instancias
• La gestión de datos de la Metaconsola
• La gestión de la licencia de la Metaconsola
• El Metasetup donde se encuentran:
  • La configuración de las Instancias
  • Las opciones de configuración de la Metaconsola

En este apartado vamos a hablar sobre el Metasetup, en el apartado siguiente explicaremos en detalle la sincronización y gestión de datos desde la Metaconsola.

Puede encontrar información detallada de la licencia aquí: Licencias en MetaConsola

En la sección Metasetup, además de todas las opciones de configuración de la consola, hay una pestaña del Setup de las consolas.

En esta pestaña gestionaremos las instancias. Todo el proceso de configuración está disponible en la sección de Instalar y Configurar del manual.

En la sección Metasetup encontramos pestañas con las diferentes opciones de configuración de la Metaconsola.

En esta sección se encuentran datos generales de la Metaconsola como el idioma, la configuración de fecha/hora o la personalización de ciertas secciones, entre otras.

Se pueden personalizar si queremos que estén activadas o desactivadas las secciones de Netflow, la vista de árbol clasificada por tags, la consola visual o la posibilidad de creación de chequeos web desde el Wizard.

Los parámetros que requieren explicación son:

• Centralized Management: Esta opción nos permite gestionar de manera centralizada desde la Metaconsola las políticas y eventos, sin poder luego gestionarlo desde los nodos.
• Force use Public URL: Fuerza el uso de URL públic. Si este campo está activo, no importa el sistema que esté implementado, los enlaces y las referencias se construirán siempre en base a public_url.
• Public URL host exclusions: Los hosts añadidos en este campo ignorarán el campo anterior.
• Enable update manager: Esta opción nos permite activar tanto el “Offline update manager” como el “Online update manager”, los cuales nos permiten actualizar la Metaconsola en esta configuración.
• Enable log viewer: Esta opción nos permite activar la pestaña del visor de logs para editar la configuración del servidor de Elasticsearch.

Se puede establecer una política de contraseñas con limitaciones en el número de caracteres de las contraseñas, expiración, bloqueo temporal de un usuario. Para conocer más sobre la política de contraseñas visitar la sección Política de contraseñas del manual.

A partir de la versión 747 de Pandora FMS se incorpora la configuración de acceso al servidor de ElasticSearch, el número máximo de entradas de logs que se verán en la sección de Monitoring > Log Viewer y el estado del servidor de ElasticSearch configurado.

Para conocer más sobre la autentificación visitar la sección Autentificación del manual.

Toda la configuración relativa a la representación de los datos. Colores y resolución de las gráficas, número de elementos en la paginación de las vistas, etc. Existe más información acerca de la configuración visual en este enlace.

Opciones de visualización, histórico, purgado de eventos y tamaño máximo de bloques en la migración de datos.

Gestor de ficheros donde se pueden subir y eliminar los ficheros de la carpeta imágenes de la instalación de la Metaconsola.

Con la utilidad de traducción de cadenas se pueden personalizar las traducciones.

Hacemos una búsqueda de la cadena deseada en el idioma que queramos personalizar. Nos aparecerá la cadena original, la traducción a ese idioma y una tercera columna para poner la traducción personalizada.

Con la utilidad de mail podemos personalizar el envio de mails desde la metaconsola, donde deberemos de configurar la cuenta de mail con la que queremos enviar, por ejemplo, los informes generados.

En esta sección podemos modificar las opciones que se van a usar para el Update Manager. Por defecto viene ya configurado para poder realizar la actualización online. Esta sección solo será visible si tenemos activado el “Enable update manager”.

En esta sección podremos actualizar la metaconsola sin necesidad de conectarnos a ningún otro lugar. Solo tendremos que subir los ficheros “rpm” en orden hasta la versión que queremos actualizar, dado que no son versiones acumulativas. Esta sección solo será visible si tenemos activado el “Enable update manager”.

En esta sección podremos actualizar la Metaconsola de manera automática, solo tendremos que poseer una licencia válida de Metaconsola y acceso a internet. Esta sección solo será visible si tenemos activado el “Enable update manager”.

La Metaconsola tiene herramientas de sincronización de elementos, las cuales son fundamentales para la correcta gestión de las Instancias. La sincronización se basa en pasar toda la información creada en la Metaconsola a las distintas Instancias para gestionar desde la Metaconsola toda la información posible de cada una de ellas.

Por ejemplo, si tenemos 20 instancias(nodos) distintos en nuestra empresa, y queremos que un mismo usuario tenga los mismos permisos de acceso en dichos 20, podremos crear un usuario con los perfiles deseados y sincronizaremos dicho usuario para tenerlo en las 20 instancias(nodos) y así no tener que crearlo de manera individual en cada instancia.

Otro ejemplo, tenemos que monitorizar distintos clientes que están repartidos por nuestras instancias, de manera que algunos clientes además se encuentran repetidos en distintas instancias. Podremos crear los distintos grupos a los que van a pertenecer los agentes de las distintas instancias, y posteriormente sincronizar cada grupo correspondiente con su instancia.

A continuación, vamos a ver en detalle las distintas sincronizaciones que nos permite realizar la Metaconsola.

Esta opción permite al usuario sincronizar los usuarios de la Metaconsola y sus perfiles en las instancias.

Dentro de esta sincronización podemos encontrar dos distintas opciones:

• Copiar los perfiles configurados al usuario

• Dar nuevos perfiles al usuario creado.

En ambos casos tenemos la opción de crear los grupos asociados a los perfiles en caso de que no existan en la instancia (nodo).

Se recomienda antes de usar esta sincronización, tener en cuenta los usuarios que se van a crear nuevos en las instancias, debidos a posibles conflictos en el ID de usuario. Es recomendable no tener usuarios creados en las instancias y crearlos todos desde la Metaconsola para así tener los mismos usuarios tanto en esta como en las instancias.

Esta opción permite al usuario sincronizar los grupos de la Metaconsola con las instancias.

Es recomendable no tener grupos creados en las instancias y crearlos todos desde la Metaconsola para así tener los mismos grupos tanto en esta como en las instancias.

Esta opción permite al usuario sincronizar las alertas de la Metaconsola con las instancias.

Es recomendable no tener alertas creadas en las instancias y crearlas todas desde la Metaconsola para así tener las mismas alertas tanto en esta como en las instancias.

Esta opción permite al usuario sincronizar los componentes de la Metaconsola con las instancias.

Es recomendable no tener componentes creados en las instancias y crearlos todos desde la Metaconsola para así tener los mismos componentes tanto en esta como en las instancias.

Esta opción permite al usuario sincronizar los tags de la Metaconsola con las instancias.

Es recomendable no tener tags creados en las instancias y crearlos todos desde la Metaconsola para así tener los mismos tags tanto en esta como en las instancias.

Esta opción permite al usuario sincronizar los sistemas operativos de la Metaconsola con las instancias.

Es recomendable no tener sistemas operativos creados en las instancias y crearlos todos desde la Metaconsola para así tener los mismos sistemas operativos tanto en esta como en las instancias.

Esta opción permite al usuario sincronizar los grupos de módulos operativos de la Metaconsola con las instancias.

Es recomendable no tener los grupos de módulos creados en las instancias y crearlos todos desde la Metaconsola para así tener los mismos grupos de módulos tanto en esta como en las instancias.

La Metaconsola tiene herramientas de propagación de elementos. A diferencia de la sincronización, no se trata de una herramienta fundamental para el funcionamiento óptimo de la Metaconsola, solo facilita la disponibilidad de los datos en las Instancias, algo que es necesario si, por ejemplo, utilizamos políticas que se aplican en diferentes instancias (o nodos).

A continuación, vamos a ver en detalle las distintas propagaciones o gestión de datos que nos permite realizar la Metaconsola.

En esta sección se pueden realizar las siguientes acciones:

• Gestión de usuarios
• Gestión de perfiles
• Editar mi usuario

Por ejemplo, tenemos 10 instancias dentro de nuestra Metaconsola, donde queremos que un usuario con permisos especiales opere dentro de 3 de ellas. En primer lugar, nos iríamos a gestión de perfiles donde crearíamos un perfil especial con los permisos que queramos. Posteriormente, creamos el usuario que vamos a querer que gestione las tres instancias, asignándole el permiso que hemos creado. Por último, sincronizaremos dicho usuario y perfiles con las instancias para tenerlo ya en las tres. Después de un tiempo el usuario se nos ha quedado obsoleto, pero en vez de borrar el usuario lo desactivamos por si en un futuro lo queremos volver a usar, nos vamos a la gestión de usuarios y utilizamos el símbolo de la bombilla para desactivarlo hasta nuevo aviso.

En este apartado podemos ver la lista de usuarios ya creados, modificar la configuración de los mismos, borrarlos, desactivarlos o crear usuarios nuevos.

Para añadir un usuario hagamos clic en el botón de “Create User”, donde nos aparecerá el siguiente formulario el cual deberemos rellenar:

Los parámetros que requieren explicación son:

• Interactive charts: Permite al usuario escoger si prefiere ver las gráficas interactivas, o por el contrario usar la configuración general de la Metaconsola.
• Metaconsole access: Fija los permisos con los que usuario va a acceder a la Metaconsola. Estos permisos pueden ser:
• Básico: Con este acceso el usuario podrá utilizar en el Wizard solamente a los componentes cuyo nivel de Wizard sea Básico. Siempre que tenga permisos ACLs sobre el grupo al que pertenezcan.
• Avanzado: Con este acceso el usuario podrá utilizar en el Wizard cualquiera de los componentes independientemente de su nivel de Wizard. Siempre que tenga permisos ACLs sobre el grupo al que pertenezcan.
• Search custom field view: Seleccionamos el filtro por defecto para la vista de “Campos personalizados”
• Not Login: Si se selecciona esta opción el usuario podrá acceder a la API
• Enable agents management: Esta opción sirve para habilitar la administración de agentes en el Wizard. Si está desactivada solamente estarán disponibles los Wizard de módulos y alertas.
• Enable node access: Esta opción sirve para habilitar el acceso a las instancias. Si está activada, se podrá acceder a través del nombre de agentes y módulos en muchos sitios a las consolas de las instancias. Por ejemplo, desde el mapa de red o la vista de eventos.

En la lista de usuarios se disponen de opciones para:

• Activar/Desactivar el usuario
• Editar el usuario
• Borrar el usuario de la Metaconsola
• Borrar el usuario de la Metaconsola y de todas las Instancias

El formulario de edición de un usuario es igual al de creación, pero incluyendo el editor de perfiles.

En el editor de perfiles se le puede asignar al usuario perfiles en grupos determinados y además limitar esos privilegios a los Tags seleccionados. Si no se seleccionan Tags, el usuario tendrá acceso a todos los módulos, tengan asociados Tags o no.

En este apartado podemos ver la lista de perfiles ya creados, modificar la configuración de los mismos, borrarlos o crear perfiles nuevos.

Hay una serie de flags de ACLs que darán acceso a las diferentes funcionalidades de Pandora FMS. Para saber qué función habilita cada flag de ACLs de los perfiles, visite la sección Perfiles en Pandora FMS en el manual de usuario.

Para añadir un perfil hagamos clic en el botón de “Create”, donde nos aparecerá el siguiente formulario donde deberemos rellenar aquellos permisos que queremos dar con el perfil:

En la lista de perfiles se disponen de opciones para:

• Editar el perfil
• Borrar el perfil de la Metaconsola

En este apartado podemos configurar el usuario que está autenticado en la Metaconsola. Los perfiles asignados al usuario serán meramente informativos. En caso de que el usuario autenticado no sea administrador, este será el único apartado que podrá ver.

En esta sección se pueden realizar las siguientes acciones:

• Migración de agentes entre instancias
• Autoaprovisionamiento de agentes
• Gestión de grupos

Por ejemplo, tenemos pensado gestionar 15 instancias en la Metaconsola, y queremos que la distribución de los agentes se organice según la carga de cada instancia, creándose los agentes de manera que siempre se generen en la instancia con menor carga. Para ello, nos iremos al autoaprovisionamiento y activaremos la opción indicada para ello. Una vez realizado, si por ejemplo, nos damos cuenta que ciertos agentes deberían ir juntos en la misma instancia, iremos a la migración de agentes entre instancias, donde escogeremos que agentes se mueven a qué otras instancias de manera que no tengamos que borrar y crear los agentes manualmente.

En esta sección podemos migrar agentes entre las instancias conectadas a nuestra Metaconsola.

Para que no se transfieran los datos históricos de los agentes a transferir deberemos tener activada la casilla de “Discard history data”. Una vez que tengamos todo seleccionado y le demos al botón “move”, empezará a realizar las siguientes comprobaciones para poder realizar la migración.

Los agentes no existen en el servidor destino

No debe existir ningún agente a migrar con el mismo nombre de agente en el servidor objetivo.

Las colecciones necesarias están sincronizadas con el servidor destino

Para evitar que el agente intente descargar colecciones inexistentes una vez migrado, verifique que las colecciones existen en ambos servidores (origen y destino).

Las definiciones de alertas necesarias están sincronizadas con el servidor objetivo

Verifique que las plantillas, acciones y comandos definidas en el servidor origen están definidas también en el servidor destino. Las relaciones se realizan a través de ID, por lo que estos valores también deberán ser idénticos.

Los ficheros de configuración de los agentes software asociados a los agentes no existen en el servidor objetivo

No deben existir ficheros de configuración con el mismo nombre que los asociados a los agentes que vamos a migrar en el servidor objetivo. De ser así deberemos eliminarlos del servidor destino.

Ambos servidores tienen la misma versión

Verifique que las versiones de Pandora FMS son idénticas en ambos servidores.

La dirección del servidor destino está configurad

Verifique que la dirección IP de su servidor destino (Dataserver) está configurada, puede acceder a la siguiente pantalla a través de Servidores > Administrar servidores de la instancia a la que queremos trasladar los agentes:

Las políticas necesarias están sincronizadas con el servidor destino

Verifique que las políticas del servidor origen estén disponibles en el servidor destino. Las relaciones se realizan a través de ID, por lo que estos valores también deberán ser idénticos.

Los grupos están sincronizados con el servidor destino

Verifique que los grupos del servidor origen están definidos en el servidor destino. Las relaciones se realizan a través de ID, por lo que estos valores también deberán ser idénticos.

Los plugins remotos están sincronizados con el servidor destino

Verifique que los plugins de servidor están definidos en el servidor destino. Las relaciones se realizan a través de ID, por lo que estos valores también deberán ser idénticos.

Los plugins de inventario están sincronizados con el servidor destino

Verifique que los plugins de inventario estén definidos en el servidor destino. Las relaciones se realizan a través de ID, por lo que estos valores también deberán ser idénticos.

Una vez realizadas todas las comprobaciones daremos al botón “Next” para continuar con la migración, donde nos aparecerá una tabla con el estado de la migración.

Cuando desplegamos Pandora en entornos grandes y complejos con muchos nodos de Pandora y entorno de Metaconsola, encontramos la problemática de decidir cómo desplegar los agentes: ¿a qué servidor se les asigna? ¿cómo equilibrar la carga de trabajo?

Para esto aparece el concepto de autoaprovisionamiento de agentes, que permite asignar un agente a uno de los múltiples servidores de Pandora que tengamos en nuestra infraestructura.

Para poder utilizar esta funcionalidad deberemos configurar el servidor y la Metaconsola.

Para que el sistema de autoaprovisionamiento funcione deberemos habilitar el ProvisioningServer en /etc/pandora/pandora_server.conf:

 # Enables self-provisioning service
 provisioningserver 1

En este apartado podremos escoger entre los tres tipos distintos de autoaprovisionamiento, activando el que queremos mediante un interruptor:

Round Robin

Utiliza el método de planificación Round-robin para distribuir, de manera equitativa y en un orden racional, todos los nuevos agentes software de Pandora que lleguen a la Metaconsola. La distribución de los agentes se hará de forma circular, asignando el servidor correspondiente a cada nuevo agente.

Less Loaded

Se asignarán los nuevos agentes a aquellos servidores con menos carga dinámicamente.

Custom

En la clasificación personalizada, podremos definir nuestras propias reglas de clasificación, en base a ciertos parámetros recuperados de la información reportada por el agente (nombre del agente y su dirección IP.).

Si escogemos el caso de “Custom” hagamos clic en el botón de “Create a custom entry” donde nos aparecerá el siguiente formulario:

Donde en configuration tendremos que poner el contenido que se agregará al archivo de configuración, es la personalización que utilizaremos para la clasificación del agente, por ejemplo:

  # Text contained here will be validated and inserted in the agent configuration
server_ip 192.168.80.164

Una vez creado deberemos introducir las reglas que queramos que los agentes cumplan dándole al botón “add”.

Podremos especificar las condiciones de coincidencia en forma de reglas usando los siguientes campos:

• alias del agente
• dirección del agente

Podremos especificar las operaciones usando los siguientes campos:

• OR
• AND

En este apartado se pueden editar las autoconfiguraciones de los agentes de manera centralizada desde la Metaconsola. Para poder realizar esta edición, debemos de tener activado el “Centralized management”.

Para más información, por favor visite el siguiente enlace.

En esta sección podemos gestionar, borrar y crear nuevos grupos en la Metaconsola.

Para crear un nuevo grupo hagamos clic en el botón “create group” y nos aparecerá el siguiente formulario:

Los parámetros que requieren explicación son:

• Parent: combo donde se puede definir otro grupo como padre del grupo que se está creando.
• Propagate ACL: permite propagar las ACL a los subgrupos hijos.
• Custom ID: los grupos tienen un ID en la Base de Datos, en este campo es posible poner otro ID personalizado que pueda ser usado desde un programa externo para realizar una integración.

En la lista de grupos se disponen de opciones para:

• Editar el grupo
• Borrar el grupo de la Metaconsola

En esta sección podremos realizar exactamente las mismas acciones que en la sección anterior, cambiando el modo de visualización:

A partir de Pandora FMS OUM729 se puede centralizar la gestión de colecciones desde la Metaconsola.

La primera vez que acceda a la gestión de colecciones, con la gestión centralizada activada, se realizará un proceso interno de sincronización de las colecciones de los nodos hacia la Metaconsola:

A partir de este momento, tendrá las colecciones en Metaconsola. Para evitar conflictos, deberá copiar manualmente los directorios de colecciones desde los nodos a la Metaconsola:

Ubicación origen (nodo):

/var/www/html/pandora_console/attachment/collection/

Ubicación destino (Metaconsola):

/var/www/html/pandora_console/attachment/collection/

Nota: Recuerde asignar los permisos correctos a los archivos transferidos:

chmod apache. -R  /var/www/html/pandora_console/attachment/collection/*

Una vez transferidos los ficheros, podrá recrear la colección para forzar la sincronización a nodos.

Para obtener más informaciones a cerca de las colecciones, por favor visite el siguiente enlace.

En esta sección se pueden realizar las siguientes acciones:

• Gestión de grupos de componentes
• Gestión de componentes locales
• Gestión de componentes de red
• Gestión de plugins

Antes de empezar vamos a explicar que es un componente: es un “módulo genérico” que se puede aplicar repetidamente sobre un agente, siendo una especie de “copia maestra” de un módulo. Esto es muy útil para poder monitorizar nuevos agentes con los componentes guardados en la base de datos.

Por ejemplo, tenemos 12 instancias donde queremos crear el mismo tipo de módulos en cada una: queremos crear 10 módulos locales, 5 módulos de red y 3 plugins personalizados. Pues gracias a la gestión en la Metaconsola podremos crear dichos componentes, cada uno en su sección, y posteriormente sincronizarlos para tenerlos en las diferentes instancias sin tener que crear manualmente uno a uno los distintos módulos y plugins a utilizar.

En esta sección podremos borrar y crear nuevos grupos de componentes.

Para poder crear un nuevo grupo hagamos clic en el botón “Create”

En esta sección podemos borrar, duplicar y crear nuevos componentes locales. Un componente local es la elaboración de un módulo definido en la configuración de los agentes software, estructurado como “trozos” de texto que se pueden cortar y pegar en la configuración de los agentes.

Para poder crear un componente local hagamos clic en el botón “Create” donde nos aparecerá el siguiente formulario:

Para ver en detalle más información sobre los parámetros de creación de un nuevo componente local puede visitar el siguiente enlace.

En la lista de componentes locales se disponen de opciones para:

• Duplicar un componente local
• Borrar un componente local de la Metaconsola

En esta sección podremos borrar, duplicar y crear nuevos componentes de red. Un componente de red agrupa a todos los módulos de tipo remoto (wmi, tcp, snmp, icmp, plugin, web, etc).

En la lista de componentes de red se disponen de opciones para:

• Duplicar un componente de red
• Borrar un componente de red de la Metaconsola

En esta sección podremos borrar, modificar y crear nuevos plugins que usarán los componentes de red de tipo plugin.

Para crear un plugin hagamos clic en el botón “Add” y aparecerá el siguiente formulario:

Los parámetros que requieren explicación son:

• Plug-in command: Donde pondremos la PATH donde se encuentra el plugin
• Plug-in parameters: Donde pondremos los parámetros que debemos escribir para que el plugin funcione correctamente.

En la lista de plugin se disponen de opciones para:

• Modificar un plugin
• Borrar un plugin de la Metaconsola

Ciertos plugins tienen un candado delante de la opción de modificar, porque estos plugins no pueden ser modificados ni borrados.

En esta sección se pueden realizar las siguientes acciones:

• Gestión de comandos
• Gestión de acciones
• Gestión de plantillas

Por ejemplo, en nuestra Metaconsola tenemos 5 instancias con distintos clientes y en todas ellas necesitamos medir en cada agente la temperatura de su CPU. Con esta información, necesitamos que una alerta salte cuando la CPU supere cierta temperatura, y lo que queremos es realizar un comando que haga que la CPU elimine ciertos servicios para no ser utilizada de una manera excesiva provocándole la subida de temperatura. Crearíamos una alerta que realice dicho comando y luego la sincronizaríamos con todas nuestras instancias para no tener que realizarla manualmente una a una.

En esta sección solo se hablará de la gestión de plantillas, en particular, de las diferencias con la gestión de alertas de las instancias. Para conocer más sobre su funcionamiento y configuración se puede consultar el apartado del manual de Pandora FMS Sistema de alertas.

La única diferencia con la gestión de alertas de las instancias, está en la creación de una nueva plantilla. A la hora de crear una plantilla nos aparece una opción llamada “Wizard level”.

Este campo definirá qué usuarios podrán utilizar esta plantilla para crear alertas desde el Wizard.

• No Wizard: Esta plantilla no estará disponible en el Wizard
• Básico: Cualquier usuario con acceso al Wizard podrá utilizar esta plantilla para crear alertas
• Avanzado: Solamente los usuarios con nivel avanzado de acceso a Metaconsola podrán utilizar esta plantilla (Ver Crear usuario).

En esta sección se pueden realizar las siguientes acciones:

• Crear alerta de evento
• Modificar/Borrar/Deshabilitar/Silenciar alertas de eventos

Por ejemplo, tenemos 4 instancias donde tenemos en un agente la monitorización del servidor apache de cada una de las páginas web situadas en las distintas instancias. Crearemos una alerta de evento que nos avise cuando dicha monitorización se caiga para avisar al administrador que se debe de levantar el servicio Apache de inmediato, y así no habría que crearla manualmente una a una en los agentes de las instancias.

Para conocer más sobre su funcionamiento y configuración se puede consultar el apartado Sistema de Alertas del manual de Pandora FMS.

En esta sección se pueden realizar las siguientes acciones:

• Gestión de etiquetas
• Gestión de grupo de módulos
• Gestión de OS

En esta sección podremos borrar, modificar y crear nuevos etiquetas.

Para crear una nueva etiqueta hagamos clic en el botón “create tag” y a continuación nos saldrá el siguiente formulario que tendremos que rellenar:

En la lista de etiquetas se disponen de opciones para:

• Editar la etiqueta
• Borrar la etiqueta de la Metaconsola

En esta sección podemos borrar y crear nuevos grupos de módulos.

Para poder crear un nuevo grupo de módulo haga clic en el botón “Create module group”:

En esta sección podemos borrar y crear nuevos OS del sistema.

Para crear un nuevo OS hagamos clic en el botón “create OS” y nos aparecerá un formulario que deberemos rellenar:

Desde esta sección se pueden crear, modificar y borrar políticas.

Por ejemplo, tenemos 7 instancias en la cuales 2 de ellas se van a monitorizar de la misma manera, con el mismo nombre de agentes y módulos. Crearíamos una política que nos realice la creación de módulo en los agentes de manera automática, la cual posteriormente sincronizaremos con las distintas instancias sin tener que crearla de una en una.

Se pueden crear nuevas políticas haciendo clic en el botón “Create”, donde se muestra el siguiente formulario:

Para una mejor comprensión de como configurar las políticas, consulte la sección sobre gestión de políticas.

En la lista de políticas se disponen de opciones para modificar una política y eliminarla. Si una política tiene agentes, el botón de eliminar estará deshabilitado y aparecerá junto a él un botón para eliminar todos sus agentes. Este botón introducirá en la cola el eliminado de los agentes, y en cuanto se procese, volverá a estar activo el botón de eliminado de la política.

En esta sección podemos modificar, borrar y crear nuevas categorías.

Para crear una nueva categoría hagamos click en el botón “create category”:

En la lista de categorías se disponen de opciones para:

• Editar la categoría
• Borrar la categoría de la Metaconsola

En esta sección podremos borrar los servidores que tengamos instalados en la Metaconsola. Para poder realizar todas las funcionalidades deberían estar los servidores de Autoaprovisionamiento y de Migración activados.

Volver al Índice de Documentación Pandora FMS

Esta opción permite al usuario sincronizar los componentes de la Metaconsola con las instancias.

Es recomendable no tener componentes creados en las instancias y crearlos todos desde la metanconsola para así tener los mismos componentes tanto en está como en las instancias.

Esta opción permite al usuario sincronizar los tags de la Metaconsola con las instancias.

Es recomendable no tener tags creados en las instancias y crearlos todos desde la metanconsola para así tener los mismos tags tanto en está como en las instancias.

Esta opción permite al usuario sincronizar los sistemas operativos de la Metaconsola con las instancias.

Es recomendable no tener sistemas operativos creados en las instancias y crearlos todos desde la metanconsola para así tener los mismos sistemas operativos tanto en está como en las instancias.

Esta opción permite al usuario sincronizar los grupos de módulos operativos de la Metaconsola con las instancias.

Es recomendable no tener los grupos de módulos creados en las instancias y crearlos todos desde la Metanconsola para así tener los mismos grupos de módulos tanto en está como en las instancias.

Volver al Índice de Documentación Pandora FMS