Monitoring with Policies

The policy system is conceived to make large monitoring environment management easier. It allows to propagate modules, alerts, external alerts, plugins, remote inventories and collections to the agents in a centralized and homogeneous way, by modifying its configuration files through the remote edition feature called software agent configuration More information can be found in the video tutorial «Pandora FMS policies. Centralized monitoring. Workshop.».

Policy management can be performed by clicking on Configuration → Manage policies on the left side of the Pandora FMS web console as shown below.

You can also get more information with the quick guide “Differences between Templates, Policies and Massive Operations”.

You may search policies in Pandora FMS from the search header both in the Metaconsole and node. Example:

Metaconsole searches return two types of results:

• Centralized search: Policies shown are those in the Metaconsole itself. In the table you see the Server field filled out with a dash to indicate that data are retrieved from the Metaconsole itself.

• Non-centralized search: Policies shown are those obtained directly from each node. In the table you see the name of the server filled out with the name of each node.

Click on Configuration > Manage Policies and all available policies will be shown.

To create a new policy, click on Create to create a new policy. Then enter the name, the group it belongs to, and an optional description. Afterwards, click on Create.

There is also a button to duplicate a policy in the options column:

If a policy contains agents, the delete button is disabled and a button to delete all its agents is shown.

This button will add the delete process to the queue. Once processed, the policy delete button will be enabled again.

In order to configure the policy, use the policy name under Configuration > Manage Policies. Once inside, access the different setup sections through the upper right menu. You may also edit elements directly by clicking on the direct accesses provided when hovering the mouse over the policy you intend to configure.

Policy configuration contains the following tabs in addition to the setup:

• Agents
• Modules
• Inventory modules
• Alerts
• External alerts
• Collections
• Linking
• Queue
• Agent plugins
• Agent wizards

The options available in a policy are:

• Adding/deleting one ore several existent policy agents.
• Creating/editing/deleting a module.
• Defining/editing/deleting an agent plugin.
• Creating/editing/deleting an alert.
• Creating/editing/deleting an external alert.
• Adding/deleting an existing collection.
• Adding/deleting an existing inventory module.
• Linking the policy to one or several adopted modules.
• Applying changes on the policy.

The different executable actions are not applied until the policy is applied. For instance, if you add an agent to the policy, you may create several modules and alerts, but they do not go into effect until the policy is applied.

Likewise, if you have a policy applied and you modify or delete elements, the changes do not take effect until it is applied again.

All changes are displayed within the Queue window, where changes may be applied.

The policy operations queue contains a summary of the elements changed since its last application:

This list contains the elements yet to be updated and the ones yet to be deleted:

• Pending to be updated
  • Agents
  • Groups
  • Adopted modules pending to be linked
  • Adopted modules pending to be unlinked
• Pending to be deleted
  • Agents
  • Groups
  • Modules
  • Inventory modules
  • Alerts
  • External alerts
  • Plugins

This summary shows whether the policy should be applied or not. Sometimes, a button will be shown to apply them next to the icon of agents pending to be applied.

If the pending changes only affect the database, e.g. changes in alerts, this button will apply the changes just at that level, so the application will be faster.

However, if the configuration that affects configuration files has been changed, e.g. if collections or local modules have been modified, the application is complete.

Under summary, there is a button called 'Apply All' at the right side, to apply everything regardless of the pending modifications.

When selecting “apply”, the policy agents are added to the application queue. The Pandora FMS Server will be in charge of applying the pending policies to the queue. You may see in the same screen the application's progress, and when it is finished, it will appear as complete in the queue together with the time passed since it finished.

To add agents to the poicy, you have at the top filtering options to select the agents you need in bulk by selecting them through the keys Ctrl or Shift.

At the bottom, there is a list with all agents associated to the policy, including those that are yet to be deleted from the policy.

The agent list has a filter by group, substring or application status.

List of items displayed:

Name

Agent Name

R.

Remote Configuration

S.

Policy agent status

U.

Number of unlinked modules in the agent

A.

Button to add the agent to the policy

Group

