Metaconsole

Go back to Pandora FMS documentation index

This article is preserved in its entirety for historical purposes.

If you already knew Pandora FMS before version 5.0, then you know that the Metaconsole concept already existed.

This section discusses the differences between the current Metaconsole and the old one, and also the failures fixed and the developments proposed.

Before version 5.0, a normal Pandora FMS installation (Console+Server) could also work as Metaconsole.

The communication between the Metaconsole and the instances was unidirectional. The Metaconsole was connected to the instance databases and managed all memory data.

It did not store almost nothing in its own database.

Synchronization was done between instances.

For example:

Let us suppose that you wish to configure some alert templates so that they have all of the instances.

You must get into one of the instances, configure it, go back to the Metaconsole and synchronize the templates from that instance with the rest of them.

The Metaconsole was very inefficient due to its non-centralized architecture. Lots of connections to different databases were established and user experience was poor.

The available options were insufficient to get the intended control of instance environments without logging out of the Metaconsole.

To sum up, the Metaconsole was slow when it was a little bit loaded and users were very limited by its options.

The Metaconsole from version 5.0 onwards is an special environment completely independent and incompatible with the console.

The communication between the Metaconsole and the instances is bi-directional. The Metaconsole connects with the instance database and the instances replicate part of their data to the Metaconsole database.

Other data such as groups, alert templates, tags… are stored in the Metaconsole.

The synchronization is done in a one way: from the Metaconsole to the instances.

For example:

Let's suppose that you wish to configure some alert templates for the ones that have several or all instances.

Without getting out of the Metaconsole we may configure the templates and synchronize them with the instances that you want.

From version 5.0 onwards, the Metaconsole is a much more centralized, quick, and flexible tool than the previous version.

It also includes many more views and features, as well as developments in the existing ones.

It does not manage all data in memory, storing part of the information, which improves user experience.

This table summarizes the differences between the old Metaconsole features and the new ones.

	Before version 5.0	From version 5.0
The metaconsole can work as an instance
Synchronization	Decentralization	Centralized
Communication	Unidirectional	Bidirectional
Instance configuration
User panel
Tactical view	Through instances	General and 15 last events
Agent browser
Group view
Event visor	(Data in Instances)	(Data in the Metaconsole)
Tree view
Alert view
Module view
Network map
Traffic monitoring (Netflow)
Synchronization tools	Users/Profiles Components Policies Alerts	Users/Profiles Groups Components Alerts Tags
Move agents between instances
Report templates
Editors	Reports Visual console	Users/Profiles Groups Components Reports Visual console Alerts Tags Categories
Apply/Policy queue
Monitor view
Custom field view
Wizard
Visual console viewer
Cronjob setup

The Metaconsole has tools for element synchronization, such as the synchronization of users and groups, which is essential for instance correct management. Synchronization is based on passing all the information created in the Metaconsole to the different instances in order to manage all the information from each and everyone of them from the Metaconsole.

For example, a user created in an instance, but not in the Metaconsole, cannot be managed from the Metaconsole. On the other hand, if there is a created user in the Metaconsole, and users are synchronized, this user will be in Instances and it will be possible to manage it from the Metaconsole.

The Metaconsole has tools for element propagation, such component propagation or moving agents between instances (or nodes). Unlike synchronization, it is not a fundamental tool for the optimal functioning of the Metaconsole. It only provides data availability in instances, something that is necessary if, for example, policies that are applied in different instances (or nodes) are used.

For example, you may want to move an agent from Instance A to Instance B to balance instance load, through this set of tools it can be easily achieved.

Instance and Metaconsole installation must be hosted in servers connected both ways.

So, make sure that:

• The Metaconsole can contact the Instances
• The instances can contact the Metaconsole

To better understand this requirement, take a look at Metaconsole architecture.

The timezone setting should be the same. The more synchronized instance and Metaconsole times are, the more accurate the displayed data will be.

For example, if an instance has a 5-minute difference regarding the Metaconsole, when these data are shown in the Metaconsole, the display of the time lapse since the events were generated will be false.

An instance or node is a common Pandora FMS Enterprise installation made up by its own server and web console.

To learn more about how to install an instance, visit the following link.

A Metaconsole is a Pandora FMS Enterprise installation with a Metaconsole license.

It is necessary to have an active server in order to perform different operations related to the Metaconsole, such as migration, auto-provisioning, service execution, etc.

After installing Pandora FMS Enterprise console, regardless of the installation method, access Pandora FMS console (http://IP/pandora_console/) and a welcome screen will appear to activate the license.

To find out more about how the license is activated, visit the following link.

From Pandora FMS version 7.0NG, there is a unique license for an environment with Metaconsole. It is possible to create as many instances as needed, as long as the total number of agents inside the Metaconsole is not exceeded.

This license is applied into the Metaconsole and can be synchronized in as many instances as desired, allowing centralized management of different agents that will be deployed in those instances.

With this license, if an installation is started from scratch, first install the Metaconsole validating its metalicence. Once validated, register each and every one of the desired instances (explained in the following sections), later synchronizing the metalicence so that you may work on all of them.

Apart from occasional network failures, Pandora FMS nodes must be able to reach Pandora FMS Metaconsole at all times. If you need to support nodes that may go offline for arbitrarily long time periods, contact Ártica ST at mailto:[email protected].

In order for instances to communicate with the Metaconsole and the other way around, configure both sides correctly.

In the Metasetup section, you may register and configure the Instances to which the Metaconsole will be linked.

To register a new instance, it is required to know a series of parameters referring to the instance to be handled. If it is the registration of an instance that has not yet been registered through a license, the default data are:

• Server name: localhost.localdomain
• Auth token: empty
• Console URL: http://IP/pandora_console
• API password: empty
• DB host: database IP
• DB name: pandora
• DB user: pandora
• DB password: pandora
• DB port: 3306
• Control user: admin
• Console password: pandora

Advance Field

To ensure connectivity between node and Metaconsole, configure the connection data manually.

• Metaconsole DB host: database IP
• Metaconsole DB name: pandora
• Metaconsole DB user: pandora
• Metaconsole DB password: pandora
• Metaconsole DB port: 3306

These fields indicate the configuration of the connection that the node will establish against the Metaconsole.

If it is a Pandora FMS installation where a valid license has already been included in the instance, obtain these data from the Instance setup and its database.

Instances can be modified, deactivated and deleted in configured instance view. There are some indicators that check certain information of the setup of each instance. These checks are done when loading this view, but they can also be done individually by clicking on them.

The indicators are the following:

• Database: If the instance database has been misconfigured or you do not have the necessary permissions, the indicator will be red and will give information about the problem.
• API: This indicator will test the instance API. If it fails, it will give information about the failure.
• Compatibility: This indicator checks some requirements between instance and Metaconsole. The name of the instance server, for example, must match the name given in the Metaconsole configuration.
• Event Replication: This indicator shows whether the instance has event replication enabled, whether events have already been received from the instance and how long ago the last replication was.
• Agent cache: This indicator shows that the last node agent and module status were correctly saved in the Metaconsole database. When there is a change, only said change will be modified in the database.
• Synchronization: This indicator refers to the possibility of being able to synchronize the different elements from the Metaconsole to the instances.

The first three indicators must be green in order for the instance to be properly linked and for its data to appear. On the other hand, the Event Replication indicator only gives information about this feature.

Most of the synchronization between the Metaconsole and instances is done by name, regardless of the internal ID of the elements, with the exception of groups, tags, alerts, operating systems and module groups, whose IDs must be synchronized.

In order to ensure that the IDs of the groups, tags, alerts, operating systems and module groups that are synchronized from the Metaconsole do not exist in the instances, increase the AUTO_INCREMENT value of the tgroup, ttag, talert_templates, talert_actions, talert_commands, tconfig_os and tmodule_group tables noticeably. That way, you will provide a leeway in the event that elements are created in the instances for reasons beyond the Metaconsole.

Thus, execute in the Metaconsole's database the following query:

 ALTER TABLE tgrupo AUTO_INCREMENT = 3000;
 ALTER TABLE ttag AUTO_INCREMENT = 3000;
 ALTER TABLE talert_templates AUTO_INCREMENT = 3000;
 ALTER TABLE talert_actions AUTO_INCREMENT = 3000;
 ALTER TABLE talert_commands AUTO_INCREMENT = 3000;
 ALTER TABLE tconfig_os AUTO_INCREMENT = 3000;
 ALTER TABLE tmodule_group AUTO_INCREMENT = 3000;

It is necessary to install the server packages (Open and Enterprise) in the system where the Metaconsole is installed in order to launch the database maintenance script (pandora_db). Make sure that it is correctly programmed for execution in cron every hour (as detailed in the following link.).

If you are going to use on-demand reports (sent by email), program the cron extension execution as it is done in a normal Enterprise console. Usually this is done by typing in the following line into the cron, adjusting the corresponding local paths:

• /5 * * * * <user> wget -q -O - http://x.x.x.x/pandora_console/enterprise/extensions/cron/cron.php » /var/www/pandora_console/log/console.log

Finally, to configure email sending SMTP, edit the corresponding parameters in the mail configuration section, which have the following values by default:

In instances, there are a series of parameters to ensure the access of your data with the Metaconsole.

The Metaconsole accesses an instance in two different ways:

• Remote access to the Database to see and edit the data stored in the instances.
• Access to the API for some actions such as configuration file edition or NetFlow monitoring

The instance should be configured to guarantee both accesses to the Metaconsole.

As we said before, you must know the database credentials to configure the instance in the Metaconsole (host, database, user and password).

Besides this, another important point is grantig permissions to the user to remotely access the database.

For MySQL 5.7:

It is done with MySQL's GRANT command:

GRANT ALL PRIVILEGES on <MetaconsoleDatabaseName>.* to <UserName>@<HostAddress> IDENTIFIED BY <UserPass>;

For example:

GRANT ALL PRIVILEGES on `PandoraMetaBase.*` to `[email protected]` IDENTIFIED BY `pandora`;

For MySQL 8:

• $SBROOTPASS: Root user password in MySQL 8.
• $DBUSER: User name in MySQL 8.
• $DBPASS: User password in MySQL 8.
• $DBPORT: Connection port for MySQL 8.
• $DBHOST: MySQL 8 server IP adress or FQDN.
• $DBNAME: Database name.

To use these environment variables just define them before running grants in the terminal, enter the following:

env TZ='Europe/Madrid' \
 DBHOST='127.0.0.1' \
 DBNAME='pandora' \
 DBUSER='pandora' \
 DBPASS='pandora' \
 DBPORT='3306' \
 DBROOTPASS='pandora'

Enter in the terminal:

systemctl restart mysql

Enter in the terminal:

export MYSQL_PWD=$DBROOTPASS
echo "CREATE USER  \"$DBUSER\"@'%' IDENTIFIED BY \"$DBPASS\";" | mysql -uroot -P$DBPORT -h$DBHOST
echo "ALTER USER \"$DBUSER\"@'%' IDENTIFIED WITH mysql_native_password BY \"$DBPASS\"" | mysql -uroot -P$DBPORT -h$DBHOST
echo "GRANT ALL PRIVILEGES ON $DBNAME.* TO \"$DBUSER\"@'%'" | mysql -uroot -P$DBPORT -h$DBHOST
 
export MYSQL_PWD=$DBPASS

The access to the API instance will be guaranteed with the following parameters:

• User and password: It is necessary to know a valid user and password in the instance.
• API password: It is necessary to know the access password to the API configured in the instance.
• IP list with access to the API: In the Instance configuration, there is an IP list that could have access to the API. It is possible to use '*' as wildcard to give access to all IPs or to one subnet

In some parts of the Metaconsole, there are accesses to the instance Web Console. For example, in the event viewer when clicking on the agent associated to an event (if there is one), it will take you to the view of that agent in the console of the instance it belongs to. Auto-authentication is used for this access. This authentication is done with a hash for which you need a string configured in the instance: The auto-identification password. The password is entered in the “Auth token” field of the instance configuration in the Metaconsole.

In order for instance events to be seen in the Metaconsole, these should have access to the Metaconsole database.

The instances will be replicated every once in a while, their events saving the date and time of the last replication to continue from there the next time.

Besides event replication, they will make Metaconsole autovalidation effective. That is, for events associated to a module, when they replicate the event to the Metaconsole, they will validate all the previous events that were assigned to the same module.

To configure event replication, activate in the Instance Enterprise Configuration section Event Replication.

The following will be configured:

• Interval: How often (seconds) the server will replicate the events generated from the last replication to the Metaconsole database.

• Replication mode: Whether all events will be replicated or only the ones that are validated.
• Show list of events in the local console (only reading): When event replication is activated, event management is done in the Metaconsole and there is not access to them in the instance. With this option you will have access to a read-only event view.
• Metaconsole database credentials : Host, database, user, password and port (if the port is not indicated, the port by default will be used).

Event replication is done by the server. In the configuration file there should be the following enabled token:

If you wish to modify the date from which the node will synchronize events with the Metaconsole (for example, to force event replication from the current date), execute this SQL query against the database node for Pandora FMS versions older than 5.1SP3:

UPDATE tconfig SET `value` = UNIX_TIMESTAMP() WHERE `token` = "replication_copy_last_utimestamp"

For versions after 5.1SP3, execute the following query:

UPDATE tconfig SET `value` = (SELECT MAX(id_evento) FROM tevento) WHERE `token` = "replication_copy_last_id";

From Pandora version 7 onwards, you may find in the Metaconsole configuration setup, the option to register the node in the Metaconsole.

You may also check whether it arrives through API to the Metaconsole and whether the node is registered in the Metaconsole.

Indicate the correct credentials for connecting to the node, database and API.

Advanced options configuration is the one sent to the node to connect to the database.

If the node event replication has been activated, the Metaconsole stores event data in its own database. For their maintenance these data can be deleted and/or moved to the Metaconsole history event database. This is done, as in a Pandora FMS instance, through the execution of the database maintenance script at/usr/share/pandora_server/util/pandora_db.pl. Usually, the server file is used to launch it. But since it is a Metaconsole there is no need for a server. To do this, copy fhe file /etc/pandora/pandora_server.conf from one of the nodes, edit it, and modify the data related to the database (hostname, DB name, user and password) and save the file, for example as:

/etc/pandora/pandora_meta.conf

Create an script at /etc/cron.daily/pandora_meta_db with the following content:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_meta.conf

And modify its permissions through chmod:

chmod 755 /etc/cron.daily/pandora_meta_db

In order to execute it, install the necessary packages to execute (even if you do not) Pandora FMS server and its Enterprise section.

Execute it manually to check that it works and it does not report errors:

/etc/cron.daily/pandora_meta_db

Next, there is an example of how to synchronize the Metalicence between a Metaconsole and an Instance.

First, there is an instance with its own generated and correctly validated key.

Once the node is generated and properly validated, it is configured in the Metaconsole to later synchronize the license:

Once these steps are finished, go to the Metaconsole license and click “Validate” to synchronize the Metalicence with the Instance.

The result will be the Metalicence in the Instance.

There are several permission systems that restrict what an user can see or manage.

The ACL system controls which elements a user can see or manage depending on the group they belong to.

For example:

• A user may have reading permissions on the alert templates of the Application group and those of Administration on the Server group.
• You will be able to see and assign templates to both groups, but you only have the option to edit or delete those of the Server group.

To find out more about the ACLs, click on this link.

A tag is a label that you may assign to a module.

A user could have the ACLs of some specific group restricted by Tags. If so, only these ACLs will be applied to the modules that contain those Tags.

For example:

• A user may have reading or management permissions on the Server group restricted to the Systems Tag.
• It will only have these permissions on the modules, that even belonging to an agent of the Server group, will have the System Tag assigned.

To learn more about tags, click on this link.

Users have an access level assigned regarding the Metaconsole Wizard. This level may be Basic or Advanced. In turn, alert templates and module components (local and network) will also have this access level.

Basic access users will only see in the Wizard the alerts corresponding to the alert templates with Basic level and the modules created from Basic level components.

Advanced access level users will see in the Wizard the alerts and modules from both Basic and Advanced levels.

Apart from visibility, the access level also affects module configuration and its alerts.

The section Operation (Monitoring Wizard) explains in detail the differences between Basic and Advanced monitor configuration.

The Advanced section contains the Metaconsole administration options, among them:

• Data synchronization between the Metaconsole and the Instances
• Data management of the Metaconsole
• Licence management of the Metaconsole
• The Metasetup where you may find:
  • Instance configuration
  • Metaconsole configuration options

In this chapter we are going to discuss the Metasetup and the licence management, in the next chapter we will describe in detail the synchronization and data management of the Metaconsole.

You may find more detailed information about the license here: Licences in the Metaconsole

In the Metasetup section, besides all the options of the console configuration, there is a tab for console Setup.

In this tab, select the instances. All the configuration process is available at the manual section Install and Configure

In the Metasetup section you find tabs with the Metaconsole configuration's different options:

This section contains the general data of the Metaconsole, such as the language, the date/hour configuration or customization about some sections, among others.

It is possible to customize it if you want for the Netflow sections, the tree view classified by tags, the visual console or the possibility of web check creation from the Wizard to be enabled or disabled.

The parameters that require explanation are:

• Centralized Management: This option allows us to centrally manage policies and events centrally from the Metaconsole, without being able to manage them from the nodes.
• Force se Public URL: It forces the use of the public URL. If this field is active, regardless of the system it is implemented in, links and references will always be built based on public_url.
• Public URL host exclusions: The hosts added in this field will ignore the previous field.
• Enable update manager: This option allows us to activate both the “Offline update manager” and the “Online update manager”, which allow you to update the Metaconsole in this configuration.
• Enable log viewer: This option allows you to activate the log viewer tab to edit the Elasticsearch server configuration.

It is possible to set a password policy with limitations in the password number of characters, expiration, temporary blocking of a user. To find out more about the password policy, go to the manual section Password policy.

From Pandora FMS version 747 access configuration to ElasticSearch server, the maximum number of log entries that will be seen in the Monitoring > Log Viewer section and the status of the configured ElasticSearch server is incorporated.

To find out more about the authentication, go to the manual section Authentication.

All configuration related to the data representation. Colors and graph resolution, number of items in the view pagination,etc.You may see more information about the visual configuration in this link.

Display options, history, event purging and maximum size of blocks in data migration.

File manager where it is possible to upload and delete files from the images folder from the Metaconsole installation.

With the string translation feature it is possible to customize translations.

Search for the string in the language that you want to customize. You will be shown the original string, the translation to that language and a third column to type in the customized translation.

With the email feature you may customize email forwarding from the Metaconsole, where you must configure the email account with which you want to send for example the generated reports.

In this section you may modify the options that will be used for the Update Manager. It comes configured by default to update it online. This section will only be visible if you have “Enable update manager” activated.

In this section you may update the Metaconsole without the need to connect to any other place. You just have to upload the “rpm” files in order up to the version you wish to update, since they are not accumulative versions. This section will only be visible if you have “Enable update manager” activated.

In this section you may update the Metaconsole automatically, you just need to have a valid Metaconsole license and access to the Internet. This section will only be visible if you have “Enable update manager” activated.

The Metaconsole has tools for element synchronization, which are fundamental for proper instance management. Synchronization is based on passing all the information created in the Metaconsole to the different Instances to manage all possible information of each of them from the Metaconsole.

For example, if you have 20 different instances (nodes) in your company, and you want the same user to have the same access permissions in those 20, you may create a user with the desired profiles and synchronize that user to have it in the 20 instances (nodes) and thus not have to create it individually in each instance.

Another example, you have to monitor different clients that are distributed throughout your instances, so that some clients are also repeated in different instances. You will be able to create the different groups the agents of the different instances will belong to, and then synchronize each corresponding group with its instance.

Next, we are going to see in detail the different synchronizations that the Metaconsole allows us to make.

This option allows users to synchronize the Metaconsole users and their profiles in the instances.

Within this synchronization you may find two different options:

• Copy the configured profiles to the user.

• Give new profiles to the created user.

In both cases you have the option to create the groups associated to the profiles in case they do not exist in the instance (node).

Before using this synchronization, it is recommended to take into account the users that are going to create new ones in the instances, due to possible conflicts with the user ID. It is recommended not to have users created in the instances and to create them all from the Metaconsole in order to have the same users both in there as in the instances.

This option allows users to synchronize the Metaconsole groups with the instances.

It is recommended not to have groups created in the instances and to create them all from the Metaconsole in order to have the same groups both in there and in the instances.

This option allows users to synchronize the Metaconsole alerts with the instances.

It is recommended not to have alerts created in the instances and to create them all from the Metaconsole in order to have the same alerts both in there and in the instances.

This option allows the user to synchronize the components of the Metaconsole with the instances.

It is recommended not to have components created in the instances and to create them all from the Metaconsole in order to have the same components both in there and in the instances.

This option allows users to synchronize the tags of the Metaconsole with the instances.

It is recommended not to have tags created in the instances and to create them all from the Metaconsole in order to have the same tags both in there and in the instances.

This option allows users to synchronize the OS of the Metaconsole with the instances.

It is recommended not to have OS created in the instances and to create them all from the Metaconsole in order to have the same OS both in there and in the instances.

This option allows users to synchronize the module groups operating in the Metaconsole with the instances.

It is recommended not to have module groups created in the instances and to create them all from the Metaconsole in order to have the same module groups both in there and in the instances.

The Metaconsole has element propagation tools. Unlike synchronization, it is not a fundamental tool for the optimal functioning of the Metaconsole, it only makes Instance data availability easier, something that is necessary if, for example, you use policies that are applied in different instances (or nodes).

Next, we are going to see in detail the different propagations or data management that the Metaconsole allows.

The following actions can be performed in this section:

• User management
• Profile management
• Edit my user

For example, there are 10 instances inside a Metaconsole, where you want a user with special permissions to operate inside 3 of them. First, go to profile management where you will create a special profile with the permissions you wish. Then create the user you want to manage the three instances, assigning the permissions you created to it. Finally, synchronize this user and profiles with the instances to have it in all three of them. After a while the user has become obsolete, but instead of deleting the user deactivate it in case you want to use it again later in the future, so go to user management and use the bulb icon to deactivate it until further notice.

In this section you may see the list of users already created, modify their configuration, delete them, deactivate them or create new users.

To add a user click Create User, where you will see the following form that you have to fill in:

The parameters that require explanation are:

• Interactive charts: It allows the user to choose whether they prefer to see the interactive graphics, or on the contrary, to use the Metaconsole's general configuration.
• Metaconsole access: It sets the user permissions to access the console. These permissions can be:
  • Basic: With this access users will be able to use in the Wizard only the components whose Wizard level is Basic, as long as the user has ACL permissions on the group they belong to.
  • Advanced: With this access users will be able to use any of the components in the Wizard regardless of their Wizard level, as long as the user has ACL permissions on the group they belong to.
• Search custom field view: Select the default filter for the “custom field” view.
• Not Login: If this option is selected, users will be able to access the API.
• Enable agents management: This option is used to enable agent management in the Wizard. If it is deactivated, only module and alert Wizards will be available.
• Enable node access: This option is used to enable access to the instances. If it is activated, it will be possible to access the consoles of the instances through the name of agents and modules in many places; for example, from the network map or the events view.

In the user list the following options are available:

• Activate/Deactivate the user
• Edit the user
• Delete the user form the Metaconsole
• Delete the user form the Metaconsole and all Instances

A user's editing form is the same as the creation form, but including the profile editor.

In the profile editor the user can be assigned profiles in certain groups besides limiting those privileges to the selected Tags. If no Tags are selected, the user will have access to all modules, whether they have associated Tags or not.

In this section you may see the list of profiles already created, modify their configuration, delete them or create new profiles.

There are a series of ACL flags that will give access to the different Pandora FMS features. To find out which function enables each ACL flag of the profiles, visit section Profiles in Pandora FMS in the user manual.

To add a profile click on “Create” to see the following form, where you must fill in those permissions that you want to give to the new profile:

In the profile list you have options to:

• Edit the profile
• Delete a profile from the Metaconsole

In this section you may configure the user authenticated in the Metaconsole. The profiles assigned to the user will be just informative. If the authenticated user is not an administrator, this will be the only section you can see.

The following actions can be performed in this section:

• Agent migration between instances
• Agent self-provisioning
• Group management

For example, you may be planning to manage 15 instances in the Metaconsole, and you want agent distribution to be organized according to each instance's load, creating the agents so that they are always generated in the instance with the lowest load. To do this, go to auto-provisioning and activate the option indicated for it. Once done, if for example, you realize that certain agents should go together in the same instance, go to agent migration between instances, where you may choose which agents move to which instances so that you do not have to delete and create the agents manually.

In this section you may migrate agents between the instances connected to your Metaconsole.

In order for agent history data to be transferred, the “Discard history data” checkbox must be activated. Once you have everything selected and click “move”, it will start to perform the following checks to be able to perform the migration.

The agents do not exist in the destination server

There must not exist any agent to migrate with the same agent name in the target server.

The necessary collections are synchronized with the destination server

To prevent the agent from attempting to download non-existent collections once migrated, verify that the collections exist on both servers (source and destination).

The necessary alert definitions are synchronized with the target server

Verify that the templates, actions and commands defined on the source server are also defined on the target server. Relations are made through ID, so these values must also be identical.

The configuration files of the software agents associated to the agents do not exist in the target server

There must not be configuration files with the same name as those associated to the agents that we are going to migrate in the target server. If so, remove them from the destination server.

Both servers have the same version

Verify that Pandora FMS versions are identical in both servers.

The address of the destination server is configured

Verify that the IP address of your destination server (Dataserver) is configured, you may access the following screen through Servers > Manage servers of the instance to which you want to move the agents:

The necessary policies are synchronized with the target server

Verify that the source server policies are available on the target server. Relations are made through ID, so these values must also be identical.

The groups are synchronized with the destination server

Verify that the groups of the source server are defined in the destination server. All relations are made through ID, so these values must also be identical.

The remote plugins are synchronized with the destination server

Verify that the server plugins are defined in the destination server. All relations are made through ID, so these values must also be identical.

Inventory plugins are synchronized with the target server

Verify that inventory plugins are defined on the target server. All relations are made through ID, so these values must also be identical.

Once all the checks are done, click “Next” to continue with the migration, where a table with the status of the migration will appear.

When you deploy Pandora FMS in big and complex environments with many Pandora FMS nodes and Metaconsole environment, you find the problem of deciding how to deploy the agents: which server should be assigned to them? how to balance the workload?

For that there is the concept of agent auto-provisioning, which allows assigning an agent to one of the multiple Pandora FMS servers that you have in your infrastructure.

To be able to use this feature configure the server and the Metaconsole.

For the autoprovisioning system to work enable the ProvisioningServer at /etc/pandora/pandora_server.conf:

 # Enables auto provisioning service
 provisioningserver 1

In this section you may choose between three different types of autoprovisioning, activating the one you want by means of a switch:

Round Robin

It uses the Round-robin planning method to distribute, evenly and in a rational order, all the new Pandora FMS software agents that reach the Metaconsole. Agent distribution will be done in a circular way, assigning the corresponding server to each new agent.

Less Loaded

New agents will be dynamically assigned to those servers with less load.

Custom

In the customized classification, you will be able to define your own classification rules, based on certain parameters retrieved from the information reported by the agent (name of the agent and its IP address).

If you choose the Custom option, click “Create a custom entry” where the following form will appear:

In the configuration section you will have to enter the content that will be added to the configuration file. It is a way of customization that will be used to classify agents; an example would be:

 # Text contained here will be validated and inserted in the agent configuration
 server_ip 192.168.80.164

Once created enter the rules that you want the agents to comply with by clicking “add”.

You will be able to specify the matching conditions in the form of rules using the following fields:

• agent alias
• agent address

You will be able to specify the operations using the following fields:

• OR
• AND

In this section you may edit agent autoconfiguration centrally from the Metaconsole. In order to edit this, activate “Centralized management”.

For more information, visit this link.

In this section you may manage, delete and create new groups in the Metaconsole.

To create a new group, click “create group” and the following form will appear:

The parameters that require explanation are:

• Parent: Combo where another group can be defined as the parent of the group being created.
• Propagate ACL: It allows ACLs to be propagated to child subgroups.
• Custom ID: The groups have an ID in the Database. In this field it is possible to enter another custom ID that can be used from an external program to perform an integration.

In the list of groups there are options for:

• Editing the group
• Deleting the Metaconsole group

In this section you may perform exactly the same actions as in the previous section, changing the display mode:

From Pandora FMS OUM729 you may centralize collection management from the Metaconsole.

The first time you access collection management, with centralized management enabled, an internal collection synchronization process from the nodes to the Metaconsole will be performed:

From this moment onwards, you will have the collections in the Metaconsole. To avoid conflicts, copy manually the collection directories from the nodes to the Metaconsole:

Source location (node):

/var/www/html/pandora_console/attachment/collection/

Destination location (Metaconsole):

/var/www/html/pandora_console/attachment/collection/

Note: Remember to assign the correct permissions to the transferred files:

chmod apache. -R  /var/www/html/pandora_console/attachment/collection/*

Once the files are transferred, recreate the collection to force synchronization to nodes.

For more information about the collections, please visit this link.

The following actions can be performed in this section:

• Component group management
• Local component management
• Network component management
• Plugin management

Before we start, let us explain what a component is: it is a “generic module” that can be applied repeatedly on an agent, being a kind of “master copy” of a module. This is very useful to monitor new agents with the components stored in the database.

For example, you may have 12 instances where you want to create the same type of modules in each one of them: you may want to create 10 local modules, 5 network modules and 3 custom plugins. Thanks to the Metaconsole management you will be able to create these components, each one in its section, and then synchronize them to have them in the different instances without having to manually create them.

In this section you may delete and create new component groups.

To create a new group click “Create”.

In this section you may delete, duplicate and create new local components. A local component is the creation of a module defined in the configuration of software agents, structured as “pieces” of text that can be cut and pasted in agent configuration.

In order to create a local component click “Create” where the following form will appear:

In order to see in detail more information about the parameters for creating a new local component you may visit Create user.

In the list of local components you have options for:

• Duplicating a local component.
• Deleting a Metaconsole local component.

In this section you may delete, duplicate and create new network components. A network component groups all remote modules (wmi, tcp, snmp, icmp, plugin, web, etc).

In the list of network components you have options for:

• Duplicating a network component.
• Deleting a network component from the Metaconsole.

In this section you may delete, modify and create new plugins that will use plugin network components.

To create a plugin click “Add” and the following form will appear:

The parameters that require explanation are:

• Plug-in command: Where you may enter the PATH to where the plugin is located
• Plug-in parameters: Where you may enter the parameters that you must type in so that the plugin works correctly.

In the plugin list there are options for:

• Modifying a plugin
• Deleting a plugin from the Metaconsole

Certain plugins have a padlock in front of the Modify option, because these plugins cannot be modified or deleted.

The following actions can be performed in this section:

• Management of commands
• Management of shares
• Management of templates

For example, in your Metaconsole you may have 5 instances with different clients and in all of them you need to measure in each agent the temperature of its CPU. With this information, you need an alert to be triggered when the CPU exceeds a certain temperature, and what you want is to create a command that will make the CPU delete certain services so as not to be used excessively, rising its temperature. You would generate an alert that carries out this command and then synchronize it with all your instances so that you don't have to do it manually one by one.

In this section we will only talk about emplate management, in particular, the differences with instance alert management. To find out more about its operation and configuration you may take a look at the Alert System section inside Pandora FMS manual.

The only difference regarding instance alert management is in new template creation. When creating a template there is the option called “Wizard level”.

This field will define which users will be able to use this template to create alerts from the Wizard.

• No Wizard: This template will not be available in the Wizard.
• Basic: Any user with access to the Wizard will be able to use this template to create alerts.
• Advanced: Only users with advanced level of access to the Metaconsole will be able to use this template (see section Create user).

The following actions can be performed in this section:

• Create event alert
• Modify/Delete/Disable/Silence event alerts

For example, you might have 4 instances where you have in one of the agents apache server monitoring of each of the web pages located in the different instances. Create an event alert that will warn you when this monitoring fails to warn the administrator that the Apache service should be immediately fixed, so that it wouldn't be necessary to create it one by one manually in the instance agents.

To find out more about its operation and configuration, please check the section Alert System of Pandora FMS manual.

The following actions can be performed in this section:

• Tag Management
• Module group management
• OS Management

In this section you may delete, modify, and create new tags.

To create a new tag we click “create tag” and then you will get the following form to fill in:

In the list of tags there are options to:

• Edit the tag.
• Delete the tag from the Metaconsole.

In this section you may delete and create new module groups.

To be able to create a new module group click on “Create module group”:

In this section you may delete and create new OS.

To create a new OS click “create OS” and a form will appear for you to fill in:

From this section you may create, modify, and delete policies.

For example, there could be 7 instances among which 2 of them were monitored in the same way, with the same agent and module names. You would create a policy that creates the modules in the agents automatically, which will be later synchronized with the different instances without having to create it one by one.

New policies can be created by clicking “Create”, where the following form is displayed:

For a better understanding on how to configure policies, please refer to section Policy Management.

In the policy list, there are options to modify a policy and delete it. If a policy has agents, the “Delete” button will be disabled and a button to delete all its agents will appear next to it. This button will add agent deletion into the queue, and as soon as it is processed, the policy deletion button will become active again.

In this section you may modify, delete and create new categories.

To create a new category click on “create category”:

In the list of categories there are options to:

• Edit the category.
• Delete the category from the Metaconsole.

In this section you will be able to delete the servers installed in the Metaconsole. In order to be able to use all the features, the Auto-provisioning and Migration servers should be activated.

This option allows users to synchronize Metaconsole components with instances.

It is recommended not to keep created components within the instances and create them all from the Metaconsole to theredor have the same components both in the Metaconsole and in the instances.

This option allows users to cynchronize Metaconsole tags with instances.

It is recommended not to keep tags created within the instances and create them all from the Metaconsole to therefore hace the same ones both in the Metaconsole and the instances.

This option allows users to synchornize Metaconsole OS with the instances.

It is recommended not to keep OS created on the instances but rather create them all from the Metaconsole to therefore hace the same OS both in the Metaconsole and in the instances.

This option allows users to synchronize operative module groups with the instances.

It is recommended not to keep created module groups on the instances but rather create them all from the Metaconsole to then have the same module groups both in the Metaconsole and the instances.

Go back to Pandora FMS Documentation Index