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 mezclado 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 Command Center para poder estar centralizados de nuevo de forma correcta.

El Command Center hará una mezcla 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:


Solo se tienen en cuenta para el proceso de mezcla los nodos configurados en la Metaconsola que no estén deshabilitados.


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. Por ejemplo, que los 2 nodos y la Metaconsola tuvieran el grupo “Databases”. Con este orden de prioridad se tomaría para todos la configuración del elemento más prioritario, en este ejemplo el grupo de la Metaconsola.

En otro caso, si por ejemplo solo los nodos 1 y 2 contasen con una política llamada “Windows”, para todos los nodos y la Metaconsola la configuración para esa política sería la del nodo 1 (se saltaría la Metaconsola porque no lo tendría).


Esa configuración sería solo la propia configuración de la política (grupo, descripció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 mezclan también.


El caso de las políticas sería el más particular de todos los elementos sincronizados por cómo se configuran, ya que cada módulo, alerta, plugin (complemento),… son tratados como elementos independientes y no como parte de la configuración de la política. Es decir, en el ejemplo anterior de la política y viéndolo solo con módulos, si tenemos:

El resultado de la mezcla del Command Center sería:

Esto permite que el resultado tenga el máximo posible de configuraciones distintas para que ya podamos gestionarlas desde la Metaconsola.

Elementos centralizados por el Command Center

Los siguientes elementos son los que se centralizan desde el nuevo Command Center:

  • Usuarios: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Command Center 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 Command Center 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 Command Center se considerarán el mismo grupo los que tengan el mismo nombre (siguiendo las reglas de prioridad descritas anteriormente).

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 Command Center.

  • Colecciones de ficheros: Se gestiona únicamente desde la Metaconsola. Se desactiva la gestión en nodo. Al unificar desde el Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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 Command Center 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.

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.

Requisitos previos a lanzar la unificación de bases de datos del Command Center

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

  • 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 “Setup” → “Enterprise” para la Metaconsola en los nodos sea la correcta.

  • 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.conf” o 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_limit de php.ini a -1 , es decir, sin límite, pero solo para el proceso de mezcla 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 mezcla 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 Command Center 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_size de php.ini que 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 deben tener un valor para el parámetro upload_max_filesize de php.ini que 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 tener un valor para el parámetro post_max_size de php.ini que sea mayor o al menos igual que su valor upload_max_file_size de php.ini .
  • 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 mezcla 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 Command Center

Auque 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_db del cron temporalmente mientras dure el proceso, por los mismos motivos que el servidor.


Cuando se inicia el proceso de mezcla 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 mezcla

El proceso de mezcla 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 mezcla 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 mezcla 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 mezcla 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.



En ocasiones se pueden producir errores inesperados, por ejemplo la perdida de conexión momentanea 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 mezcla. 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 mezclado. En este punto el servidor y pandora_db se 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 mezcla. 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 Command Center

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 mezcla en el Command Center.

Inclusión de nodos nuevos a la Metaconsola

Si en un entorno ya centralizado agregamos un nuevo nodo, editamos alguno o rehabilitamos uno ya existente que se hubiera quedado fuera de la mezcla, será necesario pasar de nuevo por el Command Center.

Se mostrará un mensaje avisando al administrador de que haga esta tarea. Mientras no se haga el nodo permanecerá bloqueado e inaccesible, en estado “Pending to merge”. No se le asignarán los cambios realizados ni se tendrá acceso a la consola hasta que no pase el proceso de merge.


Si se requiere hacer un cambio en la consola para solucionar un error en el proceso de mezcla (como aplicar un OUM), se puede borrar el elemento de la lista de nodos para desbloquearlo temporalmente.

Volver al Índice de Documentación Pandora FMS