This is an old revision of the document!


COMMAND CENTER

Command Center

From Pandora FMS version 756, the synchronization system for environments with centralized mode has been redesigned from scratch, making it faster and more efficient, since the changes will be replicated to the nodes automatically without the need for manual synchronization, as it was the case up to now.

This change deems the previous system outdated, so in environments where it was active, it will have to go through the previous automatic merging system to use the new centralization system and be able to guarantee data integrity.

When updating, all already centralized Metaconsole environments will be forced to go through the new Command Center to be able to be centralized again correctly.

The Command Center will mix the different elements of the node and Metaconsole databases (of those that must be managed from Metaconsole) in the following way. An order of priority will be established between the Metaconsole nodes and the Metaconsole itself, placing the elements with the highest priority at the top of the list and at the bottom those with lower priority.

For example:

<


Only the nodes configured in the Metaconsole that are not disabled are taken into account for the mixing process.

This priority list is used for cases where the same element exists in the different nodes but has different configurations. For example, for 2 nodes and the Metaconsole to have the group “Databases”. With this priority order, the configuration of the highest priority element will be taken for all, in the example of the Metaconsole.

In another case, if for example only nodes 1 and 2 had a policy called “Windows”, for all nodes and the Metaconsole the configuration for that policy would be that of Node 1 (we skip the Metaconsole because it does not have it).


Only for the policy's own settings (group, description,…). Modules, alerts and other policy elements are considered separate elements independent of the policy and therefore are mixed as well.


The case of policies would be the most particular one out of all the synchronized elements due to how they are configured, since every module, alert, plugin… is dealt with as an independent element and seeing it only with modules, if you have:


The result of the Command Center would be:

This allows the result to have as many different configurations as possible so that you can now manage them from the Metaconsole.

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.

Prerequisites for launching the Command Center database merge

  • The Metaconsole must be able to connect to all databases and all node APIs. Make sure that the “Consoles setup” configuration is correct and that the indicators are green.

  • Node consoles must be able to connect to the Metaconsole database. Usually this will not be a problem, unless you have the consoles on computers other than that of Pandora FMS servers. Make sure that the SetupEnterprise configuration parameters for the Metaconsole on the nodes is correct.
  • Each Metaconsole and node must be able to connect to its own history database, if it is configured.
  • All nodes and the Metaconsole must be in the same version.
  • All nodes and the Metaconsole must be in the same MR (database schema update).
  • All nodes and the Metaconsole must have the same maximum collection size configured.


Important:

  • To avoid errors, the Metaconsole must have the memory_limit in file configurationphp.ini to -1, that is, without limit, but only for the mixing process . After finishing it, it is recommended to set it back to the previous value (800M by default). That is because a lot of memory is used to mix the nodes, and in a very large environment (with many different elements) a large amount of memory can be used, that way you make sure that the system can use all the memory available. If the items to be merged exceed the value of the physical memory available on the server, the Command Center will fail due to an unexpected error, and in the console/apache logs you will see the line indicating the excess memory reached.
  • All nodes and the Metaconsole must have a value for the post_max_size (in file configurationphp.ini ) larger than the size of the collections configured in the environment. The recommended (and default) value for most environments is 800M.
  • All nodes must have a value for the upload_max_filesize (in file configurationphp.ini ) that is higher than or equal to the value configured for the same parameter in the Metaconsole.


Check that the nodes have the parameter console_api_pass correctly defined in the server configuration file.


If all those requirements are not met, nodes will not be mixed and it will return an error. If you check the errors of the result, it will return a message with the requirements still pending.

It is important, once the database unification is done, to set again the corresponding value of memory_limit in file configuration php.ini. Remember that for the change to take effect, the apache httpd service must be restarted

Recommendations prior to launching the Command Center

  • Stop the pandora_server of all nodes and the Metaconsole for the whole process. As key elements such as groups are going to be changed, their IDs can be modified, and it is not recommended to have the server process include new references to the environment while it lasts. However, the running server shouldn't be a problem in most cases.
  • Disable the cron pandora_db process temporarily for the duration of the process, for the same reasons as the server.


When the merging process starts, both the nodes and the Metaconsole go into maintenance mode. The purpose of this is the same as the recommendation to stop the servers and pandora_db, to prevent a user from modifying elements during the process and for that to cause errors or inconsistencies.


Only the nodes configured in the Metaconsole that are not disabled are taken into account for the merging process.

