Difference between revisions of "Pandora: Documentation en: Alerts"

From Pandora FMS Wiki
Jump to: navigation, search
(Command Creation for an Alert)
(Event Alerts and Event Correlation)
 
(58 intermediate revisions by 3 users not shown)
Line 5: Line 5:
 
== Introduction ==
 
== Introduction ==
  
An alert is Pandora FMS's reaction to a module's value being 'out of range'. Such a reaction is configurable and results in sending an e-mail or an SMS to the administrator, sends an SNMP trap, records the incident within the system's log, etc. An alert is basically any script-triggered action, configured in the operating system, where the Pandora FMS Server, which processes the module, is executed.  
+
An alert is Pandora FMS's reaction to a module's value being incorrect. Such a reaction is configurable and can result in any action that can be triggered by a script configured in the Operating System where the Pandora FMS server that processes the module is running.  
  
There are several alert types: Simple Alerts, Event Alerts and SNMP Trap Alerts. In this chapter, we're going to talk about the Alert System in general and specially about the first type.
+
There are several alert types: simple alerts, avent alerts and SNMP trap alerts. This chapter discusses the alert system as a whole and particularly the first type.
  
== Introduction to the current Alert System ==
+
== Introduction to the alert system ==
  
In Pandora FMS, alerts work by defining some firing conditions, some actions chosen for that alert, and finally the execution of some commands in the Pandora FMS server, which will be in charge of carrying out the configured actions.
+
In Pandora FMS, alerts work by defining some triggering terms, some actions selected for that alert, and finally the execution of some commands in the Pandora FMS server, which will be in charge of carrying out the configured actions.
  
 
The general alert system associates a single alert for each module, this alert can carry out one or more actions.
 
The general alert system associates a single alert for each module, this alert can carry out one or more actions.
Line 25: Line 25:
 
An alert consists on:
 
An alert consists on:
  
* '''Commands''':They specify ''what will be done''; it will be the execution that the Pandora FMS server will do when firing the alert. This can be writing in a log, sending an email or an SMS, executing a script, etc.
+
* '''Commands''': They specify ''what will be done''. This will be the execution done by Pandora FMS server when triggering an alert. This could be writing in a log, sending an email or an SMS, executing a script, etc.
  
* '''Actions ''': They specify ''how it will be done''; they are the customizations of the command's arguments, they allow to customize the execution as such, passing to the command particular parameters like module name, agent, etc.
+
* '''Actions ''': They specify ''how it will be done''. They are the customizations of the command's arguments, they allow to customize the execution itself, adding to the command particular parameters like module name, agent, etc.
  
 
*''' Templates''': They specify ''when it will be done'', defining the conditions for triggering the action(s). For example: when the module becomes critical.
 
*''' Templates''': They specify ''when it will be done'', defining the conditions for triggering the action(s). For example: when the module becomes critical.
Line 33: Line 33:
 
=== The Alert System's Information Flow ===
 
=== The Alert System's Information Flow ===
  
When you're defining actions and templates, you have some generic fields called 'Field1', 'Field2' and 'Field3' that are used to customize the alert.
+
When defining actions and templates, both have some '''general fields''' called Field1, Field2 and Field3 that are used to customize the alert's triggering.
  
 
These fields are applied according to a precedence order, "transferring" information from template -> action -> command, to finally be used as parameters in the execution of this command.
 
These fields are applied according to a precedence order, "transferring" information from template -> action -> command, to finally be used as parameters in the execution of this command.
Line 49: Line 49:
 
<br>
 
<br>
  
If a template has any content in Field1 , but the action has '''no''' content in its Field1, it inherits the content of Field1 from the template. However, if the action already has its own content (configured previously while creating the action) in its Field1, it will prevail over the one that is transfered from the template. So following the succession Template -> Action -> Command, the information will be transferred from the first to the second and from the second to the third if the next step does not already have any defined information in its fields Field1, Field2, Field3....
+
If a template has any content in Field1, but the action has '''no''' content in its Field1, it inherits the content of Field1 from the template. However, if the action already has its own content (configured previously while creating the action) in its Field1, it will prevail over the one that is transfered from the template. So following the succession Template -> Action -> Command, the information will be transferred from the first one to the second one and from the second one to the third one if the next step does not already have any defined information in its fields Field1, Field2, Field3...
  
The following diagram shows this transfer of parameters from the template to the command:
+
The following diagram shows this parameter transfer from the template to the command:
  
 
<br>
 
<br>
Line 66: Line 66:
 
<br>
 
<br>
  
We can e.g. create a template that fires an alert and sends an email, containing the following fields:
+
For example, this is a template that triggers an alert and sends an email, containing the following fields:
  
 
* '''Template''':
 
* '''Template''':
Line 78: Line 78:
 
** Field 3:<left blank>
 
** Field 3:<left blank>
  
The values which are going to be passed to the command are:
+
The values transferred to the command are:
  
 
* '''Command''':
 
* '''Command''':
Line 86: Line 86:
  
  
For Field2 and Field3, the values defined in the template are retained, but for Field1, it will use the value defined in the action.
+
Field2 and Field3 keep the values defined in the template, but Field1, uses the value defined in the action.
  
 
== The Alert Command  ==
 
== The Alert Command  ==
 
===Introduction===
 
===Introduction===
Pandora FMS's reaction to a value like 'out of range' can consist of the following types: A record in a system log, the sending of an e-mail or SMS or the execution of any processable script which is hosted on it.
+
Pandora FMS's acctions in face of alert situations at the end mean server executions, in the form of commands.
  
 
<center>
 
<center>
Line 96: Line 96:
 
</center>
 
</center>
  
=== Command Creation for an Alert ===
+
=== Command creation for an alert ===
  
 
The form will request some descriptive information about the command:
 
The form will request some descriptive information about the command:
Line 104: Line 104:
 
</center>
 
</center>
  
Next, the following fields are introduced:
+
Next, the following fields are further explained:
  
 
'''Name:'''
 
'''Name:'''
The command's name. It's important to be descriptive but short, e.g. 'Log' or 'Communications'.
+
The command's name. It must be descriptive but short.
  
 
'''Command:'''
 
'''Command:'''
The command to be executed when the alert is fired. Macros can be used to replace the parameters configured in the alert declaration. The macros that can be used are detailed below in a specific section.
+
The command to be executed when the alert is triggered. Macros can be used to replace the parameters configured in alert declaration. The macros that can be used are detailed below in a specific section.
  
When creating the commands for alerts it is necessary to take into account that these commands are executed by Pandora FMS server. The alerts are also executed with the privileges of the user that executes the Pandora FMS server.  
+
When creating the commands for alerts, it is necessary to take into account that these commands are executed by Pandora FMS server. The alerts are also executed with the privileges of the user that executes the Pandora FMS server.  
  
When defining a command it is convenient to test, from the command line, that the execution of the command is successful and produces the desired result (sending an e-mail, generating an entry in a log file, etc.).
+
When defining a command, it is convenient to test, from the command line, that the execution of the command is successful and produces the desired result (sending an e-mail, generating an entry in a log file, etc.).
  
  
 
'''Group'''
 
'''Group'''
  
Command group. This will determine which alerts the command can be associated with.
+
Command group. This will determine which alerts the command can be associated to.
  
  
 
'''Description'''
 
'''Description'''
  
A thorough description of the alert command for information purposes.
+
Long description of the alert command just for further information.  
  
  
 
'''Description of the fields and possible values'''
 
'''Description of the fields and possible values'''
  
For each field:
+
For each field it is possible to configure:
  
* Description: It would be the tab near the text box in the configuration form of the command action.  
+
* Description: The label next to the text box in the configuration form of the command action.  
  
 
* Possible values: A collection of the possible values for that field.  
 
* Possible values: A collection of the possible values for that field.  
  
If the field is configured, will be a selection combo instead of a text box. The combo needs a tag (the visible value) for each value (the sent value).  
+
If the field is configured (it is not empty), it will be a selection combo instead of a text box. The combo needs a tag (the visible option) for each possible value and a value (the sent option).  
  
 
This is the supported syntax:  
 
This is the supported syntax:  
Line 162: Line 162:
 
<br>
 
<br>
  
{{tip|From the 6.0 version, it will be possible to show a HTML editor in a command field in the creation or edition of an alert action if that command field has as value the special token ''_html_editor_''}}
+
{{tip|From 6.0 version on, it will be possible to show an HTML editor in a command field in the creation or edition of an alert action if that command field has as value the special token ''_html_editor_''}}
  
* Hide: This box must be checked when the field value is preferred to be hidden or blurred. This option will be used in case the field contains a password.
+
* Hide: This box must be checked when the field value would rather be hidden or blurred. This option will be used in case the field contains a password.
  
Once it's created, please click on the 'Create' button.
+
Once it created, click on the 'Create' button.
  
 
==== Command macros ====
 
==== Command macros ====
Line 174: Line 174:
  
 
* '''_address_:''' Address of the agent that triggered the alert.
 
* '''_address_:''' Address of the agent that triggered the alert.
* '''_address_n_ :''' The address of the agent that corresponds to the position indicated in "n" e.g: address_1_ , address_2__
+
* '''_address_n_ :''' The address of the agent that corresponds to the position indicated in "n". E.g: address_1_ , address_2__
* '''_agent_:''' Alias of the agent that triggered the alert. If there is no alias assigned, the name of the agent will be used instead.
+
* '''_agent_:''' Alias of the agent that triggered the alert. If there is no alias assigned, the name of the agent will be used instead.
* '''_agentalias_:''' Alias of the agent that triggered the alert.
+
* '''_agentalias_:''' Alias of the agent that triggered the alert.
* '''_agentcustomfield_n_:''' Agent custom field number n (eg. _agentcustomfield_9_).
+
* '''_agentcustomfield_n_:''' Agent custom field number n (e.g. _agentcustomfield_9_).
* '''_agentcustomid_:''' Agent custom ID.
+
* '''_agentcustomid_:''' Agent custom ID.
* '''_agentdescription_:''' Description of the agent that triggered the alert.
+
* '''_agentdescription_:''' Description of the agent that triggered the alert.
* '''_agentgroup_ :''' Agent group name.
+
* '''_agentgroup_ :''' Agent group name.
* '''_agentname_:''' Name of the agent that triggered the alert.
+
* '''_agentname_:''' Name of the agent that triggered the alert.
* '''_agentos_:''' Agent's operative system.
+
* '''_agentos_:''' Agent's Operative System.
* '''_agentstatus_ :''' Current status of the agent.
+
* '''_agentstatus_ :''' Current agent status.
 
* '''_alert_critical_instructions_:'''  Instructions for CRITICAL status contained in the module.
 
* '''_alert_critical_instructions_:'''  Instructions for CRITICAL status contained in the module.
* '''_alert_description_:''' Alert description.
+
* '''_alert_description_:''' Alert description.
* '''_alert_name_:''' Alert name.
+
* '''_alert_name_:''' Alert name.
* '''_alert_priority_:''' Alert’s numeric priority.
+
* '''_alert_priority_:''' Alert’s numeric priority.
* '''_alert_text_severity_:''' Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).
+
* '''_alert_text_severity_:''' Text alert priority level (Maintenance, Informational, Normal Minor, Major, Critical).
* '''_alert_threshold_:''' Alert threshold.
+
* '''_alert_threshold_:''' Alert threshold.
* '''_alert_times_fired_:''' Number of times the alert has been triggered.
+
* '''_alert_times_fired_:''' Number of times the alert has been triggered.
* '''_alert_unknown_instructions_:''' Instructions for UNKNOWN status contained in the module.
+
* '''_alert_unknown_instructions_:''' Instructions for UNKNOWN status contained in the module.
* '''_alert_warning_instructions_:''' Instructions for WARNING status contained in the module.
+
* '''_alert_warning_instructions_:''' Instructions for WARNING status contained in the module.
* '''_all_address_ :''' All address of the agent that fired the alert.
+
* '''_all_address_ :''' All address of the agent that triggered the alert.
* '''_data_:''' Module data that caused the alert to fire.
+
* '''_data_:''' Module data that caused the alert to be triggered.
 
* '''_email_tag_:'''  Emails associated to the module’s tags.
 
* '''_email_tag_:'''  Emails associated to the module’s tags.
* '''_event_cfX_:'''  (Only event alerts) Key of the event custom field that fired the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
+
* '''_event_cfX_:'''  (Only event alerts) Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
* '''_event_description_:'''  (Only event alerts) The textual description of the Thor event.
+
* '''_event_description_:'''  (Only event alerts) Text event description.
 
* '''_event_extra_id_:'''  (Only event alerts) Extra id.
 
* '''_event_extra_id_:'''  (Only event alerts) Extra id.
 
* '''_event_id_:'''  (Only event alerts) ID of the event that triggered the alert.
 
* '''_event_id_:'''  (Only event alerts) ID of the event that triggered the alert.
 
* '''_event_text_severity_:'''  (Only event alerts) Event text severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
 
* '''_event_text_severity_:'''  (Only event alerts) Event text severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
* '''_eventTimestamp_:'''  Timestamp in which the event was created.
+
* '''_eventTimestamp_:'''  Timestamp where the event was created.
* '''_fieldX_:'''  User defined field X.
+
* '''_fieldX_:'''  User defined field C.
* '''_groupcontact_:''' Group contact information. Configured when the group is created.
+
* '''_groupcontact_:''' Group contact information. Configured when the group is created.
* '''_groupcustomid_:''' Group custom ID.
+
* '''_groupcustomid_:''' Group custom ID.
* '''_groupother_:''' Other information about the group. Configured when the group is created.
+
* '''_groupother_:''' Other information about the group. Configured when the group is created.
* '''_homeurl_ :''' It is a link of the public URL this must be configured in the general options of the setup.
+
* '''_homeurl_ :''' It is a link of the public URL that must be configured in setup general options.
* '''_id_agent_:''' Agent’s ID, useful for building a direct URL that redirects to a Thor console webpage.
+
* '''_id_agent_:''' Agent’s ID, useful for building a direct URL to access Pandora FMS console webpage.
* '''_id_alert_:''' Alert’s numeric ID (unique), used to correlate the alert with third party software.
+
* '''_id_alert_:''' Alert’s ID, used to correlate the alert with third party software.
* '''_id_group_ :''' Agent group ID.
+
* '''_id_group_ :''' Agent group ID.
* '''_id_module_:''' Module ID.
+
* '''_id_module_:''' Module ID.
* '''_interval_:''' Module’s execution interval.
+
* '''_interval_:''' Module’s execution interval.
* '''_module_:''' Module name.
+
* '''_module_:''' Module name.
* '''_modulecustomid_:''' Module custom ID.
+
* '''_modulecustomid_:''' Module custom ID.
* '''_moduledata_X_:''' Last data of module X (module name, cannot have white spaces).
+
* '''_moduledata_X_:''' By using this macro ("X" is the module name) it is possible to retrieve that module's last data and if t is numeric, it is returned under the decimal format specified in the console's setup and with its unit (if it has it). It would be useful, for instance, for sending an email when an alert is triggered at the same time it sends additiona information about other modules from the same agent (which might be quite relevant).
* '''_moduledescription_:''' Description of the module that triggered the alert.
+
* '''_moduledescription_:''' Module description.
* '''_modulegraph_nh_:'''  (Only for alerts that use the command eMail) Returns an image encoded in base64 of a module’s graph with a period of n hours (eg. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done on the server's configuration file.
+
* '''_modulegraph_nh_:'''  (Only for alerts that use the command eMail) It returns an image encoded in base64 of a module’s graph with a period of n hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done on the server's configuration file.
* '''_modulegraphth_nh_:'''  (Only for alerts that use the command eMail) Same operation as the previous macro only with the critical and warning thresholds of the module provided they are defined.
+
* '''_modulegraphth_nh_:'''  (Only for alerts that use the command eMail) Same operation as the previous macro, only with the critical and warning thresholds of the module, provided they are defined.
* '''_modulegroup_:''' Module’s group name.
+
* '''_modulegroup_:''' Module’s group name.
* '''_modulestatus_:''' Module status.
+
* '''_modulestatus_:''' Module status.
* '''_moduletags_:''' URLs associated to the module tags.
+
* '''_moduletags_:''' URLs associated to the module tags.
* '''_name_tag_:''' Names of the tags related to the module.
+
* '''_name_tag_:''' Names of the tags related to the module.
* '''_phone_tag_:''' Phone numbers associated to the module tags.
+
* '''_phone_tag_:''' Phone numbers associated to the module tags.
* '''_plugin_parameters_:''' Module plugin parameters.
+
* '''_plugin_parameters_:''' Module plugin parameters.
* '''_policy_:''' Name of the policy that the module belongs to (if applies).
+
* '''_policy_:''' Name of the policy that the module belongs to (if it applies).
* '''_prevdata_:''' Module previous data before the alert has been triggered.
+
* '''_prevdata_:''' Module previous data before the alert was triggered.
* '''_rca_:''' Root cause analysis chain (only for services).
+
* '''_rca_:''' Root cause analysis chain (only for services).
* '''_server_ip_:''' Ip of server assigned to agent.
+
* '''_secondarygroups_:''' It displays the agent's groups.  
* '''_server_name_:''' Name of server assigned to agent.
+
* '''_server_ip_:''' Ip of server assigned to agent.
* '''_target_ip_:''' IP address for the module’s target.
+
* '''_server_name_:''' Name of server assigned to agent.
* '''_target_port_:''' Port number for the module’s target.
+
* '''_target_ip_:''' IP address for the module’s target.
* '''_timestamp_:''' Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).
+
* '''_target_port_:''' Port number for the module’s target.
* '''_timezone_:''' Timezone that is represented on _timestamp_.
+
* '''_timestamp_:''' Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).
 +
* '''_timezone_:''' Timezone represented on _timestamp_.
  
 
=== Editing an Alert Command ===
 
=== Editing an Alert Command ===
Line 242: Line 243:
 
</center>
 
</center>
  
To edit an alert command, please click on the command's name.
+
To edit an alert command, click on the command's name.
  
 
<center>
 
<center>
Line 248: Line 249:
 
</center>
 
</center>
  
Once the chosen alert has been modified, please click on the 'Update' button.
+
Once the chosen alert has been modified, click on the 'Update' button.
  
  
{{warning|The alerts named '''eMail''', '''Internal Audit''' and '''Pandora FMS Event''' cannot be modified.}}
+
{{warning|The commands named '''eMail''', '''Internal Audit''' and '''Pandora FMS Event''' cannot be modified.}}
 
 
  
 
=== Operations of an alert command ===
 
=== Operations of an alert command ===
Line 265: Line 265:
  
  
The alerts ”eMail”, “Internal Audit” and “Monitoring Event” can't be deleted or copied.
+
The alerts ”eMail”, “Internal Audit” and “Monitoring Event” cannot be deleted nor copied.
  
 
=== Predefined Commands ===
 
=== Predefined Commands ===
Line 273: Line 273:
 
'''eMail'''
 
'''eMail'''
  
Sends an email from the Pandora FMS Server and uses the Perl 'sendmail' command to do so. Pandora FMS utilizes the system-specific tools to conduct almost all alerts. In this case, it's going to be necessary to check whether or not the 'libmail-sendmail-perl' (an 'xprobe2' package) is already installed on your system.
+
It sends an email from the Pandora FMS Server and uses the Perl 'sendmail' command to do so. Pandora FMS uses the system-specific tools to execute almost all of the alerts. In this case, it will be necessary to check whether the 'libmail-sendmail-perl' (an 'xprobe2' package) is already installed on your system or not.
  
This action sends the emails in HTML, which allows the creation of more visually attractive templates. It should be taken into consideration that the receiver of the email should have access to the resources used in the template (images, fonts, etc.).
+
Emails are sent in HTML, which allows creating more visually attractive templates. Notice that the receiver of the email should have access to the resources used in the template such as images.
  
 
'''Internal Audit'''
 
'''Internal Audit'''
  
This generates a small entry within the internal Auditing System of Pandora FMS. It's kept in the Pandora FMS Database and could be reviewed by the console's event viewer.
+
This generates a small entry within the internal Auditing System of Pandora FMS. It is kept in the Pandora FMS database and it can be reviewed by the console's event viewer.
  
 
'''Pandora FMS Event'''
 
'''Pandora FMS Event'''
  
This creates a special event within the Pandora FMS Event Manager.
+
This creates a special event within Pandora FMS Event Manager.
  
 
'''Pandora FMS Alertlog'''
 
'''Pandora FMS Alertlog'''
Line 291: Line 291:
 
'''SNMP Trap'''
 
'''SNMP Trap'''
  
It sends an SNMP trap with the arguments being used.
+
It sends a parametrized SNMP trap with the arguments being used.
  
 
'''Syslog'''
 
'''Syslog'''
It sends an alert to the system registry and uses the system command named 'logger' to do so.
+
It sends an alert to the system registry and uses the system command named "logger" to do so.
  
 
'''Sound Alert'''
 
'''Sound Alert'''
Line 302: Line 302:
 
'''Jabber Alert'''
 
'''Jabber Alert'''
  
Sends a jabber alert to a chat room on a predefined server (please configure the file named .sendxmpprc first). It uses field3 for the text message, field1 for the user's alias, and field2 for the chat-room's name.
+
It sends a jabber alert to a chat room on a predefined server (configure the file named .sendxmpprc first). It uses field3 for the text message, field1 for the user's alias, and field2 for the chat-room's name.
  
 
'''SMS Text'''
 
'''SMS Text'''
  
Sends an SMS to a specific cellphone. You're required to define an alert and a gateway for sending configured and accessible SMS from Pandora FMS before being able to do so. It's also possible to install one using 'Gnokii' to send SMS directly by using a Nokia telephone with an USB wire. Further information on the detailed procedure is going to be described below.
+
It sends an SMS to a specific cellphone. Define an alert and a gateway for sending configured and accessible SMS from Pandora FMS before being able to do so. It is also possible to install one using 'Gnokii' to send SMS directly by using a Nokia phone with an USB connection. Further information on the detailed procedure is provided below.
  
 
'''Validate Event'''
 
'''Validate Event'''
  
It validates all events in relation to a module. The agent's and module's name will be given.
+
It validates all events regarding a module. The agent's and module's name will be given.
  
 
=== Examples of Commands ===
 
=== Examples of Commands ===
Line 316: Line 316:
 
==== Sending alerts with Jabber ====
 
==== Sending alerts with Jabber ====
  
It's very easy to set up Pandora FMS to send alerts by using a Jabber Server. Jabber can be utilized as a system to get real time alerts as well as a history log, allowing a group of people to receive those alerts simultaneously.
+
It is very easy to set up Pandora FMS to send alerts by using a Jabber Server. Jabber can be used as a system to get real time alerts as well as a history log, allowing a group of people to receive those alerts simultaneously.
  
 
===== Installing Jabber Services =====
 
===== Installing Jabber Services =====
Line 326: Line 326:
 
# Login to that account.
 
# Login to that account.
 
   
 
   
Procedure for the Pandora FMS Server:
+
Procedure for Pandora FMS Server:
 
   
 
   
# Please install the package named 'sendxmpp'. It's a dependency for the Pandora FMS Server in order to send messages to Jabber services.
+
# Install the package named 'sendxmpp'. This tool enables sending Jabber messages.
# Create a file named '.sendxmpprc' within your '/home' folder.
+
# Create a file named '.sendxmpprc' within the '/home' folder.
 
# Edit that file and insert the following text:
 
# Edit that file and insert the following text:
 
   [email protected] password
 
   [email protected] password
# Please change the file permissions for '.sendxmpprc':
+
# Grant permissions to the folder:
 
   chmod 0600 .sendxmpprc
 
   chmod 0600 .sendxmpprc
  
By the example below, you're now able to send private messages using the command line.
+
Private messages can be sent using the command line, for instance:
  
 
   $ echo "Hello" | sendxmpp -s pandora [email protected]  
 
   $ echo "Hello" | sendxmpp -s pandora [email protected]  
  
