Command Center (Metaconsole)

Command Center

From Pandora FMS version 756, the synchronization system for environments with centralized mode was 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 that was done until now.

This change replaces the previous system in disuse, so that, in environments where it was active, it will be necessary to go through the automatic merging system to use the new centralization system to guarantee data integrity.

When upgrading, all already centralized Command Center environments will be forced to go through the new Merging tool section located at Centralised management in order to be properly centralized again.

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

The Merging tool will merge the different elements of the node databases and the Command Center (of those to be managed from the Command Center) as follows: A priority order will be established among the nodes registered in the Command Center by placing the highest priority items at the top of the list and the lowest priority items at the bottom.

For example:

This priority list is for cases where the same item exists in the different nodes or Command Center and has different configurations.

In the case of monitoring policies, the modules, alerts and other policy elements are considered separate and independent elements of the policy and will therefore be merged as well.

Example only with modules:

Elements centralized by the Merging tool

The following elements are those centralized from the new Merging tool:

  • Users: It is only managed from the Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled.
  • By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool 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 Command Center. Node management is disabled. By unifying from the Merging tool those within policies with the same name will be considered as the agents within the same policy. Agent logs within Command Center 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 Command Center.

Make sure you adjust the parameter autocreate_group from the server configuration files pandora_server.conf by a valid group ID after unifying from the Merging tool.

Summary of all the above:

The following elements are centralized in Command Center, following the priority rules described above, by means of the Merging tool:

Element ID Profile Name Group Ex. 1) OS
Users ✅ ❌ ❌ ❌ ❌ ❌
User profiles ❌ ❌ ✅ ❌ ❌ ❌
Agent groups ❌ ❌ ✅ ❌ ❌ ❌
File collections ❌ ❌ ✅ 2) ❌ ❌ ❌
Alert templates ❌ ❌ ✅ ❌ ❌ ❌
Alert commands ❌ ❌ ✅ ❌ ❌ ❌
Warning actions ❌ ❌ ✅ ❌ ❌ ❌
Server plugins ❌ ❌ ✅ ❌ ✅ ❌
OS ❌ ❌ ✅ ❌ ❌ ❌
Module labels ❌ ❌ ✅ ❌ ❌ ❌
Module categories ❌ ❌ ✅ ❌ ❌ ❌
Module groups ❌ ❌ ✅ ❌ ❌ ❌
Component groups ❌ ❌ ✅ ❌ ❌ ❌
Network components ❌ ❌ ✅ ❌ ❌ ✅
Local components ❌ ❌ ✅ ❌ ❌ ✅
Component templates ❌ ❌ ✅ ❌ ❌ ❌
Inventory modules ❌ ❌ ✅ ❌ ❌ ✅
Monitoring policies ❌ ❌ ✅ ❌ ❌ ❌
Policy modules ❌ ❌ ✅ 3) ❌ ❌ ❌
Inventory modules
policies 		❌ ❌ ✅ 4) ❌ ❌ ✅
Policy plugins ❌ ❌ ✅ 5) ❌ ✅ 6) ❌
Policy collections ❌ ❌ ✅ 7) ❌ ❌ ❌
Alerts and external
policy alerts 		❌ ❌ ✅ 8) ❌ ❌ ❌
Actions on alerts
and external alerts		 ❌ ❌ ✅ 9) ❌ ❌ ❌
Agents within
the policies 		❌ ❌ ✅ 10) ❌ ❌ ❌
Agents 11) ❌ ❌ ❌ ❌ ❌ ❌

The sections where these elements are centrally managed can only be managed from the Command Center. In case of accessing these elements from the nodes, they can only be listed, editing and creation options disappear. A warning will also be displayed indicating that the environment is in centralized mode, with a link that will take the administrator to the corresponding Command Center section for the configuration of these elements.

Database tables used for the Merging tool

The following tables are synchronized between the Command Center and nodes within the Merging tool:

  • tgroup
  • 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
  • tprofile
  • tuser
  • tuser_profile
  • tpolicies
  • tpolicy_modules
  • tpolicy_modules_inventory
  • tpolicy_plugins
  • tpolicy_collections
  • tpolicy_alerts
  • tpolicy_alerts_actions
  • tautoconfig
  • tautoconfig_rules
  • tautoconfig_actions
  • tpolicy_agents

