Pandora: Documentation en: Configuration Agents
Contents
- 1 Pandora FMS Software Agents
- 1.1 What is a software Agent?
- 1.2 Introduction to the Agent Configuration
- 1.3 General Agent Parameters
- 1.3.1 server_ip
- 1.3.2 server_path
- 1.3.3 temporal
- 1.3.4 description
- 1.3.5 group
- 1.3.6 temporal_min_size
- 1.3.7 logfile
- 1.3.8 interval
- 1.3.9 disable_logfile
- 1.3.10 debug
- 1.3.11 agent_name
- 1.3.12 (>=5.1SP2) agent_name_cmd
- 1.3.13 (>=7.0) agent_alias_cmd
- 1.3.14 address
- 1.3.15 encoding
- 1.3.16 server_port
- 1.3.17 transfer_mode
- 1.3.18 (>= 6.0) transfer_timeout
- 1.3.19 server_pwd
- 1.3.20 server_ssl
- 1.3.21 server_opts
- 1.3.22 delayed_startup
- 1.3.23 pandora_nice
- 1.3.24 autotime
- 1.3.25 cron_mode
- 1.3.26 remote_config
- 1.3.27 xml_buffer
- 1.3.28 timezone_offset
- 1.3.29 parent_agent_name
- 1.3.30 agent_threads <threads>
- 1.3.31 include <filename>
- 1.3.32 broker_agent <name>
- 1.3.33 pandora_user <user>
- 1.3.34 (>= 5.X) custom_id
- 1.3.35 (>= 5.X) url_address
- 1.3.36 (>= 5.X) custom_fieldX_name
- 1.3.37 (>= 5.X) custom_fieldX_value
- 1.3.38 (> 5.1 Unix agent only) macro<macro> <value>
- 1.3.39 (>= 6.0SP5) group_password <password>
- 1.3.40 (>= 7.0) ehorus_conf <path>
- 1.3.41 (>= 7.0OUM713) transfer_mode_user <user>
- 1.4 Secondary Server
- 1.5 UDP Server
- 1.6 Modules definition
- 1.6.1 Common elements of all modules
- 1.6.1.1 module_begin
- 1.6.1.2 module_name <name>
- 1.6.1.3 module_type
- 1.6.1.4 module_min <value>
- 1.6.1.5 module_max <value>
- 1.6.1.6 module_min_warning <value>
- 1.6.1.7 module_max_warning <value>
- 1.6.1.8 module_min_critical <value>
- 1.6.1.9 module_max_critical <value>
- 1.6.1.10 module_disabled <value>
- 1.6.1.11 module_min_ff_event <value>
- 1.6.1.12 (>= 6.0 SP4) module_each_ff <value>
- 1.6.1.13 (>= 6.0 SP4) module_min_ff_event_normal <value>
- 1.6.1.14 (>= 6.0 SP4) module_min_ff_event_warning <value>
- 1.6.1.15 (>= 6.0 SP4) module_min_ff_event_critical <value>
- 1.6.1.16 (>= 6.0 SP4) module_ff_timeout <seconds>
- 1.6.1.17 module_description <text>
- 1.6.1.18 module_interval <factor>
- 1.6.1.19 module_timeout <secs>
- 1.6.1.20 module_postprocess <factor>
- 1.6.1.21 module_save <variable name>
- 1.6.1.22 module_crontab <minute> <hour> <day> <month> <day of the week>
- 1.6.1.23 module_condition <operation> <command>
- 1.6.1.24 module_precondition <operation> <command>
- 1.6.1.25 (>= 5.x) module_unit <value>
- 1.6.1.26 (>= 5.x) module_group <value>
- 1.6.1.27 (>= 5.x) module_custom_id <value>
- 1.6.1.28 (>= 5.x) module_str_warning <value>
- 1.6.1.29 (>= 5.x) module_str_critical <value>
- 1.6.1.30 (>= 5.x) module_warning_instructions <value>
- 1.6.1.31 (>= 5.x) module_critical_instructions <value>
- 1.6.1.32 (>= 5.x) module_unknown_instructions <value>
- 1.6.1.33 (>= 5.x) module_tags <value>
- 1.6.1.34 (>= 5.x) module_warning_inverse <value>
- 1.6.1.35 (>= 5.x) module_critical_inverse <value>
- 1.6.1.36 (>= 5.x) module_native_encoding <value>
- 1.6.1.37 (>= 5.x) module_quiet <value>
- 1.6.1.38 (>= 5.x) module_ff_interval <value>
- 1.6.1.39 (>= 5.x) module_macro<macro> <value>
- 1.6.1.40 (>= 5.1 SP4) module_alert_template <template_name>
- 1.6.1.41 module_end
- 1.6.2 Specific guidelines to obtain information
- 1.6.2.1 module_exec <command>
- 1.6.2.2 module_service <service>
- 1.6.2.3 module_proc <process>
- 1.6.2.4 module_cpuproc <process>
- 1.6.2.5 module_memproc <process>
- 1.6.2.6 module_freedisk <unit_letter:>|<volume>
- 1.6.2.7 module_freepercentdisk <unit_letter:>|<volume>
- 1.6.2.8 module_occupiedpercentdisk <unit_letter:>|<volume>
- 1.6.2.9 module_cpuusage <cpu id>
- 1.6.2.10 module_freememory
- 1.6.2.11 module_freepercentmemory
- 1.6.2.12 module_tcpcheck
- 1.6.2.13 module_regexp
- 1.6.2.14 module_wmiquery
- 1.6.2.15 module_perfcounter
- 1.6.2.16 module_inventory
- 1.6.2.17 module_logevent
- 1.6.2.18 module_plugin
- 1.6.2.19 module_ping <host>
- 1.6.2.20 module_snmpget
- 1.6.1 Common elements of all modules
- 1.7 Examples
- 1.8 Specific Configuration by Technologies
- 1.9 Pandora FMS Drone Agents
- 1.10 Agent / Module Autocreation from XML File / Learning Mode
- 1.11 Extended Module Information
1 Pandora FMS Software Agents
1.1 What is a software Agent?
As its name indicates, they are small pieces of software that are installed in the operating systems and remain running in them to extract monitoring information and send it to the Pandora FMS server regularly.
They use the commands and tools of the operating system in which they are installed to obtain the information. They conform the data in a file in XML format and send them to the Pandora FMS data server, which processes and stores them in the database.
Each of the individual checks is called Module.
1.2 Introduction to the Agent Configuration
The operation of the software agent is determined by its configuration file, called pandora_agent.conf, located in the installation directory on Windows systems, and /etc on Linux systems.
The configuration file contains all the operating parameters and modules of that agent.
1.3 General Agent Parameters
The Configuration of the General Agent Parameters is defined in this section. Some of them are common for all systems and others are intended specifically for Windows or Unix machines. The general parameters are:
The first time the server receives data from an agent is going to save all of the information into the database. For the following received data it will only update (depending on learning mode status enabled/disabled) the following fields from XML file: version, date, OS version, and the following parameters from the configuration file: gis_exec, latitude, longitude, altitude parent_agent_name, timezone_offset, address and custom_field. |
|
1.3.1 server_ip
The IP address or the name of the Pandora FMS Server Host where all data will be stored.
1.3.2 server_path
The server path is the comprehensive file path where the server stores all the data sent by the agents. The default path is /var/spool/pandora/data_in.
1.3.3 temporal
The path where the agent stores the data files before they are sent to the server and deleted locally.
1.3.4 description
Sends the description of the agent in XML and Pandora FMS imports this description when it creates the Agent.
1.3.5 group
If there is a group with the name specified in this parameter, the agent will be created within this group unless the server forces the creation of all agents in a given group.
1.3.6 temporal_min_size
If the free space (in MB) of the partition in which the temporary directory is located is lower than this value, it won't continue generating data packets. This prevents the disk from being full if for any reason connection to the server is lost for an extended period of time.
1.3.7 logfile
The path to the Pandora FMS agent events record file.
1.3.8 interval
It is the agent sampling time, in seconds. Each time this interval is completed, the agent will collect information and send it to the Pandora FMS server.
1.3.9 disable_logfile
This parameter disables log writing in pandora_agent.log. Only for Windows.
1.3.10 debug
If it is active (1), the agent data files are stored and renamed in the temporary directory and are not deleted after being sent to the server, being able to open XML files and analyze their content.
1.3.11 agent_name
It allows setting a custom name. If it is not enabled, the agent name will be the hostname of the machine.
1.3.12 (>=5.1SP2) agent_name_cmd
Defines the agent name using an external command. If agent_name_cmd is set, agent_name is ignored. The command must return the agent name by STDOUT. If you return more than one line, only the first line will be used.
1.3.13 (>=7.0) agent_alias_cmd
Defines the agent alias using an external command. If agent_alias_cmd is defined, agent_alias is ignored. The command must return the agent name by STDOUT. If you return more than one line, only the first line will be used.
1.3.14 address
This is the IP address of the software agent. It could be an IP address with the format X.X.X.X or a domain name such as 'localhost' or 'auto'. If it's an IP address or a domain name, it will be added to the addresses of the agent and established as a main address. If the value is 'auto', it will obtain the IP address from the host and added to the agent as in the previous case.
1.3.15 encoding
Installs the kind of codification of the local system, such as ISO-8859-15 or UTF-8.
1.3.16 server_port
This parameter allows to identify the remote port of the server that is waiting. By default it's 41121 for Tentacle.
1.3.17 transfer_mode
This parameter specifies the transfer mode we have to install in order send the agent data to the server. Tentacle by default.
1.3.18 (>= 6.0) transfer_timeout
It is the timeout for file transfer, if the indicated number of seconds is exceeded without completing the transfer, it will be cancelled.
1.3.19 server_pwd
Specific for the password of Windows FTP and for the Tentacle transference mode, although the password for the latter is optional. Server password for authentication with password.
1.3.20 server_ssl
Specific for the Tentacle transfer mode. Allows to authorize ('1') or deny ('0) the SSL network encryption.
1.3.21 server_opts
Specific for the Tentacle transfer mode. Allows to give additional parameters to the Tentacle client for advanced configurations with security options.
Coming with the 3.2 agent version, Tentacle supports the optional use of a HTTP proxy (using CONNECT) mode to send information to the server. In order to be able to use the output through a proxy, we use the following advanced option (example):
server_opts -y user:[email protected]:8080
This will force the Tentacle client to use 'proxy.inet' on port 8080 using "user" and "pass" for authentication. If you intend to use a proxy on e.g. 192.168.1.2 on port 9000 without credentials, the command would have to be:
server_opts -y 192.168.1.2:9000
1.3.22 delayed_startup
This parameter allows the Pandora FMS agent to be configured in order to start working after any specific amount of time (in minutes) after manual execution. It's deactivated by default. This option is only valid on Linux/Unix agents.
1.3.23 pandora_nice
This parameter allows to specify the priority that the Pandora FMS agent process will have within the system. It's only available for Unix / Linux agents.
1.3.24 autotime
If it's enabled ('1') it sends a timestamp of special execution (AUTO) that makes the server use its local date / time to establish the data time, not paying attention to the time sent by the agent. This is necessary in agents which have a wrong time or a different hour from the server for any reason.
1.3.25 cron_mode
With this parameter, it's possible to make the agents using the Linux crontab functions to execute itself in a predetermined interval instead of using the agents internal system to execute itself at a certain time. It's deactivated by default.
1.3.26 remote_config
(Pandora FMS Enterprise only)
Enables (1) or disables (0) remote agent configuration. Operation is only allowed with Tentacle transfer mode.
1.3.27 xml_buffer
If enabled (1), the agent will save in its temporary directory the XML files that it could not send to the server in case of a connectivity problem. They will be sent when communications are restored.
1.3.28 timezone_offset
The agent can now install its timezone offset with the server. This allows the server to make a scrolling of the time collected by the agent, so that it matches the local time of the server.
# Timezone offset: Difference with the server timezone timezone_offset 3
It is calculated by subtracting the agent's timezone from the server's timezone. For example, if the server's timezone is UTC+1 and the agent's timezone is UTC-5, the timezone offset should be 6 = 1 - (-5).
1.3.29 parent_agent_name
Indicates the parent of the software agent. It must be the name of an existing agent in Pandora FMS.
1.3.30 agent_threads <threads>
Number of threads the agent is going to launch to execute modules simultaneously.By default, the modules are executed one after the other without launching any additional thread. This is only available in Linux/Unix agents.
# Number of threads to execute modules in parallel agent_threads 4
1.3.31 include <filename>
This file can contain additional modules and collections alongside the ones found in the main configuration file. This token is optional.
1.3.32 broker_agent <name>
Enables broker agent functionality. To activate it, you only need to uncomment the parameter and indicate the name that will be assigned to the broker agent:
broker_agent Name_broker
1.3.33 pandora_user <user>
This parameter is optional and allows the agent to be executed with a specified system user. This user has to have permissions to execute the agent and all associated resources.
1.3.34 (>= 5.X) custom_id
Custom ID of the agent for external applications.
1.3.35 (>= 5.X) url_address
Custom URL to open it from the agent in the console.
1.3.36 (>= 5.X) custom_fieldX_name
Name of an agent custom field which already exists on the system. If doesn't exist, it will be ignored.
Example:
custom_field1_name Model
1.3.37 (>= 5.X) custom_fieldX_value
Value for the custom field X defined in the previous parameter.
Example:
custom_field1_value C1700
1.3.38 (> 5.1 Unix agent only) macro<macro> <value>
Defines a local execution macro that can be used in the definition of a module. These macros are used in the meta console system and local module components system to "abstract" the difficulty of using a module by directly editing the code, presenting a local interface that allows to "fill in" values to a less advanced user. These values are used below, using a macros system, relatively similar to the macros system of the local plugins.
Example:
module_begin module_name FreeDisk_opt module_type generic_data module_exec df -kh _field1_ | tail -1 | awk '{ print $5}' | tr -d "%" module_macro_field1_ /opt module_end
1.3.39 (>= 6.0SP5) group_password <password>
Password for the agent group. Leave it commented if the group is not password protected.
1.3.40 (>= 7.0) ehorus_conf <path>
Absolute path to a valid eHorus agent configuration file. The agent will create a custom field named eHorusID that contains the eHorus agent's identifying key.
1.3.41 (>= 7.0OUM713) transfer_mode_user <user>
User of files copied in the local transfer mode. In console folders, this user must have reading and writing permissions for the remote configuration to work properly. By default it is apache.
1.4 Secondary Server
We can define a secondary server to which the data will be sent in two possible situations depending on the configuration:
- on_error: Send data to the secondary server only in cases it could not send them to the primary one.
- always: Always send data to the secondary server, no matter if it's able to contact the main server or not.
Configuration example:
secondary_server_ip 192.168.1.123 secondary_server_path /var/spool/pandora/data_in secondary_mode on_error secondary_transfer_mode tentacle secondary_server_port 41121
1.5 UDP Server
The Pandora FMS Agent can be configured to listen to remote commands. This server listens to a UDP port spcified by the user and allows orders to be received from a remote system - usually from Pandora FMS' console through the execution of alerts on the server.
There are several options to configure the UDP remote server. The default file is pandora_agent.conf
- udp_server: To activate the UDP server, set it on '1'. This is deactivated by default.
- udp_server_port: Port where it listens.
- udp_server_auth_address: Authorized IP address to send orders. Several Addresses can be set separated by commas. If it is configured with 0.0.0.0, UDP Server will accept orders from all addresses.
- process_<name>_start <command>: Command which is going to start a process defined by the user.
- process_<name>_stop <command>: Command which is going to stop the process.
- service_<name> 1: Allows the service <name> to be started or stopped remotely from the UDP server.
Configuration Example:
udp_server 1 udp_server_port 4321 udp_server_auth_address 192.168.1.23 process_firefox_start firefox process_firefox_stop killall firefox service_messenger 1
The server accepts the following commands:
* <START|STOP> SERVICE <name of the service>: Starting or stopping a service. * <START|STOP> PROCESS <name of the process>: Starting or stopping a process. * REFRESH AGENT <name of the agent>: Forces one execution of the agent and refreshes data.
In 5.0 version, Unix agent only implements REFRESH AGENT command.
For example:
STOP SERVICE messenger START PROCESS firefox REFRESH AGENT 007
There is a script on the server at /util/udp_client.pl which is used by the Pandora FMS Server as a command of an alert to start processes or services. It has this syntax:
./udp_client.pl <address> <port> <command>
E.g. to restart an agent:
./udp_client.pl 192.168.50.30 41122 "REFRESH AGENT"
For more information, please go to the Alert Configuration section.
1.6 Modules definition
The local execution modules are defined in the configuration file pandora_agent. conf. Below we explain all the parameters that can be accepted.
The general syntax is the following:
module_begin module_name <Module Name> module_type generic_data module_exec <local command to execute> module_end
There are different kinds of modules,; in this example we have only used the common and mandatory lines for most of them.
1.6.1 Common elements of all modules
Module fields (except module data, description and extended info) are only stored on module creation and will never be updated if the module is already created. |
|
1.6.1.1 module_begin
Defines the beginning of the module (compulsory).
1.6.1.2 module_name <name>
Name of the module (compulsory). This name CANNOT be duplicated.
1.6.1.3 module_type
Type of data the module will return. It is compulsory to choose one of these. The available types are:
- Numerical (generic_data). Simple numerical data, in floating points or wholes.
- Incremental (generic_data_inc). Numeric data equal to the difference between the current value and the previous one divided by the elapsed time in seconds. When this difference is negative, the value is reset, which means that when the difference becomes positive again, the previous value will be taken as long as the increment returns to a positive value.
- Absolute incremental (generic_data_inc_abs). Numeric data equal to the difference between the current value and the previous one, with no division made, so the value is the total difference or increment, and not the increment per second. When this difference is negative, the value is reset, this means that at the time when the difference is again a positive value, the base value used to make this calculation is the last one from which the incremental value is positive.
- Alphanumeric (generic_data_string). Collects alphanumeric text strings.
- Booleans (generic_proc). For values that can only be correct/affirmative (1) or incorrect/negative (0). Useful to check if a computer is alive, or a process/service is running. A negative value (0) has the critical status preassigned, while any higher value is considered correct.
- Asynchronous Alphanumeric (async_string). For asynchronous text strings. Asynchronous monitoring depends on events or changes that may or may not occur, so these types of modules are never in unknown status.
- Asynchronous Boolean (async_proc). Similar to 'generic_proc' but asynchronous.
- Asynchronous Numerical (async_data). Similar to 'generic_data' but asynchronous.
1.6.1.4 module_min <value>
Minimum value that the module must return to be accepted. Otherwise it will be discarded and will not be displayed on the console.
1.6.1.5 module_max <value>
Maximum value that the module must return to be accepted. Otherwise it will be discarded and will not be displayed on the console.
1.6.1.6 module_min_warning <value>
This is the minimum value that will make the module go into 'warning' status.
1.6.1.7 module_max_warning <value>
This is the maximum value that will make the module go into 'warning' status.
1.6.1.8 module_min_critical <value>
This is the minimum value that will make the module go into 'critical' status.
1.6.1.9 module_max_critical <value>
This is the maximum value that will make the module go into 'critical' status.
1.6.1.10 module_disabled <value>
Indicates if the module is enabled ('0') or disabled ('1').
1.6.1.11 module_min_ff_event <value>
Flip flop protection value for false positives. The number of status changes indicated in this value will be necessary for the module to visually modify its status in the web console.
1.6.1.12 (>= 6.0 SP4) module_each_ff <value>
If enabled (1), flip flop thresholds per status will be used (module_min_ff_event_normal, module_min_ff_event_warning and module_min_ff_event_critical). Set to 0 to disable.
1.6.1.13 (>= 6.0 SP4) module_min_ff_event_normal <value>
Flip flop protection value for switching to normal status.
1.6.1.14 (>= 6.0 SP4) module_min_ff_event_warning <value>
Flip flop protection value for switching to warning status.
1.6.1.15 (>= 6.0 SP4) module_min_ff_event_critical <value>
Flip flop protection value for switching to critical status.
1.6.1.16 (>= 6.0 SP4) module_ff_timeout <seconds>
Resets the flip flop threshold counter after the given number of seconds. This implies that the number of status changes determined in module_min_ff_event must occur at an interval module_ff_timeout seconds before the state changes in the console's visual level.
1.6.1.17 module_description <text>
Free text with information about the module.
1.6.1.18 module_interval <factor>
This interval is calculated as a multiplier for the agent interval. If the agent has e.g. an interval 300 (5 minutes) but you want a module which is going to get processed every 15 minutes only; so you should add this line: module_interval 3. This module will be processed every 300sec x 3 = 900sec (15 minutes).
1.6.1.19 module_timeout <secs>
In seconds, maximum time allowed for the execution of the module. If this time is exceeded before the end of its execution, it will be interrupted.
1.6.1.20 module_postprocess <factor>
Numerical value by which the data returned by the module will be multiplied. It is useful for unit conversions.
1.6.1.21 module_save <variable name>
Stores the value returned by the module in a variable with the name indicated in this parameter. This value can be used later in other modules.
For example:
module_begin module_name echo_1 module_type generic_data module_exec echo 41121 module_save ECHO_1 module_end
It will store the value"41121" in the "ECHO_1" variable.
module_begin module_name echo_2 module_type generic_data module_exec echo $ECHO_1 module_end
This second module will show the contents of the variable "$ECHO_1", it being "41121".
In Windows agents the module would have to be formed with %var% instead of $var. Following the example:
module_begin module_name echo_2 module_type generic_data module_exec echo %ECHO_1% module_end
1.6.1.22 module_crontab <minute> <hour> <day> <month> <day of the week>
From version 3.2, it's possible to schedule modules in the order they'll be executed on a specific date. To do this, you're required to define the module_crontab', using a similar format to that of the crontab file: (http://es.wikipedia.org/wiki/Cron_(Unix)#Sintaxis)
module_crontab <minute> <hour> <day> <month> <day of the week>
Being:
- Minute 0-59
- Hour 0-23
- Day of the month 1-31
- Month 1-12
- Day of the week 0-6 (0 is Sunday)
It's also possible to specify intervals using the - character as a divider.
In order for one module to be executed e.g. every Monday between 12 and 15, we could use the following configuration:
module_begin module_name crontab_test module_type generic_data module_exec script.sh module_crontab * 12-15 * * 1 module_end
The module will be executed once during the interval. If we want it to be executed while the interval is on, we could use the module_cron_interval 0 option in the following way:
module_begin module_name crontab_test2 module_type generic_data module_exec script.sh module_crontab * 12-15 * * 1 module_cron_interval 0 module_end
To execute a command every hour, in an hour and 10 minutes:
module_begin module_name crontab_test3 module_type generic_data module_exec script.sh module_crontab 10 * * * * module_cron_interval 0 module_end
1.6.1.23 module_condition <operation> <command>
From version 3.2, it's possible to define commands that will be executed if the module returns some specific values. It's necessary to specify one of the following options:
- > [value]: Executes the command if the module value is higher than the given one.
- < [valor]: Executes the command if the module value is lower than the given one.
- = [valor]: Executes the command if the module value is equal to the given one.
- != [valor]: Executes the command if the module value is different to the given one.
- =~ [regular expression]: Executes the command if the module value coincides with the given regular expression.
- (valor, valor): Executes the command if the module value is ranged between the given values.
Multiple conditions can be specified for a single module. In the following case, the script_1.sh will be executed if the value returned by the module is between 1 and 3, and script_2.sh will be executed if the value of the module is greater than 5.5, so in this case, being 2.5 the value returned in the module_exec line , only the first condition script_1.sh will be executed:
module_begin module_name condition_test module_type generic_data module_exec echo 2.5 module_condition (1, 3) script_1.sh module_condition > 5.5 script_2.sh module_end
Examples of possible real cases:
module_begin module_name MyProcess module_type generic_data module_exec tasklist | grep MyProcess | wc -l module_condition > 2 taskkill /IM MyProcess* /F module_end
module_begin module_name PandoraLogSize module_type generic_data module_exec ls -la "c:\Archivos de programa\pandora_agent\pandora_agent.log" | gawk "{ print $5 }" module_condition > 10000 del "c:\Archivos de programa\pandora_agent\pandora_agent.log" module_end
module_begin module_name Service_Spooler module_type generic_proc module_service Spooler module_condition = 0 net start Spooler module_end
- NOTE: On Windows platforms, it's recommended to use cmd.exe /c to execute the command to ensure it's executed properly. For example:
module_begin module_name condition_test module_type generic_data module_exec echo 5 module_condition (2, 8) cmd.exe /c script.bat module_end
1.6.1.24 module_precondition <operation> <command>
If the precondition is true, the module is going to run. It's necessary to specify one of the following options:
- > [value]: Executes the command if the module value is higher than the given one.
- < [value]: Executes the command if the module value is lower than the given one.
- = [value]: Executes the command if the module value is equal to the given one.
- != [value]: Executes the command if the module value is different to the given one.
- =~ [regular expression]: Executes the command if the module value coincides with the given regular expression.
- (value, value): Executes the command if the module value is ranged between the given values.
In the following example, the module monitoring_variable.bat will only be executed if the result of the execution indicated in the precondition is between 2 and 8. In this case, the execution result indicated in the module_precondition line is 5, a value between 2 and 8, so monitoring_variable.bat will be executed correctly:
module_begin module_name Precondition_test1 module_type generic_data module_precondition (2, 8) echo 5 module_exec monitoring_variable.bat module_end
Like postconditions, it's also possible to use several preconditions. The module is only going to be executed if all preconditions are met:
module_begin module_name Precondition_test2 module_type generic_data module_precondition (2, 8) echo 5 module_precondition < 3 echo 5 module_exec monitoring_variable.bat module_end
- NOTE: On Windows platforms, it's recommended to use cmd.exe /c to execute the command to ensure it's proper execution. For example:
module_begin module_name Precondition_test3 module_type generic_data module_precondition (2, 8) cmd.exe /c script.bat module_exec monitoring_variable.bat module_end
1.6.1.25 (>= 5.x) module_unit <value>
Units shown next to the value obtained by the module.
Example:
module_unit %
1.6.1.26 (>= 5.x) module_group <value>
This is the name of the module group.
Example:
module_group Networking
1.6.1.27 (>= 5.x) module_custom_id <value>
This is a custom identifier for the module.
Example:
module_custom_id host101
1.6.1.28 (>= 5.x) module_str_warning <value>
This is a regular expression to define the 'warning' status in the string types modules.
Example:
module_str_warning .*NOTICE.*
1.6.1.29 (>= 5.x) module_str_critical <value>
This is a regular expression to define the 'critical' status in the string type modules.
Example:
module_str_critical .*CRITICAL.*
1.6.1.30 (>= 5.x) module_warning_instructions <value>
These are the instructions to the operator if the module changes to 'warning' status.
Example:
module_warning_instructions Increase incident priority
1.6.1.31 (>= 5.x) module_critical_instructions <value>
These are the instructions to the operator if the modules changes to 'critical' status.
Example:
module_critical_instructions Call to sys department
1.6.1.32 (>= 5.x) module_unknown_instructions <value>
These are the instructions to the operator if the module changes to 'unknown' status.
Example:
module_unknown_instructions Open incident
1.6.1.33 (>= 5.x) module_tags <value>
These are the tags which will be assigned to the module separated by commas.
Example:
module_tags tag1,tag2,tag3
1.6.1.34 (>= 5.x) module_warning_inverse <value>
Allows activating (1) the inverse interval for the warning threshold.
Example:
module_critical_inverse 0
1.6.1.35 (>= 5.x) module_critical_inverse <value>
Allows activating (1) the inverse interval for the critical threshold.
Example:
module_critical_inverse 1
1.6.1.36 (>= 5.x) module_native_encoding <value>
(Win32 only)
This configuration token only affects executed modules by command line, that is, there is a module_exec in the module configuration.
Windows manages three encodings for its processes: the command line encoding (OEM), the system encoding (ANSI) and UTF-16. Both encodings are agree on basic characters, but they are different on less common characters, like written accent. With this token, the Pandora's agent transforms the output to the encoding specified in the configuration file (pandora_agent.conf).
module_native_encoding has four acceptable values:
- module_native_encoding OEM: to command line encoding
- module_native_encoding ANSI: to system encoding
- module_native_encoding UTFLE: to UTF-16 little-endian
- module_native_encoding UTFBE: to UTF-16 big-endian
If module_native_encoding does not appear, no re-encoding will be done.
1.6.1.37 (>= 5.x) module_quiet <value>
If enabled (1) the module will be in silent mode: it will not generate events or trigger alerts, nor will it store data history.
Example:
module_quiet 1
1.6.1.38 (>= 5.x) module_ff_interval <value>
This is the flip flop execution threshold of the module (in seconds).
Example:
module_ff_interval 2
1.6.1.39 (>= 5.x) module_macro<macro> <value>
Only applicable to local components from the console. It has no utility in the configuration file.
1.6.1.40 (>= 5.1 SP4) module_alert_template <template_name>
This macro assigns to the module the alert template that corresponds to the name introduced as parameter(see Alert templates)
Example:
<module> <name><![CDATA[CPU usage]]></name> <type>generic_data</type> <module_interval>1</module_interval> <min_critical>91</min_critical> <max_critical>100</max_critical> <min_warning>70</min_warning> <max_warning>90</max_warning> <alert_template><![CDATA[Critical condition]]></alert_template> <![CDATA[92]]> </module>
1.6.1.41 module_end
Defines the end of the module (compulsory).
1.6.2 Specific guidelines to obtain information
Furthermore, there are the specific guidelines that could be specified for each module in order to obtain information. Only one kind of them can be used in each module.
1.6.2.1 module_exec <command>
General command execution line. The desired run must be specified to obtain the information in a single line.
If execution returns a return code different from '0', it will be interpreted as "execution error" and the information will be discarded. |
|
For a Windows agent there are more guidelines for obtaining data, which are described below.
1.6.2.2 module_service <service>
Checks if a specific service is being executed on the machine. Remember to use the «" "» characters if the name of the service contains blanks.
module_begin module_name Service_Dhcp module_type generic_proc module_service Dhcp module_description Service DHCP Client module_end
The service is identified with the short name of the service (service name), such as it appears in the Windows services manager.
Asynchronous Mode
Pandora FMS usually executes a test battery (each of it defined by a module) every X seconds (300 seg. = 5 min. by default). If a service is down just after an execution of Pandora, it's going to take 300 additional seconds to find out the service went down. The difference on asynchronous mode is that modules immediatly notify Pandora FMS about the fail or shutdown of this service. This is called asynchronous operation mode. It would be sufficient to add the following command to the guideline to use it:
module_async yes
This feature is not supported on broker agents.
In Windows Home Edition versions, this asynchronous functionality is not supported and, only in those versions, the Pandora agent makes a periodic query to know if the service is running or not. This can be quite resource-intensive so it is recommended to use the synchronous version if a large number of services are being monitored. |
|
Service Watchdog
There is a watchdog mode for the services, so the agent is able to restart them if they stop. In this case, the restarted service doesn't require any parameter, because Windows already knows how to do it. In such cases, the configuration is a lot easier:
module_begin module_name ServiceSched module_type generic_proc module_service Schedule module_description Service Task scheduler module_async yes module_watchdog yes module_end
Unix
In Unix, it works the same as in Windows, the only difference is that for Unix, process and service is the same concept, for example to see if the bash process is active in the system, just run:
module_begin module_name Service_bash module_type generic_proc module_service /bin/bash module_description Process bash running module_end
Watchdog mode and asynchronous detection are not possible in the Unix agent.
1.6.2.3 module_proc <process>
Checks if an specific name of process is working in this machine. If the name of the process has blanks do not use «" " »; please consider that the name of the process should have the .exe extension. The module is going to return the number of processes executed with this name.
This is an example of the monitoring of the process 'cmd.exe':
module_begin module_name CMDProcess module_type generic_proc module_proc cmd.exe module_description Process Command line module_end
UNIX
Under UNIX, this module works just like in Windows. It doesn't support asynchronous and/or watchdog mode.
Asynchronous mode
In a similar way to the services, monitoring processes can be critical in some cases. The Windows agent supports asynchronous checking for the module_proc. module now. In this case, the agent immediately reports it if the process changes its status without waiting for the agent's execution interval to be reached again. In this way, you're able to get informed about the failure of critical processes almost instantly. This is an example of asynchronous monitoring of the processes:
module_begin module_name Notepad module_type generic_proc module_proc notepad.exe module_description Notepad module_async yes module_end
The difference is located in the configuration token 'module_async yes'. This feature is not supported on broker agents.
Processes Watchdog
A Watchdog is a system that allows to act immediately if an agent is down, usually raising the process that went down. The Pandora FMS Windows Agent could act as a watchdog when a process is down.
Since executing a process would require some parameters, there are some additional configuration options for these kind of modules. It is important to keep in mind that the watchdog mode only works if the module type is set to asynchronous. This is an example of configuration of 'module_proc' with 'watchdog' enabled:
module_begin module_name Notepad module_type generic_proc module_proc notepad.exe module_description Notepad module_async yes module_watchdog yes module_start_command c:\windows\notepad.exe module_startdelay 3000 module_retrydelay 2000 module_retries 5 module_end
This is the definition of additional parameters for 'module_proc' with watchdog enabled:
- module_retries: Number of consecutive attempts that the module will try to raise the process before deactivating the watchdog. If the limit is reached, the watchdog mechanism for this module will be deactivated and will never attempt to launch the process again until the agent is restarted. Unlimited by default.
- module_startdelay: Number of milliseconds the module is going to wait before starting the process for the first time.
- module_retrydelay: Number of milliseconds that the module will wait before trying to launch the process in each retry.
- module_user_session: it vontrols in which session you want the process to be launched. If set to 'no', the process will start in the services session and therefore remain in the background (default setting). Otherwise, if set to 'yes', the process will be launched in the user's session and will be visible from the PC desktop.
For versions prior to Windows Vista, the module_user_session token can be configured in a general way by enabling the checkbox "Interactive access with desktop" in the Pandora FMS service properties, as shown in the following screenshot: |
|
It's also necessary to understand that Pandora FMS is executed under the "SYSTEM" account if started as a service. The executed process will do it under that user and with that environment, so that if you want to execute any particular process that requires to be used with a certain user, you will have to include in a script (.bat or similar) the previous processes to initialize the environment, environment variables, etc, and execute that script as a watchdog action.
1.6.2.4 module_cpuproc <process>
(UNIX only)
Returns the CPU usage of a specific process.
module_begin module_name myserver_cpu module_type generic_data module_cpuproc myserver module_description Process Command line module_end
1.6.2.5 module_memproc <process>
(Unix only)
Returns the memory used by a specific process.
module_begin module_name myserver_mem module_type generic_data module_memproc myserver module_description Process Command line module_end
1.6.2.6 module_freedisk <unit_letter:>|<volume>
This module works under UNIX and Windows. It checks for the free space in the disk unit (don't forget «":"» after the unit_letter in Windows) or the UNIX volume e.g. '/var'.
module_begin module_name freedisk module_type generic_data module_freedisk C: module_end
module_begin module_name disk_var module_type generic_data module_freedisk /var module_end
1.6.2.7 module_freepercentdisk <unit_letter:>|<volume>
This module returns the free disk percentage under a Windows unit: (don't forget the ":") or on a Unix system, the volume, like '/var'.
module_begin module_name freepercentdisk module_type generic_data module_freepercentdisk C: module_end
module_begin module_name disk_var module_type generic_data module_freepercentdisk /var module_end
1.6.2.8 module_occupiedpercentdisk <unit_letter:>|<volume>
(Unix only)
This module returns the occupied disk percentage in a UNIX volume e.g. '/var'.
module_begin module_name disk_var module_type generic_data module_occupiedpercentdisk /var module_end
1.6.2.9 module_cpuusage <cpu id>
This works under UNIX and Windows. It returns the CPU usage in a CPU number. If there is only one CPU, please leave it blank or use 'all'. It's also possible to obtain the average use of all CPU in multiprocessor systems in this way:
module_begin module_name SystemCPU module_type generic_data module_cpuusage all module_description Average CPU use in systme module_end
To check the CPU usage in CPU #1:
module_begin module_name SystemCPU_1 module_type generic_data module_cpuusage 1 module_description Average CPU use in system for CPU #1 module_end
1.6.2.10 module_freememory
Supported under Windows and UNIX. It returns the free memory of the whole system:
module_begin module_name FreeMemory module_type generic_data module_freememory module_description Non-used memory on system module_end
1.6.2.11 module_freepercentmemory
Supported under UNIX and Windows. This module returns the free memory percentage on one system:
module_begin module_name freepercentmemory module_type generic_data module_freepercentmemory module_end
1.6.2.12 module_tcpcheck
(Windows only)
This module tries to connect with an IP and a specified port. It returns '1' if successful and '0' if not. It's also recommended to specify a timeout:
module_begin module_name tcpcheck module_type generic_proc module_tcpcheck www.artica.es module_port 80 module_timeout 5 module_end
1.6.2.13 module_regexp
(Windows only)
This module monitors a record file (log) looking for coincidences using regular expressions, ruling out the already existing lines when starting the monitoring. The data returned by the module depend on the module type:
- generic_data_string, async_string: Returns all the lines which fit the regular expression.
- generic_data: Returns the number of lines which fit with the regular expression.
- generic_proc: Returns '1' if there is a coincidence and '0' if not.
- module_noseekeof: With this configuration token active, with a '0' default value in each module execution and independently from any modification of the target file, the module will restart its check process without searching for the file's EOF flag. It will always extract from the XML output all lines that correspond to our search patterns.
module_begin module_name regexp module_type generic_data_string module_regexp C:\WINDOWS\my.log module_pattern ^\[error\].* module_noseekeof 1 module_end
To obtain more information about the syntax of regular expressions in general, please visit [1].
1.6.2.14 module_wmiquery
(Windows only)
The WMI modules allow to locally execute any WMI query without the use of an external tool. It's configured through two parameters:
- module_wmiquery: Used WQL query. As a result, several lines could be obtained which will be placed as several data.
- module_wmicolumn: Name of the column which is going to be used as a data source.
For example, we could obtain a list of the installed services:
module_begin module_name Services module_type generic_data_string module_wmiquery Select Name from Win32_Service module_wmicolumn Name module_end
Or the current CPU load:
module_begin module_name CPU_speed module_type generic_data module_wmiquery SELECT LoadPercentage FROM Win32_Processor module_wmicolumn LoadPercentage module_end
1.6.2.15 module_perfcounter
(Win32 only)
Obtains data from the performance counter (http://msdn.microsoft.com/en-us/library/aa373083(v=vs.85).aspx Performance Counters (Documentación en ingles Performance Counters Documentation) through the PDH interface (the library pdh.dll should be installed in the system. PDH.DLL is a Windows library. If you have not installed it yet, you have to install the Windows performance analysis tool (which is usually installed by default).
module_begin module_name perfcounter module_type generic_data module_perfcounter \Memory\Pages/sec module_end
The Windows performance monitor is a powerful tool which has hundreds of parameters that could be used for monitoring. Each manufacturer also adds their own monitors, so this is a powerful, versatile and easy to use tool to monitor the system parameters and also the devices which run on it.
The syntax of the perfcounter elements depends on the language. In a e.g. German version, Windows is going to have specific identification strings and in an English version, Windows will have other ones. This makes it difficult to use on systems with heterogeneous languages.
To explore the different values which could be used, you can use the the Windows tool "Performance" to see which strings of performance you're able to monitor.
You can see the Windows performance monitor on this snapshot:
On this snapshot you can see how the interface shows things if we want to add a new monitoring element.
We can view several parameters of the Procesador (in Spanish in the original version) which has different sub elements, of which we have selected % of processor time and in several sub elements here. We're interested in total _Total in this case.
Surfing with the SO tool in this way, we could get different elements of the system performance. For this specific example, the module would be:
module_begin module_name Processor_Time module_type generic_data_inc module_perfcounter \Procesador(_Total)\% de tiempo de procesador module_end
By default the raw value of the counter is shown, to get the cooked value add the module_cooked 1 parameter:
module_begin module_name Disk_E/S_Seg module_type generic_data module_cooked 1 module_perfcounter \DiscoFísico(_Total)\E/S divididas por seg. module_end
Most of the returned data that are counters, so you should use 'generic_data_inc' as data type. It's also able to return values in very high data scales (several millions), so you could reduce these values using the module post process with values like '0.000001' or similar.
1.6.2.16 module_inventory
It's implemented as an agent plugin under Linux / Unix
Using predefined WMI consults and queries on the registry. This module obtains information about the different aspects of a machine ... from software to hardware.
The module can get different parameters to mark the kind of information it gets. Here is the parameter list and the kind of information that it gives:
- CPU: Gets information about the system CPUs (processor name, watch frequency and description).
- CDROM: Gets information about the CD-ROM (name, description and unity letter).
- Video: Gets information about video cards (description, RAM and processor).
- HDs: Gets information about the hard disks (model, size and name in the system).
- NICs: Gets information about the network interface controllers(description, MAC address and IP address).
- Patches: Gets information about the installed patches (identifier, description and comments).
- Software: Gets information about MSI packages installed (name and version).
- RAM: Gets information about RAM modules (tag, capacity and name).
- Services: Gets information about the installed services. The short name shown in the first column is the name of the service that Pandora FMS probably uses to monitor services.
Additional Module Parameters:
- module_interval: This module has an additional line to specify the interval in days, where one can obtain the information for the module.
This is an example to use this module:
module_begin module_name Inventory module_interval 7 module_type generic_data_string module_inventory RAM Patches Software Services module_description Inventory module_end
1.6.2.17 module_logevent
(Windows only)
This new module allows information to be obtained from the Windows event log file. It returns the elements which fit to a given pattern, also allowing to filter by source and event type. The module implemented in version 2.0 has been improved, using the Win32 native API now to have access to the events from the file, instead of using the WMI subsystem (much slower). This method is quicker and works on systems with many elements. The new implementation also allows much more field filtering compared to the previous version. The standard format of the module is the following:
module_begin module_name MyEvent module_type async_string module_logevent module_source <logName> module_eventtype <event_type/level> module_eventcode <event_id> module_application <source> module_pattern <text substring to match> module_description module_end
To avoid repeating what has already been shown, we only consider those events which occurred since the last time the agent was executed, as with other modules (e.g. 'regexp').
'module_logevent' accepts the following parameters (all of them case sensitive):
- module_source: Event source (System, Application, Security). This field is compulsory.
- module_eventtype: Event type (failure, information). This is an optional field.
- module_pattern: Pattern to search (substring). It's an optional field.
- module_eventcode: It's a numeric ID of the event, e.g. 5112. It's an optional field.
- module_application: Application source of the event. Be careful not to confuse it with 'module_source' which shows the name, source or log file where the events are looked for.
For showing all events of an error type system we e.g. should define the following module:
module_begin module_name log_events module_type generic_data_string module_description System errors module_logevent module_source System module_eventtype error module_end
To show all events which contain the word 'PandoraAgent':
module_begin module_name log_events_pandora module_type async_string module_description PandoraAgent related events module_logevent module_source System module_pattern PandoraAgent module_end
Another example: Filtering the event showed on the snapshot:
module_begin module_name MyEvent module_type async_string module_source Application module_eventtype Information module_eventcode 6000 module_application Winlogon module_pattern unavailable to handle module_description module_end
It's very important to understand that Pandora FMS is not a system to collect logs. This tool is intended to be used to select critical or important events for monitoring which collects all events without classifying them from a common source (as the 'system' could be one). Doing so will only cause problems in a way that e.g. the database can collapse and the system will work very badly. It's extremely important to understand that the event collection which comes with Pandora should always be used with taking this into account and not to abuse Pandora FMS as a generic event collector.
1.6.2.18 module_plugin
A parameter to define the data which is obtained at the exit of a plugin agent. It's a special case of a module which builds all its XML on its own. It also doesn't require any other delimiter like 'module_begin', 'module_type', etc. It requires this format:
module_plugin plugin_filename parámetro_1 parámetro_2 parámetro_3
In order to configure additional parameters for the plugin, please use the standard syntax:
module_begin module_plugin plugin_filename parameter_1 parameter_2 parameter_3 module_interval 2 module_condition (0, 1) script.sh module_end
Each plugin has its own syntax. We are going to describe the regular expressions plugin which comes with the agent by default.
module_plugin grep_log /var/log/syslog Syslog ssh
In this example, the name of the plugin is 'grep_log'. It's going to search for the regular expression 'ssh' in the file '/var/log/syslog' which will be kept in a module called 'Syslog'.
Another example intended to be solely used on Windows-based systems (and only on versions 3.1 or later):
module_plugin cscript.exe //B "%ProgramFiles%\Pandora_Agent\util\df_percent.vbs"
File collection and plugins
When you use file collections, you need to know where the file collection stores the files. File collections use a "handle" or short name which is generated when you first create the collection. It has to have a name similar to "fc_2". Here are some examples of 'module_plugin' usage using file collections:
UNIX:
module_plugin /etc/pandora/collections/fc_1/always_1.sh
Windows:
module_plugin cscript //B "%ProgramFiles%\pandora_agent\collections\fc_2\df_percent.vbs"
It's very important to know the plugin execution output could return more than one module, because it returns a full XML structure. This is e.g. the plugin output of the '/util/df.vbs' plugin in windows:
<module> <name><![CDATA[C:]]></name> <description><![CDATA[Drive C: free space in MB]]></description> <![CDATA[2361]]> </module> <module> <name><![CDATA[D:]]></name> <description><![CDATA[Drive D: free space in MB]]></description> <![CDATA[32020]]> </module> <module> <name><![CDATA[Z:]]></name> <description><![CDATA[Drive Z: free space in MB]]></description> <![CDATA[10168]]> </module>
1.6.2.19 module_ping <host>
(Only for Windows versions 4.0.1 or newer)
This module pings the preset host and returns '1' if it's up and '0' if not. It's a wrapper for ping.exe.
Is supports the following configuration parameters:
- module_ping_count x: Number of 'ECHO_REQUEST' packets to be sent ('1' by default).
- module_ping_timeout x: Timeout in milliseconds to wait for each reply ('1000' by default).
- module_advanced_options: Advanced options for ping.exe.
Example:
module_begin module_name Ping module_type generic_proc module_ping 192.168.1.1 module_ping_count 2 module_ping_timeout 500 module_end
1.6.2.20 module_snmpget
(From version 4.0.1 onwards, Windows only)
This module performs an SNMP get query and returns the requested value. It's a wrapper for snmpget.exe.
It supports the following configuration parameters:
- module_snmpversion [1,2c,3]: SNMP version (1 by default).
- module_snmp_community <community>: SNMP community (public by default).
- module_snmp_agent <host>: Target SNMP agent.
- module_snmp_oid <oid>: Target OID.
- module_advanced_options: Advanced options for snmpget.exe.
Example:
module_begin module_name SNMP get module_type generic_data module_snmpget module_snmpversion 1 module_snmp_community public module_snmp_agent 192.168.1.1 module_snmp_oid .1.3.6.1.2.1.2.2.1.1.148 module_end
1.7 Examples
Example of a Windows module, checking if 'EventLog' works. Example:
module_begin module_name ServicioReg module_type generic_proc module_service Eventlog module_description Eventlog service availability module_end
An example for a UNIX module would be:
module_begin module_name cpu_user module_type generic_data module_exec vmstat | tail -1 | awk '{ print $14 }' module_min 0 module_max 100 module_description User CPU module_end Tipos de agentes software
1.8 Specific Configuration by Technologies
With Pandora FMS it's possible to monitor any system. This could either be done with an installed Software agent on the system, which collects data straight from the system to be monitored, or by using a 'Satellite Agent' which consists of an agent which is executed in a server and monitors some parameters of systems which have adjacents through SNMP or user-defined commands.
The software agents could be Windows or UNIX agents. The agents could be installed using any of the agents described in the following lines. To use a satellite agent, it's enough to install a software agent and define the configured modules to collect data from an external system through, e.g. the snmpget tool or ping.
1.8.1 UNIX / Linux Agents
UNIX has several command line tools that allow data to be received through commands. The Unix agents are based in this premise. There are two kinds of UNIX agents:
- ShellScript: With a defined shellscript for each kind of SO based on bash, ksh or csh. In the classical UNIX Systems (Solaris, AIX, HPUX), all functionalities are not implemented yet - but under Linux or MAC they are.
- Perl: There is a unique multi-platform agent based on Perl 5.8 that works alike in all Unix systems. You're required to have a Perl 5.8 system or higher installed for proper functioning.
The shellscript agents have been designed to work in even the oldest UNIX versions: HPUX11.0, AIX 4.1, Solaris 6 ... They work, but are feature limited e.g. not having the Tentacle client and having to use the FTP or SSH system to upload the monitoring data to its server.
1.8.1.1 Pandora FMS UNIX Agents Configuration
There is hardly any difference between AIX, Solaris and GNU / Linux. We are going to describe some of their most important parameters and paths.
After starting the installer, the agents main directory or 'home' directory is '/usr/share/pandora_agent/' where the Pandora FMS agent is installed. In the system where this isn't possible for reasons of e.g. a strict system policy, we recommend creating a link to this path from the real installation path, e.g. '/opt/pandora' -> '/usr/share/pandora_agent'.
The other important folders are:
- /var/spool/pandora/data_out: Folder where the collected data from the agents is kept.
- /etc/pandora/pandora_agent.conf: Main agent configuration folder. The definition of where the data is collected is defined by the used command.
- /usr/local/bin/pandora_agent: The current Pandora FMS agent. This file is a shellscript which collects the configuration data in the 'pandora_agent.conf' files and sends the data packages to the Pandora Server. It usually has a link to '/usr/bin/pandora_agent'.
- /usr/local/bin/tentacle_client: The agent which adds the Tentacle client for being able to send the data files to the server. This is a client written in Perl 5.8. It usually has a link to '/usr/bin/tentacle_client'.
- /etc/init.d/pandora_agent_daemon: Script for starting and stopping. This daemon calls up 'pandora_agent' and gives two options (start / stop). On the AIX systems, the daemon's name is /etc/rc.pandora_agent_daemon.
- /var/log/pandora/pandora_agent.log: Text file where the activity of the Pandora FMS agent is kept if the agent is executed in depuration mode.
- /etc/pandora/plugins: Directory which keeps the agent's plugins. It's a link to /usr/share/pandora_agent/plugins.
1.8.1.2 Initial Execution of a UNIX Agent
When you start the Pandora FMS agent, this should copy the data file to the Pandora FMS server through the dispatch system which is specified in the configuration file of /etc/pandora/pandora_agent.conf. It's recommended to configure the dispatch system (Tentacle, SSH, FTP) before that.
To start the agent, execute:
/etc/init.d/pandora_agent_daemon start
For IPSO systems the agent will be launched with a priority of '-10', so it turns into the process with the lowest priority in the system CPU. It will be executed when other processes with a higher priority are waiting in the CPU system queue. The IPSO agent has a special parameter (harmless_mode ) for a special management of the CPU process on systems Checkpoint/NOKIA. This is a very special case.
In BSD systems the highest priority is '+20' and the lowest '-20'.
To stop the agent, just execute:
/etc/init.d/pandora_agent_daemon stop
1.8.1.3 Advanced Configuration for the UNIX Agent
The real power of Pandora FMS is on the agent's capacity to start processing the user defined scripts. This could be used to collect specific data or to make an operation which returns any desired value, because it's the aim of the agent plugin structure. For more information, please check the Annex on creating Agent Plugins.
1.8.1.4 Examples of Implementation for UNIX Agents
Example #1: Calculate the number of displays on the Apache Web server main page (it could degrade the running of huge records):
module_begin module_name WEB_Hits module_type generic_data_inc module_exec cat /var/log/apache/access.log | grep "index" | wc -l module_end
Example #2: Checks if the process of the (named) DNS is working or not:
module_begin module_name DNS_Daemon module_type generic_proc module_exec ps -Af | grep named | grep -v "grep" | wc -l module_end
1.8.1.5 Altering the way UNIX Agents obtain system information
This is valid for UNIX Perl agents only (version 3.2 or higher).
There are some modules which work like "blackboxes". They are performing operations the user doesn't have to know about. These modules are:
- module_procmem
- module_freedisk
- module_freepercentdisk
- module_cpuproc
- module_proc
- module_procmem
- module_cpuusage
- module_freememory
- module_freepercentmemory
Modules like e.g. 'module_cpuusage' return a percentage of the current system CPU usage, but the user doesn't need to use a command. On windows and on UNIX systems, Pandora 'already knows' what to do.
Pandora UNIX Agents have predefined commands to do that. The below mentioned commands are executed in different ways depending on the OS:
linux => 'vmstat 1 2 | tail -1 | awk \'{ print $13 }\, solaris => 'vmstat 1 2 | tail -1 | awk \'{ print $21 }\, hpux => 'vmstat 1 2 | tail -1 | awk \'{ print $16 }\
It could happen that your system is slightly different from the tested system and the command is not valid. You're able to use your own command with a simple 'module_exec' or redefine internal pandora commands to do that. You need to edit some lines of Pandora FMS Unix Agent code for that, but don't worry - it's Perl code and it's very basic editing.
The Pandora agent is usually located in '/usr/bin/pandora_agent'. Please edit with vi or nano (they are common text editors for the console), and search for "Commands to retrieve" text. You should see something like this:
# Commands to retrieve total memory information in kB use constant TOTALMEMORY_CMDS => { linux => 'cat /proc/meminfo | grep MemTotal: | awk \'{ print $2 }\, solaris => 'MEM=`prtconf | grep Memory | awk \'{print $3}\'` bash -c \'echo $(( 1024 * $MEM ))\, hpux => 'swapinfo -t | grep memory | awk \'{print $2}\ };
This is the piece of code which defines how pandora gets information from the system to get the total memory. AIX is not defined because we don't have the information on how to get this information in an AIX system yet.
# Commands to retrieve partition information in kB use constant PART_CMDS => { # total, available, mount point linux => 'df -P | awk \'NR > 1 {print $2, $4, $6}\, solaris => 'df -k | awk \'NR > 1 {print $2, $4, $6}\, hpux => 'df -P | awk \'NR > 1 {print $2, $4, $6}\, aix => 'df -kP | awk \'NR > 1 {print $2, $4, $6}\ };
These are the commands to get disk information in KB (total, free and mount point). To change any of the predefined values to get the information, just edit the command but be careful with it:
- Check that lines end with ";"
- Check that commands are between ' ' symbols.
- Check that any ' symbol you use ends on the \ symbol, e.g.:
df -P | awk 'NR > 1 {print $2, $4, $6}'
Will be
df -P | awk \'NR > 1 {print $2, $4, $6}\'
It's the same used above, so see how it's written in the code.
1.8.2 Pandora FMS Windows Agents
1.8.2.1 Check Windows agent is working
The exit of the Pandora FMS Windows agent can be checked in the file C:\archivos de programa\pandora_agent\pandora_agent.log. It's a plain text file that contains information about the agent's execution flow.
To check if Tentacle or SSH are working well, you can use the command tentacle_client or the parameter '--test-ssh' on the binary. The first command will return an error, because neither the address nor the file to send is specified, but it checks if the Tentacle client tentacle-client is in the system. The second one will force Pandora FMS to connect using SSH internally and copy a file called ssh.test. Remember that you're required to configure SSH properly, to generate the required keys and to import them onto the server if you want to use it.
1.8.2.2 Checking of Pandora FMS Agent service
The Pandora FMS 3.0 version has been carefully checked and "debugged" in order to avoid all kinds of memory leaks, handles of processes, files or TCP/IP ports. It's very stable and has been tested on all Windows platforms where it has to operate. Nevertheless, it could happen that the service crashes a few times on some systems. We have tried to give some solutions to those users which require a restarted system or a supplementary control of the agent for it.
There are two ways of having more control over the agent. The first one is to force the restart of the agent every X days through the Windows internal programmer for tasks through the AT command.
Restart with AT
In English
To schedule a restart on Mondays and Fridays:
at 00:00 /every:Monday,Friday "c:\program files\pandora_agent\scripts\restart_pandora_agent.bat"
In Spanish
For example, to schedule an every day restart:
at 00:00 /every:L,M,Mi,J,V,S,D "c:\archivos de programa\pandora_agent\scripts\restart_pandora_agent.bat"
To see a list of the scheduled tasks, just execute the following command in the command line:
at
This will give you the scheduled tasks.
Automatic control of the service in case of crashes
Windows provides an additional way of controlled restart of the service if this crashes for any reason. This allows you to tell the Windows service to restart automatically in case of a crash. You have to go to the Windows services dashboard and to the Pandora FMS agent and click on 'Properties' for it. On the 'Recovery' slide, you're required to change the default values into this:
This causes an automatic restart if the service crashes - but only once a day. If it happens to crash more than once a day, it won't get restarted again. The reason for this configuration is avoidance of a possible system overload due to a forced execution that downs too much of the other services, which is caused by a problem within the system. Pandora FMS should never be down. In any case, you can adjust these parameters if a Pandora FMS service crash should be controlled by the system and to make sure that you'll always have the agent running this way.
1.8.2.3 Configuration of Pandora FMS Windows Agent
The whole installation is done through the file pandora_agent.conf. This file is a list of pairs of keys and values which have been described before. Here is an example of this file:
# General Parameters # ================== server_ip mypandoraserver.host.com server_path /var/spool/pandora/data_in temporal "c:\windows\temp" interval 300 agent_name myagent_name # Module Definition # ================= # Counting OpenedConnections (please check language string) module_begin module_name OpenNetConnections module_type generic_data module_exec netstat -na | grep ESTAB | wc -l | tr -d " " module_description Conexiones abiertas (interval 2) module_interval 2 module_end # Is Eventlog service running ? module_begin module_name ServicioReg module_type generic_proc module_service Eventlog module_description Servicio Registro de sucesos module_end # Is lsass.exe process alive ? module_begin module_name Proc_lsass module_type generic_proc module_proc lsass.exe module_description LSASS.exe process. module_end # Received packets. # Please notice that "Paquetes recibidos" string must be replaced by # the correct string in your Windows system language. module_begin module_name ReceivedPackets module_type generic_data module_exec netstat -s | grep "Paquetes recibidos " | tr -d " " | cut -f 2 -d "=" | tr -d "\n" module_description Conexiones abiertas (interval 2) module_end # Free space on disk module_begin module_name FreeDiskC module_type generic_data module_freepercentdisk C: module_description Free space on drive C: module_end module_begin module_name FreeMemory module_type generic_data module_freepercentmemory module_description Amount of free memory. module_end
1.8.2.4 Extending the agents functionality with VBS code
Starting with the 3.1 version, Windows agents started to have plugins like the Unix agents, but don't forget they also have the possibility of executing the external scripts, based on VBScript as simple modules. Take a look at the VBS code which obtains the CPU total use of a system:
strComputer = "." Set objWMIService = GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\\" _ & strComputer & "\root\cimv2") Set object1 = objWMIService.Get( _ "Win32_PerfRawData_PerfOS_Processor.Name='_Total'") N1 = object1.PercentProcessorTime D1 = object1.TimeStamp_Sys100NS Wscript.Sleep(1000) set object2 = objWMIService.Get( _ "Win32_PerfRawData_PerfOS_Processor.Name='_Total'") N2 = object2.PercentProcessorTime D2 = object2.TimeStamp_Sys100NS ' CounterType - PERF_100NSEC_TIMER_INV ' Formula - (1- ((N2 - N1) / (D2 - D1))) x 100 PercentProcessorTime = (1 - ((N2 - N1)/(D2-D1)))*100 Wscript.Echo PercentProcessorTime
We keep it in a file called "CPUTotal.vbs" which is located at c:\program files\pandora_agent\util.
Now we're going to create the new module type of 'module_exec' with this content:
cscript.exe /NoLogo c:\program_filespandora_agent\util\CPUTotal.vbs
We already have a new module that returns the CPU total use, obtained through the external script in VB. There are plenty of things that can be obtained through VBScript. Microsoft has an excellent online documentation about VBS that you can check in MSDN: [2].
1.8.2.5 Running the Pandora FMS Agent under a different user than SYSTEM
You can setup the Windows agent to run under a different user. You're required to configure the startup service with a different user and provide this user with special privileges to do that. That user is required to be included in the 'Administrators' group.
In the WMI console, all users from the group 'Administrators' have ALL permissions enabled.
This is an example of a user and it's WMI settings for the ROOT environment. Branches will inherit the root permissions by default:
You can look up some Microsoft links related to this issue on : [3] [4]
1.8.3 Auto-upgrading Software Agents
We can provide a way to 'auto-upgrade' the software agents using that mechanism and a very special tool. It works in the following way:
Pandora_update tool requires Perl's Digest:MD5 module. It is included by default from Perl 5.14, but for earlier versions it has to be manually installed. |
|
1. Agents receive new binaries e.g. in the file collection's incoming directory:
c:\program files\pandora_agent\collections\fc_1\pandoraAgent.exe
2. The agent utilizes a special module to execute the pandora_update tool. This tool receives a single parameter, the FileCollection handle (or short name). In this scenario, it's fc_1. It checks for a file called 'pandoraagent.exe' (or 'pandora_agent' under UNIX), looks at the size and contents of both files (by using a HASH), the running 'pandora_agent' and the binary provided in the file collection. If they are different, 'pandora_update' stops the agent, replaces the binary and restarts the agent again, using the new binary.
3. Furthermore, 'Pandora_update' writes the update event to a small log to be able to recover the next execution and warns the user about the agent's updating process by means of an 'async_string' module.
This means that the used modules could be configured to have a high interval to perform the update process.
UNIX Standard Installation
module_begin module_name Pandora_Update module_type async_string module_interval 20 module_exec nohup /etc/pandora/plugins/pandora_update fc_1 2> /dev/null && tail -1 nohup.out 2> /dev/null module_description Module to check new version of pandora agent and update itself module_end
UNIX Custon Installation
module_begin module_name Pandora_Update module_type async_string module_interval 20 module_exec nohup /var/opt/PandoraFMS/etc/pandora/plugins/pandora_update fc_1 /var/opt/PandoraFMS 2> /dev/null && tail -1 nohup.out 2> /dev/null module_description Module to check new version of pandora agent and update itself module_end
NOTE: The second parameter of the 'pandora_update' command is the installation path of Pandora FMS. This parameter is only required if Pandora FMS is installed in a path different from the default path.
Windows
module_begin module_name Pandora_Update module_type async_string module_interval 20 module_exec pandora_update.exe fc_1 module_description Module to check new version of pandora agent and update itself module_end
NOTE: If it has the agent in a non "standard" path under UNIX, you're required to modify some of the 'pandora_update' utility values, specifically the following lines:
# Setup your particular paths / process settings here # [SETUP BEGIN] 12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC)12:46, 23 November 2010 (UTC) # Location of binaries # UNIX my $running_binary = "/usr/bin/pandora_agent"; my $updated_binary = "/etc/pandora/collections/$fc_path/pandora_agent"; # UNIX style my $start_pandora = "/etc/init.d/pandora_agent_daemon start"; my $stop_pandora = "/etc/init.d/pandora_agent_daemon stop";
Please change the paths to the ones which fit with your system manually.
1.8.4 Process to Auto Upgrade Agents from versions previous to 3.2
The first thing is to get the executables from the Pandora FMS agent and the 'pandora_update' tool ('pandoraAgent.exe' and 'pandora_update.exe' under Windows and 'pandora_agent' and 'pandora_update' under UNIX).
Many of the steps that we are giving here means the following things:
1. You have a way to copy files to the systems which you want to update. This is a feature which the Pandora FMS 3.2 version provides (File Collection) but just now, you want to migrate to the 3.2 version, because this feature is missing there. It's assumed that you have alternative mechanisms.
2. The agent's configuration and remote management is activated and working. This will be useful. It's recommended to create several directories and configure a new module in your Pandora FMS agent configuration.
Windows Platforms
We should copy 'pandora_update' to one directory of the system path or to the directory '/util' of our Pandora (in Windows).
Supposing that we have Pandora FMS installed in:
C:\Archivos de programa\pandora_agent
We have to copy 'pandora_update.exe' in the directory:
C:\Archivos de programa\pandora_agent\util
Then we create two directories:
C:\Archivos de programa\pandora_agent\collections C:\Archivos de programa\pandora_agent\collections\fc_1
And after this, we should copy the new agent's binary to the last directory which we have created:
C:\Archivos de programa\pandora_agent\collections\fc_1\PandoraAgent.exe
We create one module in the agent as the one that follows:
module_begin module_name Pandora_Update module_type async_string module_interval 20 module_exec pandora_update.exe fc_1 module_description Module to check new version of pandora agent and update itself module_end
This special module that uses the 'pandora_update' executable, executes a special tool ('pandora_update') which compares the current executable with the one that already exists in the directory '/collections/xxxx', where 'xxxx' is a parameter that is passed on to the module. This location is the one specified with the file collections. After using the 3.2 version, the distribution of the new *.exe of the agents will be done through file collections and this identifier will be necessary to 'locate' in which file collection our executable is located.
UNIX Platforms
Similar to the Windows platforms, we have to copy the executable of the UNIX agent and the 'pandora_update' feature. If it has a non-standard installation and possesses customized paths, you should have to pay lot of attention to the previous paragraph where it's described which files should be modified.
You have to copy pandora_update into your agent's plugins / folder:
/etc/pandora/plugins/pandora_update
Now create directory 'collection/fc_1' in the base directory of your '/etc/pandora':
/etc/pandora/collections/ /etc/pandora/collections/fc_1
The call to 'pandora_update' will be done on its system paths to the plugins. In this case, the default path is '/etc/pandora/plugins/pandora_update'.
The module for the UNIX case will be the following:
module_begin module_name Pandora_Update module_type async_string module_interval 20 module_exec nohup /etc/pandora/plugins/pandora_update fc_1 2> /dev/null && tail -1 nohup.out 2> /dev/null module_description Module to check new version of pandora agent and update itself module_end
NOTE: It's recommended to check if both 'pandora_update' and 'pandora_agent' have suitable permissions and owners, executing permissions and the same user which owns the 'pandora_agent' executable.
1.9 Pandora FMS Drone Agents
1.9.1 What is a Drone Agent ?
The Pandora FMS Drone Agent is a running mode of Pandora FMS Software Agent. This running mode only works on Windows and Linux machines. It was developed to deal with complicated environments with restricted access to the machines. The Drone Agent has two main features:
- Proxy mode
- Broker mode
Running in this mode, the Drone Agent can report data and utilize all features of the standard Pandora FMS Software Agent.
The picture below shows an architecture of Pandora FMS using Drone Agents:
1.9.1.1 Proxy Mode
Proxy Mode is very useful for networks which have restrictions in their communications. The agent running this mode enabled a Tentacle Proxy Server to allow agents to communicate with the Pandora FMS Server through itself.
The new Tentacle version supports proxy usage (HTTP/Connect mode), so that agents can contact with the server using an intermediate standard proxy directly. You also can use a new tool called 'Tentacle Proxy Server' is used to centralize all communication between Pandora FMS and the agents, allowing the file management and remote configuration for policy based-monitoring. You can see more about the Tentacle Proxy Server here.
You'll get all functionalities of a proxy but managed by Pandora FMS Software Agent with this feature. This mode has two requirements 1. The agent cannot be run by the root. 2. If you want to use the proxy mode with Unix agent then it must be installed with a user without root privileges (the same user will execute the agent in proxy mode later).
All parameters to configure the Tentacle Proxy Server are available trough its agent configuration file:
server_ip
It's the IP address or the name of Pandora FMS server host. Be careful with the enabled Proxy Mode. This parameter cannot take values like 127.0.0.1, locahost, 0.0.0.0 or related.
proxy_mode
Proxy mode status. If the 'proxy_mode' is set to '1', the proxy feature of the drone agent is activated. If the proxy_mode is set to '0', the proxy feature is off. This feature is disabled by default.
proxy_max_connection
Number of max. simultaneous connections of the proxy. 10 connections are allowed by default.
proxy_timeout
Timeout for the proxied server. Default value is '1 second'.
1.9.1.1.1 Usage Examples
I only have one connection to the Pandora FMS Server
This situation is not a problem for the Pandora FMS Drone Agent. To configure the proxy mode, just set 'server_ip' to the Pandora FMS IP and the 'proxy_mode' parameter to '1'. You can configure some parameters like the number of connections and timeout if needed. You'll have the agent and the Tentacle Proxy Server up and running on the machine which can connect with Pandora FMS Server with this configuration.
To configure the other agent, just set the 'server_ip' parameter to the IP address of the Drone Agent with proxy mode enabled. That's all you have to do. The agents are going to use the drone agent to connect to the Pandora FMS Server.
I'm required to setup a double proxied connection
You're able to connect a Drone Agent to another. It's very easy.
To perform the double proxy, just configure the Drone Agent which can connect to Pandora FMS Server to set the 'server_ip' to the Pandora FMS IP address. 'proxy_mode' must be set to '1' and the other parameters if you need.
To configure the second Drone Agent, just set the 'server_ip' to the one of the first Drone Agent and enable the proxy mode by setting 'proxy_mode' to '1'.
With this configuration, an agent connected to the second Drone Agent can send data to Pandora FMS Server through the two proxies.
1.9.1.2 Broker Mode
The Broker Mode is designed to "recreate" different agents (as an entity) from a single software agent installed on a server. Broker agents execute different setups, like if it has different personalities or different agents installed on the same server with different configurations. Each configuration file is independent and can have it's own plugins, inventory modules, etc. It can be remotely managed as any other agent of course. This is perfect to monitor servers / Comm devices nearby and useful when you're unable to reach a router but can install an agent in a nearby host. You can monitor ten routers from a single agent and have eleven agents in your Pandora FMS console (10 routers + 1 host) for example.
It's important to know that the broker_agent token will be ignored in the configuration of an agent which is set like a broker agent.
The main features of "broker mode" are:
- Send local data with another agent name. Useful to monitoring different instances of a software applicationn as independent agents.
- Send data from remote devices / checks executed from a single host and have it under Pandora FMS like they were different independent agents.
1.9.1.2.1 Examples
Send data to server with different agent names, using different configurations
Modify your pandora_agent.conf with following lines:
broker_agent router_1 broker_agent router_2 broker_agent router_3
On the next execution or restart you will have three new files: 'router_1.conf', 'router_2.conf' and 'router_3.conf'. They are an exact copy from origial "pandora_agent.conf" file, except the attribute of 'agent_name' which will be selected from the 'broker_agent' call.
You now have four agents with different configuration files. You can now add different modules in each configuration file, e.g. edit 'router_1.conf' and add:
Sample of remote check
Please add the following line to the remote configuration file 'pandora_agent.conf':
broker_agent server_1
A new file called 'server_1.conf' will be created and we'll edit it for the purpose of adding specific modules for this broker agent:
module_begin module_name Check SSH Status module_type generic_proc module_tcpcheck 192.168.1.1 module_port 22 module_timeout 5 module_end
This configuration can be interesting when making checks against another remote machine. Even if it has an agent installed Pandora, is unattainable by the server.
This feature is available from version 4.0 onward.
1.10 Agent / Module Autocreation from XML File / Learning Mode
Pandora FMS supports the automatic creation of agents and/or modules if you receive the information coming from an XML (data server). This happens automatically, unless you completely disable this behavior by disabling the server autocreate parameter. The 'creation' only happens the first time agent data arrives on the server. That means you can create the information but you cannot update the agent or module information each time you're getting a new XML - with a few exceptions as you can see below.
This behavior can be avoided in specific agents by disabling the learning mode of the agent. By disabling this feature, the agent will not create new modules when the XML arrives with the new module. The information won't update the agent configuration parameters.
Autodisable mode: From version 6.1 onward agents have this third mode available. In terms of creating agents and modules it behaves exactly the same as an agent in learning mode: when the first XML reaches it, the first agent is created and, on each report, if there are new modules they can also be added automatically. Nevertheless, when all modules from an agent that are in autodisable mode are also marked as unknown, the agent is automatically disabled. In any case, if the agent reports again, it gets enabled again on its own.
1.10.1 Loaded Data from the XML in the Creation of an Agent
Stored Data for an agent is the following:
In 4.x version:
- Agent name.
- IP address.
- Agent description.
- Agent's parent.
- Timezone offset.
- Group.
- Operating system.
- Agent interval.
- Agent version
In 5.x version
It's the same as in 4.x version, plus the following:
- Custom fields.
- Custom ID.
- URL address.
In 6.1 version
- Agent mode: (Learning -default-, No-learn, Autodisable).
1.10.2 Data modified in the Agent when receiving XML (Learning Mode enabled)
- Agent's IP address
- Agent's parent (if defined in server setup, for v4.x parents it's always updated)
- OS Version.
- Agent's version.
- Timezone.
- Custom fields.
By enabling the learning mode the new modules which get received through the XML file are going to be created under Pandora FMS.
1.10.3 Data added to the Module on Creation Time
The first time you get data coming from an XML for a module, the read data from the XML and inserted in the system are the following:
In 4.x version
- Name.
- Type.
- Description.
- Max Min value filter.
- Post process.
- Module interval.
- Min / Max Critical.
- Min / Max Warning.
- Disabled module.
In 5.x version
The same as in 4.x plus the following:
- Units.
- Module group.
- Custom ID.
- Str. Warning / Critical.
- Critical instructions.
- Warning instructions.
- Unknown instructions.
- Tags.
- Critical inversion mode.
- Warning inversion mode.
- Quiet mode.
- Min. FF Threshold.
- Alert template (from SP4)
In 6.x version
- Crontab
1.10.4 Loaded Data when Module already exists
If the data server processes an XML containing information for a pre-existent module, part of its information will be overwritten / updated. The description and extended information (see next epigraph) are updated.
Note: GIS data are always updated unless you have the GIS update disabled for that agent (this is configured in agent's GIS setup).
1.11 Extended Module Information
This epigraph is for advanced and development environments. You're able to send custom XML data (using your own application or altering the Pandora agent's source code). This XML file has two 'custom' tags named 'rack_number' and 'severity':
<module> <name><![CDATA[battery_level]]></name> <description><![CDATA[The actually device battery level]]></description> <type><![CDATA[generic_data]]></type> <data><![CDATA[61]]></data> <rack_number>2</rack_number> <severity>MAJOR</severity> </module>
The module is going to be shown like on the picture below.
These fields don't store history values. They're only going to store the last received value from the XML data. |
|