Pandora: Metaconsole: Documentation en: Administration

From Pandora FMS Wiki
Revision as of 11:16, 14 August 2018 by Alberto.sanchez (talk | contribs)
Jump to: navigation, search

Go back to Pandora FMS documentation index


1 Administration

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

  • The data synchronization between the Metaconsole and the Instances
  • The data management classified in:
  • Users
  • Agents
  • Modules
  • Alerts
  • Tags
  • Policies
  • Categories
  • The Metasetup where there are:
  • The Instances configuration
  • The Metaconsole configuration options

1.1 Instance Configuration

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

In this tab, we will select the instances. All the configuration process is available at the manual section

Install and Configure

1.2 Metaconsole Configuration

In the Metasetup section we find tabs with the Metaconsole configuration different options:

1.2.1 General Configuration

In this section we find general data of the Metaconsole, such as the language, the date/hour configuration, information about the license or customization about some sections, among others.

It is possible to customize if we want that the Netflow section would be enabled or disabled, the tree view classified by tags, the visual console and the possibility of web checks creation from the Wizard.

Metasetup general.png

1.2.2 Password Policy

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

Metasetup passwords.png

1.2.3 Visual Configuration

All configuration related to the data representation. Colors and graph resolution, number of items in the view pagination,etc.

Metasetup visual.png

1.2.4 Performance

Visualization options, historic and event purging.

Metasetup performance.png

1.2.5 File Management

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

Template warning.png

The Metaconsole code re-uses some images from the normal console code. These images will be not accessible form this manager and it will be necessary to get to the installation manually to manage them.


Metasetup file manager.png

1.2.6 String Translation

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

We do a search of the string in the language that we want to customize. The original string will be shown, the translation to that language and a third column to writte the customized translation.

Metasetup string translations.png

1.3 Synchronization Tools

1.3.1 User Synchronization

This option allows to the user synchronize the Metaconsole users, and also their profiles with the Instances.


The profiles that are not in the Instance will be created.


There are two options:

  • To copy the profiles configured in the user.

Sync users copy.png

  • With this option we can configure profiles that are different from the user profiles.

Sync users new.png

Template warning.png

In doubt of which one of these two options use, you should Copy the user profiles.


1.3.2 Group Synchronization

This option allows to the user to synchronize the Metaconsole groups with the Instances.

Sync groups.png

Template warning.png

To avoid problems with the synchronization of groups, we shoud have done the recommended steps regarding Index scaling in the section of Install and Configure the Metaconsole.


Template warning.png

Once the groups are synchronized for the first time then the names of the groups can't be modified. If they are (modified or deleted) then the exact same changes need to be applied to the node as well. The group synchronization is based on the group id. The first time the synchronization between the node and the metaconsole is executed the name of the group is synchronized but on the future synchronizations the names of the groups aren't synchronized.


1.3.3 Alert Synchronization

This option allows to the user synchronize the alerts already created in the Metaconsole with the Instances.

Sync alerts.png

1.3.4 Components Synchronization

This option allows to the user to synchronize the module components already created in the Metaconsole with the Instances.

Sync components.png

1.3.5 Tags Synchronization

This option allows to the user synchronize the tags already created in the Metaconsole with the Instances.

Sync tags.png

1.4 Data Management

1.4.1 Users

It is possible to do the following actions in the user management section:

  • User Management
  • Profiles Management
  • Edit my user User Management

In the section Advanced>User Management>User Management, we can see the list of the already created users and modify their configuration and also create new users:

Docc7.png Create an User

To add an user click on Create user

Next the following form is shown:

Docc9 create.png

