Pandora: Documentation en: Common param modules
1 Common module parameters
1.1 Historical data
By default, Pandora FMS saves each value collected from each module. This, in a system with many agents, has a very considerable impact on the database of the system. Therefore, the system allows you to choose which data needs to be stored in a historical and which does not. If you only need to know the last value and it is enough for you to have a history of alerts and/or events, deactivate the historical storage for modules where you do not need it, your system will have better performance.
1.2 No generating unknown events
Similar to the previous point (historical), Pandora FMS modules generate "unknown" events when they stop receiving data over a period of time. To relieve the server load, avoid generating these types of events if you don't really need this feature.
The system will automatically multiply the value obtained in the monitoring by this number. It is useful for normalizing data, converting it from drives or other uses. Some conversions, for example:
- Converts timeticks (SNMP) to days: 0.000000115740741
- Converts bytes to Megabytes: 0.00000095367432
- Converts bytes to Gigabytes: 0.00000000093132
- Converts megabits to megabytes: 0.125
It has some predefined values, for a simpler use, as you can see in the previous screenshot. You can also add and modify some of the default values in the Visual Setup option of the console.
1.4 Max / Min Value
Unlike the threshold max/min values, these limit the maximum and minimum possible "acceptable" values for this module. They act as a filter to avoid entering data that could distort monitoring. The simplest case to understand is a supposed percentage value, which should have minimum values of 0 and maximum values of 100. Any other value outside those margins would be meaningless.
1.5 Flip Flop Threshold
A remote module (either a network module, plug-in module, etc.) can return unreliable data for a variety of reasons. For example, a ping module can return 0 even if a host is up due to network congestion problems.
Depending on how Pandora FMS is configured, this can trigger a series of unwanted events (status changes, alert triggers, sending emails...).
To solve this situation, Pandora FMS has FF thresholds customized for each module. The FF threshold is the number of additional times a module will run before changing its status (a value of 0 means that this feature is disabled). Only if the condition that causes the status change is maintained in all retries will the module status be changed.
The interval of these additional runs can be specified with the FF interval.
All this is best seen with an example: let's suppose we have a WMI module that returns the amount of free disk space in megabytes. We configure this module to go into critical status when this value is less than 100. Next, we create an alert that sends an email to the system administrator when the module goes critical so that it can free up some space. But, because of a software bug, every now and then the returned value is much lower than the current value. To solve this problem we configure the FF threshold of the module to one and the FF interval to 30 seconds. This means that the first time the module receives a data less than 100, the module will run again after 30 seconds, and only if it is still less than 100 will it go into in critical status. Otherwise, the module will continue its normal execution.
This works well for synchronous modules, but asynchronous modules need an additional configuration parameter. Since they do not send data at regular intervals, checking consecutive values may not be very useful if they are far apart over time. In this case, you must specify an FF timeout, which means that consecutive values must occur within the specified time interval.
From version 5.1, individual FM thresholds can be defined for each state, so that a module may need two consecutive values to change to critical state, but only one to return to normal state.
Used to assign a unit to the module data. It is a purely informative data and will be displayed in various data views as well as graphs of the module in question.
The module data is still stored, but the generation of events and alerts is stopped. This is especially relevant when, through the planned stops, we leave a module "quiet" for a certain period of time.
The difference between the "quiet" mode and the "off" mode is that the latter does not process data and the "quiet" mode does, so we will quietly continue to store data but ignore its status information, and with the "off" mode we will completely ignore the data.
1.8 Critical, Warning, and Unknown instructions
Instructions will be displayed when the status of the module is critical. This can be seen in the extended event information.
In addition, this information can be used as part of an alert, using the following macros (see the Alerts chapter for more details) :
- _alert_critical_instructions_: Instructions contained in the module for a CRITICAL status.
- _alert_warning_instructions_: Instructions contained in the module for a WARNING status.
- _alert_unknown_instructions_: Instructions contained in the module for an UNKNOWN status.
1.9 Module groups
Module groups allow you to make filters and are used in some specific views. It is a way of gathering modules together, which is useful when we have a large volume of modules in the same agent. You can define new modules or modify existing ones in the configuration menu "Resources -> Module groups".
Tags are labels associated with each module that will then be propagated to the events generated by this module and can be used in its event alerts. Tags are useful because they allow you to use them as filters in reports, event views, and even have specific views on them. Additional tag information (URL, email, phone) can be used in alerts, as they are available as a macro.
To be able to create or modify a tag, we click on Module tags:
Tags allow you to set name, description and optionally a complete URL (http://somewebpage.com), email or phone associated with this tag. Note that it is possible to associate one or more tags to each module. To do this, they must first be created as described above. Once created, they will be available to be assigned to each module.
In the advanced options of a module, the available tags will be shown in the left column and the tags already associated with the module in the right column:
Tags can also be used to grant specific access permissions to a module, so that a user can only access one module of the agent, without having access to the other modules. You can see this in the user profiling section inside Managing and Administration