Home
Command Center
Command Center
A partir de la versión 756 de Pandora FMS se ha rediseñado desde cero el sistema de sincronización para entornos con modo centralizado, haciéndolo más rápido y eficiente, ya que los cambios se replicarán a los nodos de forma automática sin necesidad de la sincronización manual que se hacía hasta ahora.
Este cambio deja en desuso el sistema anterior por lo que en entornos en los que estuviera activo, se deberá pasar por el sistema automático de fusionado para usar el nuevo sistema de centralización y poder garantizar la integridad de los datos.
Al actualizar, todos los entornos de Metaconsola ya centralizados serán forzados a pasar por la nueva sección Merging tool localizada en Centralised managament para poder estar centralizados de nuevo de forma correcta.
Solo se tienen en cuenta para el proceso de fusión los nodos configurados en la Metaconsola que no estén deshabilitados.
El Merging tool hará una fusión de los distintos elementos de las bases de datos de los nodos y la Metaconsola (de aquellos que deban gestionarse desde la Metaconsola) de la siguiente forma: Se establecerá un orden de prioridad entre los nodos registrados en la Metaconsola y la propia Metaconsola, ubicando en la parte superior de la lista los elementos más prioritarios y en la inferior los menos.
Por ejemplo:
Esta lista de prioridad sirve para casos en los que un mismo elemento exista en los distintos nodos o la Metaconsola pero tenga configuraciones distintas.
En el caso de las políticas de monitorización, los módulos, alertas y demás elementos de la política se consideran elementos aparte e independientes a la política y por lo tanto se fusionarán también.
Ejemplo solamente con módulos:
Elementos centralizados por el Merging tool
Los siguientes elementos son los que se centralizan desde el nuevo Merging tool:
- Usuarios: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo usuario los que tengan el mismo ID de usuario (siguiendo las reglas de prioridad descritas anteriormente).
- Perfiles de usuario: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo perfil los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Grupos de agentes: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo grupo los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Colecciones de ficheros: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma colección las que tengan el mismo nombre corto (siguiendo las reglas de prioridad descritas anteriormente).
- Plantillas de alerta: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma plantilla las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Comandos de alerta: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo comando los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Acciones de alerta: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma acción las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Plugins de servidor: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo plugin los que tengan el mismo nombre y ejecución (siguiendo las reglas de prioridad descritas anteriormente).
- OS: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo OS los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Etiquetas de módulos: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma etiqueta las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Categorías de módulos: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma categoría las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Grupos de módulos: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo grupo los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Grupos de componentes: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo grupo los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Componentes de red: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo componente los que tengan el mismo nombre y OS (siguiendo las reglas de prioridad descritas anteriormente).
- Componentes locales: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo componente los que tengan el mismo nombre y OS (siguiendo las reglas de prioridad descritas anteriormente).
- Plantillas de componentes: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma plantilla las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Módulos de inventario: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo módulo los que tengan el mismo nombre y OS (siguiendo las reglas de prioridad descritas anteriormente).
- Políticas de monitorización: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. En el nodo se permitirá aplicar las políticas previamente gestionadas por la meta. Al unificar desde el Merging tool se considerarán la misma política las que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Módulos de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo módulo los que tengan el mismo nombre dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Módulos de inventario de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo módulo los que tengan el mismo nombre y OS dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Plugins de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán el mismo plugin los que tengan la misma ejecución dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Colecciones de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma colección las que tengan el mismo nombre corto dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Alertas y alertas externas de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma alerta las que tengan la misma plantilla sobre el mismo nombre de módulo dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Acciones sobre alertas y alertas externas de políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán la misma acción las que tengan el mismo nombre sobre la misma plantilla sobre el mismo nombre de módulo dentro de una política con el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).
- Agentes dentro de las políticas: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Merging tool se considerarán agentes dentro de una misma política los que se encuentren dentro de políticas con el mismo nombre. Se descartarán los registros de agentes dentro de políticas de la Metaconsola y solo se tendrán en cuenta los registros de los nodos (que es donde se hace la aplicación efectiva).
- Agentes: Se permite la gestión de agentes en nodo, excepto su eliminación que debe hacerse desde la Metaconsola.
En resumen de todo lo anterior:
Asegúrese de ajustar el parámetro autocreate_group de los ficheros de configuración de los servidores pandora_server.conf por un ID de grupo válido tras unificar desde el Merging tool.
Los siguientes elementos se centralizan en Metaconsola, siguiendo las reglas de prioridad descritas anteriormente, por medio de Merging tool:
| Elemento | ID | Perfil | Nombre | Grupo | Eje.1) | OS |
| Usuarios | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| Perfiles de usuario | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Grupos de agentes | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Colecciones de ficheros | ❌ | ❌ | ✅ 2) | ❌ | ❌ | ❌ |
| Plantillas de alerta | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Comandos de alerta | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Acciones de alerta | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Plugins de servidor | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ |
| OS | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Etiquetas de módulos | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Categorías de módulos | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Grupos de módulos | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Grupos de componentes | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Componentes de red | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
| Componentes locales | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
| Plantillas de componentes | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Módulos de inventario | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
| Políticas de monitorización | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| Módulos de políticas | ❌ | ❌ | ✅ 3) | ❌ | ❌ | ❌ |
| Módulos de inventario de políticas | ❌ | ❌ | ✅ 4) | ❌ | ❌ | ✅ |
| Plugins de políticas | ❌ | ❌ | ✅ 5) | ❌ | ✅ 6) | ❌ |
| Colecciones de políticas | ❌ | ❌ | ✅ 7) | ❌ | ❌ | ❌ |
| Alertas y alertas externas de políticas | ❌ | ❌ | ✅ 8) | ❌ | ❌ | ❌ |
| Acciones sobre alertas y alertas externas de políticas | ❌ | ❌ | ✅ 9) | ❌ | ❌ | ❌ |
| Agentes dentro de las políticas | ❌ | ❌ | ✅ 10) | ❌ | ❌ | ❌ |
| Agentes 11) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Las secciones donde se gestionan estos elementos de forma centralizada sólo pueden gestionarse desde la Metaconsola. En caso de acceder a estos elementos desde los nodos, solo podremos listarlos, desapareciendo las opciones de edición y creación. También se mostrará un aviso que indicará que el entorno se encuentra en modo centralizado, con un enlace que llevará al administrador a la sección de la Metaconsola correspondiente para la configuración de estos elementos.
Tablas de la base de datos utilizadas para el Merging tool
Las siguientes tablas se sincronizan entre Metaconsola y nodos dentro del Merging tool:
- tgrupo
- tcollection
- tplugin
- tconfig_os
- ttag
- tcategory
- tmodule_group
- tnetwork_component_group
- tnetwork_component
- tlocal_component
- tnetwork_profile
- tmodule_inventory
- talert_commands
- talert_actions
- talert_templates
- talert_calendar
- talert_special_days
- tperfil
- tusuario
- tusuario_perfil
- tpolicies
- tpolicy_modules
- tpolicy_modules_inventory
- tpolicy_plugins
- tpolicy_collections
- tpolicy_alerts
- tpolicy_alerts_actions
- tautoconfig
- tautoconfig_rules
- tautoconfig_actions
- tpolicy_agents
Requisitos previos a lanzar la unificación de bases de datos del Merging tool
- La Metaconsola debe poder conectarse a todas las bases de datos y a todas las APIs de los nodos. Hay que asegurarse de que la configuración de Consoles setup de la Metaconsola sea la correcta y que los indicadores estén en verde.
- Las consolas de los nodos deben poder conectarse a la base de datos de la Metaconsola. Normalmente esto no será un problema, a no ser que se tengan las consolas en equipos distintos a los servidores de Pandora.
- Hay que asegurarse de que los parámetros de la configuración de Management → Setup → Enterprise para la Metaconsola en los nodos sean los correctos.
- Los servidores de todos los nodos deben poder conectarse al API de la Metaconsola. Se recomienda configurar la URL pública en la Metaconsola.
- Los servidores de todos los nodos deben tener su configuración del API correcta en
pandora_server.confo su configuración de URL pública en el Setup de la consola. Si no se tiene configurado, los servidores deberán alojarse en las mismas máquinas en las que se encuentren sus consolas.
console_api_url http://localhost/pandora_console/include/api.php console_api_pass pandora
- Cada nodo debe poder conectarse a su propia base de datos de histórico.
- Todos los nodos y la Metaconsola se deben encontrar en la misma versión.
- Todos los nodos y la Metaconsola se deben encontrar en el mismo MR.
- Todos los nodos y la Metaconsola deben tener configurado el mismo tamaño máximo de colección en el Setup.
- Para evitar errores, todos los nodos y la Metaconsola deben tener configurado el parámetro
memory_limitdephp.inia-1, es decir, sin límite, pero solo para el proceso de fusión de las bases de datos. Tras terminarlo se recomienda volver a ajustarlo al valor anterior. Esto es así ya que se utiliza bastante memoria para hacer la fusión de los nodos, y en entornos muy grandes (con muchos elementos distintos) se puede usar bastante memoria, y de esta forma nos aseguramos de que el sistema pueda usar toda la memoria disponible. Si esto no se cumple y se alcanza el límite de memoria especificado, el Merging tool fallará por un error inesperado y en los logs de la consola y/o de apache se verá la línea que indique el exceso de memoria alcanzado. - Todos los nodos deben tener un valor para el parámetro
post_max_sizedephp.inique sea mayor o igual al valor configurado para el mismo parámetro en la Metaconsola. Este valor debe ser al menos tan grande como el tamaño de la colección de ficheros más pesada que se tenga. Además se debe tener en cuenta que este parámetro debe tener un valor mayor o igual, tanto en los nodos como en la Metaconsola, al deupload_max_filesize. - Todos los nodos deben tener un valor para el parámetro
upload_max_filesizedephp.inique sea mayor o igual al valor configurado para el mismo parámetro en la Metaconsola. Este valor debe ser al menos tan grande como el tamaño de la colección de ficheros más pesada que se tenga. - Todos los nodos y la Metaconsola deben contar con espacio suficiente en el disco que aloje su directorio “attachment” para poder realizar los backups (respaldo de datos) de la base de datos y colecciones.
- Todos los nodos y la Metaconsola deben tener la fecha y hora del equipo correctamente configurada (se recomienda el uso de servidores NTP).
Si no se cumplen todos esos requisitos, no se realizará la fusión de nodos y se arrojará un error. Si se consultan los errores del resultado, dará un mensaje de los requisitos aún pendientes.
Es importante una vez realizada la unificación de bases de datos, que se vuelva a poner el valor correspondiente el parámetro memory_limit del fichero de configuración php.ini. Recordar que para que el cambio tenga efecto se debe reiniciar el servicio de apache httpd.
Recomendaciones previas al lanzamiento del Merging tool
Aunque no son requisitos para el proceso de unificación de las bases de datos, se recomienda encarecidamente realizar también las siguientes acciones:
- Detener los servidores de todos los nodos y la Metaconsola mientras dure el proceso. Como se van a cambiar elementos fundamentales como grupos, sus IDs se pueden modificar, y no es recomendado tener el proceso del servidor incluyendo nuevas referencias al entorno mientras este dure. No obstante, el servidor en ejecución no debería ser un problema en la mayoría de los casos.
- Detener el proceso de
pandora_dbdel cron temporalmente mientras dure el proceso, por los mismos motivos que el servidor.
Cuando se inicia el proceso de fusión tanto los nodos como la Metaconsola entran en un modo de mantenimiento para los usuarios estándar (no para los administradores). El propósito de esto es el mismo que la recomendación de detener los servidores y el pandora_db, evitar que un usuario modifique elementos durante el proceso y eso provoque errores o incongruencias.
Ejecución del proceso de fusión
El proceso de fusión tiene 2 fases diferenciadas, una primera fase para sincronizar los distintos elementos gestionables desde la Metaconsola y una segunda fase para actualizar las referencias que haya en los eventos a esos elementos centralizados. Este proceso se hace de esta forma para permitir que la consola sea accesible de nuevo lo antes posible, dado que la actualización de los eventos es la parte del proceso que más tiempo puede tomar al tratarse por lo general del mayor volumen de información. Ambas fases se encuentran a su vez divididas en otras 2 subfases diferenciadas en 2 barras de progreso.
Fase 1: Sincronización del entorno
En esta fase se sincronizan los elementos encontrados en las bases de datos de todos los nodos que sean gestionables desde la Metaconsola. Se trata del proceso de fusión como tal y se subdivide en otras 2 fases, cada una con su barra de progreso:
- Initialize: Comprueba todos los requisitos anteriores, genera los backups correspondientes (si se cumplen los requisitos) por si alguna parte del proceso falla, y genera en memoria el resultado de la fusión de las bases de datos. Si este proceso falla por algún motivo las bases de datos aún no se habrán modificado, por lo que no hará falta restaurar backups. Los backups se almacenan en cada nodo/Metaconsola dentro de su directorio “attachment” en
attachment/merge_backups. - Apply: Si la fase de inicialización anterior ha tenido éxito, se empezará a aplicar la fusión en todos los nodos y la Metaconsola. Este proceso es secuencial en orden de prioridad, de modo que cuando termine con uno empezará con el siguiente.
Si se producen errores durante este proceso (por ejemplo, perdida de conexión con alguna base de datos), el propio proceso tratará de restaurar los backups generados (se verá una tercera barra de progreso roja que marcará el progreso en la restauración).
Si el motivo del fallo impidiese que se recuperasen los backups, la recuperación se deberá hacer manualmente.
- Sincronización cancelada:
En ocasiones se pueden producir errores inesperados, por ejemplo la perdida de conexión momentánea entre la Metaconsola y la base de datos de un nodo o la imposibilidad de crear un backup por no tener espacio suficiente en el disco, por lo que es posible que el mensaje de error mostrado sea genérico. Si es el caso y lo necesita, póngase en contacto con el equipo de soporte de Pandora FMS para recibir asistencia.
Fase 2: Actualización de eventos
En esta fase se actualizarán las referencias existentes en los eventos a los distintos elementos que se hayan sincronizado (por ejemplo a grupos). La fase se subdivide en la actualización de los eventos de la base de datos principal y la actualización de los eventos de la base de datos de histórico, y solo afectará a los eventos que existiesen antes de lanzar el proceso de fusión. Los nuevos eventos que se generen habiendo ya centralizado el entorno tendrán todas las referencias correctamente y no será necesario actualizarlos.
- Base de datos principal: Como los eventos son un gran volumen de información que también se ve afectado, este proceso de actualización se realiza en paralelo con el funcionamiento normal del entorno ya fusionado. En este punto el servidor y
pandora_dbse pueden volver a iniciar normalmente, y los usuarios estándar son capaces de volver a acceder a la consola. Eso sí, verán en la vista de eventos la barra de progreso de actualización de todos los eventos, por lo que para esa parte aún podrán tener incongruencias (respecto a filtros por ejemplo) solo para los eventos que hubiese antes de la fusión. Los nuevos eventos se generarían de forma normal. Esta fase y proceso es lanzado por cada uno de los nodos, mediante una tarea específica del cron de la consola. Por el volumen de información puede ser una tarea pesada y que tome bastante tiempo, por lo que en la medida de lo posible cuanta menos carga tenga el entorno en ese momento mejor. - Base de datos de histórico: Sería la continuación del punto anterior, actualizando los eventos en la base de datos de histórico bajo las mismas características ya indicadas.
Entorno ya centralizado mediante Merging tool
Ya terminada la fase 1, el entorno se considerará centralizado, y a partir de ahí podremos gestionar todo desde la Metaconsola. La sincronización de elementos también se ha cambiado, siendo ahora el pandora_ha de cada nodo el que se encarga de sincronizar su base de datos con la de la Metaconsola.
Esto funciona de la siguiente forma: cuando en la Metaconsola hacemos algún cambio (por ejemplo, crear un usuario) esto encola para los nodos las consultas necesarias a la base de datos (INSERTS, UPDATES, etc.) las cuales el pandora_ha lee de forma ordenada de la base de datos de la Metaconsola y va ejecutando cada server_threshold. Esto asegura que si un servidor está detenido durante un tiempo, cuando se inicie de nuevo pueda ponerse al día de forma correcta.
Esta lista de consultas pendientes se podrá ver desde la Metaconsola en la sección de “Consoles setup”. Si por algún motivo alguna consulta falla, el nodo no seguirá con las demás, podremos ver un error en “Consoles setup” y será necesario tratarlo manualmente por un administrador. En la mayoría de los casos se debería de poder solucionar lanzando de nuevo el proceso de fusión en el Merging tool.
Inclusión de nodos nuevos a la Metaconsola
Para agregar un nuevo nodo a un entorno centralizado se debe ir en la Metaconsola a Setup → Metasetup → Consoles setup y pulsar en el botón New node. Se deberán rellenar todos los campos para lograr la conexión y al momento de guardar dependerá de si es un nodo completamente nuevo, sin dato alguno, se agregará con el botón Register empty node, de lo contrario se utilizará el botón Register node with data to merge.
- Al utilizar el botón Register empty node se mostrará una ventana de advertencia indicando que los datos en el nodo serán borrados:
Presione Ok si está seguro y el nodo nuevo será centralizado.
- Al utilizar el botón Register node with data to merge se mostrará una ventana de confirmación indicando que los datos en el nodo existente serán centralizados:
