Metaconsole in versions prior to NG 756

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 solved failures 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 is done one-way between instances: from Metaconsole to instances.

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

Without logging out of the Metaconsole, templates can be configured and synchronized with the desired instances.

The Metaconsole was very inefficient due to its non-centralized architecture. A lot 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.

Summarizing, the Metaconsole was slow when it was a little bit loaded and the user was very limited by its options.

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

The communication between the Metaconsole and the instances is bi-directional. The Metaconsole connect 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:

Lets suppose that we want to configure some alert templates for the ones that have several or all instances. Without exit from the metaconsole we could configure the templates and synchronize them with the instances that we 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.

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

The ACL system controls which elements an 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.

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

An 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:

• An user may have reading or administration 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 the tags, click on this link.

Users have an access level assigned regarding the Metaconsole Wizard. This level may be Basic or Advanced.

Besides, 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.