Pandora: Metaconsole: Documentation en: Arquitecture
Go back to Pandora FMS documentation index
Contents
1 Architecture
The Metaconsole architecture is composed by a single central node: The Metaconsole along with as many server nodes as you want, which here we call Instances. Instances are normal installations of Pandora FMS. They consist of a web console in the front end and a server in the back end that processes the data received, performs remote checks,etc. The Metaconsole doesn't have its own server. From version 6.0 onward, the Metaconsole has been changed, and now has its own server.
1.1 Where does it store data?
Some data can be found on the Instances, others on the Metaconsole, and others in both places. They need to be synchronized between themselves to work properly.
On Instances:
- Agents
- Modules
- Alerts
- Policies
On the Metaconsole:
- The Metaconsole configuration:
- Components
- Reports* and the template reports
- Network maps*
- Visual maps*
- Netflow filters
In both:
- Users and profilesThe userLos usuarios y perfiles
- Groups
- Templates, actions and alert commands
- Tags
- Categories
* Though these items are stored in the metaconsole, they are configurations that are used to view the Instance data, therefore are useless on their own.
1.2 How is information obtained and modified?
The Metaconsole obtains and modifies the Instances' information in two different ways:
- Active: Accesses the instances' Database or API remotelt from the Metaconsole (this is the case for agents,modules, alerts, etc).
- Passive: replicates data from instances to the Metaconsoloe Database (this is the case for events).
2 Synchronization
There are two different types of Metaconsole synchronization tools:
- Synchronization utilities:
- Users
- Groups
- Alerts
- Tags
- Propagation Utilities:
- Component Propagation (from the Metaconsole to the Instances)
- Agent movements (From one instance to the other)
|
|
If you want to synchronize module categories, it has to be done manually by entering each Instance |
|
2.1 Synchronization utilities
Synchronization tools match the content between the Metaconsole and Instances to make sure its functioning correctly.
|
|
After modifying this data in the Metaconsole, it will be necessary to synchronize the data with Instances to avoid unusual behaviors. |
|
|
|
Most of the synchronization process is done by name. In order to not have any problems with the exceptions we should follow the instructions listed on Index scaling in the Metaconsole configuration section. |
|
2.1.1 User Synchronization
In order for an user to operate with the Metaconsole, this user should exist both in the Metaconsole and the Instance.
|
|
Passwords don't necessarily have to coincide |
|
|
|
Users should have the same permissions(ACLs, Tags and Wizard access) in the Metaconsole and Instances for it to correctly function |
|
We'll later look at the tool to synchronize users and their profiles in the Synchronization administration section .
2.1.2 Group Synchronization
Groups should be synchronized in order to guarantee access to the data they have.
|
|
The ACLs that an user has on each group in the Metaconsole should correspond with the user accesses that have the same name in the instance. |
|
We will later look at the tool to synchronize the groups in the Administration section. More information on ACLs
2.1.3 Alert Synchronization
Alert synchronization refers to the synchronization between the metaconsole and instances for templates, actions and alert command lines.
This synchronization is necessary because an alert is a link between a template -which includes a series of actions- and a module. Plus, each action has a command synchronized to it.
Alerts are configured and assigned from the Metaconsole with templates, actions and commands which are from the Metaconsole itself. For this configuration to be possible and coherent, the instance where the module that will be assigned an alert can be found must have the same templates, actions and commands.
There exists a tool to synchronize alerts, which can be seen in the Administration section of this Wiki.
|
|
The tool only synchronizes data structures. The commands are related to a script. Synchronization for said script must be secured manually entering the instances. |
|
2.1.4 Tag Synchronization
Tags are an access control mechanism which are complementary to groups, and therefore must also be synchronized to guarantee access to all related data.
|
|
The tags an user has on each Metaconsole group must correspond with a homonymous user's tags in the instance. |
|
2.2 Propagation Utilities
These tools are useful to copy or move data from one Instance to other or from the Metaconsole to the Instances.
Unlike the synchronization utilities, propagation is not necessary for the best performance of the Metaconsole. It is only a tool to make easier the availability of data in the Instances.
Tools for tag synchronization will be seen in the Administration part of the Wiki.
2.2.1 Propagation utilities
These tools are meant for copying or moving data from a particular instance to another, or from the Metaconsole to Instances.
Different from synchronization utilities, propagation isn't needed for the Metaconsole's optimum performance. It's only a tool to make data availability easier on Instances.
2.2.2 Agent Movement
This tool allows moving agents from instance to instance.
|
|
To avoid involuntary mistakes, what's really done is copying the agents to the destined Instances, and deactivate them in the Instances of origin. |
|