The more remarkable parameters are these:

  • User ID: identifier that the user will use to authenticate in the application.
  • Full Display Name: Field to write the complete name.
  • Password: Field to put the password
  • Password confirmation: Field to confirm the password
  • Global Profile: you should choose between Administrator and Standard User. The Administrator will have absolute permissions on application over the groups where it is defined.The standar user will have permissions defined in the profile that they have assigned.
  • E-mail: Field to write the user mail address.
  • Phone Number: Field to write the user telephone.
  • Comments: Fields where comments are written
  • Interactive charts:Allows that the user could or not see the Interactive graphs and at last option to base on the option configured in the global configuration.
  • Metaconsole access: Sets the user access permissions to the Metaconsole, being these:
    • Basic: With this access the user could user in the Wizard only the components whose Wizard level would be Basic as long as it has ACLs permissions on the group to which they belong to
    • Advanced: With this access the user could use in the Wizard any of the components, regardless what their Wizard level are. As long as it has ACLs permissions on the group to which they belong to.
  • Not Login: If this option is selected, the user could have access to the API
  • Enable agents management: This options is to enable the agent administration in the Wizard. If it is disabled only the module and alert Wizard will be available.
  • Enable node access: This option is to enable the access to the instances. If it is enabled, it will be possible to have access through the name of agents and modules in many places to the Instance consoles. For example, from the network map or the event view. Modify/Deactivate/Delete an user

In the user list are available options to:

  • Activate/Deactivate the user
  • Edit the user
  • Delete the user from the Metaconsole
  • Delete the user from the Metaconsole an from all Instances


The edition form for an user is the same to the creation one but including the profile editor.


In the profile editor it is possible to assign to the user profiles in specific groups and besides, limit those privileges to the selected Tags. It tags are not selecte, the user will have access to all modules, have the associated Tags or not. Profile Management

In the profiles are defined the permissions that an user can have. There is a serial of ACLs flags that will give access to the different Pandora FMS functionalities.

It is possible to see a profile list created by default:


In order to know which function enables each ACLs flag from the profiles, go to user manual section Profiles in Pandora FMS Adding a profile

Clicking on Create, it will be possible to add profiles to the ones that comes by default to customize the user access.


Then select the profile name and select the permissions that you want to assign to it.


Some of these bits doesn't makes any sense in the Metaconsole.However, we may want to use the Metaconsole to synchronize profiles to the Instances, where they could be useful. Modify/Edit a profile

In the profile list there are available options to modify a profile and delete it.

Dac2.1.png Edit my user

In this section could be edited the data of the user that is authenticated in the Metaconsole. The profiles assigned to the user are shown in this screen with informative character.Its edition is done from the user administrator.

Meta edit my user.png

This will be the only section available for users without administration permissions.

1.4.2 Agents

It is included in agent management:

  • Auto-provisioning of agents
  • Movement of agents between instances
  • Group management Agent auto-provisioning

When we deploy Pandora FMS in large and complex environments with many Pandora nodes and Meta console environment, we find the problem of deciding how to deploy the agents, to which server shluld they be assigned?how to balance the workload?to which group do I assign it?

For this purpose, the concept of agent autp-provisioning appears, which allows us to assign an agent to one of the multiple Pandora servers that we have in our infrastructure.

Template warning.png

This functionality requires a Meta Console server with ProvisioningServer started to work. Configuration: server

For the auto-provisioning system to work, we must enable the ProvisioningServer in /etc/pandora/pandora_server.conf:

# Enables auto provisioning service
provisioningserver 1

Note: Verify that the IP address of your target servers (Dataserver) is configured in each node, you can access the following screen through Servers > Manage servers:

Configure server ip address.png Configuration: console

We will need to have the ProvisioningServer enabled for the auto-provisioning system to work.

To configure the way in which the system will classify the agents among the different Pandora FMS servers registered in our Meta Console, we will access to the agent configuration section in Advanced > Agents administration > Provisioning management


We will choose one of the available server selection options:

Round Robin
Use the Round-robin planning method to distribute all new Pandora software agents that arrive at the Meta Console in an equitable and rational order. The distribution of agents will be done in a circular way, assigning the corresponding server to each new agent.
Less Loaded
New agents will be assigned to those servers with less dynamic load.
In the custom classification, we can define our own classification rules, based on certain parameters retrieved from the information reported by the agent (agent name and IP address).

Activate the desired method by clicking on the switch:

Provisioning enable.png Custom classification

Seleccione el método de clasificación personalizado para asignar el agente a un servidor específico en función de reglas.

Para crear una nueva regla haremos clic en crear entrada personalizada

Provisioning custom.png

We must indicate:

Name of the configuration to be applied
optionally a description.
Content that will be added to the configuration file, is the customization that we will use for the agent classification, for example:
# Text contained here will be validated and inserted in the agent configuration

Provisioning rule desc.png

Once the configuration is created, we will indicate the rules that make the system apply it (like triggers). We will have to click on the button add to add a new rule:

Provisioning custom2.png

A pop-up will appear in which we will have to choose the fields that will be used to search for the matching agents:

Provisioning rule new.png

You can specify matching conditions in the form of rules using the following fields:

  • agent alias
  • agent address

Template warning.png

This functionality is used to manage the initial assignment of the agents to a specific server. When you install your agents for the first time, select as server_ip the IP address of the Console. Agent Migration

This option will allow us to migrate an agent between our Pandora FMS servers connected to our Meta Console.

Meta agents movement.png

In the view form we will select the source server and the target server.

Next we will select the agents that we want to transfer to the new server, we will add them to the list of agents to transfer by pressing the '>' button.

Select the "Database only active" check box to no transfer the historical data of this module to the target server.

When we start the migration process by pressing the move button, a series of pre-requisite checks will be performed that must be satisfied in order to start the process.

Move agents prerrequisites.png

List of requirements

Agents do not exist on the target server
There must be no agent to be migrated with the same agent name on the target server.
Required collections are synchronized with the target server
To prevent the agent from attempting to download non-existent collections after migration, verify that the collections exist on both servers (source and destination).
The required 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. Dependencies are made via 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, we must remove them from the target server.
Both servers have the same version
Verify that Pandora FMS versions are identical in both servers.
The destination server address is configured
Verify that the IP address of your destination server (Dataserver) is configured, you can access the following screen through Servers > Manage servers:

Configure server ip address.png

The required policies are synchronized with the target server
Verify that the policies of the source server are available on the target server. Dependencies are made via ID, so these values must also be identical.
Groups are synchronized with the target server
Verify that the groups on the source server are defined on the target server. Dependencies are made via ID, so these values must also be identical.
Remote plugins are synchronized with the target server
Verify that the server plugins are defined on the target server. Dependencies are made via ID, so these values must also be identical.
Inventory plugins are synchronized with the target server
Verify that the inventory plugins are defined on the target server. Dependencies are made via ID, so these values must also be identical.

Once you have solved all the requirements, click "Next" to start the migration of the selected agents to the new server.

Once the transfer has started, you can see the status of the transfer in the table below, under the form:

Move agents queue.png

When the transfer is complete, the status will be displayed in the table:

Move agents queue completed.png

Another example with a lot of historical data:

Move agents queue completed2.png


To avoid blocking the work queue, the agent to be transferred will always be processed with lower priority, this prevents the system from being blocked by transferring an agent with a lot of data, giving priority to the agent migration over the data migration.



To optimize the process the original agent will be disabled and the automatic disable mode will be set. By default, this setting will remove the original agent in 30 days.


Template warning.png

This functionality requires a Meta Console server started to run.


Template warning.png

It is possible that the defined prediction modules will lose functionality once the agent is migrated. Review the definitions after the migration. Advanced Configuration

You can configure the volume of information transferred by iteration in the section Advanced > Metasetup > Performance, adjusting the value of the parameter Migration block size, by default with value 300.

Indicates the number of data records to be transferred per iteration per module.

Move agents setup.png Group Management

We can manage the groups defined in the Meta console.


Template warning.png

After creating or updating a group, it must be synchronized with the Instances for proper operation. Creating a Group

To add a group you have to click on “Create Group”.

The following form will appear:


The fields of the form are detailed below.

  • Name: name of the group
  • Icon: combo where you can choose the icon that the group will have.
  • Parent: combo where you can define another group as the parent of the group you are creating.
  • Alerts: if checked, the agents belonging to the group will be able to send alerts, if not checked, they will not be able to send alerts.
  • Custom ID:groups have an ID in the Database, in this field it is possible to put another custom ID that can be used from an external program to perform an integration (e.g.: CMDB's).
  • Propagate ACL: Allows ACLs to be propagated to child subgroups.
  • Description: Group Description
  • Contact: Contact information accessible from the group_contact_macro
  • Other: Information accessible from the group_other_macro

Once the fields have been filled in, click on the Button “Create”. Modifying/deleting a Group

In the list of groups you have options to modify or delete a group.


1.4.3 Modules

In the module management we find options to configure the Metaconsole components and also the Plugins. Components

A component is a "generic module" that could be applied several times on one agent, as if it was a "master copy" of one module, generating a modules associated to one agent. This way, having a database of the components that we use more in our company, when monitoring new agents, it's very easy, so we have our own components adapted to the technologies that we generally use and we only have to apply these components to the new agents.

There are two kinds of components:Network components, that groups all the remote type modules (wmi, tcp, snmp, icmp, plugin, web, etc), and local components, that are the definition of the modules that are defined in the software agents configuration, defined as text "pieces" that could be cut and pasted in the agent configuration.

From the component management section the following actions can be done:

  • Component Groups Management
  • Local Components Management
  • Network Components Management Component Groups Management

In the view you can see the list of component groups already created.

Meta components groups list.png Create Component Group

To create a Component Group you only need to click on "Create "

It will show the following form:

Meta components groups editor.png

Once it is filled in, click on "Create" Modify/Delete Component Group

In the category list are available some options to modify a category and delete it.

Meta components groups op col.png Local Components Management

The local components refers to the local modules templates that can be applied to create modules in the software agents through the Wizard

In the view, you can see the list of the local components already created.

Meta local component list.png Create Local Component

To create a new local component, click on "Create" button.

It shows the following form:

Meta local component editor.png

The configuration items are these:

  • Name:Component name. This name will be visible when you select the component when you create a module for one agent.
  • OS: Operative system for which the component is
  • Group: The group in which the module will be. It is useful to filter and order by monitoring technologies.
  • Description:Module description. In a predefined way a description already exists which could be changed.
  • Configuration: Component configuration,same as the module configuration for the software agents.
  • Wizard level: The Wizard level is fixed. It can be basic or advanced.
  • Type:Type of data that the module returns
  • Module group:Group to which the module will belongs to.
  • Interval: Module execution intervale.
  • Warning/Critical status:Minimum and Maximum range for the warning and critical status.
  • FF threshold:Number of times that a value should be return for it could be considered right
  • Unit:Field to show the value unity.
  • Post proccess:Value which the value that the module will return will be multiplied by
  • Critical/warning/unknown instructions:Instructions that will be executed when the module goes to a critical, warning or unknown status.
  • Category:Category to which the module will belongs to
  • Tags:Tags association to the policy Macros

It is possible to define macros in the local components. These macros will be used in the parameter module_exec and will have the structure _field1_ , _field2_ ... _fieldN_.

Each macro will have three fields:Description, Default value and Help.

  • Description:It will be the tag next to the field in the module form.
  • Default value:Optional value to load by default in the module form field.
  • Help:Optional field to add additional information to the field. If it is defined, a tip will be shown next to the field with this string.

Meta local component macros.png

If the component Wizard level is basic, the macros couldn't be configured in the module creation process. They will have as value the one that will be assigned to them by default in the component.

Instead, if it is advanced, they will be shown in the module edition form (Wizard) as normal fields, in a transparent way for the user.

Meta local component macros wizard.png Modify/Delete/Duplicate Local Components

To modify a local component, we click on its name.

In the local components list are available options to duplicate the component and delete it.

Meta local component op col.png

It is possible to delete them one by one, or to select several ones and delete them in one step. Network Components Management

Network components refers to the templatesof network modules, plugins of WMI that could be applied to create modules in the agents through the Wizard.

In the view, you can see the list of network components already created.

Meta net component list.png Creating Network Components

It is possible to create three different kinds of network components:

  • Network (from Network).
  • Plugin (from server plugin).
  • WMI.

To create a new network component in the drop-down menu, select a network component from the three possible ones (WMI, Red o Plugin): and press the button Create.

Meta net component options.png

Depending on the type of module there will be some field that could change,like the selection of the plugin in the type plugin or the WMI query or in the WMI type.

In the view it is possible to see the creation form from one of them:

Meta net component editor.png Modify/Delete/Duplicate Network Components

To modify a network component we click on its name.

In the network components list are available some options to duplicate the component and delete it.

Meta net component op col.png

It is possible to delete them one by one or select several of them and delete them in one step. Plugins

From this section is possible to create and modify the plugins that the Network components type plugin will use.

Meta plugins list.png Create Plugin

It is possible to create new tags clicking on "Add".The following form will be shown:

Meta plugins editor.png

In plugins, same as in the local components, it's possible to use macros that will be replaced, in this case in their parameters.

These macros will be shown as normal fields in the plugin type Network Component definition.This way they won't be differenced by an user with other one more field of the Component

Meta plugins fields.png Modify/Delete Plugins

In the plugin list some options are available to modify one plugin and delete it.

Meta plugins op col.png

1.4.4 Alerts

In the Metaconsole, alerts could be created. Alerts, same as in a Pandora FMS normal Instance are composed by Commands, Actions, and Templates.

In this section there will be an introduction for each one of the sections where they are managed. To know more about their performance and configuration, you can see the Pandora FMS manual section Alerts System

Template warning.png

After creating or updating one alert, you should synchronize it with the Instances for a correct performance Commands

Commands are the alerts lowest level. It could be the execution of one script or any other type of reaction to the alert firing

Meta alerts commands.png

We can manage the Metaconsole commands in an identical way to as it is done in the Pandora FMS instances. Action

Actions are a higher level to the commands in the alerts. A command and its configuration is assigned to an action. For example their parameters.

Meta alerts actions.png

We could manage the Metaconsole actions in an identical way as it is done in the Pandora FMS instances. Alert template

Alert templates are the highest layer of alerts and which will be allocated directly to the modules. On the templates it is specified that trigger actions, under what conditions (fall in a given state of the module, overcoming certain values ​​...) and when (certain days of the week, when the condition several times in a row ... )

Meta alerts templates.png

We manage templates metaconsole alerts in an almost identical as in the instances of Pandora FMS. The only difference is the field "Wizard level".

Meta alerts templates wizard level.png

This field defines which users can use this template to create alerts from the Wizard.

  • No Wizard: This template will not be available in the wizard.
  • Basic: Any user with wizard access can use this template to create alerts.
  • Advanced: Only users with advanced level access can use this template.

1.4.5 Tags

From this section it is possible to create and modify tags.

Meta tags list.png Creating Tags

It is possible to create new tags clicking on the "Create tag" button. The following form will be shown:

Meta tags editor.png

Parameters definition:

  • Name:Tag name
  • Description:Tag description
  • Url:Hyperlink to help information that should have been previously created
  • E-Mail:Email that will be associated in the alerts that belongs to the tag Modify/Delete Tags

In the tag list there are available options to modify one tag and to delete it.

Meta tags op col.png

1.4.6 Policies

In Metaconsole there is no policy system, but you can manage policies instances. Policy apply

Desde esta sección se pueden crear y modificar políticas.

Meta menu.png Crear políticas

Se pueden crear nuevas políticas pulsando el botón "Create" donde se muestra el siguiente formulario:

Meta crear.png

Definición de los parámetros:

  • Name:Nombre de la política
  • Group:Grupo al que pertenece la política
  • Description:Descripción de la política Configurar políticas

Para una mejor comprensión de como configurar las políticas, dirigase a la gestión de políticas. Modificar/Borrar políticas

En la lista de políticas se disponen de opciones para modificar una política y eliminarla.

Para modificar una política simplemente debemos de clickear encima de la política que queremos modificar.

Para eliminar una política es necesario que no tenga ningún agente asociado.

Si una política tiene agentes, el botón de eliminar estará deshabilitado y aparecerá junto a él un botón para eliminar todos sus agentes. Este botón introducirá en la cola el eliminado de los agentes, y en cuanto se procese, volverá a estar activo el botón de eliminado de la política.

Meta borrar.png

1.4.7 Categories

In this section, we can manage the "categories". Later we will use this in module components.

Meta category list.png Create categories

Click on button "Create category".

Meta category editor.png Modify/Delete category

On the list, you can click on edit button or delete to delete it.

Meta category op col.png

Go back to Pandora FMS documentation index