Icon group in order to find out whether that agent was applied by a policy group

Last application

Timestamp of the last time that the policy was applied

D.

Delete/Undo button.

When an agent is deleted, its name will appear crossed out and the delete button will be replaced by a button to undo the deletion and link the agent to the policy again.

Of course, adding or deleting policy agents will take effect when the policy is applied on the Queue page.

At the top there is the group recursion option. If it is checked, all child groups will be also added to the policy. The desired groups can be selected through the Ctrl or Shift keys.

At the bottom, there is a list containing all the groups linked to the policy, including those yet to be deleted.

The group list shows the following information:

Name

Group Name

S.

Policy group status

A.

Button to add that group to the queue in order to be applied

T.

Number of agents belonging to that group that have that policy applied, over the total number of group agents

Last application

Timestamp of the last time that the policy was applied

D.

Delete/Undo button.

When a group is deleted, its name will appear crossed out and the delete button will be replaced by a button to undo the deletion and link the group to the policy again. The agents belonging to that group will also appear crossed out.

Of course, adding of deleting policy groups will not take affect until this one is applied.

The modules menu allows to configure the modules to be added to the policy.

In order to add modules, choose the type of module in the drop-down menu. Select one of the available ones, and click Create:

Nota: This is the same procedure as that of creating a module in an agent.

Data Server modules are modules added to software agents. In order to work with these modules, the agents must have remote configuration enabled.

Select the option Create a new data server module and click Create in order to create a new data server module.

Later, configure all module fields. The field called Data Configuration is the one that allows to enter the module's code which is applied to the agents subscribed to this policy. This change will be displayed in this particular agent's pandora_agent.conf file.

Go to advanced options by clicking on Advanced Options.

Either fill out the fields, or if you defined previously a local component, select it. Finde more information about the description of said fields in Templates and components.

To create a Network Server module, choose the option Create a new Network Server Module and click on Create.

Then configure all module fields.

Click on Advanced Options.

Check the description of these fields and screens in the Templates and components section.

Click on Create once all fields have been filled out.

Keeping in mind that modules are repeated most of the time. Instead of filling out the fields any time a module is added, the best option is to preliminarily define it as a component and to use it as such.

To use a component, fill out the combo located under Using module component where it is possible to choose between the different component groups:

Once the group has been selected, another combo pops up where to choose the desired component.

In this example, the component called Catalyst CPU Usage from the Cisco MIBs Group has been chosen.

Once the component is selected, any of its fields may be modified. Click on Create once all fields have been filled out appropriately.

Choose the option Create a new Plug-In Server Module and click Create.

Then configure all module fields.

Fill in the advanced options:

Either fill in the fields, or if you defined previously a local component, select it. Find more information about the description of these fields in Templates and components.

Once you have filled out all the fields appropriately, click on Create.

To create a WMI Server module, click on Create a new WMI Server Module and click on Create.

Then define all module fields.

Click on Advanced Options:

Check the description of the fields of these screens in the Templates and components section. Once all the fields have been filled out appropriately, click on Create.

Keeping in mind that the modules are repeated most of the time. Instead of always filling out the fields any time a module is added, the best option is to preliminarily define it as a component and to use it as such. Component use is further explained in the section named “create a network module”.

For more information, check Windows remote monitoring through WMI.

To create a Web Server module, select the option called Create a new Web Server module and click on the Create button.

Then configure all the module's fields. Later access Advanced options.

Check the description of the fields in the Templates and Components section. Once all the fields have been filled out appropriately, click on Create.

For more information about Web module creation check Web monitoring.

It is possible to modify all modules assigned to a policy.

In order to do so, click on the module's name so the module configuration options are shown.

Once they have been modified appropriately, click on Update.

In order to delete the module from the policy and remove it from agent configuration, click on the trash button to the right of the module's name. Once done, the module will still appear but crossed out. The Delete button will have been replaced by the Undo button.

If you wish to delete several modules, select the check box to the right of the trash icon and click Delete.

It is also possible to create inventory modules within a policy by picking one from the list of the available ones in the system, thereby picking an interval and the credentials.

