Pandora: Documentation en: Other Monitoring
1 Other Types of Monitoring
In addition to features like remote monitoring, agent-based monitoring or web monitoring, Pandora FMS offers other advanced resources to improve monitoring. With these resources, you're able to predict the value of a module based on historical data or create new modules, conducting arithmetic operations by utilizing existing ones.
1.2 Monitoring by Synthetic Modules
This is a feature of the Enterprise version. Synthetic modules are manufactured from data from other modules, which can be in the same agent or in different agents. The operations that can be carried out are arithmetic (add, subtract, multiply and divide) between modules and/or with absolute values
Here are some examples:
- A module called 'Traffic sum' which adds the values of the incoming and outgoing traffic of a router, generating a new module by the total traffic of the interface.
- A module called 'Total users' which adds the values of ten modules called 'Connected users' in each of the five servers where the number of connected users is monitored.
Synthetic modules are managed by the prediction server, so in order to use them we must have that subcomponent of the Pandora FMS server activated and the agent on which we create the modules must use that server.
The first step to create a synthetic module is to go to the 'management' section in the 'module' tab of an agent, where we're going to create a new module of the prediction type.
In our first example, we're going to create a fictitious module which is going to contain the arithmetic average value of two modules from two different agents: CPUUse (Sancho-XP) and cpu_user (Garfio). Within each machine, this module measures the percentage of CPU use, and they are two Windows and Linux machines respectively. The final result will be a module stored in agent 'Sancho-XP' which is going to contain the average of both values.
The second example creates a module called "Total accesses" with the average of the values of the modules "Apache_accesses" from two different agents, called Sancho-XP and Sancho-XP_2.
Another easier but more useful example is the one which has been used to create the module called 'Total accesses' in 'Sancho-XP_2'. It simply 'copies' the value of a module of the same name into 'Sancho-XP' to produce the value.
In order to operate with other logical operations (multiplication, subtraction, and division), we simply have to keep the order of the operators in mind. Please feel free to play around with the interface to see how all other arithmetic operations between different modules can be conducted. We're also able to use a fixed value to add it to our logical operations as shown in the picture below.
You're able to select multiple agents from the box on the left side (by using 'control'). In the central box, all the 'common' modules from the selected agents are going to be shown. It can be pretty useful to produce averages from common modules in a server group (e.g. CPU or disk space).
1.3 Predictive monitoring
Predictive modules require a "base" module on which to "compare" and make predictions. We have two types: anomaly detection and value prediction, both based on the series of data from the module we use as a basis to make the prediction. These two types are based on the type of data to be stored in the predictive module that we are going to create:
- (generic_data) Predict what an acceptable value would be, in a time span of 5-10 minutes (or more, but the longer we estimate in the future, the worse approximation).
- (generic_proc) Detect if there is an anomaly or not in the value collected by the "origin" module being analyzed.
Predictive modules are managed by the prediction server, so in order to use them we must have activated that subcomponent of the Pandora server and the agent on which we create the modules must use that server.
Let's see how to define a predictive module.
Within an existing agent, click on the top tab of Modules. In it, select Create a new predictive module:
Once the Create button is pressed, a form will be displayed in which the necessary fields must be filled in in order to create a prediction module. The data type defines the behavior of the predictive module type: depending on the type, we will act as anomaly detector (Boolean type module) or as "predictor" of the module value in the future (numerical data type module).
Below, in the specific section on predictive modules, attention should be paid to the following fields:
- Agent. Just put a part of the name on it and it'll look for agents with that piece in the name.
- Module. Once you have selected the agent, it will show which modules it has. This will be the "source module" from which it will use the history to predict its future data or detect anomalies.
- Period. Choose the type of sample to be used: daily, monthly or weekly. In this way, an average will be made with the information of the current data and the data in the last four periods. If you have chosen daily, the average of the last four days will be chosen. Same with weekly or monthly data.
Finally, we should not forget a field that appears in advanced properties:
- Interval: The interval takes a number of samples from the last 4 days/weeks/month during the duration of that interval. For example, if we're taking that sample at 13.00, and the interval we set is one hour, it will take the average to add all the values of the last 4 weeks/months/day from 12.30 to 13.30.
The difference between the numerical predictive calculation and anomalies detection is that the latter compares the value obtained in the prediction calculation with the current one if it is outside a threshold defined by the standard deviation of that calculated period, it returns fault (0), or it returns ok (1) if it is inside.