Prerequisites for launching the Merging tool database merge

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

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

  • Node servers must have their API configuration correct in pandora_server.conf or their public URL configuration in the console 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 Command Center must be from the same version.
  • All nodes and the Command Center must be in the same MR.
  • All nodes and Command Center must have the same maximum collection size configured in the Setup .
  • To avoid errors, the Command Center and the nodes must have the memory_limit parameter from php.ini to -1, that is, limitless, but only for the database merging 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 merge the nodes, and in 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 Merging tool 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 must have a value for the parameter post_max_size from php.ini higher or equal to the value configured for the same Command Center parameter. This value must be at least as big as the biggest file collection size there is. It should also be taken into account that this parameter must have a value higher than or equal, both in the nodes and in the Command Center, to the value of upload_max_filesize.
  • All nodes must have a value for the upload_max_filesize parameter from php.ini higher or equal to the value configured for the same Command Center parameter. This value must be at least as high as the size of the biggest file collection you have.
  • All nodes and Command Center 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 Command Center must have the computer's date and time correctly configured (the use of NTP servers is recommended).

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

It is important, once the database merging 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 Merging tool

Although they are not requisites for the database merging process, it is recommended to carry out the following actions too:

  • Stop the servers of all nodes and the Command Center for the duration of the process. As key elements such as groups will be changed, their IDs may 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 should not be a problem in most cases.
  • Stoppandora_db process from the cron temporarily for the duration of the process, for the same reasons as the server.

When the merging process starts, both the nodes and the Command Center go into maintenance mode (not for admins). The purpose 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.

Merging process execution

The merging process has 2 stages, a first stage to synchronyze the different elements that may be managed from the Command Center 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 may take the longest since it usually entails more information. Both stages are in turn divided into other 2 sub-stages differentiated into 2 progress bars.

Stage 1 elements

In this stage, elements found in the databases from all nodes that can be managed from the Command Center are synchronized. It is the merging process as such and it is divided into 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/Command Center in the directory: /attachment/merge_backups
  • Apply: If the previous initialization stage was successful, it will be applied to all nodes and the Command Center. 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.

If the source of the failure prevents the backups from being recovered, the recovering shall be performed manually.

  • Synchronization cancelled:

Sometimes there might be unexpected failures, for example connection lost for a while between the Command Center and a node's database or the impossibility of creating a backup due to not having enough disk space, so it is possible the error message shown will be generic. If that is the case and you need it, contact Pandora FMS support team to receive assistance.

Stage 2: Event updating

At this stage, the existing references to the different synchronized elements in events will be updated (for example by groups). The stage is subdivided into 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 environment will have all the correct references and will not need to be updated.

  • Main database: As events are a large volume of information that is also affected, this update process takes place at the same time as the normal operation of the already merged environment. At this point, the server and pandora_db may 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 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.
  • History database: It would be the continuation of the previous point, updating the events in the history database under the same features already indicated.

Environment already centralized through Merging tool

Once stage 1 is finished, the environment will be considered centralized, and from there you will be able to manage everything from the Command Center. Element synchronization was also changed, now the pandora_ha process of each node is in charge of synchronizing its database with that of the Command Center.

When you make a change in the Command Center (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 Command Center 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 Console setup and it will be necessary to process it manually by an administrator. In most cases you should be able to fix it by launching the merging process again in the Merging tool.

Including new nodes

To add a new node to a centralized environment, go to Setup → Metasetup → Consoles setup → New node. All the fields must be filled in to achieve the connection and at the moment of saving, it will depend on whether it is a completely new node, without any data, it will be added with the Register empty node button, otherwise the Register node with data to merge button must be used.

  • When using the Register empty node button, a warning window will be displayed indicating that the data in the node will be deleted:

Click OK if you are sure and the new node will be centralized.

  • When using the Register node with data to merge button, a confirmation window will be displayed indicating that the data in the existing node will be centralized:

Go back to Pandora FMS index

1)
Execution
2)
Short name.
3) , 4) , 5) , 6) , 7)
Within a policy with the same name
8)
With the same module name within a policy with the same name.
9)
In the same template over the same module name within a policy with the same name.
10)
Within policies with the same name, agent records within Command Center policies will be discarded and only node records will be taken into account.
11)
Node management, deleted in Command Center.