To register the alert within the Pandora FMS Web Console and to add a new command and configure its variables, you're required to do the following:
+
To register the alert within the Pandora FMS Web Console and to add a new command and configure its variables, do the following:
  
 
* Field_1: The Jabber address.
 
* Field_1: The Jabber address.
* Field_2: The text you intend to send.
+
* Field_2: The text to be sent.
  
The alert is going to be defined as follows:
+
The alert is defined as follows:
  
 
   echo _field2_ | sendxmpp -s pandora _field1_
 
   echo _field2_ | sendxmpp -s pandora _field1_
  
===== Additional Examples of Jabber Usage =====
+
===== Additional examples of Jabber usage =====
  
To send a message to a chat room, please enter the following command:
+
Send this to a chat room:
  
 
   $ echo "Dinner Time" | sendxmpp -r TheCook --chatroom [email protected]
 
   $ echo "Dinner Time" | sendxmpp -r TheCook --chatroom [email protected]
  
To send the log entries to a Jabber destination in real-time, please enter the following command:
+
Send the log entries to a Jabber destination:
 
    
 
    
 
   $ tail -f /var/log/syslog | sendxmpp -i [email protected]
 
   $ tail -f /var/log/syslog | sendxmpp -i [email protected]
  
  
NOTE:|Be careful not to flood public Jabber Servers by your messages or you're very likely to get banned by them.
+
NOTE:|Be careful not to overload public Jabber servers or they will cut off access.
  
 
==== Sending Emails by the Expect Script ====
 
==== Sending Emails by the Expect Script ====
  
Sometimes it's necessary to use an authenticated SMTP to send emails. It's a probably easier and more versatile method to use a simple 'expect' script instead of configuring 'sendmail' to use an authenticated SMTP. This is an example using 'expect' to send emails by using an Exchange Server:
+
Sometimes, it is necessary to use an authenticated SMTP to send emails. It is probably an easier and more versatile method using a simple EXPECT script instead of configuring 'sendmail' to use an authenticated SMTP. This is an example using EXPECT to send emails by using an Exchange Server:
  
First, you're required to create a file called '/etc/snmp' containing the following script:
+
A file called '/etc/snmp' containing the following script is created:
  
 
<pre>
 
<pre>
Line 397: Line 397:
 
</pre>
 
</pre>
  
To edit the file permissions to allow the execution, please enter the following command:
+
File permissions are changed to allow execution:
  
 
<pre>
 
<pre>
Line 403: Line 403:
 
</pre>
 
</pre>
  
Before trying to use it, please make sure that /usr/bin/expect is working appropriately.
+
Before trying to use it, make sure that /usr/bin/expect works properly.
  
Before being able to utilize this in conjunction with Pandora FMS, you're also required to create a new command (or to modify an already existing email alert-sending command) and to specify the following fields within the Pandora FMS Alert Command definition in the field named 'Command'. It's going to write the following:
+
To use this toghether with Pandora FMS, create a new command (or modify the already existing email alert-sending command) and specify the following fields within the Pandora FMS Alert Command definition in the field named 'Command'. Write the following:
  
 
<pre>
 
<pre>
Line 411: Line 411:
 
</pre>
 
</pre>
  
The script can be located in any place on the system. Just keep in mind that the alert script is launched by the server which is going to process the data. If the payload is consisted of network data, the '''Network Server''' is going to process it. If it's an XML data file sent by an agent, it's the '''Data Server''' which is going to launch it.
+
The script can be located anywhere on the system. Just keep in mind that the alert script is launched by the server that processes the data. If it is a network data, it will be the network server, if it is a data coming from an agent, through an XML file, then the dataserver will be the one to launch it.
  
If you have several physical servers, it's possible that you're required to copy the same script to the same location, along with the same permissions and the same owner on all the systems you have a Pandora FMS Server running and want to execute this alert on. Please keep in mind that the Pandora FMS Network Servers are required to be executed as 'root' (e.g. for being able to execute ICMP latency tests). However, the Data Server isn't required to be executed as 'root' - it may be started by any user without special privileges.
+
If you have several physical servers, it is possible that you need to copy the same script to the same location, along with the same permissions and the same owner on all the systems where you have a Pandora FMS Server running and want to execute this alert on. Remember that Pandora FMS Network Servers must be executed as 'root' (e.g. for being able to execute ICMP latency tests). However, dataservers can be started by any user without special privileges.
  
The alert is going to be executed by the user who's executing the Pandora FMS Server process.
+
The alert will be executed by the user who is executing the Pandora FMS Server process.
  
==== Sending SMS by 'Gnokii' ====
+
==== Sending SMS through Gnokii ====
  