Like the rest of the policy elements, if you remove an inventory module, it will appear crossed out. The “Undo” button will replace the delete one to undo the action.

For more information about adding remote inventory modules check Inventory modules.

When a module is created based on a policy is applied, it is referenced through the policy icon. These policy modules may have several states:

• Linked
• Unlinked
• Adopted
• Linked adopted

These modules are created in the policy and once the policy is applied, they are also created within the agent. These are the average modules created within policies.

You may link and unlink modules from the module setup page by clicking on this button.

Unlinked modules are modules that belong to a policy but which are not affected by policy changes. They can be useful because the enable establishing individual exceptions to modules that belong to a certain policy. That way you may customize a specific agent module within a policy without taking it out from said policy.

These modules were created within the policy with the same name of an already existing module within the agent. When applying the policy, Pandora FMS uses the existing module's data instead of creating a new module and it will keep on being managed from the agent.

An adopted module can be linked to use the definition set in the policy instead of the local one. That way, when managing the module from the policy, when there is some change the module changes too.

The Alert menu allows to configure the alerts of the modules that belong to the policy.

In order to add an alert, link it to one of the predefined alert templates or to a module that belongs to the policy and click on Add.

It is possible to add actions to alerts, set them on stand-by mode or disable them. If you intend to change any module or template, delete it and create a new one.

In order to delete an alert from the policy and remove it from the agents that have it installed, click on the trash button at the right of the module's name. Once done, the alert will still be visible but crossed out. Then, the “Delete” button will be replaced by an “Undo” button.

External alerts allow to link alerts to agent modules not included in the policy module's main list. It is sometimes very useful to assign alerts to some agent modules but not to all of them.

In order to create an external alert, fill out this form.

The first field is intended to select the agent's modules. Only those not contained in the policy. The second field is intended to select the appropriate alert template. Click Add.

This feature is available both in the Metaconsole and the nodes.

Considering how easy it is to create new external alerts and their few variables, the possibility of modifying external alerts does not exist. In order to modify an external alert, delete it and create a new one.

In order to delete an external alert from the policy and remove it from the agents that have it installed, click on the trash button on the right of the external alert.

The deletion system is the same as the one of the regular alerts. The deletion does not take effect until the policy is applied. Until that very moment, the policy will still appear but crossed out and the “Delete” button will be replaced by an “Undo” button to undo the action.

One or several modules may have different actions from different policies.

For example, for an agent module:

• Proceed to create two separate policies and include the module agent.

• Proceed to create the external alerts in each policy. Add the selected agent module.

• Apply the changes.
• By going to the module view of the selected agent, you will be able to see the external alerts for the two policies, i.e. one alert per template, module and policy:

As an advanced example, a direct alert, which does not belong to any policy, can be added to the same module.

This will generated, when the module changes its status to the specified condition, three different alerts (of which the last two correspond to policies):

The process to add policy plugins is the same as that of the agent. Check the section Plugins in software agents .

For more information about the development of these plugins go to Agent plugin development.

These are resources used to massively deploy scripts or plugins to be used in Software Agents, monitoring policies on agents and Satellite servers. It is accessed from the menu Configuration → Collections.

To create a new file collection, click Create:

Fill in the name, group, short name and description and click Create.

To add resources to a collection go back to the collection list and click on the name of the collection resources will be added to.

In the three icons highlighted in the image above, from left to right you may create a directory, create a text (which you can then edit) or store a new file.

Once the resources have been added, return to the collection list and an icon with a yellow triangle will appear where you may click to synchronize the changes with the different Pandora FMS elements (agents, Software Agents, monitoring policies and Satellite servers).

Each collection has its own base directory. In the Web Console these are stored in the directory /pandora_console/attachment/collection with a name like fc_XXX, where XXX is the numeric ID of the collection. File collections can contain subdirectories. File collections are transferred as ZIP (compressed) files to the Agent, through Tentacle. File collections are only supported with Tentacle transfer mode.

Go to Resources → Manage agents and click on the name of a Software Agent. Click on the Collection tab. You will have a list of available collections similar to this one:

To add a collection, click on the plus icon in the Add column:

If you see an icon with a yellow warning triangle in the Status column, either the collection is empty or the collection has not been synchronized. If the collection contains files or directories, click on the yellow icon. Once you have applied the changes, the collection status will indicate the successful synchronization.

After a few minutes you may go to Configuration → Collections and click on the name of the collection added. The newly added Software Agent will be displayed in the Agents tab.

Each file collection has a short name; for this example fc_13830334393. This means that the utilities, scripts or executables inside the collection will be in:

%ProgramFiles%\pandora_agent\collections\fc_13830334393

It is important to know that the collection is compressed to be sent to the Software Agent, so the latter must have the unzip.exe tool in order to decompress the file. As of version 3.2 of the Agent, this utility is installed within:

%ProgramFiles%\pandora_agent\utils

You need to know this to be able to use Modules that work when working with those files, so that you may specify the full “real” path. Each file collection is stored at different addresses, to prevent different file collections from overwriting or conflicting with each other.

The collection control system is based on md5 hashes, similar to Agent configuration file management. When creating the collection in the Pandora FMS Web Console, an md5 hash is created and sent to the Software Agent. This md5 will only be updated when there are changes in the collection in Pandora FMS Web Console, and not in the Software Agent. Therefore, the changes in the collections made locally in the agents will remain as long as the collection is not modified in the Web Console.

If any change is made in the collection in the Web Console, the md5 will be recalculated, and when it does not match the existing one in the Agents, it will apply the last collection configuration, overwriting the previous one and deleting possible local modifications on the collections.

If you want to use a Module that uses a file included in the collection, reference only the directory that contains the collection, using its fixed identifier. This is an example using a plugin Module:

It works much like individual Agent collections, but instead of applying a collection to a specific Agent, it is applied to a policy:

Refer to this section to manage and synchronize collections.

Click on the Servers → Manage servers menu and then click on the remote configuration icon of the Satellite server to which the collection will be added. Click on the Collections tab and in the list of available collections, in the Actions column add the respective collection by clicking on the + icon. You may also delete the added collections by clicking on the trash can icon.

When you save the changes, after a few minutes, you will see in the configuration file the new section created with the added collections and their respective short name.

Refer to this section to manage and synchronize collections.

From Pandora FMS 729 OUM you may centralize collection management from the Metaconsole. To access it, go to the Centralised management → Agent management menu and click on the Collections tab.

Refer to this section to manage and synchronize collections, as they work similarly in the Web Console.

It is possible to manage policies from the Metaconsole. The process consists of distributing the information to all the nodes for each of the servers in charge of applying them. This distribution of information is complex because it is important that all nodes have the same data as the Metaconsole.

The Metaconsole has a centralized management mode. This means that, as far as policies are concerned, management is done from the Metaconsole and not from the node. In the Metaconsole, the selection of this mode is made from the general configuration.

For the configured nodes to know that the mode is centralized, just go to the license screen and synchronize. That way, all policy management pages will be informative only, that is, available in read-only mode. The new nodes that are added will be automatically configured in this mode.

Finding out if a node is in centralized mode or not. If so, a warning message will appear in the policy view.

The policy queue in the Metaconsole is different from that of the nodes. While in the latter, you can see the status of the implementation of the incomplete policies and a history of those already completed, in the Metaconsole this second part has been deleted. Only those that have not been applied or are in progress are shown indicating the node they belong to.

However, if you want to check the history, it is available at the node. In fact, it is the only thing that can be managed from the node, since all other pages are in read-only mode.

Node and Metaconsole data of each policy must match. Modules, alerts, inventory module, collections… have to be consistent. Therefore, when applying a policy from the Metaconsole, all this data is copied to the involved nodes.

It is very diverse and very sensitive information. There may be an error when copying the data. In this case, the console will display an error and the node will be rolled back with the previous data. In clean installations there should be no problem, but it is recommended to delete the previous policy configurations made manually in the nodes, transferring them to the metaconsole to later synchronize them from there.

Go back to Pandora FMS documentation index