This is an old revision of the document!
Metaconsole in versions prior to NG 756
Comparative
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
Before version 5.0, a normal Pandora FMS installation (Console+Server) could also work as Metaconsole.
Communication
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
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.
Troubleshooting
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.
From Version 5.0
The Metaconsole from version 5.0 is an special environment completely independent and incompatible with the console.
Communication
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.
Synchronization
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.
Developments
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.
Summary table
This table summarizes the differences between the old Metaconsole features and the new ones.
Synchronization
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.
Propagation
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.
User Permissions
There are several permission systems that restrict what an user can see or manage.
ACLs
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.
Tags
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.
Wizard Access Control
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.
Visibility
Basic Access
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
Advanced access level users will see in the Wizard the alerts and modules from both Basic and Advanced levels.
Configuration
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.