COMMAND CENTER

Go back to Pandora FMS documentation index

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:

<

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

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.

The following elements are those centralized from the new Command Center:

• Users: It is only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same ID will be considered the same user (following the priority rules described previously).
• User profiles: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same user (following the priority rules described previously).
• Agent groups: They are only managed from the Metaconsole. Node management is disabled.
• By unifying from the Command Center those with the same name will be considered to be from the same group (following the priority rules described previously).

• File collections: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same short name will be considered to be from the same collection (following the priority rules described previously).
• Alert template: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same template (following the priority rules described previously).
• Alert commands: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same command (following the priority rules described previously).
• Alert actions: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same action (following the priority rules described previously).
• Server plugins : They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name and execution will be considered as the same plugin (following the priority rules described previously).
• OS: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same OS (following the priority rules described previously).
• Module tags: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same tag (following the priority rules described previously).
• Module categories: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same category (following the priority rules described previously).
• Module groups: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same group (following the priority rules described previously).
• Component group: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same group (following the priority rules described previously).
• Network components: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name and OS will be considered as the same component (following the priority rules described previously).
• Local components: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name and OS will be considered as the same component (following the priority rules described previously).
• Component Template: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same template (following the priority rules described previously).
• Inventory module: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name and OS will be considered as the same module (following the priority rules described previously).
• Monitoring policies: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name will be considered as the same policy (following the priority rules described previously).
• Policy modules: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name within a policy with the same name will be considered as the same module (following the priority rules described previously).
• Policy inventory modules: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name and OS within a policy with the same name will be considered as the same module (following the priority rules described previously).
• Policy plugins : They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same execution within a policy with the same name will be considered as the same plugin (following the priority rules described previously).
• Policy collections: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same short name within a policy with the same name will be considered as the same collection (following the priority rules described previously).
• Alerts and policy external alerts: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same template on the same module name within a policy with the same name will be considered as the same alert (following the priority rules described previously).
• Actions on alerts and policy external alerts: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those with the same name on the same template on the same module name within a policy with the same name will be considered as the same action (following the priority rules described previously).
• Agents within policies: They are only managed from the Metaconsole. Node management is disabled. By unifying from the Command Center those within policies with the same name will be considered as the agents within the same policy. Agent logs within Metaconsole policies will be discarded and noly node logs will be taken into account (which is where application becomes effective).
• Agents: Agent management in node is allowed, except for their deletion which should be done from the Metaconsola.

The sections where those elements are centrally managed can only be managed from the Metaconsole. In case of accessing those elements from the nodes, you may only list them, and the editing and creating options will disappear. Also a warning that will indicate that the environment is in centralized mode, with a link that will lead to the administrator to the corresponding Metaconsole section for element configuration.

• 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 Setup → Enterprise configuration parameters for the Metaconsole on the nodes is correct.

• Servers from all nodes must be able to connect to the Metaconsole's API. It is recommended to configure the public URL in the Metaconsole.

• Node servers must have their API configuration correct in “pandora_server.conf” or their public URL configuration in the consoles Setup. If it is not configured, servers must be hosted in the same machines their consoles are in.

console_api_url http://localhost/pandora_console/include/api.php
console_api_pass pandora

• Each node must be able to connect to its own history database.

• All nodes and the Metaconsole must be from the same version.
• All nodes and the Metaconsole must be in the same MR.

• All nodes and Metaconsole must have the same maximum collection size configured in the Setup.

• To avoid errors, the Metaconsole and the nodes must have the memory_limit parameter from php.ini to -1, that is, without limit, but only for the database mixing process. After finishing it, it is recommended to set it back to the previous value. That is because a lot of memory is used to mix the nodes, and in a very large environments (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 from php.ini larger or equal to their value upload_max_file_size de php.ini .
• All nodes and Metaconsole must have enough space in the disk that hosts its directory “attachment” to be able to carry out backups from the database and collections.

• All nodes and Metaconsole must have the computer's date and time correctly configured (the use of NTP servers is recommended).

Although they are notrequisites for database unification process, it is recommended to carry out the following actions too:

• Stop thepandora_serverof 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.
• Stop thecron pandora_db process temporarily for the duration of the process, for the same reasons as the server.

The merging proces has 2 stages, a first sitage to synchronyze the different elements that can be managed from the Metaconsole and a second stage to update the references in the events to those centralized elements. This process is performed that way to allow the console to be accesible again as soon as possible, since event updating is part of the process that can take the longest since it usually entails more information. Both stages are in turn divided into other 2 sub-stages differentiated in 2 progress bars.

In this stage elements are synchronized found in the databases from all nodes that can be managed from the Metaconsole. It is the merging process as such and it is sub-divided in other 2 stages, each one with its own progress bar:

• 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: /attachment/merge_backups
• Apply: If the previous initialization stage was successful, it will 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.

In this stage the existing references to the different synchronized elements in events will be updated (for example by groups). The stage is subdivided in the update of the main database events and the history database event update and will only affect those events that existed before launching the merging process. The new generated events after centralizing the nevironment will have all the correct references and won't need to be updated.

• Main database: As 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).
• History 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 ().

When you 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.

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 warning the administrator to do this task. While it is not performed, the node will remain locked and inaccessible, in pending-to-merge status. The changes made will not be assigned to it aor will it have access to the console until it goes through the merging process.

Go back to Pandora FMS index