There's also the option of using 'Gnokii'. Do do so, it's required to use a Nokia cellphone or one compatible with Gnokii (please feel free to check the compatible hardware list on the Gnokii Project Page. You're also required to have a USB data cable connected the cellphone and a connection to the Pandora FMS Server you intend to send the SMS Alerts from.
+
To use Gnokii, use a Nokia cellphone or one compatible with Gnokii (check the compatible hardware list on the Gnokii Project Page). You will also need a USB data cable connected the cellphone and a connection to the Pandora FMS Server you intend to send the SMS Alerts from.
  
 
Gnokii supports a large variety of Nokia cellphones and some models by other manufacturers.
 
Gnokii supports a large variety of Nokia cellphones and some models by other manufacturers.
  
By using Gnokii, you may also send SMS directly from the command line. This is a very easy and quick way to send any SMS directly from a Pandora FMS Server, thereby avoiding the use of gateways sending SMS by using the internet (which is not very useful if the network is down) or GSM hardware solutions for sending messages which are very expensive in some countries.
+
By using Gnokii, you may also send SMS directly from the command line. This is a very easy and quick way to send any SMS directly from a Pandora FMS Server, thereby avoiding the use of gateways sending SMS by using the Internet (which is not very useful if the network is down) or GSM hardware solutions for sending messages which are very expensive in some countries.
  
An alternative to the use of Gnokii is the Gammu Project.
+
An alternative is the Gammu Project.
  
 
This is an example of sending an SMS from the command line using Gnokii:
 
This is an example of sending an SMS from the command line using Gnokii:
Line 433: Line 433:
 
</pre>
 
</pre>
  
Gnokii is unable to send an SMS with  images attached, but it's able to send a URL via HTTP or WAP. If a message is received, it could look like the one you're going to see if you enter the command shown below:
+
Gnokii is unable to send an SMS with  images attached, but it can send a URL via HTTP or WAP for it to be displayed when receiving a message, for example:
  
 
<pre>
 
<pre>
Line 439: Line 439:
 
</pre>
 
</pre>
  
It's also able to send '''one''' image's URL or one that leads to a 'light version' of the console in order to provide console access for the cellphone, facilitating the reception and analysis of emergency data for the user.
+
It can also send an image's URL or one that leads to a 'light version' of the console in order to provide console access and data analysis to the user.
  
The Artica Development Team has tested it. They've sent SMS alerts from a Nokia 6030 cellphone in a moment an internet connection wasn't available. The Nokia 6030 cellphone uses the module's 6510 definition within the 'gnokiirc' file. It takes about four seconds to send an SMS.
+
The development team has tested sending SMS alerts from a Nokia 6030 cellphone when Internet connection was not available. The Nokia 6030 cellphone uses the module's 6510 definition within the 'gnokiirc' file. It takes about four seconds to send an SMS.
  
It's also possible to install a much more versatile sending gateway using Gammu instead of Gnokii.
+
It is possible to install a much more powerful sending gateway using Gammu.
  
 
==== Executing a Remote Command on another System (UNIX) ====
 
==== Executing a Remote Command on another System (UNIX) ====
  
Sometimes, it's pretty interesting to execute the command on another system; for that, the ssh command is used to do so. The system in which the command is going to be executed should be a UNIX system. It's also required to have the SSH daemon installed, started and accessible.  
+
Sometimes, it is pretty interesting to execute the command on another system by means of the ssh command. The system where the command is executed should be a UNIX system and have the SSH daemon installed, started and accessible.  
  
To avoid storing the access password on the machine which executes the command within the Pandora Console, it's recommended to copy the server's public key to where you intend to execute the remote command on the Pandora FMS Server.
+
To avoid storing the access password on the machine that executes the command within the Pandora FMS Console, copy the server's public key to where you intend to execute the remote command on the Pandora FMS Server.
  
Once you have done this, please execute the following command:
+
Once done, execute the following command:
  
 
<pre>
 
<pre>
Line 461: Line 461:
 
== Alert Actions ==
 
== Alert Actions ==
 
===Introduction===
 
===Introduction===
Actions are the components of alerts in which a command are related to the generic variables Field 1, Field 2,..., Field 10.  
+
Actions are the components of alerts where a command is related to the generic variables Field 1, Field 2,..., Field 10.  
  
Actions allow us to define ''how'' we will launch the command.
+
Actions allow defining ''how'' to launch the command.
  
 
=== Creating an Action ===
 
=== Creating an Action ===
Line 473: Line 473:
 
</center>
 
</center>
  
Once you have clicked on 'Create', you're going to see the following window:
+
Once you have clicked on 'Create', this window will appear:
  
 
<center>
 
<center>
Line 479: Line 479:
 
</center>
 
</center>
  
An explanation of the fields you're going to see is shown below:
+
Here is an explanation about the fields to be filled out:
  
*'''Name''': The name of the action.
+
*'''Name''': The action name.
 
*'''Group''': The action group. If the associated command has a group other than ''All'', only the group associated with the command or the ''All'' group can be set as the action group.
 
*'''Group''': The action group. If the associated command has a group other than ''All'', only the group associated with the command or the ''All'' group can be set as the action group.
*'''Command''': The command which is going to be used in case of a fired alert. You may choose between numerous predefined commands under Pandora FMS.
+
*'''Command''': The command used in case of a triggered alert. You may choose among several predefined commands under Pandora FMS.
 
*'''Threshold''': The action's execution threshold.
 
*'''Threshold''': The action's execution threshold.
*'''Command Preview''': The command which is going to be executed on the system is going to appear here automatically. This field is '''not''' editable.
+
*'''Command Preview''': The command to be executed on the system appears here automatically.
*'''Field 1-10''': The values of the macros from '_field1_ through '_field10_' are defined here. They are intended to be used in conjunction with the command if necessary.
+
*'''Field 1-10''': The values of the macros from '_field1_ through '_field10_' are defined here. They are intended to be used along with the command if necessary. These fields might be a text field or a selection combo if configured.
  
Once you have filled out the fields, please click on the 'Create' button.
+
Once you have filled out the fields, click on the 'Create' button.
  
 
<center>
 
<center>
Line 494: Line 494:
 
</center>
 
</center>
  
To edit the newly created actions, please click on '''Alerts''' and '''Actions'''.
+
To edit newly created actions, click on '''Alerts''' and '''Actions'''.
  
 
==== Action macros ====
 
==== Action macros ====
Line 506: Line 506:
 
* '''_agentalias_:'''  Alias of the agent that triggered the alert.
 
* '''_agentalias_:'''  Alias of the agent that triggered the alert.
 
* '''_agentcustomfield_n_:'''  Agent custom field number n (eg. _agentcustomfield_9_).
 
* '''_agentcustomfield_n_:'''  Agent custom field number n (eg. _agentcustomfield_9_).
* '''_agentcustomid_:''' Agent custom ID.
+
* '''_agentcustomid_:''' Agent custom ID.
* '''_agentdescription_:''' Description of the agent that triggered the alert.
+
* '''_agentdescription_:''' Description of the agent that triggered the alert.
* '''_agentgroup_ :''' Agent group name.
+
* '''_agentgroup_ :''' Agent group name.
* '''_agentname_:''' Name of the agent that triggered the alert.
+
* '''_agentname_:''' Name of the agent that triggered the alert.
* '''_agentos_:''' Agent's operative system.
+
* '''_agentos_:''' Agent's operative system.
* '''_agentstatus_ :''' Current status of the agent.
+
* '''_agentstatus_ :''' Current status of the agent.
 
* '''_alert_critical_instructions_:'''  Instructions for CRITICAL status contained in the module.
 
* '''_alert_critical_instructions_:'''  Instructions for CRITICAL status contained in the module.
* '''_alert_description_:''' Alert description.
+
* '''_alert_description_:''' Alert description.
* '''_alert_name_:''' Alert name.
+
* '''_alert_name_:''' Alert name.
* '''_alert_priority_:''' Alert’s numeric priority.
+
* '''_alert_priority_:''' Alert’s numeric priority.
* '''_alert_text_severity_:''' Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).
+
* '''_alert_text_severity_:''' Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).
* '''_alert_threshold_:''' Alert threshold.
+
* '''_alert_threshold_:''' Alert threshold.
* '''_alert_times_fired_:''' Number of times the alert has been triggered.
+
* '''_alert_times_fired_:''' Number of times the alert has been triggered.
* '''_alert_unknown_instructions_:''' Instructions for UNKNOWN status contained in the module.
+
* '''_alert_unknown_instructions_:''' Instructions for UNKNOWN status contained in the module.
* '''_alert_warning_instructions_:''' Instructions for WARNING status contained in the module.
+
* '''_alert_warning_instructions_:''' Instructions for WARNING status contained in the module.
* '''_all_address_ :''' All address of the agent that fired the alert.
+
* '''_all_address_ :''' All addresses of the agent that triggered the alert.
* '''_data_:''' Module data that caused the alert to fire.
+
* '''_data_:''' Module data that caused the alert to be triggered.
* '''_email_tag_:''' Emails associated to the module’s tags.
+
* '''_email_tag_:''' Emails associated to the module’s tags.
* '''_event_cfX_:''' (Only event alerts) Key of the event custom field that fired the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
+
* '''_event_cfX_:''' (Only event alerts) Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
* '''_event_description_:''' (Only event alerts) The textual description of the Thor event.
+
* '''_event_description_:''' (Only event alerts) Text description of the Pandora FMS event.
* '''_event_extra_id_:''' (Only event alerts) Extra id.
+
* '''_event_extra_id_:''' (Only event alerts) Extra id.
* '''_event_id_:''' (Only event alerts) ID of the event that triggered the alert.
+
* '''_event_id_:''' (Only event alerts) ID of the event that triggered the alert.
* '''_event_text_severity_:''' (Only event alerts) Event text severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
+
* '''_event_text_severity_:''' (Only event alerts) Event text severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
* '''_eventTimestamp_:''' Timestamp in which the event was created.
+
* '''_eventTimestamp_:''' Timestamp when the event was created.
* '''_fieldX_:''' User defined field X.
+
* '''_fieldX_:''' User defined field C.
* '''_groupcontact_:''' Group contact information. Configured when the group is created.
+
* '''_groupcontact_:''' Group contact information. Configured when the group is created.
* '''_groupcustomid_:''' Group custom ID.
+
* '''_groupcustomid_:''' Group custom ID.
* '''_groupother_:''' Other information about the group. Configured when the group is created.
+
* '''_groupother_:''' Other information about the group. Configured when the group is created.
* '''_homeurl_ :''' It is a link of the public URL this must be configured in the general options of the setup.
+
* '''_homeurl_ :''' It is a link of the public URL. It must be configured in the general options of the setup.
* '''_id_agent_:''' Agent’s ID, useful for building a direct URL that redirects to a Thor console webpage.
+
* '''_id_agent_:''' Agent’s ID, useful for building a direct URL that redirects to a Pandora FMS console webpage.
* '''_id_alert_:''' Alert’s numeric ID (unique), used to correlate the alert with third party software.
+
* '''_id_alert_:''' Alert’s numeric ID (unique), used to correlate the alert with third party software.
* '''_id_group_ :''' Agent group ID.
+
* '''_id_group_ :''' Agent group ID.
* '''_id_module_:''' Module ID.
+
* '''_id_module_:''' Module ID.
* '''_interval_:''' Module’s execution interval.
+
* '''_interval_:''' Module’s execution interval.
* '''_module_:''' Module name.
+
* '''_module_:''' Module name.
* '''_modulecustomid_:''' Module custom ID.
+
* '''_modulecustomid_:''' Module custom ID.
* '''_moduledata_X_:''' Last data of module X (module name, cannot have white spaces).
+
* '''_moduledata_X_:''' Using this macro ("X" is its actual name) the last module data is retrieved. If it is umerical it is returned under the decimal format specified in the console's setup along with is unit (if it has it). I could be used, for instance, to send an email when a module alert is triggeres anlong with additiona information from other modules from the same agent (which might be quite relevant).
* '''_moduledescription_:''' Description of the module that triggered the alert.
+
* '''_moduledescription_:''' Description of the module.
* '''_modulegraph_nh_:''' (Only for alerts that use the command eMail) Returns an image encoded in base64 of a module’s graph with a period of n hours (eg. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done on the server's configuration file.
+
* '''_modulegraph_nh_:''' (Only for alerts that use the command eMail). It returns an image encoded in base64 of a module’s graph with a rango of n hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done on the server's configuration file.
* '''_modulegraphth_nh_:''' (Only for alerts that use the command eMail) Same operation as the previous macro only with the critical and warning thresholds of the module provided they are defined.
+
* '''_modulegraphth_nh_:''' (Only for alerts that use the command eMail). Same operation as the previous macro, only with the critical and warning thresholds of the module, provided they are defined.
* '''_modulegroup_:''' Module’s group name.
+
* '''_modulegroup_:''' Module’s group name.
* '''_modulestatus_:''' Module status.
+
* '''_modulestatus_:''' Module status.
* '''_moduletags_:''' URLs associated to the module tags.
+
* '''_moduletags_:''' URLs associated to the module tags.
* '''_name_tag_:''' Names of the tags related to the module.
+
* '''_name_tag_:''' Names of the tags related to the module.
* '''_phone_tag_:''' Phone numbers associated to the module tags.
+
* '''_phone_tag_:''' Phone numbers associated to the module tags.
* '''_plugin_parameters_:''' Module plugin parameters.
+
* '''_plugin_parameters_:''' Module plugin parameters.
* '''_policy_:''' Name of the policy that the module belongs to (if applies).
+
* '''_policy_:''' Name of the policy that the module belongs to (if applies).
* '''_prevdata_:''' Module previous data before the alert has been triggered.
+
* '''_prevdata_:''' Module's previous data before the alert has been triggered.
* '''_rca_:''' Root cause analysis chain (only for services).
+
* '''_rca_:''' Root cause analysis chain (only for services).
* '''_server_ip_:''' Ip of server assigned to agent.
+
* '''_secondarygroups_:''' It displays the agent's secondary groups.
* '''_server_name_:''' Name of server assigned to agent.
+
* '''_server_ip_:''' Ip of server assigned to the agent.
* '''_target_ip_:''' IP address for the module’s target.
+
* '''_server_name_:''' Name of server assigned to the agent.
* '''_target_port_:''' Port number for the module’s target.
+
* '''_target_ip_:''' IP address for the module’s target.
* '''_timestamp_:''' Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).
+
* '''_target_port_:''' Port number for the module’s target.
* '''_timezone_:''' Timezone that is represented on _timestamp_.
+
* '''_timestamp_:''' Time and date when the alert was triggered (yy-mm-dd hh:mm:ss).
 +
* '''_timezone_:''' Timezone represented on _timestamp_.
  
 
=== Editing an Action ===
 
=== Editing an Action ===
Line 568: Line 569:
 
<br>
 
<br>
  
To edit the action, please click on the action's name.
+
To edit an action, click on the action's name.
  
 
<br>
 
<br>
Line 574: Line 575:
 
<br>
 
<br>
  
Once you've completed the changes, please update them by clicking on the 'Update' button.
+
Once you have completed the changes, update them by clicking on the 'Update' button.
  
 
<br>
 
<br>
 +
 
=== Deleting an Action ===
 
=== Deleting an Action ===
  
To delete an action, please click on the gray trash icon which is located on the right side.
+
To delete an action, click on the gray trash icon which is located at the right side.
  
 
<center>
 
<center>
Line 587: Line 589:
 
== Alert Templates ==
 
== Alert Templates ==
 
===Introduction===
 
===Introduction===
Alert templates are alerts in which all parameters are already predefined. They only require their assigned agent and the module that is used to activate the command or the response if a value is 'out of range'. The templates were created to render the administrator's management job a little easier, so they could be assigned to the required agents more quickly if they're already predefined.
+
Templates define alert triggering terms (''when'' the action should be executed).
  
 +
Alert templates are associated to modules, so theta ehen the template terms are met, the linked action(s) are executed.
 +
 +
Their design allows generating a small generic template group that is used for most cases in Pandora FMs.
  
 
=== Creating an Alert Template ===
 
=== Creating an Alert Template ===
Line 604: Line 609:
 
</center>
 
</center>
  
This is a description for the fields you're going to see there:
+
You may specify in the template wizard:
  
 
*'''Name:''' The name of the template.
 
*'''Name:''' The name of the template.
*'''Description:''' It describes the template function. It's useful to distinguish the template from others within the alert's general view.
+
*'''Description:''' It describes the template's function. It is useful to distinguish the template from others within the alert's general view.
*'''Priority:''' The field which provides information about the alert. It's useful when searching for alerts.  
+
*'''Priority:''' The field which provides information about the alert. The generated event will inherit this priority whenthe alert is triggered. It is useful for filtering when searching for alerts.  
  
You may choose between the following priorities:
+
You may choose among the following priorities:
  
 
**Maintenance
 
**Maintenance
Line 624: Line 629:
 
<br>
 
<br>
  
In this section we are offered the possibility to customize the template itself, '''when''' it must be launched:
+
This section offers the possibility of customizing the template itself, '''when''' it must be launched:
  
* ''' 'Condition Type:' ''' The field where the type of condition which is going to be applied on the alert is defined. The required combos will be added according to the defined type, which are:
+
* ''' 'Condition Type:' ''' The field where the type of condition to be applied on the alert is defined. The required combos will be added according to the defined type, which are:
  
* '''Regular Expression:''' The used regular expression. The alert is going to be fired if the module's value performs a defined condition, expressed by using a regular expression. '''This is the used firing condition for string and text data.''' All other conditions are intended for status and any other types of numerical data.
+
* '''Regular Expression:''' A regular expression is used. The alert will be triggered if the module's value meets certain requirement.
  
 
<br>
 
<br>
Line 634: Line 639:
 
<br>
 
<br>
  
By choosing the 'regular expression' condition, the possibility to select the trigger box appears if the value is matched. If you select it, the alert is going to be fired if the value matches. If not, the alert is going to be fired if the value doesn't match.
+
By choosing the 'regular expression' condition, the possibility of selecting the trigger box appears if it matches the value. If you select it, the alert will be fired if the value matches. If not, the alert will be fired if the value does not match.
  
 
* '''Max and Min:''' The used maximum and a minimum values.
 
* '''Max and Min:''' The used maximum and a minimum values.
Line 642: Line 647:
 
<br>
 
<br>
  
When checking 'Trigger when matches the value' the alert will be launched when the value is within the indicated range between maximum and minimum and, if not marked, the alert will be launched when the value is outside the indicated range.
+
When checking 'Trigger when matches the value', the alert will be launched when the value is within the indicated range between maximum and minimum and, if not marked, the alert will be launched when the value is outside the selected range.
  
* Max: The used 'maximum' value. The alert is going to be fired if the module's value is higher than the defined 'maximum' value.
+
* Max: The used 'maximum' value. The alert will be triggered if the module's value is higher than the defined 'maximum' value.
  
 
<center>
 
<center>
Line 650: Line 655:
 
</center>
 
</center>
  
* Min: The used 'minimum' value. The alert is going to be fired if the module's value is lower than the defined minimum value.
+
* Min: The used 'minimum' value. The alert will be triggered if the module's value is lower than the defined minimum value.
  
  
Line 664: Line 669:
 
</center>
 
</center>
  
*Not Equal to: Same as above but denying the condition (logic operator NOT).
+
*Not Equal to: It is the same as previous one but denying the condition (logic operator NOT).
  
 
<center>
 
<center>
Line 670: Line 675:
 
</center>
 
</center>
  
*Warning/Critical/Unknown status: The module status is used. The alert will fire when the monitor status is indicated:
+
*Warning/Critical/Unknown status: The module status is used. The alert will be triggered when the monitor status is appropriate one:
  
 
<center>
 
<center>
Line 676: Line 681:
 
</center>
 
</center>
  
These are the explanations for the fields you're going to see there:
+
These are the explanations for the fields featured there:
  
 
'''Days of Week'''
 
'''Days of Week'''
  
The days on which the alert could be fired at all.
+
Days when the alert could possibly be triggered.
  
 
'''Use special days list'''
 
'''Use special days list'''
  
It's used to enable or disable the use of the special days list, e.g. holidays and special working days.
+
It is used to enable or disable the use of the special days list, e.g. holidays and special working days.
  
 
'''Time From'''
 
'''Time From'''
  
The time from which the alert action is going to be executed.
+
Time from which the alert action is going to be executed.
  
 
'''Time To'''
 
'''Time To'''
  
The time until the alert action is going to be executed.
+
Alert action time limit.
  
 
'''Time Threshold'''
 
'''Time Threshold'''
Line 698: Line 703:
 
Time required to reset the alarm counter.
 
Time required to reset the alarm counter.
  
Defines the time interval in which it is guaranteed that an alert will not be triggered more than the maximum number of alerts.
+
It defines the time interval where it is guaranteed that an alert will not be triggered more than the maximum number of alerts.
  
 
After the defined interval, the counter will be reset. The restart of the trigger counter will not be restarted if the alert recovers when a correct value arrives, unless the value ''Alert recovery'' is activated, in which case the counter will restart immediately after receiving a correct value.
 
After the defined interval, the counter will be reset. The restart of the trigger counter will not be restarted if the alert recovers when a correct value arrives, unless the value ''Alert recovery'' is activated, in which case the counter will restart immediately after receiving a correct value.
Line 704: Line 709:
 
'''Min. number of Alerts'''
 
'''Min. number of Alerts'''
  
The minimum number of times the data has to be 'out of range' to fire an alert. It's always counting from the number defined within the 'FlipFlop' parameter of the module. The default value is '0', which means the alert is going to be fired if the condition's first value is met. It's intended as a filter, which is necessary to eliminate any false positives.
+
The minimum number of times the terms set on the template have to be met (counting from the number defined in the module's FlipFlop parameter) so that an alert is triggered. The default value is '0', which means the alert will be triggered when the first value that meets the terms is received. It is intended to work as a filter, which might be useful to ignore false positives.
  
 
'''Max number of Alerts'''
 
'''Max number of Alerts'''
The maximum number of alerts which could be sent consecutively within the same time interval (time threshold).
+
Maximum number of alerts which could be sent consecutively within the same time interval (time threshold). It is the maximum alert counter value. No more alerts than the specified number will be received by interval.
  
  
 
'''Default Action:'''
 
'''Default Action:'''
The default action the template is going to have is defined in this combo. It's the action which is going to be automatically created if the template is assigned to the module. You may assign one or none to it, but you're unable to assign several default actions here.
+
The default action the template will have is defined in this combo. This will be the action to be automatically created when the template is assigned to the module. You may assign one or none, but you cannot assign several default actions here.
  
 
==== Step 3: Advanced fields====
 
==== Step 3: Advanced fields====
Line 720: Line 725:
 
</center>
 
</center>
  
This is a definition for the fields you're going to see there:
+
You may adjust the following options:
  
 
'''Alert Recovery'''
 
'''Alert Recovery'''
  
The Combo where you're able to define whether the alert recovery is enabled or not.
+
The combo where alert recovery is enabled or disabled.
  
In the event that alert recovery is enabled, when the module no longer meets the conditions indicated by the template, the action associated with the arguments specified by the fields defined in this column will be executed.
+
In the event that alert recovery is enabled, when the module no longer meets the terms specified in the template, the action linked to the arguments specified by the fields defined in this column will be executed.
 
   
 
   
 
'''Field 1'''
 
'''Field 1'''
It defines the value for the '_field1_' variable. The list of macros (which are going to be described below) could be used here.
+
It defines the value for the '_field1_' variable. The list of macros (which are described below) may be used here.
 
 
'''Field 2'''
 
It defines the value for the '_field2_' variable.
 
  
 
'''Field n'''
 
'''Field n'''
 
It defines the value for the '_fieldn_' variable in n is a number between 1 and 10.
 
It defines the value for the '_fieldn_' variable in n is a number between 1 and 10.
  
Once all appropriate fields have been filled out, please click on the 'Finish' button.
+
Once all appropriate fields have been filled out, click on 'Finish'.
  
=== Replaceable Macros within Field 1 through Field 10 ===
+
=== Replaceable Macros within Field1, Field2, Field3... Field10 ===
  
It's possible to use the following macros in all cases of the fields 'Field1', 'Field2' and 'Field3' (in the alert template, the command and the action). These are 'words' which are going to be replaced if executed by a value. That value is going to change by a value or agent which has fired the alert, etc. depending on the moment.
+
It is possible to use the following macros in all cases the instances of 'Field1', 'Field2'... 'Field10' (both in the alert template, as well as the command and the action). These are 'words' that will be replaced if executed by a value. That value is depends on the time, value or agent that triggered the alert, etc.
  
* '''_address_:''' The address of the agent which fired the alert.
+
* '''_address_:''' The address of the agent that triggered the alert.
 
* '''_address_n_:''' The address of the agent that corresponds to the position indicated in "n" e.g: address_1_ , address_2_.
 
* '''_address_n_:''' The address of the agent that corresponds to the position indicated in "n" e.g: address_1_ , address_2_.
* '''_agent_:''' Alias of the agent that triggered the alert. If there is no alias assigned, the name of the agent will be used instead.
+
* '''_agent_:''' Alias of the agent that triggered the alert. If there is no alias assigned, the agent name will be used instead.
 
* '''_agentalias_:''' Alias of the agent that triggered the alert.
 
* '''_agentalias_:''' Alias of the agent that triggered the alert.
 
* '''_agentcustomfield_''n''_:''' Agent custom field number ''n'' (eg. _agentcustomfield_9_).
 
* '''_agentcustomfield_''n''_:''' Agent custom field number ''n'' (eg. _agentcustomfield_9_).
Line 753: Line 755:
 
* '''_agentname_:''' Name of the agent that triggered the alert.
 
* '''_agentname_:''' Name of the agent that triggered the alert.
 
* '''_agentos_:''' Agent's operative system.
 
* '''_agentos_:''' Agent's operative system.
* '''_agentstatus_:''' Current status of the agent.
+
* '''_agentstatus_:''' Current agent status.
 
* '''_alert_critical_instructions_:''' Instructions for the CRITICAL status contained in the module.
 
* '''_alert_critical_instructions_:''' Instructions for the CRITICAL status contained in the module.
 
* '''_alert_description_:''' Alert description.
 
* '''_alert_description_:''' Alert description.
* '''_alert_name_:''' Name of the agent that triggered the alert.
+
* '''_alert_name_:''' Alert name.
 
* '''_alert_priority_:''' Alert’s numeric priority.
 
* '''_alert_priority_:''' Alert’s numeric priority.
* '''_alert_text_severity_:''' Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).
+
* '''_alert_text_severity_:''' Priority level, in the alert's text (Maintenance, Informational, Normal Minor, Major, Critical).
 
* '''_alert_threshold_:''' Alert threshold.
 
* '''_alert_threshold_:''' Alert threshold.
* '''_alert_times_fired_:''' Number of times the alert has been triggered.
+
* '''_alert_times_fired_:''' Number of times the alert was triggered.
* '''_alert_unknown_instructions_:''' Instructions for the UNKNOWN status contained in the module.
+
* '''_alert_unknown_instructions_:''' Instructions for UNKNOWN status contained in the module.
* '''_alert_warning_instructions_:''' Instructions for the WARNING status contained in the module.
+
* '''_alert_warning_instructions_:''' Instructions for WARNING status contained in the module.
* '''_all_address_:''' All address of the agent that fired the alert.
+
* '''_all_address_:''' All addresses of the agent that triggered the alert.
* '''_data_:'''  Module data that caused the alert to fire.
+
* '''_data_:'''  Module data that caused the alert to be triggered.
 
* '''_email_tag_:''' Emails associated to the module's tags.
 
* '''_email_tag_:''' Emails associated to the module's tags.
* '''_event_cfX_:''' (Only event alerts) Key of the event custom field that fired the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
+
* '''_event_cfX_:''' (Only event alerts) Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
* '''_event_description_:''' (Only event alerts) Textual description of the event that fired the alert.
+
* '''_event_description_:''' (Only event alerts) Textual description of the event that triggered the alert.
 +
* '''_event_id_:''' (Only event alerts) Id of the event that fired the alert.
 
* '''_event_extra_id_:''' (Only event alerts) Extra id.
 
* '''_event_extra_id_:''' (Only event alerts) Extra id.
* '''_event_id_:''' (Only event alerts) Id of the event that fired the alert.
+
* '''_event_text_severity_:''' (Only event alerts) Priority in the text of the event that triggered the alert (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
* '''_event_text_severity_:''' (Only event alerts) Event text severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
+
* '''_eventTimestamp_:''' Timestamp when the event was created. v733
* '''_eventTimestamp_:''' Timestamp in which the event was created. v733
 
 
* '''_field1_:''' User defined field 1.
 
* '''_field1_:''' User defined field 1.
 
* '''_field2_:''' User defined field 2.
 
* '''_field2_:''' User defined field 2.
Line 790: Line 792:
 
* '''_groupcustomid_:''' Group custom ID.
 
* '''_groupcustomid_:''' Group custom ID.
 
* '''_groupother_:''' Other information about the group. Configured when the group is created.
 
* '''_groupother_:''' Other information about the group. Configured when the group is created.
* '''_homeurl_:''' It is a link of the public URL this must be configured in the general options of the setup.
+
* '''_homeurl_:''' It is a link to the public URL. Configured in the setup general options.
* '''_id_agent_:''' Agent’s ID, useful for building a direct URL that redirects to a Pandora FMS console webpage.
+
* '''_id_agent_:''' Agent ID, useful for building a direct URL that redirects to a Pandora FMS console webpage.
* '''_id_alert_:''' Alert’s numeric ID (unique), used to correlate the alert with third party software.
+
* '''_id_alert_:''' Alert numeric ID (unique), used to correlate the alert with third party software.
 
* '''_id_group_:''' Agent group ID.
 
* '''_id_group_:''' Agent group ID.
 
* '''_id_module_:''' Module ID.
 
* '''_id_module_:''' Module ID.
Line 798: Line 800:
 
* '''_module_:''' Module name.
 
* '''_module_:''' Module name.
 
* '''_modulecustomid_:''' Module custom ID.
 
* '''_modulecustomid_:''' Module custom ID.
* '''_moduledata_X_''': Use this macro (named "X" ) to get the most recent data from the module and, if it's numeric, it comes back formatted with the decimals specified on the console configuration and its unit (if it has one). The macro is good, for example, in the case of sending an email when an alert is triggered and an email is sent, said email can include additional (and possibly important) information from other modules belonging to the same agent.
+
* '''_moduledata_X_''': Use this macro (named "X") to get the most recent data from the module and, if it is numeric, it will return formatted with the decimals specified on the console setup and that of its unit (if it has one). It would be useful in case of sending an email when an alert is triggered and send additional (and possibly relevant) information from other modules belonging to the same agent.
 
* '''_moduledescription_:'''Description of the module that triggered the alert.
 
* '''_moduledescription_:'''Description of the module that triggered the alert.
* '''_modulegraph_''n''h_''': (Only for alerts that use the command ''eMail'') Returns an image codified in base64 of a module graph with a period of ''n'' hours (eg. _modulegraph_24h_). A correct setup of the connection between the server and the console's api is required. This setup is done into the server's configuration file.
+
* '''_modulegraph_''n''h_''': (Only for alerts that use the command ''eMail''). It returns an image codified in base64 of a module graph with a period of ''n'' hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's api is required. This setup is done in the server configuration file.
* '''_modulegraphth_''n''h_''': (Only for alerts that use the command ''eMail'') Same operation as the previous macro only with the critical and warning thresholds of the module provided they are defined.
+
* '''_modulegraphth_''n''h_''': (Only for alerts that use the command ''eMail''). Same operation as the previous macro but with module critical and warning thresholds, provided they are defined.
 
* '''_modulegroup_:''' The module's group name.
 
* '''_modulegroup_:''' The module's group name.
 
* '''_modulestatus_:''' Module status.
 
* '''_modulestatus_:''' Module status.
* '''_moduletags_:''' URLs associated to the module tags.
+
* '''_moduletags_:''' URLs associated to module tags.
 
* '''_name_tag_:''' Names of the tags associated to the module.
 
* '''_name_tag_:''' Names of the tags associated to the module.
 
* '''_phone_tag_:''' Phone numbers associated to the module tags.
 
* '''_phone_tag_:''' Phone numbers associated to the module tags.
 
* '''_plugin_parameters_:''' Module plugin parameters.
 
* '''_plugin_parameters_:''' Module plugin parameters.
 
* '''_policy_:''' The policy's name the module belongs to (if applies).
 
* '''_policy_:''' The policy's name the module belongs to (if applies).
* '''_prevdata_:''' Module previous data before the alert has been triggered.
+
* '''_prevdata_:''' Module previous data before the alert was triggered.
 
* '''_server_ip_:''' Ip of server assigned to agent.
 
* '''_server_ip_:''' Ip of server assigned to agent.
 
* '''_server_name_:''' Name of server assigned to agent.
 
* '''_server_name_:''' Name of server assigned to agent.
 
* '''_target_ip_:''' IP address for the module’s target.
 
* '''_target_ip_:''' IP address for the module’s target.
 
* '''_target_port_:''' Port number for the module’s target.
 
* '''_target_port_:''' Port number for the module’s target.
* '''_timestamp_:''' Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).
+
* '''_timestamp_:''' Time and date when the alert was triggered (yy-mm-dd hh:mm:ss).
* '''_timezone_:''' Timezone that is represented on _timestamp_.
+
* '''_timezone_:''' Timezone represented on _timestamp_.
 +
 
 +
Example:  The agent_agent_ has module_module_ in status_modulestatus_ with data_data_
  
==== Complete Example of an Alert containing Replacement Macros ====
+
==== Complete example of an alert containing replacement macros ====
  
Let's suppose for a moment you intend to create a log entry in which every line appears in the following format:
+
Suppose you intend to create a log entry where every line appears in the following format:
  
 
2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status
 
2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status
 
To do so, you're required to change your configuration as shown below.
 
  
 
'''Command Configuration'''
 
'''Command Configuration'''
Line 846: Line 848:
 
  Field3 = <left blank>
 
  Field3 = <left blank>
  
If an alert is fired, the following line is going to be added to the log:
+
If an alert is triggered, the following line will be added to the log:
  
 
  2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status
 
  2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status
  
In the moment of alert recovery, the following line is going to be added:
+
And the this one to recover the alert:
  
 
  2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status
 
  2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status
  
=== Editing a Template ===
+
=== Editing a template ===
  
You may edit the newly created templates by clicking on the menus of ''Administration -> Manage Alerts ->Templates''.
+
You may edit newly created templates by clicking on ''Administration -> Manage Alerts ->Templates''.
  
 
<br>
 
<br>
Line 863: Line 865:
 
</center>
 
</center>
  
To edit a template, please click on the template's name.
+
To edit a template, click on the template's name.
  
=== Deleting a Template ===
+
=== Deleting a template ===
  
To delete a template, please click on the gray trash icon which is located on the alert's right side.
+
To delete a template, click on the gray trash icon located at the right of the alert.
  
 
<center>
 
<center>
Line 873: Line 875:
 
</center>
 
</center>
  
== Assigning Alert Templates to Modules ==
+
== Assigning alert templates to modules ==
  
Once the basic information about the alert system is known, we will show you the possible ways to assign the alerts to the modules.
+
Once the basic information about the alert system is known, we will show you the possible ways to assign alerts to the modules.
  
=== Alert Management from an Alert's Sub Menu ===
+
=== Alert management from alert submenu ===
  
==== Assigning Alerts from an Alert's Sub Menu ====
+
==== Assigning alerts from alert submenu ====
  
From the section ''List of Alerts'' we can create new alerts from the builder:
+
From section ''List of Alerts'', create new alerts through the builder:
  
 
<br>
 
<br>
Line 887: Line 889:
 
<br>
 
<br>
  
This is a definition for the fields you're going to see there:
+
These are the fields to fill in:
  
* '''Agent:''' The name of the agent to which the alert is going to be assigned to.
+
* '''Agent:''' Smart auto-completion to choose the agent.
* '''Module:''' The module which is used for firing the alert.
+
* '''Module:''' Module list of the previously selected agent.
* '''Actions:''': It allows to choose between all preconfigured alerts. The selected action is added to the one defined within the template. You may choose more than one action.
+
* '''Actions:''': Action to be executed when the alert is triggered. If the template has a default action, ''Default'' may be kept.
* '''Template:''' You may choose the template to configure the alert by a combo here.
+
* '''Template:''' Template that contains alert triggering terms.
* '''Threshold:''' The alert action will not be executed more than once every 'action_threshold' seconds, regardless of the number of times the alert is fired.
+
* '''Threshold:''' The alert action to not be executed more than once every 'action_threshold' seconds, regardless of the number of times the alert is triggered.
  
==== Modifying Alerts from an Alert's Sub Menu ====
+
==== Modifying alerts from an alert's submenu ====
  
Once an alert has been created, it's only possible to modify the actions which have been added to the template's action.
+
Once an alert has been created, it is only possible to modify the actions that have been added to the template's action.
  
It's also possible to delete the action that was selected in the moment you've created the alert by clicking the gray trash icon which is located on the right side of the action, or to add new actions by clicking on the 'Add' ('+') button.
+
It is also possible to delete the action that was selected when the alert was created by clicking on the gray trash icon located at the right side of the action, or to add new actions by clicking on the 'Add' ('+') button.
  
 
<br>
 
<br>
Line 905: Line 907:
 
<br>
 
<br>
  
==== Deactivating Alerts from an Alert's Sub Menu ====
+
==== Deactivating alerts from an alert's submenu ====
  
Once the alert has been created, it's possible to deactivate it by clicking on the light-bulb icon which is located on the right side of the alert's name.
+
Once the alert has been created, it is possible to deactivate it by clicking on the light-bulb icon located at the right side of the alert's name.
  
 
<br>
 
<br>
Line 913: Line 915:
 
<br>
 
<br>
  
==== Deleting Alerts from the Alert's Sub Menu ====
+
==== Deleting alerts from the alert submenu ====
  
It's possible to delete any alert by clicking on the gray trash icon which is located on the right side of the alert.
+
It is possible to delete any alert by clicking on the gray trash icon located at the right side of the alert.
  
 
<center>
 
<center>
Line 921: Line 923:
 
</center>
 
</center>
  
=== Managing Alerts from within the Agent ===
+
=== Managing alerts from within the agent ===
  
==== Alert Assignment from within the Agent ====
+
==== Alert assignment within the agent ====
  
From the section Agent Management we can add new alerts by clicking on the corresponding tab.
+
From the agent management section, new alerts can be added by clicking on the corresponding tab.
  
 
<br>
 
<br>
Line 932: Line 934:
  
  
This is a definition for the fields you're going to find there:
+
These are the form's available fields:
  
* '''Module:''' It's the module which is going to be used for firing the alert.
+
* '''Module:''' Agent module list.
* '''Template:''' You may select the template which is going to be used to configure the alert here.
+
* '''Actions:''' Action executed when the alert is triggered. If the template has a default one, leave it as ''Default''.
* '''Actions:''' It allows you to choose between all preconfigured actions. The chosen action is added to the one defined in the template. It's possible to select more than one action here.
+
* '''Template:''' Template that contains alert triggering terms.
* '''Threshold:''' The alert action is not going to be executed more than once every 'action_threshold' seconds, regardless of the number of times the alert is fired.
+
* '''Threshold:''' The alert action will not be executed more than once every 'action_threshold' seconds, regardless of the number of times the alert is triggered.
  
==== Modifying Alerts from within the Agent ====
+
==== Modifying alerts from within the agent ====
  
Once an alert has been created, it's only possible to modify the actions which have been added to the template's action.
+
Once an alert has been created, it is only possible to modify the actions that have been added to the template's action.
  
It's also possible to delete the action which was selected in the moment you've created the alert by clicking on the gray trash icon which is located on the right side of the action, or to add new actions by clicking on the 'Add' button.
+
It is also possible to delete the action selected at the moment the alert was created by clicking on the gray trash icon which is located at the right side of the action, or to add new actions by clicking on the 'Add' button.
  
 
<center>
 
<center>
Line 950: Line 952:
  
  
==== Deactivating Alerts from the Agent ====
+
==== Deactivating alerts from the agent ====
  
Once an alert has been created, it's possible to deactivate it by clicking on the light bulb icon which is located on the right side of the alert's name.
+
Once an alert has been created, it is possible to deactivate it by clicking on the light bulb icon located at the right side of the alert's name.
  
 
<center>
 
<center>
Line 958: Line 960:
 
</center>
 
</center>
  
In the example image, the second alert is disabled (note that the font color and the disabled alert icon are light grey)
+
In the example image, the second alert is disabled (note that the font color and the disabled alert icon are light grey).
  
  
==== Deleting Alerts from within the Agent ====
+
==== Deleting alerts from within the agent ====
  
It's possible to delete any alert by clicking on the gray trash icon which is located on the alert's right side.
+
It is possible to delete any alert by clicking on the gray trash icon which is located at the alert's right side.
  
  
Line 971: Line 973:
  
  
====Detalle de alertas====
+
==== Alert detail ====
  
Clicking on the magnifying glass icon in the button panel of the alert options will take you to a summary page of the effective configuration of the alert.
+
By clicking on the magnifying glass icon on the button panel of alert options, you will see a summary page of the effective alert setup.
  
This is the screen where we will be able to confirm each of the settings we have selected for our alert:
+
This is the screen where each of the settings selected for the alert can be confirmed:
  
  
Line 990: Line 992:
 
<br>
 
<br>
  
== Defining a Threshold ==
+
== Defining a threshold ==
  
In the following screenshot we see a module called "CPU Load" for which we will define a critical threshold and a warning threshold.
+
In the following screenshot, there is a module called "CPU Load" for which a critical threshold and a warning thresholds will be defined.
  
 
<br>
 
<br>
Line 1,000: Line 1,002:
 
The module edit form will be accessed to set the thresholds as shown in the following screenshot.
 
The module edit form will be accessed to set the thresholds as shown in the following screenshot.
  
It is important to remember that the modification of local modules is only available from the console in the Enterprise version, otherwise it will have to be done directly in the agent configuration file:
+
It is important to remember that modifying local modules is only available from the console in the Enterprise version, otherwise it will have to be done directly in the agent configuration file:
  
 
<br>
 
<br>
Line 1,006: Line 1,008:
 
<br>
 
<br>
  
We accept and save the modification. Now when the value of the module ''CPU Load'' is between 70 and 90, its status will be changed to WARNING, and between 91 and 100 will become CRITICAL, showing its status in red as we see here:
+
Accept and save the changes. When the value of the module ''CPU Load'' is between 70 and 90, its status will change to WARNING, and when between 91 and 100, it will become CRITICAL, showing its status in red as seen here:
  
 
<br>
 
<br>
Line 1,012: Line 1,014:
 
<br>
 
<br>
  
== Configuring an Action ==
+
== Configuring an action ==
  
Now we have to create an action that is "Send an email to the operator". Go to the menu:'' Alerts'' >'' Actions'' and click on the button to create a new action:
+
Create an action that is "Send an email to the operator". Go to the menu:'' Alerts'' >'' Actions'' and click on the button to create a new action:
  
 
<center>
 
<center>
Line 1,020: Line 1,022:
 
</center>
 
</center>
  
This action utilizes the command 'Send email' and its fields  named 'Field1', 'Field2' and 'Field3' which correspond to the destination address, email subject, and message body.
+
This action uses the command 'Send email' and its fields  named 'Field1', 'Field2' and 'Field3' which correspond to the target address, email subject, and message body.
  
  
Line 1,027: Line 1,029:
 
<br>
 
<br>
  
== Configuring an Alert Template ==
+
== Configuring an alert template ==
  
A generic alert template will be created for any module in critical status, and its default action will be to notify the group of operators by email. We will define the template from the ''Templates'' section:
+
A generic alert template will be created for any module in critical status, and its default action will be to notify the group of operators by email. Define the template from the ''Templates'' section:
  
  
Line 1,035: Line 1,037:
  
  
The priority set here "Informational" will be used to display the event in a certain color when the alert is triggered.
+
The priority set here as "Informational" will be used to display the event in a certain color when the alert is triggered.
  
Step 2 specifies the parameters that determine the specific triggering conditions, such as the state the module should have or the time intervals at which the plant will operate.
+
Step 2 specifies the parameters that determine the specific triggering terms, such as the state the module should have or the time intervals when the template will work.
  
  
Line 1,045: Line 1,047:
 
The most important parameters in this step are:
 
The most important parameters in this step are:
  
* '''Condition type''': determines whether the alert will be triggered by a status change, a variation of a value, etc. It is the most important parameter for the alert to function as desired. We would use the ''Critical status'' condition to trigger the alert when a module is in a critical status.
+
* '''Condition type''': It determines whether the alert will be triggered by a status change, a value change, etc. It is the most important parameter for the alert to work as desired. The ''Critical status'' term would be used to trigger the alert when a module is in a critical status.
  
* '''Default action''': the action to be executed by default when the alert is triggered. It is optional.
+
* '''Default action''': The action to be executed by default when the alert is triggered. It is optional.
  
* '''Time threshold''': time during which the alert will not be repeated if the incorrect status is maintained continuously. If we leave it at one day (24 hours), it will only send us the alert once every 24 hours even if the module remains longer in the wrong status.
+
* '''Time threshold''': Time during which the alert will not be repeated if the incorrect status is continuously kept. If left at one day (24 hours), it will only send the alert once every 24 hours even if the module remains longer in faulty status.
  
* '''Min. Number of alerts''': The minimum number of times that the condition will have to be given (in this case, that the module is in CRITICAL status) before Pandora FMS executes the actions associated to the alert template. With a value of 0, the first time the module is wrong, it will trigger the alert.
+
* '''Min. Number of alerts''': The minimum number of times that the term has to be met (in this case, that the module is in CRITICAL state) before Pandora FMS executes the actions linked to the alert template. With a value of 0, the first time the module is faulty, the alert will be triggered.
  
* '''Max. Number of alerts''': 1 means that you will only execute the action once. If we have 10 here, it will run the action 10 times. This is a way to limit the number of times an alert can be executed.
+
* '''Max. Number of alerts''': 1 means that the action will be executed only once. If the value is 10, the action will be run 10 times. This is a way to limit the number of times an alert can be executed.
  
In section 3 we have the fields Field1, Field2, Field3, etc. that as we have explained will be used to transfer parameters from the template to the action, and from the action to the command. In addition, in this third section we can enable or disable the ''alert recovery'', which consists of executing another action when the problematic situation returns to normal.
+
In section 3, Field1, Field2, Field3, etc. will be used to transfer parameters from the template to the action, and from the action to the command. In addition, in this third section ''alert recovery'' can be enabled or disabled, which consists of executing another action when the situation goes back to normal.
  
 
<center>
 
<center>
Line 1,065: Line 1,067:
 
<br>
 
<br>
  
== Associating an Alert to a Module ==
+
== Associating an alert to a module ==
  
Now that we're already having all we need, we just have to associate the alert template to the module. To do so, we're required go to the 'Alert' tab within the agent where the module is located:
+
Now just link the alert template to the module. To do so, go to the 'Alert' tab within the agent where the module is located:
  
 
<center>
 
<center>
Line 1,073: Line 1,075:
 
</center>
 
</center>
  
We've created an association between the module named 'cpu_user' and the 'critical condition' alert template. It's going to show the predefined action in this template ('Send email to XXX') by default.
+
Here the module named 'cpu_user' and the 'critical condition' alert template have been linked. It will show the predefined action in this template ('Send email to XXX') by default.
  
== Scaling Alerts ==
+
== Scaling alerts ==
  
Once a complete alert has been associated with a module, it is possible to add additional actions that are executed if the alert is repeated a certain number of times consecutively. That's what we call scaling alerts.
+
Once a complete alert has been associated with a module, it is possible to add additional actions that are executed if the alert is repeated a certain number of times consecutively. That is called scaling alerts.
  
We will only need to add the additional actions and determine between which consecutive repetitions of the alert this action will be executed, as we see in the following capture:
+
Add the additional actions and determine between which consecutive alert repetitions this action will be executed, as shown in the following capture:
  
 
[[File:Alert1.JPG|center]]
 
[[File:Alert1.JPG|center]]
  
When an alert is retrieved, all actions that have been executed up to that point will be re-executed, not just those that correspond to the "Number of alerts match from" current setting.
+
When an alert is recovered, all actions that have been executed up to that point will be re-executed, not just those that correspond to the "Number of alerts match from" current setting.
  
In addition, we can set a second interval, on the basis of which it will not be possible to send an alert more than once within said interval.
+
In addition, a second threshold on the basis of which it will not be possible to send an alert more than once within said interval.
  
  
Line 1,093: Line 1,095:
 
== Stand-By Alerts ==
 
== Stand-By Alerts ==
  
Alerts can be defined as 'active', 'deactivated' or in 'standby'. The difference between 'deactivated' alerts and 'standby' is that 'deactivated' alerts aren't going to be fired at all. They're also not going to be shown in the alert's view. 'Standby' alerts will be shown in the views. They're also going to work - but only on the visualization level. They're going to show you whether they're fired or not, but they're neither going to perform the assigned actions nor generate events.
+
Alerts can be defined as 'active', 'deactivated' or in 'standby'. The difference between 'deactivated' and 'standby' alerts is that 'deactivated' alerts are not fired at all. They will not be shown in the alert's view either. 'Standby' alerts will be shown in alert view. They will also work - but only on the display level. They will show whether they are triggered or not, but they neither perform the assigned actions nor generate events.
 
   
 
   
Standby alerts are useful to see what happens, but they're disabling the notifications and actions.
+
Standby alerts are useful to see what happens, but they have notifications and actions disabled.
  
 
== Cascade Protection ==
 
== Cascade Protection ==
  
The Cascade Protection is a Pandora FMS feature which allows you to avoid a 'flooding' of alerts if a group of agents can't be reached due to a connection failure. These kinds of things tend to happen if an intermediate device such as a router or a switch is down and all the devices which come behind it simply cease to be reachable by Pandora FMS. It's probable the devices are working as they're supposed to, but if Pandora FMS can't reach them by the use of 'ping', it considers them to be 'down'.
+
Cascade Protection is a Pandora FMS feature which allows to avoid alert overload if a group of agents cannot be reached due to a connection failure. These kinds of things tend to happen if an intermediate device such as a router or a switch is down and most of the network managed by Pandora FMS becomes unaccessible. Since network checks would not work in that situation, alerts would start being triggered due to down devices, despite not being true.
  
 
<center>
 
<center>
Line 1,105: Line 1,107:
 
</center>
 
</center>
  
Cascade protection is enabled from the agent configuration. Click on the ''Cascade protection'' option. In order for the agent with cascade protection to work, it must have correctly configured the parent agent, on which it depends. If the parent agent currently has any critical-state module alert triggered, the lower agent with cascade protection will not execute its alerts.
+
Cascade protection is enabled from agent configuration. Click on the ''Cascade protection'' option. In order for the agent to work with cascade protection, the parent agent it depends on must be correctly configured. If the parent agent currently has any critical-state module alert triggered, the lower agent with cascade protection will not execute its alerts.
  
 
This does not apply to module alerts in WARNING or UNKNOWN status.
 
This does not apply to module alerts in WARNING or UNKNOWN status.
Line 1,115: Line 1,117:
 
=== Examples ===
 
=== Examples ===
  
You're going to have the following monitoring types at your disposal:
+
These are the agents at your disposal:
  
* '''Router:''' it  has ICMP check module and SNMP check module, using a standard OID to verify the status of an ATM port. We can also verify latency towards our provider's router.
+
* '''Router:''' ICMP check module and SNMP check module, using a standard OID to verify the status of an ATM port. Latency towards your provider's router can be verified too.
  
* '''Web Server:''' it has several modules executed by the agent: CPU, Memory, Apache process verification. It also has a four-step WEB latency check.
+
* '''Web Server:''' It has several modules executed by the agent: CPU, Memory, Apache process verification. It also has a four-step WEB latency check.
  
* '''Database Server:''' It has several modules executed by the agent: CPU, Memory, MySQL process verification. It also has some additional BBDD integrity checks. It also has verification of remote connectivity to another database, using a specific plugin that logs in, queryes and exits, measuring the total time.
+
* '''Database Server:''' It has several modules executed by the agent: CPU, Memory, MySQL process verification. It has some additional BBDD integrity checks. It can also verify connectivity to another database remotely, using a specific plugin that logs in, queries and exits, measuring the total time.
  
You're also able to define several alerts. We suggest to define them in the following way:
+
In WEB SERVER and DATABASE SERVER, ROUTER is defined as parent. Check the cascade protection check-box in WEBSERVER and DATABASE SERVER.
 +
Now define several simple alerts:
  
 
*'''ROUTER'''
 
*'''ROUTER'''
Line 1,141: Line 1,144:
 
SQL LATENCY / CRITICAL > Action, send MAIL.
 
SQL LATENCY / CRITICAL > Action, send MAIL.
  
If e.g. the router connection is down, Pandora FMS receives information from the Web and Database Servers by using that connection within which you haven't activated the Cascade Protection, you're going to receive six alerts. Just try to imagine the effect if you e.g. have 200 Servers connected by this particular router. That's the reason for why it's sometimes called an 'Alert Storm'. In worst-case scenarios, this problem has the potential to kill your Mail and Monitoring Servers or your cellphone, because they're getting flooded by lots of alerts or SMS messages.
+
If ROUTER connection fails, by means of which Pandora FMS connects with WEB SERVER and DATABASE, and if cascade protection is disabled, you will receive six alerts. Imagine what would happen if you had 200 Servers connected instead of six. That is the reason for why it is sometimes called an 'Alert Storm'. In worst-case scenarios, this problem may kill your Mail and Monitoring Servers or your cellphone, because they get flooded by lots of alerts or SMS messages.
  
However, if you have the Cascade Protection enabled, you're only going to receive one alert, which e.g. says that the ATM interface on your router is down. You're still going to see the Web and Database Servers bearing a red status, but you won't receive tons of alert mails by them anymore.
+
However, if you have the cascade protection enabled, you will only receive one alert, saying that the router ATM interface is down. You will still see the Web and Database Servers in red, but you will not receive the alerts
 +
.
 
=== Service-based cascade protection ===
 
=== Service-based cascade protection ===
  
From version 7.0 OUM727 onwards, we can use the services to avoid multiple source alerts reporting the same incident.
+
From version 7.0 OUM727 onwards, services can be used to avoid multiple source alerts reporting the same incident.
  
 
<br>
 
<br>
If you enable service-based cascade protection, the service elements (agents, modules or other services) will not report problems, but the service itself will alert on behalf of the affected element.
+
If service-based cascade protection is enabled, the service elements (agents, modules or other services) will not report problems, but the service itself will alert on behalf of the affected element.
  
  
Line 1,160: Line 1,164:
  
  
If the element <i>192.168.10.149</i> would go into critical status without affecting the rest of the service, the operator will receive an alert indicating that <i>192.168.10.149</i> is down, but the service <i>Service</i> is working normally.
+
If the element <i>192.168.10.149</i> goes into critical status without affecting the rest of the service, the operator will receive an alert pointing out that <i>192.168.10.149</i> is down, but the service <i>Service</i> works normally.
  
In case that <i>192.168.10.149</i> affected the service's functioning, the operator will receive an alert indicating that the <i>Service</i> is affecting by <i>192.168.10.149</i> being down.
+
In case that <i>192.168.10.149</i> affects the service performance, the operator will receive an alert indicating that the <i>Service</i> is affected by <i>192.168.10.149</i> being down.
  
 
<br><br>
 
<br><br>
In order to receive this information we must edit or create a new alert template, using the _rca_ <i>root cause analysis</i> macro.
+
In order to receive this information, edit or create a new alert template, using the _rca_ <i>root cause analysis</i> macro.
  
 
  _rca_
 
  _rca_
Line 1,183: Line 1,187:
  
  
Though the status of the service would be incorrect.
+
Though the status of the service would be correct.
  
<b>Observation</b>: The chain of events represented in root cause analysis represents the critical elements within a service, allowing us to see what elements are affecting my service.
+
<b>Observation</b>: The chain of events represented in root cause analysis represents the critical elements within a service, allowing to see what elements are affecting the service.
  
 
<br><br>
 
<br><br>
Line 1,191: Line 1,195:
 
=== Cascade protection based on modules ===
 
=== Cascade protection based on modules ===
  
The state of a module of a parent agent can be used to avoid agent alerts in case the module of the parent agent goes to critical state.
+
The state of a module of a parent agent can be used to avoid agent alerts in case the module of the parent agent goes into critical state.
  
 
<center>
 
<center>
Line 1,203: Line 1,207:
 
</center>
 
</center>
  
Safe operation mode can be enabled in an agent's advanced configuration options.
+
Safe operation mode can be enabled in agent advanced configuration options.
  
 
If the selected module's status becomes critical, the rest of the agent's modules are disabled until it goes back to warning or normal again. This allows, for example, to disable remote modules if connectivity is lost.
 
If the selected module's status becomes critical, the rest of the agent's modules are disabled until it goes back to warning or normal again. This allows, for example, to disable remote modules if connectivity is lost.
Line 1,209: Line 1,213:
 
== List of special days ==
 
== List of special days ==
  
Pandora FMS allows to define a list of special days for holidays and vacations that can be used in the template configuration so that during those days alerts are not triggered.
+
Pandora FMS allows to define a list of special days for holidays and vacations that can be used in the template configuration, so that during those days alerts are not triggered.
  
 
=== Creating a Special Day ===
 
=== Creating a Special Day ===
  
New special days are created in the "Alerts" -> "List of special days" section, by clicking on the "More" or "Create"button underneath the calendar.
+
New special days are created in the "Alerts" -> "List of special days" section, by clicking on "More" or "Create" underneath the calendar.
  
 
<br>
 
<br>
Line 1,223: Line 1,227:
 
<br>
 
<br>
  
Once one of them has been clicked, a screen like this one will appear:
+
Once one of them has been clicked, a window like this one will appear:
  
 
<br>
 
<br>
Line 1,233: Line 1,237:
 
<br>
 
<br>
  
This is an explanation for the options you're going to encounter here:
+
This is an explanation of the given options:
  
* '''Date:''' The special day's date. The data format is 'YYYY-MM-DD'. If you want to define the same day in every year, you may use wildcards like '*' for the 'YYYY' entry.
+
* '''Date:''' The special day's date. The data format is 'YYYY-MM-DD'. If you want to define the same day every year, you may use '*' for the 'YYYY' entry.
*'''Group''': Here you select the group to which the special day applies.
+
*'''Group''': Select here the group to which the special day applies.
* '''Same Day of the Week:''' Please select a day. The above date is treated the same as the selected day.
+
* '''Same Day of the Week:''' Select a day. The date in field "Date" is dealt with the same as that weekday.
* '''Description:''' The Special Day's description.
+
* '''Description:''' Special Day's description.
  
Let's assume for a moment that May 3, 2012 would be a holiday. If you define the date of '2012-05-03' as a 'Sunday', that day is treated in the same way as a Sunday would. Bearing in mind that the templates have configuration options and will act in one way or another depending on the day of the week, this will help us make them behave the way we want.
+
Suppose that May 3, 2020 is holiday. If you define the "2012-05-03" as a "Sunday", that day becomes the same as a Sunday. Bearing in mind that templates have configuration options and will work in one way or another depending on the day of the week, this will help you make them work the way you want.
  
 
'''Practical example'''
 
'''Practical example'''
  
We have a template that alerts us from Monday to Friday from 8 am to 6 pm, on Saturdays and Sundays this template will not cause any alert to go off. The 15th of August is Wednesday and it is a public holiday, so we will create a special day and in the field'' Same day of the week'' we will choose Saturday or Sunday, so we will not be alerted of any problem on August 15th as it will be treated as a day (Saturday or Sunday) in which the template is not configured to trigger alerts.
+
There is a template that alerts you from Monday to Friday from 8 am to 6 pm but on Saturdays and Sundays this template will not cause any alert to go off. The 15th August is Wednesday and it is holiday, so a special day is created and in the field ''Same day of the week'' Saturday or Sunday is chosen, so alerts of any kind will not be received on August 15th as it will be as if it was Saturday or Sunday, when the template is configured to not trigger any alerts.
  
Once the fields have been selected, we click on "Create".
+
Once the fields have been selected, click on "Create".
  
=== Creating special days in bluk from an .ics file ===
+
=== Creating special days in bulk from an .ics file ===
  
 
Special days can also be created using an iCalendar file (. ics). These can be imported at the top of the window.
 
Special days can also be created using an iCalendar file (. ics). These can be imported at the top of the window.
Line 1,261: Line 1,265:
 
<br>
 
<br>
  
=== Editing a Special Day ===
+
=== Editing a special day ===
  
You may edit the Special Days created within the 'List of Special Days' option by clicking on 'Alerts'.
+
You may edit special days created within the "List of Special Days" option by clicking on "Alerts".
  
 
<br>
 
<br>
Line 1,283: Line 1,287:
 
<br>
 
<br>
  
Once your changes are completed, please click on the 'Update' button.
+
Once the changes are completed, click on the 'Update' button.
  
 
=== Deleting a Special Day ===
 
=== Deleting a Special Day ===
  
In order to delete a Special Day, please click on the gray trash icon is located next to the Special Day wrench icon.
+
In order to delete a Special Day, click on the gray trash icon located next to the Special Day wrench icon.
  
 
<br>
 
<br>
Line 1,301: Line 1,305:
 
=== Sending SMS Alerts ===
 
=== Sending SMS Alerts ===
  
In this example, we're going to see something we see very often: To send an SMS either if something happens or it's about to happen.
+
This example exemplifies something quite common: how to send an SMS either if something happens or it is about to happen.
  
To accomplish this, we're going to use a script you may download from our [http://pandorafms.com/Library/Library/en '''Pandora FMS Module Library.'''] This script uses a commercial Perl API to send the SMS by using a commercial HTTP gateway (for which you're required to create an account and to pay a small fee). This is very easy to do, because once you've set up the account and configured the script, it's ready to be put to use. You're just required to enter your user name and password to use it.
+
You must have a tool that allows sending SMS installed, such as smstools.  
 
+
Suppose you have already configured your SMS account. Enter the following command:
If you've already configured your SMS account and installed the script on the Pandora FMS Server, please enter the following command:
 
  
 
  > sendsms  
 
  > sendsms  
  
  
  You're required to enter three parameters: <source>, <destination> and 'complete message'.
+
  Enter three parameters: <source>, <destination> and 'complete message'.
  Please keep in mind to encapsulate the message in single quotes (') and to enter the  
+
  Do not forget to enclose the message in single quotes (') and to enter the  
 
  destination number by using the international code format  
 
  destination number by using the international code format  
 
  (e.g. '''34'''6276223 for Spanish phone numbers).
 
  (e.g. '''34'''6276223 for Spanish phone numbers).
 
   
 
   
  
After we've made sure the 'sendsms' command is ready to be used, the first thing we have to do is to define the '''alert command'''. We're going to define the command within the Pandora FMS Administration Interface:
+
Next, use the "alert command" in the Pandora FMS management interface:
  
 
<br><br>
 
<br><br>
Line 1,324: Line 1,327:
 
<br><br>
 
<br><br>
  
Within this command, we're going to define "346666666666" as the source of the message. We could use an alphanumerical word here, but we're not going to do that, because some mobile phone providers can't handle alphanumeric IDs very well. 'Field 1' and 'Field 2' are going to be used to define the command's behavior. On the photo of the mobile phone which receives the SMS, we've used a string identifier named 'Aeryn'. 'Field 1' is the field in which the destination phone is defined, while 'Field 2' is going to be the text, defined within the alert's action.
+
Within this command, send "346666666666" as the source of the message. An alphanumerical word can be used here, but some mobile phone providers cannot handle alphanumeric IDs very well. 'Field 1' and 'Field 2' will be used to define the command's performance. On the photo of the mobile phone that receives the SMS, a string identifier named 'Aeryn' is used. 'Field 1' is the target phone, while 'Field 2' is the text, defined within the alert's action.
  
Now we're going to define the alert's action. It going to execute the predefined command and replaces Field 1 and Field 2 by custom values. In this specific case, the template's alert doesn't return any data within the SMS. All information is defined in the Alert's Action.
+
Now define the alert's action. It will execute the predefined command and replace Field 1 and Field 2 by custom values. In this specific case, the template's alert does not return any data in the SMS. All information is defined in Alert Action.
  
 
<br><br>
 
<br><br>
Line 1,334: Line 1,337:
 
<br><br>
 
<br><br>
  
Field 1 would be our phone number. In Field2 is the text message. We use a few macros here, which will be replaced over time, when the alert occurs.
+
Field 1 is the phone number. Field2 contains the text message. A few macros are used here, which will be replaced over time, when the alert goes off.
  
Final step: we will create an Alert Template (skip this if you already have a valid Alert Template). We want to create a very simple Alert Template, just to "go off" when a module is CRITICAL. This alert will be fired once a day at the most, but if it recovers, it will be fired again each time it recovers and fired again.
+
Final step: create an Alert Template (skip this if you already have a valid Alert Template). This is a very simple Alert Template, just to "go off" when a module goes into CRITICAL. This alert will be triggered once a day at the most, but if it recovers, it will be triggered again each time it recovers and is triggered again.
  
  
Line 1,351: Line 1,354:
 
<br><br>
 
<br><br>
  
Now, please assign a module along with an alert template and an alert action:
+
Now, assign a module along with an alert template and an alert action:
  
 
<center>
 
<center>
Line 1,357: Line 1,360:
 
</center>
 
</center>
  
To get this alert fired, the module is required to be in 'critical' state. On the picture below, I'm going to review the module's configuration to see if their 'critical' thresholds are properly defined. If they weren't, the alert is never going to be fired because it's waiting for the moment to reach the 'critical' status. In my case, I've set it to the value of '20'. If a low value gets received, the module will go to a 'critical' state and the alert is going to be fired.
+
To have this alert field, the module must be in CRITICAL state. On the picture below, the module's configuration must be reviewed to see if its 'critical' thresholds are properly defined. If it is not, the alert will never be triggered because it is waiting for the moment to reach the 'critical' status. In this case, it is set to '20'. If a lower value is received, the module will go into CRITICAL state and the alert will be triggered.
  
 
<br><br>
 
<br><br>
Line 1,365: Line 1,368:
 
<br><br>
 
<br><br>
  
To have this alert field, the module must be in CRITICAL. In the next screenshot, we will check the module configuration to see if its CRITICAL threshold is defined. If it is not, the alert will never go off because it is waiting to have a CRITICAL status. In this case, we've set it at 20. When a lower value is received, the module will switch to CRITICAL and the alert will be triggered.
+
Finally, the alert can be forced to execute it and test it. To force the alert, go to agent alert view and click on the green circle icon.
  
 
<br><br>
 
<br><br>
Line 1,381: Line 1,384:
 
<br><br>
 
<br><br>
  
An SMS may appear on my mobile phone, as shown in the following picture. I obtained "N/A" data because, when you force the alert, no real data is received from the module.
+
An SMS may appear on your mobile phone, as shown in the following picture. The obtained data is "N/A" because, when forcing the alert, no real data is received from the module.
  
 
<br><br>
 
<br><br>
Line 1,389: Line 1,392:
 
<br><br>
 
<br><br>
  
=== Using Alert Commands different from Email ===
+
=== Using alert commands different from email ===
  
The internal email is defined as a non-configurable command to Pandora FMS, because 'Field 1', 'Field 2' and 'Field 3' are fields which are clearly intended to be used for 'addressee', 'subject' and 'message text' - but what am I supposed to do if I intend to execute a user-defined action ?
+
The email is hosted as command in Pandora FMS, because 'Field 1', 'Field 2' and 'Field 3' are fields clearly intended to be used for 'addressee', 'subject' and 'message text' - but what if you intend to execute a user-defined action?
  
We're now going to define a new command - something completely defined by us. Let's suppose that we intend to generate a log file entry for each alert we encounter. The format of this log file entry should be something like this:
+
This is how a new command is custom defined. Suppose you intend to generate a log file entry for each alert alert find. The format of the log file should be something like this:
  
 
  DATE_HOUR - NAME_AGENT -NAME_MODULE -VALUE- PROBLEM DESCRIPTION
 
  DATE_HOUR - NAME_AGENT -NAME_MODULE -VALUE- PROBLEM DESCRIPTION
 
   
 
   
VALUE is going to be the module's value in this specific moment. There will be several log file entries, depending on the action which calls the command. The alert is going to define the description and the file to which the events are going to be added.
+
VALUE is the module's value at that specific moment. There will be several log file entries, depending on the action that calls the command. The alert will define the description and the file to which the events are added.
  
  
To accomplish this, we're required to create a command like this first:
+
To accomplish this, first create a command like this one:
  
 
<center>
 
<center>
Line 1,408: Line 1,411:
 
</center>
 
</center>
  
Subsequently, we're defining an action:
+
Then, define an action:
  
 
<center>
 
<center>
Line 1,417: Line 1,420:
  
  
If we take a look into the created log file, we're going to see the following:
+
If you take a look into the created log file, you will see the following:
  
 
  2010-05-25 18:17:10 - farscape - cpu_user - 23.00 - Custom log alert #1
 
  2010-05-25 18:17:10 - farscape - cpu_user - 23.00 - Custom log alert #1
  
The alert was fired at '18:17:10' within the agent named 'Farscape', in the module named 'cpu_sys' containing the data of '23.00' and the description we've entered in the moment we've defined the action.
+
The alert was triggered at '18:17:10' within the agent named 'Farscape', in the module named 'cpu_sys' containing the data '23.00' and the description entered when the action was defined.
  
As for the command execution, the field order and the other things we're likely not to understand very well (e.g. how the command is executed), the easiest way to learn is to activate the Pandora Server's debug traces within the server's configuration file located at '/etc/pandora/pandora_server.conf'. Please restart the server by entering '/etc/init.d/pandora_server restart', look for the file named '/var/log/pandora/pandora_server.log' and look for the exact line which contains the execution of the user-defined alert command to see how the Pandora FMS Server is firing it in detail.
+
As for command execution, the field order and the other things might make you not to understand very well how the command is eventually executed, the easiest way is activating the Pandora FMS Server's debug traces within the server's configuration file located at '/etc/pandora/pandora_server.conf'. Restart the server by entering '/etc/init.d/pandora_server restart', look for the file named '/var/log/pandora/pandora_server.log' and look for the exact line which contains the execution of the user-defined alert command to see how Pandora FMS Server triggers it in detail.
  
==== Complete Example of an Alert by Substitution Macros ====
+
==== Complete example of an alert with substitution macros ====
  
Let's suppose for a moment you intend to generate a log entry in which each line is supposed to show its data the following format:
+
Suppose for a moment you intend to generate a log entry where each line is supposed to show its data in the following format:
  
 
2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status
 
2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status
  
'''Command Configuration:'''
+
'''Command configuration:'''
  
 
  echo _timestamp_ pandora _field2_ >> _field1_
 
  echo _timestamp_ pandora _field2_ >> _field1_
  
'''Action Configuration:'''
+
'''Action configuration:'''
  
 
  Field1 = /var/log/pandora/pandora_alert.log
 
  Field1 = /var/log/pandora/pandora_alert.log
Line 1,441: Line 1,444:
 
  Field3 = <left blank>
 
  Field3 = <left blank>
  
'''Template Configuration'''
+
'''Template configuration'''
  
 
  Field1 = <left blank>
 
  Field1 = <left blank>
Line 1,452: Line 1,455:
 
  Field3 = <left blank>
 
  Field3 = <left blank>
  
If you execute an alert, the following line is going to be written into the log:
+
When executing an alert, the following line is entered in the log:
  
 
  2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status
 
  2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status
  
  
The following line is going to be written into the log if the alert is recovered:
+
And the following line to recover the alert:
  
 
  2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status
 
  2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status
Line 1,463: Line 1,466:
 
== Custom module alert macros ==
 
== Custom module alert macros ==
  
Any number of custom-made Module Macros may be added to an agent module.  
+
Any amount of macros may be added to an agent module.  
  
 
<center><br><br>
 
<center><br><br>
Line 1,471: Line 1,474:
 
These macros have the following characteristics:  
 
These macros have the following characteristics:  
 
<ul>
 
<ul>
<li>Defined in the module configuration section</li>
+
<li>They are defined in the module configuration section.</li>
<li>Store the information in database</li>
+
<li>They store information in the database.</li>
<li>Can have any name for example:  _pepito_ </li>
+
<li>They may have any name, for example:  _joey_ </li>
<li>Doesn't affect the agent configuration files(pandora_agent.conf)</li>
+
<li>They do not affect local configuration. files(pandora_agent.conf).</li>
<li>Can only be used in the alert system.</li>
+
<li>They are exclusively used in alerts.</li>
<li>Can't be added to the local components.</li>
+
<li>They cannot be defined at local component level.</li>
<li>Can be added to modules in the policies.</li>
+
<li>They can be defined in policies.</li>
 
</ul>
 
</ul>
  
These specific macros can be added by just expanding the module macros section.  
+
These specific macros can be added by just extending the module macros section.  
  
 
<center><br><br>
 
<center><br><br>
Line 1,486: Line 1,489:
 
</center><br><br>
 
</center><br><br>
  
The macro values can be used as part of the fields in alert definitions.
+
Macro values can be used as part of the fields in alert definition.
 
For Example:
 
For Example:
To include a macro to the mail to xxx action and send an e-mail, when the alert fires, the field with the e-mail body must be configured in the following fashion:  
+
To include a macro to the mail sending action, the field with the e-mail body must be configured in the following fashion:  
  
 
<center><br><br>
 
<center><br><br>
Line 1,494: Line 1,497:
 
</center><br><br>
 
</center><br><br>
  
If a module is added without any defined custom macro then no information would be displayed for the value of the macro in the body of the e-mail when an alert fires.
+
If a module is added to this alert without any defined custom macro, then no information will be displayed in the macro value section.
  
 
== Event Alerts and Event Correlation ==
 
== Event Alerts and Event Correlation ==
  
There is a [[Pandora:Documentation_en:Events#Event_Alerts_and_Event_Correlation|Specific chapter ]] about this topic.
+
There is a [https://pandorafms.com/docs/index.php?title=Pandora:Documentation_en:Alerts#Alert_correlation:_event_and_log_alerts specific chapter] about this topic.
  
 
==Quick guide to email configuration for alerts in Pandora FMS==
 
==Quick guide to email configuration for alerts in Pandora FMS==
Line 1,504: Line 1,507:
 
=== Email configuration with a Gmail account ===
 
=== Email configuration with a Gmail account ===
  
In order to configure Pandora FMS to send alerts via Gmail, Pandora and Postfix must be configured this way:
+
In order for Pandora FMS server to send alerts via Gmail, Pandora FMS and Postfix must be configured this way:
 
   
 
   
==== Pandora's Configuration ====
+
==== Pandora FMS setup ====
  
In order to properly configure your email with a Gmail account, all the fields must have the following comments in the Pandora FMS server configuration file (/etc/pandora/pandora_server.conf) except the mta_address field, which will be configured with the IP server or localhost (where the postfixserver is installed).
+
In order to properly configure your email with a Gmail account, all the fields must have the following comments in the Pandora FMS server configuration file (/etc/pandora/pandora_server.conf) except for the mta_address field, which will be configured with the IP server or localhost where the postfixserver is installed.
  
If Postfix is installed in the same server than Pandora FMS, the configuration in the pandora_server.conf would be like this:
+
If Postfix is installed in the same server as Pandora FMS, the configuration in the pandora_server.conf would be like this:
  
 
  mta_address localhost  
 
  mta_address localhost  
Line 1,520: Line 1,523:
  
  
Now, I would like to show you briefly how to configure an alert in the Pandora FMS console.  
+
The following section shows briefly how to configure an alert in Pandora FMS console.  
  
 
===== Action Setup =====
 
===== Action Setup =====
  
To set the mail recipient, use the mail action to XXX so you can add an email recipient to which all the mail alerts will be sent.
+
To set the mail recipient, use the mail action to XXX so you can add an email recipient to which all mail alerts will be sent.
  
 
<center>
 
<center>
Line 1,532: Line 1,535:
 
===== Alert setup =====
 
===== Alert setup =====
  
In this case, the module configuration has been generated in the module configuration> Alerts, a new alert with the module as the one that you can see in the screenshot below.
+
In this case, a new alert with the module seen on the screenshot has been generated in ''module configuration'' > ''Alerts''.
  
 
<center>
 
<center>
Line 1,538: Line 1,541:
 
</center>
 
</center>
  
Once the alert is fired, you can see how the alert reaches the e-mail picked in the action:  
+
Once the alert is triggered, you can see how the alert reaches the e-mail chosen in the action:  
  
 
<center>
 
<center>
Line 1,545: Line 1,548:
 
</center>
 
</center>
  
==== Postfix Setup ====
+
==== Postfix Installation====
 +
The following packages must be installed in Pandora FMS server for postfix server to work properly together with a GMAIL account.
 +
 
 +
yum install postfix mailx cyrus-sasl-plain cyrus-sasl cyrus-sasl-lib cyrus-sasl-md5 cyrus-sasl-scram cyrus-sasl-gssapi
 +
 
 +
==== Postfix Configuration ====
 +
 
 +
Once Postfix has been installed within the server and everything works properly, except for sending emails through Gmail, follow these steps:
  
Assuming you already installed Postfix and everything works fine except sending to gmail smtps, here are the steps to follow:
+
1-- Check that the "less secure pass" option is enabled in your Gmail account. It can be enabled through this link.(https://myaccount.google.com/lesssecureapps)
  
1-- Edit the /etc/postfix/main.cf configuration file and add the following lines at the end of the file:
+
2-- Edit the /etc/postfix/main.cf file and add the following lines at the end of said file:
  
 +
myhostname = <hostname> #Add here server hostname
 
  relayhost = [smtp.gmail.com]:587
 
  relayhost = [smtp.gmail.com]:587
 
  smtp_sasl_auth_enable = yes
 
  smtp_sasl_auth_enable = yes
  smtp_sasl_password_maps = hash:/etc/postfix/sasl/passwd
+
  smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
 +
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
 
  smtp_sasl_security_options = noanonymous
 
  smtp_sasl_security_options = noanonymous
 
  smtp_use_tls = yes
 
  smtp_use_tls = yes
  smtp_tls_CAfile = /etc/postfix/cacert.pem
+
  smtp_tls_CAfile = /etc/pki/tls/cert.pem
 +
smtp_tls_security_level = encrypt
 +
 +
 
 +
3-- Create the /etc/postfix/sasl_passwd file with its corresponding Gmail address and password.
 +
 
 +
nano /etc/postfix/sasl_passwd
 +
 
 +
Add the following line with the Gmail address and password to the file:
 +
 
 +
[smtp.gmail.com]:587 [email protected]:PASSWORD
 +
 
 +
Secure it accordingly:
 +
 
 +
chmod 600 /etc/postfix/sasl_passwd
 +
chown root:root /etc/postfix/sasl_passwd
 +
 
 +
4-- Create the /etc/postfix/tls_policy file with the following information:
 +
 
 +
nano /etc/postfix/tls_policy
 +
 
 +
[smtp.gmail.com]:587 encrypt
 +
 
 +
Secure it accordingly:
 +
 
 +
chmod 600 /etc/postfix/tls_policy
 +
chown root:root /etc/postfix/tls_policy
 +
 
 +
 
 +
5-- Turn /etc/postfix/sasl_passwd and /etc/postfix/tls_policy into a hash-type indexed file through this command:
  
2-- Create the /etc/postfix/sasl/passwd file with your gmail address and password (you must create the “sasl” directory and then create the passwd file in there).
+
postmap /etc/postfix/sasl_passwd && postmap /etc/postfix/tls_policy
  
To create the “sasl” directory:
+
It will create the /etc/postfix/sasl_passwd.db and /etc/postfix/tls_policy.db file.
  
mkdir /etc/postfix/sasl
 
  
To create the passwd file:
+
6-- Finally, restart postfix to apply the changes as it follows:
  
  nano /etc/postfix/sasl/passwd
+
  /etc/init.d/postfix restart
  
And paste the line below with your own gmail address and password inserted:
+
7-- The performance can be checked by logging in two consoles. Execute the following command to monitor mail performance:
  
  [smtp.gmail.com]:587 [email protected].com:PASSWORD
+
  tail -f /var/log/maillog
 +
 
 +
The other one will send an email:
 +
 
 +
echo "Mail test" | mail [email protected]
 +
 
 +
If the preceding steps have been carried out correctly, the other console should show something like this:
 +
 
 +
Dec 18 18:33:40 OKComputer postfix/pickup[10945]: 75D4A243BD: uid=0 from=
 +
Dec 18 18:33:40 OKComputer postfix/cleanup[10951]: 75D4A243BD: message-id=
 +
Dec 18 18:33:40 OKComputer postfix/qmgr[10946]: 75D4A243BD: from=, size=403, nrcpt=1 (queue active)
 +
Dec 18 18:33:44 OKComputer postfix/smtp[10953]: 75D4A243BD: [email protected], relay=smtp.gmail.com[74.125.93.109]:587, delay=3.7,  delays=0.15/0.14/1.8/1.6, dsn=2.0.0, status=sent (250 2.0.0 OK 1324249500 eb5sm36008464qab.10)
 +
Dec 18 18:33:44 OKComputer postfix/qmgr[10946]: 75D4A243BD: removed
 +
 
 +
If this is the result, Pandora FMS will point to the Postfix server to send emails and they will be successfully sent.
 +
 
 +
== Alert correlation: event and log alerts ==
 +
<br>
 +
From Pandora FMS version 741, alerts can be build based on received events or logs collected by means of the log collection system. Simple or complex alerts may be created based on a set of terms with logic relations. This feature replaces the previous one of event alerts.
 +
 
 +
Pandora FMS allows working from a much more flexible perspective, since alerts are not generated according to the status of a specific module, but on an event -which may have been generated by several different modules of different agents.
 +
 
 +
Event alerts are based on filtering rules using logical operators (and, or, xor, nand, nor, nxor) to look for events matching the configured filtering rules and if matches are found, the alert will be triggered.
 +
 
 +
They also use templates to define some parameters, such as the days on which the alert will work. However, in this case the templates do not determine when the event alert is triggered, but rather it is through the filtering rules that the events that match will be searched and the corresponding alerts will be triggered.
 +
 
 +
From version NG741, a new rule editor that allows building alerts visually can be used. The old event alert editor will still be available for some time.
 +
<br>
 +
<br>
 +
{{Tip|Given the high number of events Pandora FMS Database is able to store, the server works on an maximal event window which is defined in the <b>pandora_server.conf</b> configuration file by a parameter named '<b>event_window</b>'. Events generated outside the specified time range will not be processed by the server. So it does not make any sense to specify in a rule a time range wider than the one configured within the Server.}}
 +
<br>
 +
In a similar way, there is another server parameter called log_window that works in a similar fashion as the previously described one.
 +
<br>
 +
<br>
 +
{{Warning|In order for event correlation alerts to work, it is necessary to activate the event correlation server with the parameter ''eventserver 1'' in the Pandora FMS server configuration file.}}
 +
<br>
 +
=== Correlation alert creation ===
 +
 
 +
==== Correlation alerts / templates ====
 +
 
 +
To configure a correlated alert, access the 'Alert correlation' section through the menu.
 +
 
 +
<center>
 +
[[Image:alertaslog2.png]]
 +
</center>
 +
<br>
 +
Create a rule and define its performance (similar to Alert Templates):
 +
 
 +
<center>
 +
[[Image:alertaslog12.PNG]]
 +
</center>
 +
<br>
 +
 
 +
<center>
 +
[[Image:alertaslog13.PNG]]
 +
</center>
 +
<br>
 +
 
 +
Template configuration parameters for correlation alerts are similar to those of a module alert. There are only two event alert specific parameters:
 +
 
 +
*<b>Rule evaluation mode</b>: It provides two options, <b>Pass</b> and <b>Drop</b>. "Pass" means that if an event matches an alert, the rest of alerts are still evaluated. "Drop" means that if an event matches an alert, the alerts left will no longer be evaluated.
 +
*<b>Group by</b>: It allows to group rules by agent, module, alert or group. E.g. If a rule is configured to go off when two critical events are received and it is grouped by agent, two critical events are required to come from the same agent. This can be disabled.
 +
 
 +
In case of alerts containing log rules, it will only affect grouping by agent. If a different grouping is chosen, '''entry log-based alerts will never be met.'''
 +
 
 +
Each rule is configured to go off due to a specific type of event or log match. When the logic ecuation defined by rules or their operators is met, the alert is triggered.
  
Protect the password file accordingly:
 
  
chmod 600 /etc/postfix/sasl/passwd
+
==== Rules within a correlation alert ====
  
This will allow only root users to access the file.
+
<center>
 +
[[Image:alertaslog14.PNG]]
 +
</center>
 +
<br>
  
3-- Transform /etc/postfix/sasl/passwd into a hash type indexed file. This will create a lookup table via postmap:
+
To define these rules, drag the elements from the left side to the "drop area" at the right to create your rule.  
  
postmap /etc/postfix/sasl/passwd
+
<b>'Configuration available items</b>:
  
Issuing this command will create a passwd.db file in the /etc/postfix/sasl/ directory.
+
<center>
 +
[[Image:alertaslog3.png]]
 +
</center>
 +
<br>
  
4-- Now to install the Gmail and Equifax certificates. Pre-built Pandora FMS ISO and VMware virtual image do not have these certificates by default. If you have the certificates installed, then you can skip this part.
+
These elements will be enabled to guide the user to meet the rule's grammar. Hereon the grammar to be used is further explained:
  
To install the Gmail certificate, follow these steps:
+
S -> R | R + NEXUS +R
 +
R -> FIELD + OPERATOR + C | FIELD + OPERATOR + C + MODIFIER
 +
C -> VARIABLE
  
Google’s SSL cert is signed by Equifax – so first we need to fetch that.
+
Where <b>S</b> is the set of rules defined for the correlated alert.
Move to “tls” directory:
 
cd /etc/pki/tls/
 
  
We need to download Equifax certificate.
+
Drag the element to the rule definition area:
sudo wget -O Equifax_Secure_Certificate_Authority.pem https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer
 
  
Now let’s add the permissions to the downloaded file:
+
<center>
chmod 644 Equifax_Secure_Certificate_Authority.pem
+
[[Image:alertaslog4.png]]
 +
</center>
 +
<br>
  
We also need to request the signature for the certificate:
+
To clean up and undo all changes, the '<b>Cleanup</b>' and '<b>Reset</b>' buttons are available.  
openssl x509 -in Equifax_Secure_Certificate_Authority.pem -fingerprint -subject -issuer -serial -hash -noout
 
  
Next we need need to install the GMail cert. The first thing we need is the c_rehash util, so lets install its package:
+
{{Warning|No changes will be saved until you click on the '<b>Next</b>' button.}}
yum install openssl-perl
 
  
If you receive errors attempting to install openssl-perl, I took the following additional steps to resolve this problem:
+
<b>REMEMBER</b>: Blocks are simultaneous when meeting a term.
  sudo su
 
  nano /etc/yum.repos.d/extra_repos.repo
 
  In the #percona repository I changed the baseurl line to:  http://repo.percona.com/centos/6/os/x86_64/
 
  ^O to write the edited file
 
  ^x to exit
 
  After returning to root terminal, enter "yum install openssl-perl" and accept the defaults
 
  
Next we need to actually acquire the certificate for GMail. So use openssl to do this:
+
  (A and B)
openssl s_client -connect pop.gmail.com:995 -showcerts
 
  
The output should contain the required lines for the certificate and we need to copy them to /etc/pki/tls/gmail.pem file. For this, create the file:
+
It forces the analyzed item (whether event or log) to meet A and B simultaneously.
nano /etc/pki/tls/gmail.pem
 
  
and paste these lines into the gmail.pem file:
+
A and B
-----BEGIN CERTIFICATE-----
 
MIIDWjCCAsOgAwIBAgIKYgy3qQADAAAJ5zANBgkqhkiG9w0BAQUFADBGMQswCQYD
 
VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu
 
dGVybmV0IEF1dGhvcml0eTAeFw0wOTA3MTcxNzE2NTVaFw0xMDA3MTcxNzI2NTVa
 
MGcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N
 
b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRYwFAYDVQQDEw1wb3Au
 
Z21haWwuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDTHqjJfnRXdpmZ
 
4iP/WNCpvzX4N97bEZ3rvS4aDYey/DJetKZqp9DK1Ie4/C5j8M1aakwiTNA/eHS/
 
wNWVgQx8+HxproYKUeeYj3shYKEkHGfrRYBcyCxc7Gd6NSGaaYru3Z7nJ+STIPUJ
 
E1N35JAwcjjdITVI2O4LckAL4b7GkwIDAQABo4IBLDCCASgwHQYDVR0OBBYEFIln
 
0T5I8Mw6cqhtUS4pyMGYRxOTMB8GA1UdIwQYMBaAFL/AMOv1QxE+Z7qekfv8atrj
 
axIkMFsGA1UdHwRUMFIwUKBOoEyGSmh0dHA6Ly93d3cuZ3N0YXRpYy5jb20vR29v
 
Z2xlSW50ZXJuZXRBdXRob3JpdHkvR29vZ2xlSW50ZXJuZXRBdXRob3JpdHkuY3Js
 
MGYGCCsGAQUFBwEBBFowWDBWBggrBgEFBQcwAoZKaHR0cDovL3d3dy5nc3RhdGlj
 
LmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS9Hb29nbGVJbnRlcm5ldEF1dGhv
 
cml0eS5jcnQwIQYJKwYBBAGCNxQCBBQeEgBXAGUAYgBTAGUAcgB2AGUAcjANBgkq
 
hkiG9w0BAQUFAAOBgQCEGIebkDpktdjtzMiTTmEiN7e4vc73hEI4K0jYKyY0Wn5N
 
dc44AXTfIWOzsikwb886PCUSevGs9rcw2/kaHdPaBSuGrzSCf8ODQqTC3odry3lo
 
PtZGr6nf/81F5UW71+bE1iWOQlJ5/olWOr2SlqYla1iOmosEctD/GyoFnDh+BA==
 
-----END CERTIFICATE-----
 
  
Next we need to run the c_rehash util:
+
It forces both rules (A) and (B) to be met in the evaluation window. This means that during the last couple of seconds (defined by '<b>log_window</b>' and '<b>event_window</b>' parameters), entries that meet both rules must exist.  
cd /etc/pki/tls
 
and
 
c_rehash .
 
  
Finally, we can test it with:
+
==== Multiple correlated alerts ====
openssl s_client -connect pop.gmail.com:995 -CApath /etc/pki/tls
 
  
The important point is to Verify the return code:0 (ok), and the final OK Gpop ready.  If you get them then you can connect to GMail.
+
When you have multiple alerts, these have a specific evaluation order. They are always orderly evaluated, starting by the first of the list.
  
Now let’s create the Equifax_secure_CA.pem file:
+
If the '<b>PASS</b>' rule evaluation mode is configured, if a correlated alert is run, the next ones will also be evaluated. Tha is the "normal" mode.
nano /etc/ssl/certs/Equifax_Secure_CA.pem
 
  
Paste the following certification lines:
+
If you configure the '<b>DROP</b>' rule evaluation mode, if a correlated alrt configured through this mode is run, the evaluation of the next rules will come to a halt. This feature makes cascade alert protection possible.
-----BEGIN CERTIFICATE-----
 
MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJV
 
UzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2Vy
 
dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1
 
MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx
 
dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B
 
AQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPRfM6f
 
BeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+A
 
cJkVV5MW8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kC
 
AwEAAaOCAQkwggEFMHAGA1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQ
 
MA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlm
 
aWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoGA1UdEAQTMBGBDzIwMTgw
 
ODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvSspXXR9gj
 
IBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQF
 
MAMBAf8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUA
 
A4GBAFjOKer89961zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y
 
7qj/WsjTVbJmcVfewCHrPSqnI0kBBIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh
 
1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee9570+sB3c4
 
-----END CERTIFICATE-----
 
  
Save and exit.
 
  
In order to add the Equifax certificating authority (which certifies emails from Gmail) into the certificate file that postfix uses, run the following command in a root console:
+
For example:  
cat /etc/ssl/certs/Equifax_Secure_CA.pem > /etc/postfix/cacert.pem
 
  
5 - Finally, restart postfix to apply the changes:
+
*Generic alert.
 +
*Specific alert.
  
/etc/init.d/postfix restart
+
If the general alert fails, there is no need to evaluate the specific one. Configure both of them with <b>DROP</b>.  
  
6 - You can verify the performance by opening two consoles. You should execute the following command in one console to monitor the behavior of the mail:
+
Click on the order icon and drag to change rule evaluation order.
  
tail -f /var/log/mail.log
 
  
You can send an email through the other one:
+
<center>
 +
[[Image:alertaslog9.png]]
 +
</center>
 +
<br>
  
echo "Hello" | mail [email protected].com
+
The rest of correlation rules (action fields and action application) work similarly to the rest of Pandora FMS alerts and do not require additional explanation.  
  
You also may need to change the settings under your gmail account (under the “devices” tab) to receive the e-mail. You can also turn on access for less secure apps and read more about it from here:
+
==== Event Alert macros ====
https://www.google.com/settings/security/lesssecureapps
 
  
If you have done everything right, something like that should appear in the other console:
+
The macros that can be used in the event alerts are:
  
Dec 18 18:33:40 OKComputer postfix/pickup[10945]: 75D4A243BD: uid=0 from=
 
Dec 18 18:33:40 OKComputer postfix/cleanup[10951]: 75D4A243BD: message-id=
 
Dec 18 18:33:40 OKComputer postfix/qmgr[10946]: 75D4A243BD: from=, size=403, nrcpt=1 (queue active)
 
Dec 18 18:33:44 OKComputer postfix/smtp[10953]: 75D4A243BD: [email protected], relay=smtp.gmail.com[74.125.93.109]:587, delay=3.7,  delays=0.15/0.14/1.8/1.6, dsn=2.0.0, status=sent (250 2.0.0 OK 1324249500 eb5sm36008464qab.10)
 
Dec 18 18:33:44 OKComputer postfix/qmgr[10946]: 75D4A243BD: removed
 
  
If the result is similar, Pandora is properly configured and linked to the Postfix server, so it will send mails as expected.
+
*<b>_address_</b>: Address of the agent that triggered the alert.
 +
*<b>_address_n_</b>: Address of the agent that corresponds to the position indicated in "n" e.g: address_1_ , address_2_
 +
*<b>_agent_</b>: Alias of the agent that triggered the alert. If there is no alias assigned, the name of the agent will be used instead.
 +
*<b>_agentalias_</b>: Alias of the agent that triggered the alert.
 +
*<b>_agentcustomfield_n_</b>: Agent number n custom field (e.g. _agentcustomfield_9_).
 +
*<b>_agentcustomid_</b>: Agent custom ID.
 +
*<b>_agentdescription_</b>: Description of the agent that triggered the alert.
 +
*<b>_agentgroup_</b>: Agent group name.
 +
*<b>_agentname_</b>: Name of the agent that triggered the alert.
 +
*<b>_agentos_</b>: Agent's operative system.
 +
*<b>_agentstatus_</b>: Current agent status.
 +
*<b>_alert_critical_instructions_</b>: Instructions for CRITICAL status contained in the module.
 +
*<b>_alert_description_</b>: Alert description.
 +
*<b>_alert_name_</b>: Alert name.
 +
*<b>_alert_priority_</b>: Alert’s numeric priority.
 +
*<b>_alert_text_severity_</b>: Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).
 +
*<b>_alert_threshold_</b>: Alert threshold.
 +
*<b>_alert_times_fired_</b>: Number of times the alert has been triggered.
 +
*<b>_alert_unknown_instructions_</b>: Instructions for UNKNOWN status contained in the module.
 +
*<b>_alert_warning_instructions_</b>: Instructions for WARNING status contained in the module.
 +
*<b>_all_address_</b>: All addresses of the agent that fired the alert.
 +
*<b>_data_</b>: Module data that caused the alert to be triggered.
 +
*<b>_email_tag_</b>: Emails associated to the module’s tags.
 +
*<b>_event_cfX_</b>: (Only event alerts). Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
 +
*<b>_event_description_</b>: (Only event alerts) Textual description of the Pandora FMS event.
 +
*<b>_event_extra_id_</b>: (Only event alerts) Extra id.
 +
*<b>_event_id_</b>: (Only event alerts) ID of the event that triggered the alert.
 +
*<b>_event_text_severity_</b>:(Only event alerts) Priority text about the event that triggered the alert (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
 +
*<b>_eventTimestamp_</b>: Timestamp in which the event was created.
 +
*<b>_fieldX_</b>: User defined field C.
 +
*<b>_groupcontact_</b>: Group contact information. Configured when the group is created.
 +
*<b>_groupcustomid_</b>: Group custom ID.
 +
*<b>_groupother_</b>: Other information about the group. Configured when the group is created.
 +
*<b>_homeurl_</b>: It is a link of the public URL this must be configured in the general options of the setup.
 +
*<b>_id_agent_</b>: Agent ID, useful for building a direct URL with to Pandora FMS console.
 +
*<b>_id_alert_</b>: Alert ID, used to correlate the alert with third party tools.
 +
*<b>_id_group_</b>: Agent group ID.
 +
*<b>_id_module_</b>: Module ID.
 +
*<b>_interval_</b>: Module execution interval.
 +
*<b>_module_</b>: Module name.
 +
*<b>_modulecustomid_</b>: Module custom ID.
 +
*<b>_moduledata_X_</b>: Using this macro ("X" is the module name) the last piece of data of this module is collected, and if it is a number it is returned with the decimals specified in the console and its unit (if it has it). This could be useful for example for sending an email once a module alert is triggered, and also send additional information about other modules of the same agent (which could be very relevant).
 +
*<b>_moduledescription_</b>: Module description.
 +
*<b>_modulegraph_nh_</b>: (Only for alerts that use the eMail command) It returns an image encoded in base64 of a module graph with a period of n hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done in the server configuration file.
 +
*<b>_modulegraphth_nh_</b>: (Only for alerts that use the eMail command) Same operation as the previous macro, but with the critical and warning thresholds of the module provided they are defined.
 +
*<b>_modulegroup_</b>: Module’s group name.
 +
*<b>_modulestatus_</b>: Module status.
 +
*<b>_moduletags_</b>: URLs associated to the module tags.
 +
*<b>_name_tag_</b>: Names of the tags related to the module.
 +
*<b>_phone_tag_</b>: Phone numbers associated to the module tags.
 +
*<b>_plugin_parameters_</b>: Module plugin parameters.
 +
*<b>_policy_</b>: Name of the policy that the module belongs to (if applies).
 +
*<b>_prevdata_</b>: Module previous data before the alert was triggered.
 +
*<b>_rca_</b>: Root cause analysis chain (only for services).
 +
*<b>_server_ip_</b>: Ip of server assigned to agent.
 +
*<b>_server_name_</b>: Name of server assigned to agent.
 +
*<b>_target_ip_</b>: IP address for the module’s target.
 +
*<b>_target_port_</b>: Port number for the module’s target.
 +
*<b>_timestamp_</b>: Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).
 +
*<b>_timezone_</b>: Timezone that is represented on _timestamp_.
  
[[Pandora:Documentation_en|Go back to Pandora FMS documentation index]]
+
<br>
  
[[Category: Pandora FMS]]
+
[[Category:Pandora FMS]]
 
[[Category:Documentation]]
 
[[Category:Documentation]]

Latest revision as of 07:04, 2 December 2019

Go back to Pandora FMS documentation index

Contents

1 Alert Configuration in Pandora FMS

1.1 Introduction

An alert is Pandora FMS's reaction to a module's value being incorrect. Such a reaction is configurable and can result in any action that can be triggered by a script configured in the Operating System where the Pandora FMS server that processes the module is running.

There are several alert types: simple alerts, avent alerts and SNMP trap alerts. This chapter discusses the alert system as a whole and particularly the first type.

1.2 Introduction to the alert system

In Pandora FMS, alerts work by defining some triggering terms, some actions selected for that alert, and finally the execution of some commands in the Pandora FMS server, which will be in charge of carrying out the configured actions.

The general alert system associates a single alert for each module, this alert can carry out one or more actions.

1.2.1 The Alert Structure


Esquema-alert-structure.png


An alert consists on:

  • Commands: They specify what will be done. This will be the execution done by Pandora FMS server when triggering an alert. This could be writing in a log, sending an email or an SMS, executing a script, etc.
  • Actions : They specify how it will be done. They are the customizations of the command's arguments, they allow to customize the execution itself, adding to the command particular parameters like module name, agent, etc.
  • Templates: They specify when it will be done, defining the conditions for triggering the action(s). For example: when the module becomes critical.

1.2.2 The Alert System's Information Flow

When defining actions and templates, both have some general fields called Field1, Field2 and Field3 that are used to customize the alert's triggering.

These fields are applied according to a precedence order, "transferring" information from template -> action -> command, to finally be used as parameters in the execution of this command.

The precedence works like follows:

Template < Action < Command

Where the field value overwrites the content specified in the previous layer:


Alert precedence.png


If a template has any content in Field1, but the action has no content in its Field1, it inherits the content of Field1 from the template. However, if the action already has its own content (configured previously while creating the action) in its Field1, it will prevail over the one that is transfered from the template. So following the succession Template -> Action -> Command, the information will be transferred from the first one to the second one and from the second one to the third one if the next step does not already have any defined information in its fields Field1, Field2, Field3...

The following diagram shows this parameter transfer from the template to the command:


Esquema-parameters-carrying.png


This is an example for how template values are overwritten by the action's values:

Alertas esquema6.png


For example, this is a template that triggers an alert and sends an email, containing the following fields:

  • Template:
    • Field 1: [email protected]
    • Field 2: [Alert] The alert was fired.
    • Field 3: The alert was fired!!! SOS!!!

The values transferred to the command are:

  • Command:
    • Field 1: [email protected]
    • Field 2: [Alert] The alert was fired
    • Field 3: The alert was fired!!! SOS!!!


Field2 and Field3 keep the values defined in the template, but Field1, uses the value defined in the action.

1.3 The Alert Command

1.3.1 Introduction

Pandora FMS's acctions in face of alert situations at the end mean server executions, in the form of commands.

Susi2.png

1.3.2 Command creation for an alert

The form will request some descriptive information about the command:

Susi3 5.png

Next, the following fields are further explained:

Name: The command's name. It must be descriptive but short.

Command: The command to be executed when the alert is triggered. Macros can be used to replace the parameters configured in alert declaration. The macros that can be used are detailed below in a specific section.

When creating the commands for alerts, it is necessary to take into account that these commands are executed by Pandora FMS server. The alerts are also executed with the privileges of the user that executes the Pandora FMS server.

When defining a command, it is convenient to test, from the command line, that the execution of the command is successful and produces the desired result (sending an e-mail, generating an entry in a log file, etc.).


Group

Command group. This will determine which alerts the command can be associated to.


Description

Long description of the alert command just for further information.


Description of the fields and possible values

For each field it is possible to configure:

  • Description: The label next to the text box in the configuration form of the command action.
  • Possible values: A collection of the possible values for that field.

If the field is configured (it is not empty), it will be a selection combo instead of a text box. The combo needs a tag (the visible option) for each possible value and a value (the sent option).

This is the supported syntax:

value1,tag1;value2,tag2;value3,tag3

For example:

A simple field where it will be possible to choose the first four numbers:

1,Number one;2,Number two;3,Number three;4,Number four



Possible values 1.png





Possible values 2.png



Info.png

From 6.0 version on, it will be possible to show an HTML editor in a command field in the creation or edition of an alert action if that command field has as value the special token _html_editor_

 


  • Hide: This box must be checked when the field value would rather be hidden or blurred. This option will be used in case the field contains a password.

Once it created, click on the 'Create' button.

1.3.2.1 Command macros

The macros that can be used in the commands are:


  • _address_: Address of the agent that triggered the alert.
  • _address_n_ : The address of the agent that corresponds to the position indicated in "n". E.g: address_1_ , address_2__
  • _agent_: Alias of the agent that triggered the alert. If there is no alias assigned, the name of the agent will be used instead.
  • _agentalias_: Alias of the agent that triggered the alert.
  • _agentcustomfield_n_: Agent custom field number n (e.g. _agentcustomfield_9_).
  • _agentcustomid_: Agent custom ID.
  • _agentdescription_: Description of the agent that triggered the alert.
  • _agentgroup_ : Agent group name.
  • _agentname_: Name of the agent that triggered the alert.
  • _agentos_: Agent's Operative System.
  • _agentstatus_ : Current agent status.
  • _alert_critical_instructions_: Instructions for CRITICAL status contained in the module.
  • _alert_description_: Alert description.
  • _alert_name_: Alert name.
  • _alert_priority_: Alert’s numeric priority.
  • _alert_text_severity_: Text alert priority level (Maintenance, Informational, Normal Minor, Major, Critical).
  • _alert_threshold_: Alert threshold.
  • _alert_times_fired_: Number of times the alert has been triggered.
  • _alert_unknown_instructions_: Instructions for UNKNOWN status contained in the module.
  • _alert_warning_instructions_: Instructions for WARNING status contained in the module.
  • _all_address_ : All address of the agent that triggered the alert.
  • _data_: Module data that caused the alert to be triggered.
  • _email_tag_: Emails associated to the module’s tags.
  • _event_cfX_: (Only event alerts) Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
  • _event_description_: (Only event alerts) Text event description.
  • _event_extra_id_: (Only event alerts) Extra id.
  • _event_id_: (Only event alerts) ID of the event that triggered the alert.
  • _event_text_severity_: (Only event alerts) Event text severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
  • _eventTimestamp_: Timestamp where the event was created.
  • _fieldX_: User defined field C.
  • _groupcontact_: Group contact information. Configured when the group is created.
  • _groupcustomid_: Group custom ID.
  • _groupother_: Other information about the group. Configured when the group is created.
  • _homeurl_ : It is a link of the public URL that must be configured in setup general options.
  • _id_agent_: Agent’s ID, useful for building a direct URL to access Pandora FMS console webpage.
  • _id_alert_: Alert’s ID, used to correlate the alert with third party software.
  • _id_group_ : Agent group ID.
  • _id_module_: Module ID.
  • _interval_: Module’s execution interval.
  • _module_: Module name.
  • _modulecustomid_: Module custom ID.
  • _moduledata_X_: By using this macro ("X" is the module name) it is possible to retrieve that module's last data and if t is numeric, it is returned under the decimal format specified in the console's setup and with its unit (if it has it). It would be useful, for instance, for sending an email when an alert is triggered at the same time it sends additiona information about other modules from the same agent (which might be quite relevant).
  • _moduledescription_: Module description.
  • _modulegraph_nh_: (Only for alerts that use the command eMail) It returns an image encoded in base64 of a module’s graph with a period of n hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done on the server's configuration file.
  • _modulegraphth_nh_: (Only for alerts that use the command eMail) Same operation as the previous macro, only with the critical and warning thresholds of the module, provided they are defined.
  • _modulegroup_: Module’s group name.
  • _modulestatus_: Module status.
  • _moduletags_: URLs associated to the module tags.
  • _name_tag_: Names of the tags related to the module.
  • _phone_tag_: Phone numbers associated to the module tags.
  • _plugin_parameters_: Module plugin parameters.
  • _policy_: Name of the policy that the module belongs to (if it applies).
  • _prevdata_: Module previous data before the alert was triggered.
  • _rca_: Root cause analysis chain (only for services).
  • _secondarygroups_: It displays the agent's groups.
  • _server_ip_: Ip of server assigned to agent.
  • _server_name_: Name of server assigned to agent.
  • _target_ip_: IP address for the module’s target.
  • _target_port_: Port number for the module’s target.
  • _timestamp_: Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).
  • _timezone_: Timezone represented on _timestamp_.

1.3.3 Editing an Alert Command

You may edit the newly created alert commands by clicking on Alerts -> Commands.

Susi2.png

To edit an alert command, click on the command's name.

Susi6 5.png

Once the chosen alert has been modified, click on the 'Update' button.


Template warning.png

The commands named eMail, Internal Audit and Pandora FMS Event cannot be modified.

 


1.3.4 Operations of an alert command

Susi7.png

Delete: To delete an alert, click on the grey trash can icon to the right of the alert.

Copy: Alerts can be copied. It is especially useful to generate commands similar to other existing ones by changing some detail such as a field or group.


The alerts ”eMail”, “Internal Audit” and “Monitoring Event” cannot be deleted nor copied.

1.3.5 Predefined Commands

There is a series of predefined commands ready to use in the Pandora FMS alert system.

eMail

It sends an email from the Pandora FMS Server and uses the Perl 'sendmail' command to do so. Pandora FMS uses the system-specific tools to execute almost all of the alerts. In this case, it will be necessary to check whether the 'libmail-sendmail-perl' (an 'xprobe2' package) is already installed on your system or not.

Emails are sent in HTML, which allows creating more visually attractive templates. Notice that the receiver of the email should have access to the resources used in the template such as images.

Internal Audit

This generates a small entry within the internal Auditing System of Pandora FMS. It is kept in the Pandora FMS database and it can be reviewed by the console's event viewer.

Pandora FMS Event

This creates a special event within Pandora FMS Event Manager.

Pandora FMS Alertlog

This is a default alert to write alerts in a standard ASCII plain-text log file located under /var/log/pandora/pandora_alert.log.

SNMP Trap

It sends a parametrized SNMP trap with the arguments being used.

Syslog It sends an alert to the system registry and uses the system command named "logger" to do so.

Sound Alert

It plays a sound if an alert is received.

Jabber Alert

It sends a jabber alert to a chat room on a predefined server (configure the file named .sendxmpprc first). It uses field3 for the text message, field1 for the user's alias, and field2 for the chat-room's name.

SMS Text

It sends an SMS to a specific cellphone. Define an alert and a gateway for sending configured and accessible SMS from Pandora FMS before being able to do so. It is also possible to install one using 'Gnokii' to send SMS directly by using a Nokia phone with an USB connection. Further information on the detailed procedure is provided below.

Validate Event

It validates all events regarding a module. The agent's and module's name will be given.

1.3.6 Examples of Commands

1.3.6.1 Sending alerts with Jabber

It is very easy to set up Pandora FMS to send alerts by using a Jabber Server. Jabber can be used as a system to get real time alerts as well as a history log, allowing a group of people to receive those alerts simultaneously.

1.3.6.1.1 Installing Jabber Services

Procedure for the Client:

  1. Please install a Jabber client like Pidgin.
  2. Register an account under 'Pidgin' by clicking on the 'Accounts' tab to configure the account.
  3. Login to that account.

Procedure for Pandora FMS Server:

  1. Install the package named 'sendxmpp'. This tool enables sending Jabber messages.
  2. Create a file named '.sendxmpprc' within the '/home' folder.
  3. Edit that file and insert the following text:
  [email protected] password
  1. Grant permissions to the folder:
 chmod 0600 .sendxmpprc

Private messages can be sent using the command line, for instance:

  $ echo "Hello" | sendxmpp -s pandora [email protected] 

To register the alert within the Pandora FMS Web Console and to add a new command and configure its variables, do the following:

  • Field_1: The Jabber address.
  • Field_2: The text to be sent.

The alert is defined as follows:

  echo _field2_ | sendxmpp -s pandora _field1_
1.3.6.1.2 Additional examples of Jabber usage

Send this to a chat room:

  $ echo "Dinner Time" | sendxmpp -r TheCook --chatroom [email protected]

Send the log entries to a Jabber destination:

  $ tail -f /var/log/syslog | sendxmpp -i [email protected]


NOTE:|Be careful not to overload public Jabber servers or they will cut off access.

1.3.6.2 Sending Emails by the Expect Script

Sometimes, it is necessary to use an authenticated SMTP to send emails. It is probably an easier and more versatile method using a simple EXPECT script instead of configuring 'sendmail' to use an authenticated SMTP. This is an example using EXPECT to send emails by using an Exchange Server:

A file called '/etc/snmp' containing the following script is created:

#!/usr/bin/expect -f
set arg1 [lindex $argv 0] 
set arg2 [lindex $argv 1]
set arg3 [lindex $argv 2]
set timeout 1 
spawn telnet myserver.com 25 
expect "220"
send "ehlo mymachine.mydomain.com\r"
expect "250"
send "AUTH login\r"
expect "334"
send "2342348werhkwjernsdf78sdf3w4rwe32wer=\r"
expect "334"
send "YRejewrhneruT==\r"
expect "235"
send "MAIL FROM: [email protected]\r"
expect "Sender OK"
send "RCPT TO: $arg1\r"
expect "250"
send "data\r"
expect "354"
send "Subject: $arg2\r"
send "$arg3 \r\r"
send ".\r"
expect "delivery"
send "quit"
quit

File permissions are changed to allow execution:

chmod 700 /root/smtp 

Before trying to use it, make sure that /usr/bin/expect works properly.

To use this toghether with Pandora FMS, create a new command (or modify the already existing email alert-sending command) and specify the following fields within the Pandora FMS Alert Command definition in the field named 'Command'. Write the following:

/root/smtp _field1_ _field2_ _field3_

The script can be located anywhere on the system. Just keep in mind that the alert script is launched by the server that processes the data. If it is a network data, it will be the network server, if it is a data coming from an agent, through an XML file, then the dataserver will be the one to launch it.

If you have several physical servers, it is possible that you need to copy the same script to the same location, along with the same permissions and the same owner on all the systems where you have a Pandora FMS Server running and want to execute this alert on. Remember that Pandora FMS Network Servers must be executed as 'root' (e.g. for being able to execute ICMP latency tests). However, dataservers can be started by any user without special privileges.

The alert will be executed by the user who is executing the Pandora FMS Server process.

1.3.6.3 Sending SMS through Gnokii

To use Gnokii, use a Nokia cellphone or one compatible with Gnokii (check the compatible hardware list on the Gnokii Project Page). You will also need a USB data cable connected the cellphone and a connection to the Pandora FMS Server you intend to send the SMS Alerts from.

Gnokii supports a large variety of Nokia cellphones and some models by other manufacturers.

By using Gnokii, you may also send SMS directly from the command line. This is a very easy and quick way to send any SMS directly from a Pandora FMS Server, thereby avoiding the use of gateways sending SMS by using the Internet (which is not very useful if the network is down) or GSM hardware solutions for sending messages which are very expensive in some countries.

An alternative is the Gammu Project.

This is an example of sending an SMS from the command line using Gnokii:

echo "PANDORA: Server XXXX is down at XXXXX" | gnokii --sendsms 555123123

Gnokii is unable to send an SMS with images attached, but it can send a URL via HTTP or WAP for it to be displayed when receiving a message, for example:

echo "Image capture sample" | gnokii --sendsms 555123123 -w http://artica.homelinux.com/capture.jpg

It can also send an image's URL or one that leads to a 'light version' of the console in order to provide console access and data analysis to the user.

The development team has tested sending SMS alerts from a Nokia 6030 cellphone when Internet connection was not available. The Nokia 6030 cellphone uses the module's 6510 definition within the 'gnokiirc' file. It takes about four seconds to send an SMS.

It is possible to install a much more powerful sending gateway using Gammu.

1.3.6.4 Executing a Remote Command on another System (UNIX)

Sometimes, it is pretty interesting to execute the command on another system by means of the ssh command. The system where the command is executed should be a UNIX system and have the SSH daemon installed, started and accessible.

To avoid storing the access password on the machine that executes the command within the Pandora FMS Console, copy the server's public key to where you intend to execute the remote command on the Pandora FMS Server.

Once done, execute the following command:

ssh [email protected] [_field1_]

By using '_Field1_' as a variable, you may use any command you want.

1.4 Alert Actions

1.4.1 Introduction

Actions are the components of alerts where a command is related to the generic variables Field 1, Field 2,..., Field 10.

Actions allow defining how to launch the command.

1.4.2 Creating an Action

New actions are created by clicking on Alerts -> Action and Create.

Accion1.jpg

Once you have clicked on 'Create', this window will appear:

Accion2.jpg

Here is an explanation about the fields to be filled out:

  • Name: The action name.
  • Group: The action group. If the associated command has a group other than All, only the group associated with the command or the All group can be set as the action group.
  • Command: The command used in case of a triggered alert. You may choose among several predefined commands under Pandora FMS.
  • Threshold: The action's execution threshold.
  • Command Preview: The command to be executed on the system appears here automatically.
  • Field 1-10: The values of the macros from '_field1_ through '_field10_' are defined here. They are intended to be used along with the command if necessary. These fields might be a text field or a selection combo if configured.

Once you have filled out the fields, click on the 'Create' button.

Boton1.jpg

To edit newly created actions, click on Alerts and Actions.

1.4.2.1 Action macros

The macros that can be used in the actions are:


  • _address_: Address of the agent that triggered the alert.
  • _address_n_ : The address of the agent that corresponds to the position indicated in "n" e.g: address_1_ , address_2__
  • _agent_: Alias of the agent that triggered the alert. If there is no alias assigned, the name of the agent will be used instead.
  • _agentalias_: Alias of the agent that triggered the alert.
  • _agentcustomfield_n_: Agent custom field number n (eg. _agentcustomfield_9_).
  • _agentcustomid_: Agent custom ID.
  • _agentdescription_: Description of the agent that triggered the alert.
  • _agentgroup_ : Agent group name.
  • _agentname_: Name of the agent that triggered the alert.
  • _agentos_: Agent's operative system.
  • _agentstatus_ : Current status of the agent.
  • _alert_critical_instructions_: Instructions for CRITICAL status contained in the module.
  • _alert_description_: Alert description.
  • _alert_name_: Alert name.
  • _alert_priority_: Alert’s numeric priority.
  • _alert_text_severity_: Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).
  • _alert_threshold_: Alert threshold.
  • _alert_times_fired_: Number of times the alert has been triggered.
  • _alert_unknown_instructions_: Instructions for UNKNOWN status contained in the module.
  • _alert_warning_instructions_: Instructions for WARNING status contained in the module.
  • _all_address_ : All addresses of the agent that triggered the alert.
  • _data_: Module data that caused the alert to be triggered.
  • _email_tag_: Emails associated to the module’s tags.
  • _event_cfX_: (Only event alerts) Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
  • _event_description_: (Only event alerts) Text description of the Pandora FMS event.
  • _event_extra_id_: (Only event alerts) Extra id.
  • _event_id_: (Only event alerts) ID of the event that triggered the alert.
  • _event_text_severity_: (Only event alerts) Event text severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
  • _eventTimestamp_: Timestamp when the event was created.
  • _fieldX_: User defined field C.
  • _groupcontact_: Group contact information. Configured when the group is created.
  • _groupcustomid_: Group custom ID.
  • _groupother_: Other information about the group. Configured when the group is created.
  • _homeurl_ : It is a link of the public URL. It must be configured in the general options of the setup.
  • _id_agent_: Agent’s ID, useful for building a direct URL that redirects to a Pandora FMS console webpage.
  • _id_alert_: Alert’s numeric ID (unique), used to correlate the alert with third party software.
  • _id_group_ : Agent group ID.
  • _id_module_: Module ID.
  • _interval_: Module’s execution interval.
  • _module_: Module name.
  • _modulecustomid_: Module custom ID.
  • _moduledata_X_: Using this macro ("X" is its actual name) the last module data is retrieved. If it is umerical it is returned under the decimal format specified in the console's setup along with is unit (if it has it). I could be used, for instance, to send an email when a module alert is triggeres anlong with additiona information from other modules from the same agent (which might be quite relevant).
  • _moduledescription_: Description of the module.
  • _modulegraph_nh_: (Only for alerts that use the command eMail). It returns an image encoded in base64 of a module’s graph with a rango of n hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done on the server's configuration file.
  • _modulegraphth_nh_: (Only for alerts that use the command eMail). Same operation as the previous macro, only with the critical and warning thresholds of the module, provided they are defined.
  • _modulegroup_: Module’s group name.
  • _modulestatus_: Module status.
  • _moduletags_: URLs associated to the module tags.
  • _name_tag_: Names of the tags related to the module.
  • _phone_tag_: Phone numbers associated to the module tags.
  • _plugin_parameters_: Module plugin parameters.
  • _policy_: Name of the policy that the module belongs to (if applies).
  • _prevdata_: Module's previous data before the alert has been triggered.
  • _rca_: Root cause analysis chain (only for services).
  • _secondarygroups_: It displays the agent's secondary groups.
  • _server_ip_: Ip of server assigned to the agent.
  • _server_name_: Name of server assigned to the agent.
  • _target_ip_: IP address for the module’s target.
  • _target_port_: Port number for the module’s target.
  • _timestamp_: Time and date when the alert was triggered (yy-mm-dd hh:mm:ss).
  • _timezone_: Timezone represented on _timestamp_.

1.4.3 Editing an Action


Alert action.png

To edit an action, click on the action's name.


Alert action edit.png

Once you have completed the changes, update them by clicking on the 'Update' button.


1.4.4 Deleting an Action

To delete an action, click on the gray trash icon which is located at the right side.

Sipo.jpg

1.5 Alert Templates

1.5.1 Introduction

Templates define alert triggering terms (when the action should be executed).

Alert templates are associated to modules, so theta ehen the template terms are met, the linked action(s) are executed.

Their design allows generating a small generic template group that is used for most cases in Pandora FMs.

1.5.2 Creating an Alert Template

Go to the Alerts menu > Templates. You can create a new template by clicking on the Create button.

Planti.jpg

1.5.2.1 Step 1: General

Sabo.jpg

You may specify in the template wizard:

  • Name: The name of the template.
  • Description: It describes the template's function. It is useful to distinguish the template from others within the alert's general view.
  • Priority: The field which provides information about the alert. The generated event will inherit this priority whenthe alert is triggered. It is useful for filtering when searching for alerts.

You may choose among the following priorities:

    • Maintenance
    • Informational
    • Normal
    • Warning
    • Critical

1.5.2.2 Step 2: Conditions


Templform2.JPG


This section offers the possibility of customizing the template itself, when it must be launched:

  • 'Condition Type:' The field where the type of condition to be applied on the alert is defined. The required combos will be added according to the defined type, which are:
  • Regular Expression: A regular expression is used. The alert will be triggered if the module's value meets certain requirement.


Regular.jpg


By choosing the 'regular expression' condition, the possibility of selecting the trigger box appears if it matches the value. If you select it, the alert will be fired if the value matches. If not, the alert will be fired if the value does not match.

  • Max and Min: The used maximum and a minimum values.


Notmaxmin.png


When checking 'Trigger when matches the value', the alert will be launched when the value is within the indicated range between maximum and minimum and, if not marked, the alert will be launched when the value is outside the selected range.

  • Max: The used 'maximum' value. The alert will be triggered if the module's value is higher than the defined 'maximum' value.

Max.png

  • Min: The used 'minimum' value. The alert will be triggered if the module's value is lower than the defined minimum value.


Min.png


  • Equal to: Used to trigger the alert when a value must be equal to the received data. This condition, like max/min, is used only for numeric values, e.g. 234 or 124.35.

Equal.png

  • Not Equal to: It is the same as previous one but denying the condition (logic operator NOT).

Notequal.jpg

  • Warning/Critical/Unknown status: The module status is used. The alert will be triggered when the monitor status is appropriate one:

Status template.png

These are the explanations for the fields featured there:

Days of Week

Days when the alert could possibly be triggered.

Use special days list

It is used to enable or disable the use of the special days list, e.g. holidays and special working days.

Time From

Time from which the alert action is going to be executed.

Time To

Alert action time limit.

Time Threshold

Time required to reset the alarm counter.

It defines the time interval where it is guaranteed that an alert will not be triggered more than the maximum number of alerts.

After the defined interval, the counter will be reset. The restart of the trigger counter will not be restarted if the alert recovers when a correct value arrives, unless the value Alert recovery is activated, in which case the counter will restart immediately after receiving a correct value.

Min. number of Alerts

The minimum number of times the terms set on the template have to be met (counting from the number defined in the module's FlipFlop parameter) so that an alert is triggered. The default value is '0', which means the alert will be triggered when the first value that meets the terms is received. It is intended to work as a filter, which might be useful to ignore false positives.

Max number of Alerts Maximum number of alerts which could be sent consecutively within the same time interval (time threshold). It is the maximum alert counter value. No more alerts than the specified number will be received by interval.


Default Action: The default action the template will have is defined in this combo. This will be the action to be automatically created when the template is assigned to the module. You may assign one or none, but you cannot assign several default actions here.

1.5.2.3 Step 3: Advanced fields



Combo.jpg

You may adjust the following options:

Alert Recovery

The combo where alert recovery is enabled or disabled.

In the event that alert recovery is enabled, when the module no longer meets the terms specified in the template, the action linked to the arguments specified by the fields defined in this column will be executed.

Field 1 It defines the value for the '_field1_' variable. The list of macros (which are described below) may be used here.

Field n It defines the value for the '_fieldn_' variable in n is a number between 1 and 10.

Once all appropriate fields have been filled out, click on 'Finish'.

1.5.3 Replaceable Macros within Field1, Field2, Field3... Field10

It is possible to use the following macros in all cases the instances of 'Field1', 'Field2'... 'Field10' (both in the alert template, as well as the command and the action). These are 'words' that will be replaced if executed by a value. That value is depends on the time, value or agent that triggered the alert, etc.

  • _address_: The address of the agent that triggered the alert.
  • _address_n_: The address of the agent that corresponds to the position indicated in "n" e.g: address_1_ , address_2_.
  • _agent_: Alias of the agent that triggered the alert. If there is no alias assigned, the agent name will be used instead.
  • _agentalias_: Alias of the agent that triggered the alert.
  • _agentcustomfield_n_: Agent custom field number n (eg. _agentcustomfield_9_).
  • _agentcustomid_: Agent custom ID.
  • _agentdescription_:Description of the agent that triggered the alert.
  • _agentgroup_: Agent group name.
  • _agentname_: Name of the agent that triggered the alert.
  • _agentos_: Agent's operative system.
  • _agentstatus_: Current agent status.
  • _alert_critical_instructions_: Instructions for the CRITICAL status contained in the module.
  • _alert_description_: Alert description.
  • _alert_name_: Alert name.
  • _alert_priority_: Alert’s numeric priority.
  • _alert_text_severity_: Priority level, in the alert's text (Maintenance, Informational, Normal Minor, Major, Critical).
  • _alert_threshold_: Alert threshold.
  • _alert_times_fired_: Number of times the alert was triggered.
  • _alert_unknown_instructions_: Instructions for UNKNOWN status contained in the module.
  • _alert_warning_instructions_: Instructions for WARNING status contained in the module.
  • _all_address_: All addresses of the agent that triggered the alert.
  • _data_: Module data that caused the alert to be triggered.
  • _email_tag_: Emails associated to the module's tags.
  • _event_cfX_: (Only event alerts) Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
  • _event_description_: (Only event alerts) Textual description of the event that triggered the alert.
  • _event_id_: (Only event alerts) Id of the event that fired the alert.
  • _event_extra_id_: (Only event alerts) Extra id.
  • _event_text_severity_: (Only event alerts) Priority in the text of the event that triggered the alert (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
  • _eventTimestamp_: Timestamp when the event was created. v733
  • _field1_: User defined field 1.
  • _field2_: User defined field 2.
  • _field3_: User defined field 3.
  • _field4_: User defined field 4.
  • _field5_: User defined field 5.
  • _field6_: User defined field 6.
  • _field7_: User defined field 7.
  • _field8_: User defined field 8.
  • _field9_: User defined field 9.
  • _field10_: User defined field 10.
  • _field11_: User defined field 11.
  • _field12_: User defined field 12.
  • _field13_: User defined field 13.
  • _field14_: User defined field 14.
  • _field15_: User defined field 15.
  • _groupcontact_: Group contact information. Configured when the group is created.
  • _groupcustomid_: Group custom ID.
  • _groupother_: Other information about the group. Configured when the group is created.
  • _homeurl_: It is a link to the public URL. Configured in the setup general options.
  • _id_agent_: Agent ID, useful for building a direct URL that redirects to a Pandora FMS console webpage.
  • _id_alert_: Alert numeric ID (unique), used to correlate the alert with third party software.
  • _id_group_: Agent group ID.
  • _id_module_: Module ID.
  • _interval_: Module’s execution interval.
  • _module_: Module name.
  • _modulecustomid_: Module custom ID.
  • _moduledata_X_: Use this macro (named "X") to get the most recent data from the module and, if it is numeric, it will return formatted with the decimals specified on the console setup and that of its unit (if it has one). It would be useful in case of sending an email when an alert is triggered and send additional (and possibly relevant) information from other modules belonging to the same agent.
  • _moduledescription_:Description of the module that triggered the alert.
  • _modulegraph_nh_: (Only for alerts that use the command eMail). It returns an image codified in base64 of a module graph with a period of n hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's api is required. This setup is done in the server configuration file.
  • _modulegraphth_nh_: (Only for alerts that use the command eMail). Same operation as the previous macro but with module critical and warning thresholds, provided they are defined.
  • _modulegroup_: The module's group name.
  • _modulestatus_: Module status.
  • _moduletags_: URLs associated to module tags.
  • _name_tag_: Names of the tags associated to the module.
  • _phone_tag_: Phone numbers associated to the module tags.
  • _plugin_parameters_: Module plugin parameters.
  • _policy_: The policy's name the module belongs to (if applies).
  • _prevdata_: Module previous data before the alert was triggered.
  • _server_ip_: Ip of server assigned to agent.
  • _server_name_: Name of server assigned to agent.
  • _target_ip_: IP address for the module’s target.
  • _target_port_: Port number for the module’s target.
  • _timestamp_: Time and date when the alert was triggered (yy-mm-dd hh:mm:ss).
  • _timezone_: Timezone represented on _timestamp_.

Example: The agent_agent_ has module_module_ in status_modulestatus_ with data_data_

1.5.3.1 Complete example of an alert containing replacement macros

Suppose you intend to create a log entry where every line appears in the following format:

2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status

Command Configuration

echo _timestamp_ pandora _field2_ >> _field1_

Action Configuration

Field1 = /var/log/pandora/pandora_alert.log
Field2 = <left blank>
Field3 = <left blank>

Template Configuration

Field1 = <left blank>
Field2 = [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <left blank>

In the recovering section:

Field2 = [RECOVERED] [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <left blank>

If an alert is triggered, the following line will be added to the log:

2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status

And the this one to recover the alert:

2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status

1.5.4 Editing a template

You may edit newly created templates by clicking on Administration -> Manage Alerts ->Templates.


Plantilla.jpg

To edit a template, click on the template's name.

1.5.5 Deleting a template

To delete a template, click on the gray trash icon located at the right of the alert.

Cruz.jpg

1.6 Assigning alert templates to modules

Once the basic information about the alert system is known, we will show you the possible ways to assign alerts to the modules.

1.6.1 Alert management from alert submenu

1.6.1.1 Assigning alerts from alert submenu

From section List of Alerts, create new alerts through the builder:


Pinar.jpg


These are the fields to fill in:

  • Agent: Smart auto-completion to choose the agent.
  • Module: Module list of the previously selected agent.
  • Actions:: Action to be executed when the alert is triggered. If the template has a default action, Default may be kept.
  • Template: Template that contains alert triggering terms.
  • Threshold: The alert action to not be executed more than once every 'action_threshold' seconds, regardless of the number of times the alert is triggered.

1.6.1.2 Modifying alerts from an alert's submenu

Once an alert has been created, it is only possible to modify the actions that have been added to the template's action.

It is also possible to delete the action that was selected when the alert was created by clicking on the gray trash icon located at the right side of the action, or to add new actions by clicking on the 'Add' ('+') button.


Modifica.jpg


1.6.1.3 Deactivating alerts from an alert's submenu

Once the alert has been created, it is possible to deactivate it by clicking on the light-bulb icon located at the right side of the alert's name.


Desha.jpg


1.6.1.4 Deleting alerts from the alert submenu

It is possible to delete any alert by clicking on the gray trash icon located at the right side of the alert.

Filter.jpg

1.6.2 Managing alerts from within the agent

1.6.2.1 Alert assignment within the agent

From the agent management section, new alerts can be added by clicking on the corresponding tab.


Wiz agent alerts.png



These are the form's available fields:

  • Module: Agent module list.
  • Actions: Action executed when the alert is triggered. If the template has a default one, leave it as Default.
  • Template: Template that contains alert triggering terms.
  • Threshold: The alert action will not be executed more than once every 'action_threshold' seconds, regardless of the number of times the alert is triggered.

1.6.2.2 Modifying alerts from within the agent

Once an alert has been created, it is only possible to modify the actions that have been added to the template's action.

It is also possible to delete the action selected at the moment the alert was created by clicking on the gray trash icon which is located at the right side of the action, or to add new actions by clicking on the 'Add' button.

Agent edit alerts.png


1.6.2.3 Deactivating alerts from the agent

Once an alert has been created, it is possible to deactivate it by clicking on the light bulb icon located at the right side of the alert's name.

Wiz agent disable alert.png

In the example image, the second alert is disabled (note that the font color and the disabled alert icon are light grey).


1.6.2.4 Deleting alerts from within the agent

It is possible to delete any alert by clicking on the gray trash icon which is located at the alert's right side.


Wiz agent delete alert.png


1.6.2.5 Alert detail

By clicking on the magnifying glass icon on the button panel of alert options, you will see a summary page of the effective alert setup.

This is the screen where each of the settings selected for the alert can be confirmed:


Agent alert summary.png

Select a specific action from the Actions dropdown to see an example of the final command:

Agent alert summary action.png


1.7 Defining a threshold

In the following screenshot, there is a module called "CPU Load" for which a critical threshold and a warning thresholds will be defined.


Cpu1.JPG


The module edit form will be accessed to set the thresholds as shown in the following screenshot.

It is important to remember that modifying local modules is only available from the console in the Enterprise version, otherwise it will have to be done directly in the agent configuration file:


Cpu2.JPG


Accept and save the changes. When the value of the module CPU Load is between 70 and 90, its status will change to WARNING, and when between 91 and 100, it will become CRITICAL, showing its status in red as seen here:


Cpu3.JPG


1.8 Configuring an action

Create an action that is "Send an email to the operator". Go to the menu: Alerts > Actions and click on the button to create a new action:

Qgcpu5.png

This action uses the command 'Send email' and its fields named 'Field1', 'Field2' and 'Field3' which correspond to the target address, email subject, and message body.




1.9 Configuring an alert template

A generic alert template will be created for any module in critical status, and its default action will be to notify the group of operators by email. Define the template from the Templates section:


Qgcpu6.png


The priority set here as "Informational" will be used to display the event in a certain color when the alert is triggered.

Step 2 specifies the parameters that determine the specific triggering terms, such as the state the module should have or the time intervals when the template will work.


Qgcpu7.png


The most important parameters in this step are:

  • Condition type: It determines whether the alert will be triggered by a status change, a value change, etc. It is the most important parameter for the alert to work as desired. The Critical status term would be used to trigger the alert when a module is in a critical status.
  • Default action: The action to be executed by default when the alert is triggered. It is optional.
  • Time threshold: Time during which the alert will not be repeated if the incorrect status is continuously kept. If left at one day (24 hours), it will only send the alert once every 24 hours even if the module remains longer in faulty status.
  • Min. Number of alerts: The minimum number of times that the term has to be met (in this case, that the module is in CRITICAL state) before Pandora FMS executes the actions linked to the alert template. With a value of 0, the first time the module is faulty, the alert will be triggered.
  • Max. Number of alerts: 1 means that the action will be executed only once. If the value is 10, the action will be run 10 times. This is a way to limit the number of times an alert can be executed.

In section 3, Field1, Field2, Field3, etc. will be used to transfer parameters from the template to the action, and from the action to the command. In addition, in this third section alert recovery can be enabled or disabled, which consists of executing another action when the situation goes back to normal.

Qgcpu8.png




1.10 Associating an alert to a module

Now just link the alert template to the module. To do so, go to the 'Alert' tab within the agent where the module is located:

Qgcpu9.png

Here the module named 'cpu_user' and the 'critical condition' alert template have been linked. It will show the predefined action in this template ('Send email to XXX') by default.

1.11 Scaling alerts

Once a complete alert has been associated with a module, it is possible to add additional actions that are executed if the alert is repeated a certain number of times consecutively. That is called scaling alerts.

Add the additional actions and determine between which consecutive alert repetitions this action will be executed, as shown in the following capture:

Alert1.JPG

When an alert is recovered, all actions that have been executed up to that point will be re-executed, not just those that correspond to the "Number of alerts match from" current setting.

In addition, a second threshold on the basis of which it will not be possible to send an alert more than once within said interval.




1.12 Stand-By Alerts

Alerts can be defined as 'active', 'deactivated' or in 'standby'. The difference between 'deactivated' and 'standby' alerts is that 'deactivated' alerts are not fired at all. They will not be shown in the alert's view either. 'Standby' alerts will be shown in alert view. They will also work - but only on the display level. They will show whether they are triggered or not, but they neither perform the assigned actions nor generate events.

Standby alerts are useful to see what happens, but they have notifications and actions disabled.

1.13 Cascade Protection

Cascade Protection is a Pandora FMS feature which allows to avoid alert overload if a group of agents cannot be reached due to a connection failure. These kinds of things tend to happen if an intermediate device such as a router or a switch is down and most of the network managed by Pandora FMS becomes unaccessible. Since network checks would not work in that situation, alerts would start being triggered due to down devices, despite not being true.

Recursive cascade protection ilustration.png

Cascade protection is enabled from agent configuration. Click on the Cascade protection option. In order for the agent to work with cascade protection, the parent agent it depends on must be correctly configured. If the parent agent currently has any critical-state module alert triggered, the lower agent with cascade protection will not execute its alerts.

This does not apply to module alerts in WARNING or UNKNOWN status.

Down1.jpg

1.13.1 Examples

These are the agents at your disposal:

  • Router: ICMP check module and SNMP check module, using a standard OID to verify the status of an ATM port. Latency towards your provider's router can be verified too.
  • Web Server: It has several modules executed by the agent: CPU, Memory, Apache process verification. It also has a four-step WEB latency check.
  • Database Server: It has several modules executed by the agent: CPU, Memory, MySQL process verification. It has some additional BBDD integrity checks. It can also verify connectivity to another database remotely, using a specific plugin that logs in, queries and exits, measuring the total time.

In WEB SERVER and DATABASE SERVER, ROUTER is defined as parent. Check the cascade protection check-box in WEBSERVER and DATABASE SERVER. Now define several simple alerts:

  • ROUTER

SNMP Check / CRITICAL -> Action, send MAIL. Latency > 200ms / WARNING -> Action, send MAIL.

  • WEB SERVER

CPU / WARNING MEM / WARNING PROCESS / CRITICAL -> Action, send MAIL. HTTP LATENCY / CRITICAL -> Action, send MAIL.

  • DATABASE SERVER

CPU / WARNING MEM / WARNING PROCESS / CRITICAL -> Action, send MAIL. SQL LATENCY / CRITICAL > Action, send MAIL.

If ROUTER connection fails, by means of which Pandora FMS connects with WEB SERVER and DATABASE, and if cascade protection is disabled, you will receive six alerts. Imagine what would happen if you had 200 Servers connected instead of six. That is the reason for why it is sometimes called an 'Alert Storm'. In worst-case scenarios, this problem may kill your Mail and Monitoring Servers or your cellphone, because they get flooded by lots of alerts or SMS messages.

However, if you have the cascade protection enabled, you will only receive one alert, saying that the router ATM interface is down. You will still see the Web and Database Servers in red, but you will not receive the alerts .

1.13.2 Service-based cascade protection

From version 7.0 OUM727 onwards, services can be used to avoid multiple source alerts reporting the same incident.


If service-based cascade protection is enabled, the service elements (agents, modules or other services) will not report problems, but the service itself will alert on behalf of the affected element.


That is to say, in the following image:

Proteccion cascada1.png



If the element 192.168.10.149 goes into critical status without affecting the rest of the service, the operator will receive an alert pointing out that 192.168.10.149 is down, but the service Service works normally.

In case that 192.168.10.149 affects the service performance, the operator will receive an alert indicating that the Service is affected by 192.168.10.149 being down.



In order to receive this information, edit or create a new alert template, using the _rca_ root cause analysis macro.

_rca_

From Pandora FMS 7.0 OUM727 onwards, this macro will provide info about the affected 'path' in the service to the operator.


Proteccion cascada2.png



For example, the value of the macro _rca_ corresponding to the service status in the image would be:

[Service -> web_service -> 192.168.10.149]


Though the status of the service would be correct.

Observation: The chain of events represented in root cause analysis represents the critical elements within a service, allowing to see what elements are affecting the service.



1.13.3 Cascade protection based on modules

The state of a module of a parent agent can be used to avoid agent alerts in case the module of the parent agent goes into critical state.

Alerta-modulo.png

1.14 Safe operation mode (Version >= 7.0)

Safe operation mode.png

Safe operation mode can be enabled in agent advanced configuration options.

If the selected module's status becomes critical, the rest of the agent's modules are disabled until it goes back to warning or normal again. This allows, for example, to disable remote modules if connectivity is lost.

1.15 List of special days

Pandora FMS allows to define a list of special days for holidays and vacations that can be used in the template configuration, so that during those days alerts are not triggered.

1.15.1 Creating a Special Day

New special days are created in the "Alerts" -> "List of special days" section, by clicking on "More" or "Create" underneath the calendar.



Creating special day61-1.png



Once one of them has been clicked, a window like this one will appear:



Creating special day2.png



This is an explanation of the given options:

  • Date: The special day's date. The data format is 'YYYY-MM-DD'. If you want to define the same day every year, you may use '*' for the 'YYYY' entry.
  • Group: Select here the group to which the special day applies.
  • Same Day of the Week: Select a day. The date in field "Date" is dealt with the same as that weekday.
  • Description: Special Day's description.

Suppose that May 3, 2020 is holiday. If you define the "2012-05-03" as a "Sunday", that day becomes the same as a Sunday. Bearing in mind that templates have configuration options and will work in one way or another depending on the day of the week, this will help you make them work the way you want.

Practical example

There is a template that alerts you from Monday to Friday from 8 am to 6 pm but on Saturdays and Sundays this template will not cause any alert to go off. The 15th August is Wednesday and it is holiday, so a special day is created and in the field Same day of the week Saturday or Sunday is chosen, so alerts of any kind will not be received on August 15th as it will be as if it was Saturday or Sunday, when the template is configured to not trigger any alerts.

Once the fields have been selected, click on "Create".

1.15.2 Creating special days in bulk from an .ics file

Special days can also be created using an iCalendar file (. ics). These can be imported at the top of the window. Once imported, the corresponding data will be recorded in the current month.



Creating special day ics.png



1.15.3 Editing a special day

You may edit special days created within the "List of Special Days" option by clicking on "Alerts".



Editing special day61-1.png



To edit a special day, click on the wrench icon next to the corresponding special day.



Editing special day2.png



Once the changes are completed, click on the 'Update' button.

1.15.4 Deleting a Special Day

In order to delete a Special Day, click on the gray trash icon located next to the Special Day wrench icon.



Deleting special day61.png



1.16 Complete Alert Examples

1.16.1 Sending SMS Alerts

This example exemplifies something quite common: how to send an SMS either if something happens or it is about to happen.

You must have a tool that allows sending SMS installed, such as smstools. Suppose you have already configured your SMS account. Enter the following command:

> sendsms 


Enter three parameters: <source>, <destination> and 'complete message'.
Do not forget to enclose the message in single quotes (') and to enter the 
destination number by using the international code format 
(e.g. 346276223 for Spanish phone numbers).

Next, use the "alert command" in the Pandora FMS management interface:



Smsalert sample1.png



Within this command, send "346666666666" as the source of the message. An alphanumerical word can be used here, but some mobile phone providers cannot handle alphanumeric IDs very well. 'Field 1' and 'Field 2' will be used to define the command's performance. On the photo of the mobile phone that receives the SMS, a string identifier named 'Aeryn' is used. 'Field 1' is the target phone, while 'Field 2' is the text, defined within the alert's action.

Now define the alert's action. It will execute the predefined command and replace Field 1 and Field 2 by custom values. In this specific case, the template's alert does not return any data in the SMS. All information is defined in Alert Action.



Smsalert sample3.png



Field 1 is the phone number. Field2 contains the text message. A few macros are used here, which will be replaced over time, when the alert goes off.

Final step: create an Alert Template (skip this if you already have a valid Alert Template). This is a very simple Alert Template, just to "go off" when a module goes into CRITICAL. This alert will be triggered once a day at the most, but if it recovers, it will be triggered again each time it recovers and is triggered again.




Smsalert sample5.png





Smsalert sample6.png



Now, assign a module along with an alert template and an alert action:

Smsalert sample4.png

To have this alert field, the module must be in CRITICAL state. On the picture below, the module's configuration must be reviewed to see if its 'critical' thresholds are properly defined. If it is not, the alert will never be triggered because it is waiting for the moment to reach the 'critical' status. In this case, it is set to '20'. If a lower value is received, the module will go into CRITICAL state and the alert will be triggered.



Smsalert sample4.png



Finally, the alert can be forced to execute it and test it. To force the alert, go to agent alert view and click on the green circle icon.



Smsalert sample7.png



All set. We can now "force" the alert to run and test it. To force the alert, go to the agent alert view and click the green circular icon.



Smsalert sample8.png



An SMS may appear on your mobile phone, as shown in the following picture. The obtained data is "N/A" because, when forcing the alert, no real data is received from the module.



Smsalert sample9.png



1.16.2 Using alert commands different from email

The email is hosted as command in Pandora FMS, because 'Field 1', 'Field 2' and 'Field 3' are fields clearly intended to be used for 'addressee', 'subject' and 'message text' - but what if you intend to execute a user-defined action?

This is how a new command is custom defined. Suppose you intend to generate a log file entry for each alert alert find. The format of the log file should be something like this:

DATE_HOUR - NAME_AGENT -NAME_MODULE -VALUE- PROBLEM DESCRIPTION

VALUE is the module's value at that specific moment. There will be several log file entries, depending on the action that calls the command. The alert will define the description and the file to which the events are added.


To accomplish this, first create a command like this one:


Qgcpu11.png

Then, define an action:


Qgcpu12.png


If you take a look into the created log file, you will see the following:

2010-05-25 18:17:10 - farscape - cpu_user - 23.00 - Custom log alert #1

The alert was triggered at '18:17:10' within the agent named 'Farscape', in the module named 'cpu_sys' containing the data '23.00' and the description entered when the action was defined.

As for command execution, the field order and the other things might make you not to understand very well how the command is eventually executed, the easiest way is activating the Pandora FMS Server's debug traces within the server's configuration file located at '/etc/pandora/pandora_server.conf'. Restart the server by entering '/etc/init.d/pandora_server restart', look for the file named '/var/log/pandora/pandora_server.log' and look for the exact line which contains the execution of the user-defined alert command to see how Pandora FMS Server triggers it in detail.

1.16.2.1 Complete example of an alert with substitution macros

Suppose for a moment you intend to generate a log entry where each line is supposed to show its data in the following format:

2009-12-24 00:12:00 pandora [CRITICAL] Agent <agent_name> Data <module_data> Module <module_name> in CRITICAL status

Command configuration:

echo _timestamp_ pandora _field2_ >> _field1_

Action configuration:

Field1 = /var/log/pandora/pandora_alert.log
Field2 = <left blank>
Field3 = <left blank>

Template configuration

Field1 = <left blank>
Field2 = [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <left blank>

In the recovery section:

Field2 = [RECOVERED] [CRITICAL] Agent _agent_ Data _data_ Module _module_ in CRITICAL status
Field3 = <left blank>

When executing an alert, the following line is entered in the log:

2009-10-13 13:37:00 pandora [CRITICAL] Agent raz0r Data 0.00 Module Host Alive in CRITICAL status


And the following line to recover the alert:

2009-10-13 13:41:55 pandora [RECOVERED] [CRITICAL] Agent raz0r Data 1.00 Module Host Alive in CRITICAL status

1.17 Custom module alert macros

Any amount of macros may be added to an agent module.



Add module macros.png


These macros have the following characteristics:

  • They are defined in the module configuration section.
  • They store information in the database.
  • They may have any name, for example: _joey_
  • They do not affect local configuration. files(pandora_agent.conf).
  • They are exclusively used in alerts.
  • They cannot be defined at local component level.
  • They can be defined in policies.

These specific macros can be added by just extending the module macros section.



Module macros.png


Macro values can be used as part of the fields in alert definition. For Example: To include a macro to the mail sending action, the field with the e-mail body must be configured in the following fashion:



Campos alertas.png


If a module is added to this alert without any defined custom macro, then no information will be displayed in the macro value section.

1.18 Event Alerts and Event Correlation

There is a specific chapter about this topic.

1.19 Quick guide to email configuration for alerts in Pandora FMS

1.19.1 Email configuration with a Gmail account

In order for Pandora FMS server to send alerts via Gmail, Pandora FMS and Postfix must be configured this way:

1.19.1.1 Pandora FMS setup

In order to properly configure your email with a Gmail account, all the fields must have the following comments in the Pandora FMS server configuration file (/etc/pandora/pandora_server.conf) except for the mta_address field, which will be configured with the IP server or localhost where the postfixserver is installed.

If Postfix is installed in the same server as Pandora FMS, the configuration in the pandora_server.conf would be like this:

mta_address localhost 
#mta_port 25
#mta_user [email protected]
#mta_pass mypassword
#mta_auth LOGIN
#mta_from Pandora FMS <[email protected]>


The following section shows briefly how to configure an alert in Pandora FMS console.

1.19.1.1.1 Action Setup

To set the mail recipient, use the mail action to XXX so you can add an email recipient to which all mail alerts will be sent.

GMAIL1.png

1.19.1.1.2 Alert setup

In this case, a new alert with the module seen on the screenshot has been generated in module configuration > Alerts.

GMAIL2.png

Once the alert is triggered, you can see how the alert reaches the e-mail chosen in the action:

GMAIL3.png GMAIL4.png

1.19.1.2 Postfix Installation

The following packages must be installed in Pandora FMS server for postfix server to work properly together with a GMAIL account.

yum install postfix mailx cyrus-sasl-plain cyrus-sasl cyrus-sasl-lib cyrus-sasl-md5 cyrus-sasl-scram cyrus-sasl-gssapi

1.19.1.3 Postfix Configuration

Once Postfix has been installed within the server and everything works properly, except for sending emails through Gmail, follow these steps:

1-- Check that the "less secure pass" option is enabled in your Gmail account. It can be enabled through this link.(https://myaccount.google.com/lesssecureapps)

2-- Edit the /etc/postfix/main.cf file and add the following lines at the end of said file:

myhostname = <hostname> #Add here server hostname
relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_CAfile = /etc/pki/tls/cert.pem
smtp_tls_security_level = encrypt

3-- Create the /etc/postfix/sasl_passwd file with its corresponding Gmail address and password.

nano /etc/postfix/sasl_passwd

Add the following line with the Gmail address and password to the file:

[smtp.gmail.com]:587 [email protected]:PASSWORD

Secure it accordingly:

chmod 600 /etc/postfix/sasl_passwd
chown root:root /etc/postfix/sasl_passwd

4-- Create the /etc/postfix/tls_policy file with the following information:

nano /etc/postfix/tls_policy
[smtp.gmail.com]:587 encrypt

Secure it accordingly:

chmod 600 /etc/postfix/tls_policy
chown root:root /etc/postfix/tls_policy


5-- Turn /etc/postfix/sasl_passwd and /etc/postfix/tls_policy into a hash-type indexed file through this command:

postmap /etc/postfix/sasl_passwd && postmap /etc/postfix/tls_policy

It will create the /etc/postfix/sasl_passwd.db and /etc/postfix/tls_policy.db file.


6-- Finally, restart postfix to apply the changes as it follows:

/etc/init.d/postfix restart

7-- The performance can be checked by logging in two consoles. Execute the following command to monitor mail performance:

tail -f /var/log/maillog

The other one will send an email:

echo "Mail test" | mail [email protected]

If the preceding steps have been carried out correctly, the other console should show something like this:

Dec 18 18:33:40 OKComputer postfix/pickup[10945]: 75D4A243BD: uid=0 from=
Dec 18 18:33:40 OKComputer postfix/cleanup[10951]: 75D4A243BD: message-id=
Dec 18 18:33:40 OKComputer postfix/qmgr[10946]: 75D4A243BD: from=, size=403, nrcpt=1 (queue active)
Dec 18 18:33:44 OKComputer postfix/smtp[10953]: 75D4A243BD: [email protected], relay=smtp.gmail.com[74.125.93.109]:587, delay=3.7,  delays=0.15/0.14/1.8/1.6, dsn=2.0.0, status=sent (250 2.0.0 OK 1324249500 eb5sm36008464qab.10)
Dec 18 18:33:44 OKComputer postfix/qmgr[10946]: 75D4A243BD: removed

If this is the result, Pandora FMS will point to the Postfix server to send emails and they will be successfully sent.

1.20 Alert correlation: event and log alerts


From Pandora FMS version 741, alerts can be build based on received events or logs collected by means of the log collection system. Simple or complex alerts may be created based on a set of terms with logic relations. This feature replaces the previous one of event alerts.

Pandora FMS allows working from a much more flexible perspective, since alerts are not generated according to the status of a specific module, but on an event -which may have been generated by several different modules of different agents.

Event alerts are based on filtering rules using logical operators (and, or, xor, nand, nor, nxor) to look for events matching the configured filtering rules and if matches are found, the alert will be triggered.

They also use templates to define some parameters, such as the days on which the alert will work. However, in this case the templates do not determine when the event alert is triggered, but rather it is through the filtering rules that the events that match will be searched and the corresponding alerts will be triggered.

From version NG741, a new rule editor that allows building alerts visually can be used. The old event alert editor will still be available for some time.

Info.png

Given the high number of events Pandora FMS Database is able to store, the server works on an maximal event window which is defined in the pandora_server.conf configuration file by a parameter named 'event_window'. Events generated outside the specified time range will not be processed by the server. So it does not make any sense to specify in a rule a time range wider than the one configured within the Server.

 



In a similar way, there is another server parameter called log_window that works in a similar fashion as the previously described one.

Template warning.png

In order for event correlation alerts to work, it is necessary to activate the event correlation server with the parameter eventserver 1 in the Pandora FMS server configuration file.

 



1.20.1 Correlation alert creation

1.20.1.1 Correlation alerts / templates

To configure a correlated alert, access the 'Alert correlation' section through the menu.

Alertaslog2.png


Create a rule and define its performance (similar to Alert Templates):

Alertaslog12.PNG


Alertaslog13.PNG


Template configuration parameters for correlation alerts are similar to those of a module alert. There are only two event alert specific parameters:

  • Rule evaluation mode: It provides two options, Pass and Drop. "Pass" means that if an event matches an alert, the rest of alerts are still evaluated. "Drop" means that if an event matches an alert, the alerts left will no longer be evaluated.
  • Group by: It allows to group rules by agent, module, alert or group. E.g. If a rule is configured to go off when two critical events are received and it is grouped by agent, two critical events are required to come from the same agent. This can be disabled.

In case of alerts containing log rules, it will only affect grouping by agent. If a different grouping is chosen, entry log-based alerts will never be met.

Each rule is configured to go off due to a specific type of event or log match. When the logic ecuation defined by rules or their operators is met, the alert is triggered.


1.20.1.2 Rules within a correlation alert

Alertaslog14.PNG


To define these rules, drag the elements from the left side to the "drop area" at the right to create your rule.

'Configuration available items:

Alertaslog3.png


These elements will be enabled to guide the user to meet the rule's grammar. Hereon the grammar to be used is further explained:

S -> R | R + NEXUS +R
R -> FIELD + OPERATOR + C | FIELD + OPERATOR + C + MODIFIER
C -> VARIABLE

Where S is the set of rules defined for the correlated alert.

Drag the element to the rule definition area:

Alertaslog4.png


To clean up and undo all changes, the 'Cleanup' and 'Reset' buttons are available.

Template warning.png

No changes will be saved until you click on the 'Next' button.

 


REMEMBER: Blocks are simultaneous when meeting a term.

(A and B) 

It forces the analyzed item (whether event or log) to meet A and B simultaneously.

A and B 

It forces both rules (A) and (B) to be met in the evaluation window. This means that during the last couple of seconds (defined by 'log_window' and 'event_window' parameters), entries that meet both rules must exist.

1.20.1.3 Multiple correlated alerts

When you have multiple alerts, these have a specific evaluation order. They are always orderly evaluated, starting by the first of the list.

If the 'PASS' rule evaluation mode is configured, if a correlated alert is run, the next ones will also be evaluated. Tha is the "normal" mode.

If you configure the 'DROP' rule evaluation mode, if a correlated alrt configured through this mode is run, the evaluation of the next rules will come to a halt. This feature makes cascade alert protection possible.


For example:

  • Generic alert.
  • Specific alert.

If the general alert fails, there is no need to evaluate the specific one. Configure both of them with DROP.

Click on the order icon and drag to change rule evaluation order.


Alertaslog9.png


The rest of correlation rules (action fields and action application) work similarly to the rest of Pandora FMS alerts and do not require additional explanation.

1.20.1.4 Event Alert macros

The macros that can be used in the event alerts are:


  • _address_: Address of the agent that triggered the alert.
  • _address_n_: Address of the agent that corresponds to the position indicated in "n" e.g: address_1_ , address_2_
  • _agent_: Alias of the agent that triggered the alert. If there is no alias assigned, the name of the agent will be used instead.
  • _agentalias_: Alias of the agent that triggered the alert.
  • _agentcustomfield_n_: Agent number n custom field (e.g. _agentcustomfield_9_).
  • _agentcustomid_: Agent custom ID.
  • _agentdescription_: Description of the agent that triggered the alert.
  • _agentgroup_: Agent group name.
  • _agentname_: Name of the agent that triggered the alert.
  • _agentos_: Agent's operative system.
  • _agentstatus_: Current agent status.
  • _alert_critical_instructions_: Instructions for CRITICAL status contained in the module.
  • _alert_description_: Alert description.
  • _alert_name_: Alert name.
  • _alert_priority_: Alert’s numeric priority.
  • _alert_text_severity_: Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).
  • _alert_threshold_: Alert threshold.
  • _alert_times_fired_: Number of times the alert has been triggered.
  • _alert_unknown_instructions_: Instructions for UNKNOWN status contained in the module.
  • _alert_warning_instructions_: Instructions for WARNING status contained in the module.
  • _all_address_: All addresses of the agent that fired the alert.
  • _data_: Module data that caused the alert to be triggered.
  • _email_tag_: Emails associated to the module’s tags.
  • _event_cfX_: (Only event alerts). Key of the event custom field that triggered the alert. For example, if there is a custom field whose key is IPAM, its value can be obtained using the _event_cfIPAM_ macro.
  • _event_description_: (Only event alerts) Textual description of the Pandora FMS event.
  • _event_extra_id_: (Only event alerts) Extra id.
  • _event_id_: (Only event alerts) ID of the event that triggered the alert.
  • _event_text_severity_:(Only event alerts) Priority text about the event that triggered the alert (Maintenance, Informational, Normal Minor, Warning, Major, Critical).
  • _eventTimestamp_: Timestamp in which the event was created.
  • _fieldX_: User defined field C.
  • _groupcontact_: Group contact information. Configured when the group is created.
  • _groupcustomid_: Group custom ID.
  • _groupother_: Other information about the group. Configured when the group is created.
  • _homeurl_: It is a link of the public URL this must be configured in the general options of the setup.
  • _id_agent_: Agent ID, useful for building a direct URL with to Pandora FMS console.
  • _id_alert_: Alert ID, used to correlate the alert with third party tools.
  • _id_group_: Agent group ID.
  • _id_module_: Module ID.
  • _interval_: Module execution interval.
  • _module_: Module name.
  • _modulecustomid_: Module custom ID.
  • _moduledata_X_: Using this macro ("X" is the module name) the last piece of data of this module is collected, and if it is a number it is returned with the decimals specified in the console and its unit (if it has it). This could be useful for example for sending an email once a module alert is triggered, and also send additional information about other modules of the same agent (which could be very relevant).
  • _moduledescription_: Module description.
  • _modulegraph_nh_: (Only for alerts that use the eMail command) It returns an image encoded in base64 of a module graph with a period of n hours (e.g. _modulegraph_24h_). A correct setup of the connection between the server and the console's API is required. This setup is done in the server configuration file.
  • _modulegraphth_nh_: (Only for alerts that use the eMail command) Same operation as the previous macro, but with the critical and warning thresholds of the module provided they are defined.
  • _modulegroup_: Module’s group name.
  • _modulestatus_: Module status.
  • _moduletags_: URLs associated to the module tags.
  • _name_tag_: Names of the tags related to the module.
  • _phone_tag_: Phone numbers associated to the module tags.
  • _plugin_parameters_: Module plugin parameters.
  • _policy_: Name of the policy that the module belongs to (if applies).
  • _prevdata_: Module previous data before the alert was triggered.
  • _rca_: Root cause analysis chain (only for services).
  • _server_ip_: Ip of server assigned to agent.
  • _server_name_: Name of server assigned to agent.
  • _target_ip_: IP address for the module’s target.
  • _target_port_: Port number for the module’s target.
  • _timestamp_: Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).
  • _timezone_: Timezone that is represented on _timestamp_.