The merging process has 2 differentiated stages, divided into another 2 differentiated stages in 2 progress bars:

Stage 1 elements

  • Initialize: It checks all the previous requirements, generates the corresponding backups (if the requirements are met) in case any part of the process fails, and generates the result of the database merging within the memory. If this process fails for any reason, the databases will not have been modified yet, so it will not be necessary to restore backups. Backups are stored in each node/Metaconsole in the directory: pandora_console/attachment/merge_backups
  • Apply: If the previous initialization stage was successful, the result of the unification will begin to be applied to all nodes and the Metaconsole. This process is sequential in order of priority, so when one is finished, the next one will start. If there is an error during this process (for example, connection loss with a database), the process itself will try to restore the generated backups (a third red progress bar will be seen that will mark the restoration progress). If the reason for the failure prevents the backups from being recovered, the recovery must be done manually.

Stage 2 events

  • Main database: CAs events are a large volume of information that is also affected, this update process takes place in parallel with the normal operation of the already merged environment. At this point, the server and pandora_db can be started again normally, and standard users are able to access the console again. Of course, you will see in the event view the update process bar for all the events, so that for that part there might still be inconsistencies (regarding filters for example) only for the events that were there before the merge. New events would be generated normally. This stage and process is launched by each of the nodes, through a specific task in the console's cron. Due to the volume of information it can be a heavy and time-consuming task, so as far as possible the less load the environment has at that time the better (try to launch it outside of the busiest hours on Pandora FMS).

Historical database

  • It would be the continuation of the previous point, updating the events in the historical database under the same characteristics already indicated.

Once stage 1 is finished, the environment will be considered centralized, and from there you will be able to manage everything from the Metaconsole. Element synchronization has also been changed, now the pandora_ha process of each node is in charge of synchronizing its database with that of the Metaconsole (this process is executed together with the server as of version 755).

When we make a change in the Metaconsole (for example, create a user) this queues the necessary queries to the database for the nodes (INSERTS, UPDATES, etc.) which pandora_ha reads in an orderly manner and executes in each server_threshold. This ensures that if a server is down for a while, when it is started again it can catch up correctly.

This list of pending queries can be seen from the Metaconsole in the Consoles setup. If for some reason any query fails, the node will not continue with the rest, you will see an error in Consoles setup and it will be necessary to treat it manually by an administrator. In most cases you should be able to fix it by launching the merging process again in the Command Center.

Including new nodes

If in an already centralized environment you add a new node, edit one, or re-enable an existing one that has been left out of the merge, it will be necessary to go through the Command Center again.

A message will be displayed advising the administrator to do this task, while the node will remain locked and inaccessible, in a pending-to-merge state.

The changes made will not be assigned and you will not have access to the console until the merging process finishes.


If you need to make a change in the console to fix a bug in the merging process (such as applying an OUM), you can delete the item from the node list to temporarily unlock it.

Items included in the synchronization

  • Users: It is managed only from the Metaconsole. Node management is disabled.
  • Profiles: It is managed only from the Metaconsole. Node management is disabled.
  • Groups: It is managed only from the Metaconsole. Node management is disabled.
  • Policies: It is managed only from the Metaconsole. Node management is disabled. In the node, you will be allowed to apply the policies previously managed by the Metaconsole.
  • Agents: Agent management is allowed in node, except its elimination that must be done from the Metaconsole.
  • Collections: It is managed only from the Metaconsole. Node management is disabled.
  • Tags: It is managed only from the Metaconsole. Node management is disabled.
  • Alerts (templates, actions and commands): It is managed only from the Metaconsole. Node management is disabled.
  • OS: It is managed only from the Metaconsole. Node management is disabled.
  • >Server plugins: It is managed only from the Metaconsole. Node management is disabled.
  • Local and remote components: It is managed only from the Metaconsole. Node management is disabled.
  • Module groups and categories: It is managed only from the Metaconsole. Node management is disabled.
  • Inventory modules: It is managed only from the Metaconsole. Node management is disabled.
  • Autoconfiguration rules: It is managed only from the Metaconsole. Node management is disabled.

The sections indicated with centralized management can only be configured from the Metaconsole. In case of accessing these elements from the nodes, you will only be able to list the elements, disappearing the editing options, and you will see a warning that will indicate that you are in centralized mode with a link that will take the administrator to the section of the corresponding Metaconsole for the configuration of these items.

Go back to Pandora FMS documentation index