Table of Contents
Monitoring with Policies
We are working on the translation of the Pandora FMS documentation. Sorry for any inconvenience.
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.».
To apply any changes you may have made in policies, apply the policy in the corresponding section (queue).
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.
Adding a Policy
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.
Duplicating a Policy
There is also a button to duplicate a policy in the options column:
The created policy copy will appear as “not applied”, regardless of the original policy's state.
Deleting a Policy
To delete any policy, it must not have any agents associated.
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.
Configuring a Policy
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:
- Inventory modules
- External alerts
- 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.
Policy queue management
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
- Adopted modules pending to be linked
- Adopted modules pending to be unlinked
- Pending to be deleted
- Inventory modules
- External alerts
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.
Agents and Groups
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
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:
Policy agent status
Number of unlinked modules in the agent
Button to add the agent to the policy
Icon group in order to find out whether that agent was applied by a policy group
Timestamp of the last time that the policy was applied
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
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:
Policy group status
Button to add that group to the queue in order to be applied
Number of agents belonging to that group that have that policy applied, over the total number of group agents
Timestamp of the last time that the policy was applied
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.
Creating a Data Server module
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
Go to advanced options by clicking on Advanced Options.
Creating a Network Server Module
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.
Creating a Plug-in Server module
Choose the option Create a new Plug-In Server Module and click Create.
Then configure all module fields.
Fill in the advanced options:
Once you have filled out all the fields appropriately, click on Create.
Use macros to configure dynamic parameters, like the IP address of an agent. To see the list of available macros, click on the help(?) button on Plugin(?)
Creating a WMI Server module
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.
Creating a Web Server module
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.
In the particular case of Web modules, there are no components.
For more information about Web module creation check Web monitoring.
Modifying a previously created module
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.
If the policy module is renamed, the name will be updated like any other field when the policy is applied.
If a policy module is renamed but a module with the new name already exists in one of the agents, this module will be adopted while the module with the old name is deleted.
Deleting an already created Module
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.
Policy module states
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 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.
Policy changes are only applied if the module is linked again.
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.
Policy changes do not affect this type of modules.
If you delete a policy, adopted modules are not deleted from the agents, they use the local definition again.
Linked adopted modules
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.
When an agent is deleted from a policy, linked modules are deleted and just the linked and linked adopted modules stay.)
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.
Adding External Alerts
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.
Modifying External Alerts
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.
Deleting External Alerts
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.
The process to add policy plugins is the same as that of the agent. Check the section Plugins in software agents.
In order for the agent plugin to be applied by a policy, the plugin must exist in the path specified by the agent.
For more information about the development of these plugins go to Agent plugin development.
They are normally used to mass deploy scripts or plugins, which will be later on executed by the very policy agents.
The first task is to arrange a life compilation. In order to do it, go to the agent's administrator. There you will see a sub-option called Collections. Click on it so that you may create a new collection as seen on the picture below.
Once you have created the file collection, upload any appropriate file necessary for that collection, all of them will go to the same base directory. These files can be binaries, scripts or data files. In the console, file collections are stored under a directory called
/pandora_console/attachment/collection, bearing a name like
fc_XXX, where “XXX” is the collection's numerical ID. File collections may also contain subdirectories. File collections are transferred as ZIP files to the agent through Tentacle. File collections are only supported by the Tentacle transfer mode.
On the picture below, you may see how the created example collection (fc_1383033439) has two files downloaded:
If we go back to the main collection screen, you can see both collections as a triangular icon, which indicates that there is a problem. This happens because collections are not synchronized. It is recommended to synchronize them by clicking on that same triangular icon.
When a file collection is synchronized, a circle arrow appears.
Once the collection is synchronized, it will be applied onto the agent - this time without using any policies. Go to the agent administrator mode and look for the collection's tabulator (it is a disk-shaped icon). The available collections are displayed there in order to pick one of them and apply it to the agent, in this case, from the previous example (Windows® utilities):
Now it has been applied. Next time the agent contacts the server, you will obtain the file and a little modification in the
.conf file, which will look like this:
File collections and policies
This works in a similar way as the single agent collections. Instead of applying a collection on a specific agent, it is applied to a policy, as seen here.
It is very easy to use a module which works with a file included in the collection: only refer to the directory that contains the collection by using its fixed ID. This is an example that employs a plug-in module:
Collection centralized management
From Pandora FMS OUM729 onwards, you can centralize the collection management from the Metaconsole.
For more information, click here.
Agent file collections location
Each file collection has a “short name”. In this example, it is called “fc_1383033439”, which means the features, scripts or executables contained in the collection are located at:
It is important to keep in mind that the collection is sent in a compressed format to the agent, so this file collection should contain the unzip tool to be able to unzip the file. Since the agent version 3.2, this feature is installed under:
This information is important in order to use modules that work by using these files and to be able to specify the complete “real” path. This is another example:
If the collection's short name is “fc_18”, the location will be:
Each file collection is stored in a different location in order to prevent file collections from overwriting each other or having conflicts among them.
Collection control system is based on md5 hashes, similarly to agent configuration file management. When creating the collection in Pandora FMS console, a md5 hash is created and later sent to the agent. This md5 will only be updated when changes in the collection next to the Pandora FMS console are made and not in the agent. Therefore, local collection changes will stay within the console while the collection is not modified in the console.
If you make some change in the collection next to the console the md5 will be recalculated and if it does not match that of the agents, the last collection configuration will be applied, overwriting what was written before and deleting possible local modifications on the collections.
This is an example of a plugin used by the
df_perfecnt.vbs file, contained in a collection called “fc_1383033439” for a Windows® agent:
module_plugin cscript //B "%ProgramFiles%\pandora_agent\collections\fc_1383033439\df_percent.vbs"
Policy management from the Metaconsole
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.
Configuration. Centralized management mode
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.
Policy queue in Metaconsole
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.