tyler.durden
/
pandorafms
mirror of https://github.com/pandorafms/pandorafms.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated english translations

This commit is contained in:
axl89 2016-08-30 13:06:10 +02:00
parent 3ae6866ab0
commit 9f22e7fec0
26 changed files with 756 additions and 906 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
pandora_console/include/help/en/help_action_threshold.php Executable file → Normal file
View File

@ -1,21 +1,18 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Action Threshold</h1>
<p>
An alert action will not be executed more than once every
action_threshold seconds, regardless of the number of times the alert is
fired.
</p>
<p>
For example, if you have configured an action that sends you an email
when the alert fires and you don't want to receive more than one email
per hour, you can set the action_threshold to 3600.
</p>
<p>
Bear in mind that the individual action_threshold of an action overrides
the global action_threshold of the alert.
</p>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Action Threshold</h1>
<p>
An alert action will not be executed more than once every
‘action_threshold’ time value, regardless of the number of times the alert is triggered.
</p>
<p>
For example, if you have configured an action that sends you an email
when the alert is activated and you don't want to receive more than one email per hour, you can set the ‘action_threshold’ value to 3600.
</p>
<p>
Bear in mind that the individual ‘action_threshold’ value of an action overrides the global ‘action_threshold’ value of the alert.
</p>

46
pandora_console/include/help/en/help_ad_advanced_permision.php
View File

@ -1,23 +1,23 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Advance Permission </h1>
<br><br>
<table width="750px" style="display:inline">
<tr>
<td class=""> If you add a new permission, you must added the text as follows:
<nav>
</nav>
"Name of Profile, Name of Group, [Name of Group AD n1|Name of Group AD n2|
<nav>
</nav>
Name of Group AD n3|...],[Nametag1|NameTag2|NameTagN|...]"
<nav>
</nav>
Between groups and tags must be "|" as showed in the top example
</td>
</table>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Advanced Permissions </h1>
<br><br>
<table width="750px" style="display:inline">
<tr>
<td class=""> If you add a new permission, you must add the corresponding text as follows:
<nav>
</nav>
“Profile name, Group name, [Group Name AD n1|Group Name AD n2|
<nav>
</nav>
Name of Group AD n3|...],[Nametag1|NameTag2|NameTagN|...]"
<nav>
</nav>
To separate groups and tags you must use "|" as shown in the top example above
</td>
</table>

17
pandora_console/include/help/en/help_agent_access.php
View File

@ -1,9 +1,8 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Agent access</h1>
Agent access graphs render access "contacts" per hour in a graph with a 24hr (daily) scale. This is used to know the contact frecuency of each agent. This could be useful to detect bottlenecks and agent break down. This could be time-consuming and if you're low on resources, this option could be deactivated in main application setup.
<?php
/**
* @package Include/help/en
*/
?>
<h1>Agent access</h1>
Agent access graphs provide access to ”contacts" per hour in a graph with a 24hr (daily) scale. This can be used to know the contact frequency for each agent. This could be useful to detect bottlenecks and agent breakdowns. This could be time-consuming and if you're short on resources, this option can be deactivated on the application’s main setup.

54
pandora_console/include/help/en/help_agent_server.php
View File

@ -1,27 +1,27 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Server field</h1>
In the field "server" there is a combo where you can choose the server that will do the checking.
Configuration at Servers
<br><br>
In Servers there are two modes of work:
<br><br>
<ul>
<blockquote>
<li>Master Mode.
<li>Non-Master Mode.
</ul>
<br>
The differences between them, and the importance that they have to work in HA mode, consist on that when there are several servers from the same kind( e.g: Network Servers).When a server falls, the first master server that could, will be in charge of the network modules of the down server that are waiting to be executed. The non-master servers does not do this.
<br><br>
This option is configured in the file /etc/pandora/pandora_server.conf through the master 1 token.
<br><br><i>
master 1
<br><br></i>
Being the value 1 to active it and 0 to deactivate it.
<?php
/**
* @package Include/help/en
*/
?>
<h1>Server field</h1>
On the “server” field there is a combination where the server for check ups is chosen.
Setup is found on the servers.
<br><br>
For servers there are two work methods:
<br><br>
<ul>
<blockquote>
<li>Master Mode.
<li>Non-Master Mode.
</ul>
<br>
The difference between them, and the importance that they carry when working in HA mode, is based on the fact that there are several servers of the same kind( e.g: Network Servers).When a server is down, the first master server available will be in charge of the network modules that are on the downed server and that are waiting to be run. Non-master servers cannot do this.
<br><br>
This option can be set in the file /etc/pandora/pandora_server.conf using the master 1 token.
<br><br><i>
master 1
<br><br></i>
Set the value to 1 to active it and 0 to deactivate it.

90
pandora_console/include/help/en/help_agent_status.php
View File

@ -1,45 +1,45 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Agent status view </h1>
Possible color values of <b>modules</b> are:
<br><br>
<b>
Number of modules
: <span class="red">Number of critical modules</span>
: <span class="yellow">Number of warning modules</span>
: <span class="green">Number of normal modules</span>
: <span class="grey">Number of down modules</span>
</b>
<br><br>
Possible values of an <b>agent status</b> are:
<br><br>
<table width="750px" style="display:inline">
<tr>
<td class="f9i"><?php html_print_image("images/status_sets/default/module_critical.png", false, array("title" => "At least one monitor fails", "alt" => "At least one monitor fails")); ?><?php html_print_image("images/status_sets/faces/module_critical.png", false, array("title" => "At least one monitor fails", "alt" => "At least one monitor fails")); ?></td><td>At least one monitor fails</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/module_warning.png", false, array("title" => "Change between Green/Red state", "alt" => "Change between Green/Red state")); ?><?php html_print_image("images/status_sets/faces/module_warning.png", false, array("title" => "Change between Green/Red state", "alt" => "Change between Green/Red state")); ?></td><td>Change between Green/Red state</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/agent_ok.png", false, array("title" => "All Monitors OK", "alt" => "All Monitors OK")); ?><?php html_print_image("images/status_sets/faces/agent_ok.png", false, array("title" => "All Monitors OK", "alt" => "All Monitors OK")); ?></td><td>All Monitors OK</td>
</tr><tr>
<td class="f9i"><?php html_print_image("images/status_sets/default/agent_no_data.png", false, array("title" => "Agent without data", "alt" => "Agent without data")); ?><?php html_print_image("images/status_sets/faces/agent_no_data.png", false, array("title" => "Agent without data", "alt" => "Agent without data")); ?></td><td>Agent without data</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/agent_down.png", false, array("title" => "Agent down", "alt" => "Agent down")); ?><?php html_print_image("images/status_sets/faces/agent_down.png", false, array("title" => "Agent down", "alt" => "Agent down")); ?></td><td>Agent down</td>
</tr>
</table>
<br><br>
Possible values of <b>alert status</b> are:
<br><br>
<table width="450px">
<tr>
<td class="f9i"><?php html_print_image("images/status_sets/default/alert_fired.png", false, array("title" => "Alert fired", "alt" => "Alert fired")); ?><?php html_print_image("images/status_sets/faces/alert_fired.png", false, array("title" => "Alert fired", "alt" => "Alert fired")); ?></td><td>Alert fired</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/alert_disabled.png", false, array("title" => "Alert disabled", "alt" => "Alert disabled")); ?><?php html_print_image("images/status_sets/faces/alert_disabled.png", false, array("title" => "Alert disabled", "alt" => "Alert disabled")); ?></td><td>Alerts disabled</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/alert_not_fired.png", false, array("title" => "Alert not fired", "alt" => "Alert not fired")); ?><?php html_print_image("images/status_sets/faces/alert_not_fired.png", false, array("title" => "Alert not fired", "alt" => "Alert not fired")); ?></td><td>Alert not fired</td>
</tr>
</table>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Agent’s status view </h1>
Possible value colors for <b>modules</b> are:
<br><br>
<b>
Total number of modules
: <span class="red">Number of modules in critical status </span>
: <span class="yellow">Number of modules in warning status </span>
: <span class="green">Number of modules in normal status </span>
: <span class="grey">Number of downed modules</span>
</b>
<br><br>
Possible values for an <b>agent’s status</b> are:
<br><br>
<table width="750px" style="display:inline">
<tr>
<td class="f9i"><?php html_print_image("images/status_sets/default/module_critical.png", false, array("title" => "At least one monitor fails", "alt" => "At least one monitor fails")); ?><?php html_print_image("images/status_sets/faces/module_critical.png", false, array("title" => "At least one monitor fails", "alt" => "At least one monitor fails")); ?></td><td>At least one monitor fails</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/module_warning.png", false, array("title" => "Change between Green/Red state", "alt" => "Change between Green/Red state")); ?><?php html_print_image("images/status_sets/faces/module_warning.png", false, array("title" => "Change between Green/Red state", "alt" => "Change between Green/Red state")); ?></td><td>Change between Green/Red state</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/agent_ok.png", false, array("title" => "All Monitors OK", "alt" => "All Monitors OK")); ?><?php html_print_image("images/status_sets/faces/agent_ok.png", false, array("title" => "All Monitors OK", "alt" => "All Monitors OK")); ?></td><td>All Monitors OK</td>
</tr><tr>
<td class="f9i"><?php html_print_image("images/status_sets/default/agent_no_data.png", false, array("title" => "Agent without data", "alt" => "Agent without data")); ?><?php html_print_image("images/status_sets/faces/agent_no_data.png", false, array("title" => "Agent without data", "alt" => "Agent without data")); ?></td><td>Agent without data</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/agent_down.png", false, array("title" => "Agent down", "alt" => "Agent down")); ?><?php html_print_image("images/status_sets/faces/agent_down.png", false, array("title" => "Agent down", "alt" => "Agent down")); ?></td><td>Agent down</td>
</tr>
</table>
<br><br>
Possible values for an <b>alert’s status</b> are:
<br><br>
<table width="450px">
<tr>
<td class="f9i"><?php html_print_image("images/status_sets/default/alert_fired.png", false, array("title" => "Alert fired", "alt" => "Alert fired")); ?><?php html_print_image("images/status_sets/faces/alert_fired.png", false, array("title" => "Alert fired", "alt" => "Alert fired")); ?></td><td>Alert fired</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/alert_disabled.png", false, array("title" => "Alert disabled", "alt" => "Alert disabled")); ?><?php html_print_image("images/status_sets/faces/alert_disabled.png", false, array("title" => "Alert disabled", "alt" => "Alert disabled")); ?></td><td>Alerts disabled</td>
<td class="f9i"><?php html_print_image("images/status_sets/default/alert_not_fired.png", false, array("title" => "Alert not fired", "alt" => "Alert not fired")); ?><?php html_print_image("images/status_sets/faces/alert_not_fired.png", false, array("title" => "Alert not fired", "alt" => "Alert not fired")); ?></td><td>Alert not fired</td>
</tr>
</table>

32
pandora_console/include/help/en/help_aggregate_by.php
View File

@ -1,16 +1,16 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Aggregate</h1>
Aggregate by destination ip: flows are grouped to show the traffic for each different destination IP.<br>
Aggregate by source ip: flows are grouped to show the traffic for each different source IP.<br>
Aggregate by destination port: flows are grouped to show the traffic for each different destination port.<br>
Aggregate by source port: flows are grouped to show the traffic for each different source port.<br>
No aggregate: global traffic.<br>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Aggregate</h1>
Add according to destined IP: flows are grouped to show traffic for each different destined IP.<br>
Add according to source IP: flows are grouped to show traffic for each different source IP.<br>
Add according to destined port: flows are grouped to show traffic for each different destined port.<br>
Add by source port: flows are grouped to show traffic for each different source port.<br>
Don’t add: global traffic.<br>

32
pandora_console/include/help/en/help_alert-matches.php Executable file → Normal file
View File

@ -1,16 +1,16 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Matches of the alert</h1>
<p>
Defines the number of alerts that must occur before executing the action. It is a fine-tunning parameter.<br><br>
This allows "redefine" a little more the alert behavior, so that if we set a maximum of 5 times the times you can fire a warning, and we just want to send us an email, we will set here 0 and 1 , to say that we only send an email from time 0 to 1 (so, once). When an alert recovers, all the actions that have been executed up to that point will be executed again.<br> <br>
Now we see that we can add more actions to the same alert, defining these fields "Number of alerts match from" alert behavior depending on how often you shoot. <br> <br>
For example, we may want to send an email to XXXXX the first time it happens, and if it continues down the monitor, send an email to ZZZZ. To do this, associate after the alert, the alert table assigned, I can add more actions to an alert defined as changing this parameter.
</p>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert matches</h1>
<p>
This defines the number of alerts that must go off before triggering the set action. This is a fine tuning parameter.<br><br>
This allows "redefining” alert behavior a little more, so that if we’ve set a maximum of 5 times you can fire a warning, and we just want to receive an email notification, then we will add the values 0 and 1, to say that we only receive an email when the alert is fired 0 to 1 times (once). When an alert recovers, all the actions that have been executed up to that point will be executed again.<br> <br>
Now we see that we can add more actions to the same alert, defining with these "Number of alerts match from" fields the alert behavior depending on how often it’s triggered. <br> <br>
For example, we may want the alert action to send an email to XXXXX the first time it happens, and if the monitor remains down, send an email to ZZZZ. In order for this to happen, after linking the alert, on the assigned alert chart, more actions can be added to an already defined alert by changing this parameter.
</p>

18
pandora_console/include/help/en/help_alert_action.php
View File

@ -1,9 +1,9 @@
<?php
/*
* @package Include/help/en/
*/
?>
<h1>Action alert</h1>
<p>Alert action is the component of the alert that keep relation between command and fields: Field 1, Field 2 and Field 3. These actions will be used in alert templates in order to associate a trigger with a specific action.</p>
<?php
/*
* @package Include/help/en/
*/
?>
<h1>Actions on alerts</h1>
<p>Actions on alerts are an alert component that maintains the relationship between a command and the “Field 1”, “Field 2” and “Field 3” fields. These actions will be used on templates that associate a condition to an entire action</p>

18
pandora_console/include/help/en/help_alert_command.php
View File

@ -1,9 +1,9 @@
<?php
/*
* @package Include/help/en
*/
?>
<h1>Alert command</h1>
<p>Pandora FMS's reaction to a value &#34;out of range&#34; can be of diverse kinds: record in a syslog, e-mail or SMS sending, or the execution of any script hosted in Pandora FMS's machine that can be processed.</p>
<?php
/*
* @package Include/help/en
*/
?>
<h1>Alert commands</h1>
<p>Pandora FMS's reaction to a value stating &#34;out of range&#34; can be diverse: it can be recorder on the syslog, an email or SMS alert can be sent, or the execution of any script found on the Pandora FMS device and that can be properly processed.</p>

138
pandora_console/include/help/en/help_alert_config.php
View File

@ -1,70 +1,68 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Configure Alert Action</h1>
<br>Actions are the components of alerts where a command (which is described in the previous section) is linked with the generic variables Field 1, Field 2, ..., Field 10. These actions will be used later in the alert templates that are the ones that associate a data condition with an specific action. <br>
Next are the fields that you should fill in:<br><br>
<b>Name:</b> Name of the action.<br>
<b>Group:</b> Group of the action. <br>
<b>Command:</b> In this field is defined the command that will be used in case the alert will be executed . You can choose between the different commands that are defined in Pandora.Depending of the command chosen we will have some or others fields to fill. <br>
<b>Threshold:</b> The action execution threshold. <br>
<b>Command Preview:</b> In this field, not editable, will automatically appear the command that will be executed in the system. <br>
<b>Field X:</b> In this fields are defined the values of the macros _field1_ to _field10_, that will be used in the command if necessary. These fields can be a text field or combo box if configured. Depending on the selected command will appear a number of fields to fill in as needed or not. For example:<br><br>
To configure email action, you can only fill _field1_ (Destination address), _field2_ (Subject) y _field3_ (Message)<br><br>
Within these fields we can configure the macros listed below.
<br><br>
<?php html_print_image ("images/help/actions.png", false, array('width' => '550px')); ?>
<br><br>
<br>
<p>
Besides the defined module macros, the following macros are available:
<ul>
<li>_field1_ : User defined field 1.</li>
<li>_field2_ : User defined field 2.</li>
<li>_field3_ : User defined field 3.</li>
<li>_agent_ : Name of the agent that fired the alert.</li>
<li>_agentdescription_ : Description of the agent who fired alert.</li>
<li>_agentgroup_ : Agent group name.</li>
<li>_agentstatus_ : Current status of the agent.</li>
<li>_address_ : Address of the agent that fired the alert.</li>
<li>_timestamp_ : Time when the alert was fired (yy-mm-dd hh:mm:ss).</li>
<li>_timezone_ : Timezone name that _timestamp_ represents in.</li>
<li>_data_ : Module data that caused the alert to fire.</li>
<li>_alert_description_ : Alert description.</li>
<li>_alert_threshold_ : Alert threshold.</li>
<li>_alert_times_fired_ : Number of times the alert has been fired.</li>
<li>_module_ : Module name.</li>
<li>_modulegroup_ : Module group name.</li>
<li>_moduledescription_ : Description of the module who fired the alert.</li>
<li>_modulestatus_ : Status of the module.</li>
<li>_moduletags_ : Tags associated to the module.</li>
<li>_alert_name_ : Alert name.</li>
<li>_alert_priority_ : Numerical alert priority.</li>
<li>_alert_text_severity_ : Text alert severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).</li>
<li>_event_text_severity_ : (Only event alerts) Text event (who fire the alert) severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).</li>
<li>_event_id_ : (Only event alerts) Id of the event that fired the alert.</li>
<li>_id_agent_ : Id of agent, useful to build direct URL to redirect to a Pandora FMS console webpage.</li>
<li>_id_group_ : Id of agent group.</li>
<li>_id_alert_ : Numerical ID of the alert (unique), used to correlate on third party software</li>
<li>_policy_ : Name of the policy the module belongs to (if applies).</li>
<li>_interval_ : Execution interval of the module. </li>
<li>_target_ip_ : IP address of the target of the module.</li>
<li>_target_port_ : Port number of the target of the module.</li>
<li>_plugin_parameters_ : Plug-in Parameters of the module.</li>
<li>_groupcontact_ : Group contact information. Configured when the group is created.</li>
<li>_groupother_ : Other information about the group. Configured when the group is created.</li>
<li>_email_tag_ : Emails associated to the module tags.</li>
<li>_modulegraph_nh_: (Only for alerts that use the command eMail) Returns an image 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.</li>
</ul>
<p>
</p>
<p>
Example: Agent _agent_ has fired alert _alert_ with data _data_
</p>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Configuring Action Alerts</h1>
<br>Actions are alert components that relate a command, explained in the previous part of the help guide, with generic variables Field 1, Field 2, …, Field 10. Said actions will be used further along in alert templates, which are those that relate a condition on a piece of data to a specific action. <br><br>
<b>Name:</b> Name assigned to the action.<br>
<b>Group:</b> Group the action belongs to. <br>
<b>Command:</b> In this field the command that will be used in case the alert is triggered can be defined. Users can choose from the different commands that are defined on Pandora. Depending on the command chosen a variable group of fields will be shown (specific to each command) <br>
<b>Threshold:</b> The action’s execution threshold. <br>
<b>Command Preview:</b> In this field, which can’t be edited, the command that will be run on the system will appear automatically. <br>
<b>Field X:</b> In these fields:<br><br>
For the email command only _field1_ (Destination address), _field2_ (Subject) y _field3_ (Message) are configured<br><br>
When it comes to creating the action these are the only 3 fields we can set. Within these fields we can configure the macros shown below.
<br><br>
<?php html_print_image ("images/help/actions.png", false, array('width' => '550px')); ?>
<br><br>
<br>
<p>
Apart from the defined module macros, the following macros are also available:
<ul>
<li>_field1_ : User defined field 1.</li>
<li>_field2_ : User defined field 2.</li>
<li>_field3_ : User defined field 3.</li>
<li>_agent_ : Name of the agent that fired the alert.</li>
<li>_agentdescription_ : Description of the agent who fired alert.</li>
<li>_agentgroup_ : Agent group name.</li>
<li>_agentstatus_ : Current status of the agent.</li>
<li>_address_ : Address of the agent that fired the alert.</li>
<li>_timestamp_ : Time when the alert was fired (yy-mm-dd hh:mm:ss).</li>
<li>_timezone_ : Timezone name that _timestamp_ represents in.</li>
<li>_data_ : Module data that caused the alert to fire.</li>
<li>_alert_description_ : Alert description.</li>
<li>_alert_threshold_ : Alert threshold.</li>
<li>_alert_times_fired_ : Number of times the alert has been fired.</li>
<li>_module_ : Module name.</li>
<li>_modulegroup_ : Module group name.</li>
<li>_moduledescription_ : Description of the module who fired the alert.</li>
<li>_modulestatus_ : Status of the module.</li>
<li>_moduletags_ : Tags associated to the module.</li>
<li>_alert_name_ : Alert name.</li>
<li>_alert_priority_ : Numerical alert priority.</li>
<li>_alert_text_severity_ : Text alert severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).</li>
<li>_event_text_severity_ : (Only event alerts) Text event (who fire the alert) severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).</li>
<li>_event_id_ : (Only event alerts) Id of the event that fired the alert.</li>
<li>_id_agent_ : Id of agent, useful to build direct URL to redirect to a Pandora FMS console webpage.</li>
<li>_id_group_ : Id of agent group.</li>
<li>_id_alert_ : Numerical ID of the alert (unique), used to correlate on third party software</li>
<li>_policy_ : Name of the policy the module belongs to (if applies).</li>
<li>_interval_ : Execution interval of the module. </li>
<li>_target_ip_ : IP address of the target of the module.</li>
<li>_target_port_ : Port number of the target of the module.</li>
<li>_plugin_parameters_ : Plug-in Parameters of the module.</li>
<li>_groupcontact_ : Group contact information. Configured when the group is created.</li>
<li>_groupother_ : Other information about the group. Configured when the group is created.</li>
<li>_email_tag_ : Emails associated to the module tags.</li>
<li>_modulegraph_nh_: (Only for alerts that use the command eMail) Returns an image 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.</li>
</ul>
<p>
</p>
<p>
Example: Agent _agent_ has fired alert _alert_ with data _data_
</p>

20
pandora_console/include/help/en/help_alert_fields_description.php
View File

@ -1,10 +1,10 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Fields description</h1>
Is possible configure a custom description to each field in the command configuration.
<br><br>
This description will appear in the action configuration form near the field text box when this command is selected.
<?php
/**
* @package Include/help/en
*/
?>
<h1>Field descriptions</h1>
It’s possible to configure a custom description for each field in the command’s settings.
<br><br>
This description will appear on the action’s configuration form next to the field’s text box when the command is selected.

38
pandora_console/include/help/en/help_alert_fields_values.php
View File

@ -1,19 +1,19 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Fields values</h1>
To limit the possible values on a field, is possible to define a list of value/tag. If this list is defined, the field will be a selection combo.
<br><br>
The format will be the following:
<br><br>
value1,tag1;value2,tag2;value3,tag3
<br><br>
Example:
<br><br>
1,Number one;2,Number two;3,Number three;4,Number four
<br><br>
Also is possible to configure the field as a HTML editor by introducing the value <i>_html_editor_</i>.
<?php
/**
* @package Include/help/en
*/
?>
<h1>Field values</h1>
To limit the possible values for a field, its possible to define a value/tag list. If this list is defined, the field will be a selection combo.
<br><br>
The format must be the following:
<br><br>
value1,tag1;value2,tag2;value3,tag3
<br><br>
Example:
<br><br>
1,Number one;2,Number two;3,Number three;4,Number four
<br><br>
It’s also possible to indicate that the field must be an HTML editor for which we must introduce the value <i>_html_editor_</i>.

143
pandora_console/include/help/en/help_alert_macros.php
View File

@ -1,72 +1,71 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert macros</h1>
<p>
Besides the defined module macros, the following macros are available:
</p>
<ul>
<li>_field1_: User defined field 1.</li>
<li>_field2_: User defined field 2.</li>
<li>_field3_: User defined field 3.</li>
<li>_field4_: User defined field 4.</li>
<li>_field5_: User defined field 5.</li>
<li>_field6_: User defined field 6.</li>
<li>_field7_: User defined field 7.</li>
<li>_field8_: User defined field 8.</li>
<li>_field9_: User defined field 9.</li>
<li>_field10_: User defined field 10.</li>
<li>_agent_: Name of the agent that fired the alert.</li>
<li>_agentcustomfield_<i>n</i>_: Agent custom field number <i>n</i> (eg. _agentcustomfield_9_).</li>
<li>_agentcustomid_: Agent custom ID.</li>
<li>_agentdescription_: Description of the agent who fired alert.</li>
<li>_agentgroup_: Agent group name.</li>
<li>_agentstatus_: Current status of the agent.</li>
<li>_address_: Address of the agent that fired the alert.</li>
<li>_timestamp_: Time when the alert was fired (yy-mm-dd hh:mm:ss).</li>
<li>_timezone_: Timezone name that _timestamp_ represents in.</li>
<li>_data_: Module data that caused the alert to fire.</li>
<li>_alert_description_: Alert description.</li>
<li>_alert_threshold_: Alert threshold.</li>
<li>_alert_times_fired_: Number of times the alert has been fired.</li>
<li>_module_: Module name.</li>
<li>_modulecustomid_: Module custom ID.</li>
<li>_modulegroup_: Module group name.</li>
<li>_moduledescription_: Description of the module who fired the alert.</li>
<li>_modulestatus_: Status of the module.</li>
<li>_alert_name_: Alert name.</li>
<li>_alert_priority_: Numerical alert priority.</li>
<li>_alert_text_severity_: Text alert severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).</li>
<li>_event_text_severity_: (Only event alerts) Text event (who fire the alert) severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).</li>
<li>_event_id_: (Only event alerts) Id of the event that fired the alert.</li>
<li>_id_agent_: Id of agent, useful to build direct URL to redirect to a Pandora FMS console webpage.</li>
<li>_id_group_ : Id of agent group.</li>
<li>_id_alert_: Numerical ID of the alert (unique), used to correlate on third party software.</li>
<li>_policy_: Name of the policy the module belongs to (if applies).</li>
<li>_interval_: Execution interval of the module </li>
<li>_target_ip_: IP address of the target of the module.</li>
<li>_target_port_: Port number of the target of the module.</li>
<li>_plugin_parameters_: Plug-in Parameters of the module.</li>
<li>_groupcontact_: Group contact information. Configured when the group is created.</li>
<li>_groupcustomid_: Group custom ID.</li>
<li>_groupother_: Other information about the group. Configured when the group is created.</li>
<li>_name_tag_: Names of the tags associated to the module.</li>
<li>_email_tag_: Emails associated to the module tags.</li>
<li>_phone_tag_: Phone numbers associated to the module tags.</li>
<li>_moduletags_: URLs associated to the module tags.</li>
<li>_alert_critical_instructions_: Instructions for the CRITICAL status contained in the module.</li>
<li>_alert_warning_instructions_: Instructions for the WARNING status contained in the module.</li>
<li>_modulegraph_<i>n</i>h_: (>=6.0) (Only for alerts that use the command <i>eMail</i>)
Returns an image codified in base64 of a module graph with a period of <i>n</i> 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.</li>
</ul>
<p>
Example: Agent _agent_ has fired alert _alert_ with data _data_
</p>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert macros</h1>
<p>
Besides the defined module macros, the following macros are available:
</p>
<ul>
<li>_field1_: User defined field 1.</li>
<li>_field2_: User defined field 2.</li>
<li>_field3_: User defined field 3.</li>
<li>_field4_: User defined field 4.</li>
<li>_field5_: User defined field 5.</li>
<li>_field6_: User defined field 6.</li>
<li>_field7_: User defined field 7.</li>
<li>_field8_: User defined field 8.</li>
<li>_field9_: User defined field 9.</li>
<li>_field10_: User defined field 10.</li>
<li>_agent_: Name of the agent that triggered the alert.</li>
<li>_agentcustomfield_<i>n</i>_: Agent custom field number <i>n</i> (eg. _agentcustomfield_9_).</li>
<li>_agentcustomid_: Agent custom ID.</li>
<li>_agentdescription_: Description of the agent that triggered the alert.</li>
<li>_agentgroup_: Agent’s group name.</li>
<li>_agentstatus_: Current agent status.</li>
<li>_address_: Address of the agent that triggered the alert.</li>
<li>_timestamp_: Time and date on which the alert was triggered (yy-mm-dd hh:mm:ss).</li>
<li>_timezone_: Timezone that is represented on _timestamp_.</li>
<li>_data_: Module data that caused the alert to fire.</li>
<li>_alert_description_: Alert description.</li>
<li>_alert_threshold_: Alert threshold.</li>
<li>_alert_times_fired_: Number of times the alert has been triggered.</li>
<li>_module_: Module name.</li>
<li>_modulecustomid_: Module custom ID.</li>
<li>_modulegroup_: Module’s group name.</li>
<li>_moduledescription_: Description of the module that triggered the alert.</li>
<li>_modulestatus_: Module status.</li>
<li>_alert_name_: Alert name.</li>
<li>_alert_priority_: Alert’s numeric priority.</li>
<li>_alert_text_severity_: Priority level, in text, for the alert (Maintenance, Informational, Normal Minor, Major, Critical).</li>
<li>_event_text_severity_: (Only event alerts) Text event (which triggered the alert) severity (Maintenance, Informational, Normal Minor, Warning, Major, Critical).</li>
<li>_event_id_: (Only event alerts) ID of the event that triggered the alert.</li>
<li>_id_agent_: Agent’s ID, useful for building a direct URL that redirects to a Pandora FMS console webpage.</li>
<li>_id_group_ : Agent group ID.</li>
<li>_id_alert_: Alert’s numeric ID (unique), used to correlate the alert with third party software.</li>
<li>_policy_: Name of the policy that the module belongs to (if applies).</li>
<li>_interval_: Module’s execution interval </li>
<li>_target_ip_: IP address for the module’s target.</li>
<li>_target_port_: Port number for the module’s target.</li>
<li>_plugin_parameters_: Module’s Plugin parameters.</li>
<li>_groupcontact_: Group’s contact information. Configured when the group is created.</li>
<li>_groupcustomid_: Group’s custom ID.</li>
<li>_groupother_: Other information about the group. Configured when the group is created.</li>
<li>_name_tag_: Names of the tags related to the module.</li>
<li>_email_tag_: Emails associated to the module’s tags.</li>
<li>_phone_tag_: Phone numbers related to the module’s tags.</li>
<li>_moduletags_: URLs associated to the module’s tags.</li>
<li>_alert_critical_instructions_: Instructions for CRITICAL status contained in the module.</li>
<li>_alert_warning_instructions_: Instructions for WARNING status contained in the module.</li>
<li>_modulegraph_<i>n</i>h_: (>=6.0) (Only for alerts that use the command <i>eMail</i>)
Returns an image encoded in base64 of a module’s graph with a period of <i>n</i> 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.</li>
</ul>
<p>
Example: Agent _agent_ has fired alert _alert_ with data _data_
</p>

16
pandora_console/include/help/en/help_alert_recovery.php
View File

@ -1,8 +1,8 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert recovery</h1>
It defines whether Pandora FMS launches another alert when the alert condition is recovered. It has the same field1, but adds "[RECOVER]" to field2 and field3. It is disabled by default.
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert recovery</h1>
It defines whether Pandora FMS launches another alert when the alert’s condition is recovered. It has the same “field1”, but adds "[RECOVER]" to “field2” and “field3”. It is disabled by default.

30
pandora_console/include/help/en/help_alert_special_days.php
View File

@ -1,15 +1,15 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Special days list</h1>
<p>Allows to define special days, holidays and special working days, for alert templates. They are treated as the same day of the week you selected.</p>
<p>For example, assume that is a holiday, May 03, 2012. When you define '2012-05-03' with 'Sunday', that day is treated as the same as Sunday. The date format is YYYY-MM-DD. If you want to define same day every year, you can use '*' for YYYY.
</p>
<p>
Note: To enable special days list, "Use special days list" should be set on the alert template (step2).
</p>
<?php
/**
* @package Include/help/en
*/
?>
<h1>List of special days</h1>
<p>Allows defining special days, holidays and special work days, for alert templates. They are treated as the same day of the week you selected.</p>
<p>For example, let’s suppose that the 3rd of May 2012 is a holiday. When we define ’03-05-2012’ as a ‘Sunday’, this day will be treated as if it were a Sunday. The date format is YYYY-MM-DD. If the year has to remain unspecified, YYYY can be replaced by ‘*’.
</p>
<p>
Note: To enable the list of special days, "Use list of special days” should be enabled on the alert’s template (step2).
</p>

18
pandora_console/include/help/en/help_alert_template.php
View File

@ -1,9 +1,9 @@
<?php
/*
* @package Include/help/es/
*/
?>
<h1>Alert template</h1>
<p>Alert templates are like preset alerts that are useful to apply on agents and modules used to fire commands. This make more easy to deal with alerts.</p>
<?php
/*
* @package Include/help/es/
*/
?>
<h1>Alert templates</h1>
<p>Alert templates are like preset alerts that are useful to apply on agents and modules used to fire commands. This make it more easy to deal with alerts.</p>

30
pandora_console/include/help/en/help_alert_type.php
View File

@ -1,15 +1,15 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert type</h1>
There are some predefined alerts, in which is very likely you will have to adjust, in case your system does not provide the internal commands needed to execute those alerts. The development team has tested these alerts with Red Hat Enterprise Linux (RHEL), CentOS, Debian and Ubuntu Server.
<ul>
<li><b>eMail</b>: Sends an e-mail from Pandora FMS Server. It uses your local sendmail. If you installed other kind of local mailer or do not have one, you should install and configure sendmail or any equivalent (and check the syntax) to be able to use this service. Pandora FMS rely on system tools to execute almost every alert, it will be necessary to check that those commands work properly on your system.</li>
<li><b>Internal audit</b>: This is the only "internal" alert, it writes the incident in Pandora FMS internal audit system. This is stored in Pandora FMS Database and can be reviewed with Pandora FMS audit viewer from the Web console.</li>
<li><b>Pandora FMS Alertlog</b>: Saves information about the alert inside a text file (.log). Use this type of alert to generate log files using the format you need. To do so, you will need to modify the command so that it will use the format and file you want. Note that Pandora FMS does not handle file rotation, and that Pandora FMS Server process that executes the alert will need acess to the log file to write on it.</li>
<li><b>Pandora FMS Event</b>: This alert create an special event into Pandora FMS event manager.</li>
</ul>
This alerts are predefined and cannot be deleted, however the user can define new ones that use custom commands and add with the Alert management.
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert types</h1>
There are some preset alerts, on which it’s very likely you will have to make adjustments, in case your system does not provide the internal commands needed to execute those alerts. The development team has tested these alerts with Red Hat Enterprise Linux (RHEL), CentOS, Debian and Ubuntu Server.
<ul>
<li><b>eMail</b>: Sends an e-mail from Pandora FMS’ Server. It uses your local sendmail. If you have installed another kind of local mailer or do not have one, you should install and configure sendmail or any equivalent (and check the syntax) to be able to use this service. Pandora FMS relies on system tools to execute almost every alert, it will be necessary to check that those commands work properly on your system.</li>
<li><b>Internal audit</b>: This is the only "internal" alert, it writes the incident in Pandora FMS’ internal auditing system. This is stored on Pandora FMS’ Database and can be reviewed from the web console with the Pandora FMS audit viewer.</li>
<li><b>Pandora FMS’ Alertlog</b>: Saves information about alerts inside a text file (.log). Use this type of alert to generate log files using the format you need. To do so, you will need to modify the command so that it will use the format and file you want. Note that Pandora FMS does not handle file rotation, and that Pandora FMS’ Server process that executes the alert will need access to the log file in order to write on it.</li>
<li><b>Pandora FMS Events</b>: This alert creates an special event on the Pandora FMS event manager.</li>
</ul>
These alerts are predefined and cannot be deleted, however the user can define new ones that can use custom commands, and add them using Alert management.

19
pandora_console/include/help/en/help_alert_validation.php
View File

@ -1,9 +1,10 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert validation</h1>
<p>
ACK an alert only changes it's current bit and clear the "fired", so if alert fired again, the process continues. It's oriented to alerts with a long threshold, for example 1 day. If you get an alarm, and you review and fix it, you probably want to set to green status and don't wait 1 day to get green again.
</p>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alert validations</h1>
<p>
Validating an alert only changes its status bit and cleans the &laquo;triggered&raquo;, this way if the alert is triggered again, the process just continues. This is oriented to alerts with larger thresholds, for example, 1 day. If you get an alert, check it and mark it as read, you’ll probably want to establish the status to green and won’t want to wait 1 day until it’s green again.
</p>

72
pandora_console/include/help/en/help_alerts.php
View File

@ -1,36 +1,36 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alerts</h1>
<i>Assigning Alerts to modules</i><br>
<i>Adding new alert to a module</i><br>
<i>Editar an alert from a module</i><br>
<p>The next step after adding an agent, having configured its modules, and defined the alerts, is assigning those alerts to the agent. This step is necessary to establish alert conditions in those desired cases. This is done by clicking on the agent to be configured in the "Manage agents" option, from Administration menu, or using the edition mode and selecting the tab "Alerts", from the agent view.</p>
<p>The next fields must be filled to assign an alert:<br><br></p>
<li><b>Alert type:</b> This can be selected from the alert list previously generated.</li>
<li><b>Max. Value:</b> Defines the maximum value for a module. Any value above that threshold will trigger the alert.</li>
<li><b>Min. Value:</b> Defines the minimum value for a module. Any value below that will trigger the alert. "max." &amp; "min." couple are the key values while defining an alert, since they define the range of normal values, out of that range Pandora FMS will trigger the alert.</li>
<li><b>Alert text:</b> In case of string modules, you can define a regular expression or a single string to match contents of data module to trigger the alert.</li>
<li><b>Time from / Time to:</b> This defines a range of "valid" time range to fire alerts.</li>
<li><b>Description:</b> Describes the function of the alert, and it is useful to identify the alert among the others in the general view of alerts.</li>
<li><b>Field #1 (Alias, name):</b> Define the used value for the "_field1_" variable.</li>
<li><b>Field #2 (Single Line):</b> Define the used value for the "_field2_" variable.</li>
<li><b>Field #3 (Full Text):</b> Define the used value for the "_field3_" variable.</li>
<li><b>Time threshold:</b> Time counter since the first alarm was triggered (or condition to trigger it) . During that time, the alerts are handled with the rest of the parameters (Min. number of alerts, Max. number of alerts). You can choose between the interval configured or define other interval.</li>
<li><b>Min. number of alerts:</b> Minimum number of alerts needed to start triggering an alert. Works as a filter, needed to remove false positives.</li>
<li><b>Max. number of alerts:</b> Maximum number of alerts that can be sent consecutively during the same time threshold.</li>
<li><b>Assigned module:</b> Module to be monitored by the alert.</li><br>
<p>All the alerts of an agent can be seen using the "Alerts" tab. Let's see an example:<br>
"I want to fire an alert when XXX goes down, and please, dont't disturb me again at least for one hour. After that time, if it is still down, fire another alert and wait another hour".</p>
<p>You need to setup:</p>
<ul>
<li>Time threshold 3600 (1 hour).</li>
<li>Min. number of alerts = 1.</li>
<li>Max. number of alerts = 1.</li>
</ul>
<?php
/**
* @package Include/help/en
*/
?>
<h1>Alerts</h1>
<i>Assigning Alerts to modules</i><br>
<i>Adding new alerts to a module</i><br>
<i>Editing a module’s alert</i><br>
<p>The next step after adding an agent, having configured its modules, and defined the alerts, is assigning those alerts to the agent. This step is needed to establish alert conditions in case we want to do so. This is done by clicking on the agent we wish to configure in the "Manage agents" option, from the Administration menu, or using the editing mode and selecting the “alerts” tab from the agent view.</p>
<p>The following fields must be completed in order to assign an alert:<br><br></p>
<li><b>Alert type:</b> This can be selected from the previously generated alert list.</li>
<li><b>Max. Value:</b> Defines the maximum value for a module. Any value above that threshold will trigger the alert.</li>
<li><b>Min. Value:</b> Defines the minimum value for a module. Any value below that will trigger the alert. The ”max." &amp; "min." couple are key values when defining an alert, since they define the range for normal values. Outside that range Pandora FMS will trigger the alert.</li>
<li><b>Alert text:</b> In the case of string modules you can define a regular expression or a substring to match the contents of a data module in order to trigger the alert.</li>
<li><b>Time from / Time to:</b> This defines a “valid” timespan to trigger alert.</li>
<li><b>Description:</b> Describes the function of the alert, and it is useful to identify the alert among the others in the general view of alerts.</li>
<li><b>Field #1 (Alias, name):</b> Defines the value used for the "_field1_" variable.</li>
<li><b>Field #2 (Single Line):</b> Defines the value used for the "_field2_" variable.</li>
<li><b>Field #3 (Full Text):</b> Defines the value used for the "_field3_" variable.</li>
<li><b>Time threshold:</b> defines the timespan during which its guaranteed that an alert will not fire more times than the set Maximum number of alerts</i> Once this timespan is surpassed, an alert is recovered if it reaches a correct value, except if the <i> Alert Recovery</i> value is enabled, in which case the alert will recover immediately after receiving a correct value, regardless of the threshold.</li>.
<li><b>Min. number of alerts:</b> Minimum number of alerts needed to start triggering an alert. Works as a necessary filter to remove false positives.</li>
<li><b>Max. number of alerts:</b> Maximum number of alerts that can be sent consecutively during the same time period.</li>
<li><b>Assigned module:</b> Module that needs to be monitored by the alert.</li><br>
<p>All the alerts of an agent can be seen using the &laquo;Alerts&raquo; tab. An example is shown here:<br>
"I want to fire an alert when XXX goes down, yet I don’t wish to be bothered again during, at least, one hour. After this time has gone by, if it’s still down, another alert should go off and another hour should go by”.</p>
<p>You need to set:</p>
<ul>
<li>Time threshold 3600 (1 hour).</li>
<li>Min. number of alerts = 1.</li>
<li>Max. number of alerts = 1.</li>
</ul>

681
pandora_console/include/help/en/help_alerts_config.php
View File

@ -1,411 +1,270 @@
<?php
/**
* @package Include/help/es
*/
?>
<h1>Pandora FMS Alert Configuration Quick Guide </h1>
<br>
<b>Introduction to the Current Alert System</b><br>
<br>
People usually complains about the complexity of defining alerts in
Pandora FMS. Before, until version 2.0, alerts were more simple to
configure. For each alert, it was defined the condition and what it did
when the action was not done, for each case. It was a more "intuitive"
thing ( but it had also fields such as the "threshold" alert that caused
lot of headaches to more than one people!). It was very simple, but, was
it worth it ?<br>
<br>
One of our best users ( because he had lots of agents installed and
managed very well Pandora FMS too), mention us that for creating an
alert in 2000 modules it was very difficult, specially when you have to
modify something in all of them. Due to this and other problems, we had
to modify the alert system to it would be a modular one and to it could
separate the definition of the alert firing condition (Alter template)
from the action to execute when it is fired (Alert action) and from the
command that is executed in the action (Alert command). The combination
of an alert template with a module triggers the alert.<br>
<br>
This way, if I have 1000 systems with a module called "Host alive" and
all of them have associated an alert template called "Host down", then
an alert called " Call to the operator" will be executed by default, and
if I want to change the minimum number of alerts that should be fired
before notifying it to the operator, I will only need to make a change
in the definition of the template, not doing it one by one, in the 1000
alerts to modify this condition.<br>
<br>
Several users only manage a few tens of machines, but there are users
with hundreds, even thousands of systems monitored with Pandora FMS, and
we have to try making possible that with Pandora FMS it would be
possible to manage all kind of environments.<br>
<br>
<br>
<br>
<b>Alert structure </b><br>
<br>
<?php
html_print_image("images/help/alert01.png", false,
array('width' => '550px'));
?>
<br>
An alert is compound by:<br>
<br>
<i>Commands</i><br>
<i>Actions</i><br>
<i>Templates </i><br>
<br>
A command defines the operation to perform when the alert is fired. Some
examples of command coudl be: write in a log, send an email or SMS,
execute a script or a program, etc.<br>
<br>
An action links a command with a template and allow you to customize the
command execution using three generic parameters: Field 1, Field 2 and
Field 3. These parameters allow you to customize the command execution
because they are passed as input parameters in command execution.<br>
<br>
In the template you defined the alert generic parameters which are:
firing conditions, firing actions and alert recovery.<br>
<br>
<i>Firing conditions:</i> the conditions when the alert will be fired,
for example: when the data is above a threshold, when the status is
critical, etc.<br>
<i>Firing actions:</i> configuration for the action that will be
performed when the alert is fired.<br>
<i>Alert recovery</i> configuration for actions performed when the
system is recovered after the alert was fired.<br>
<br>
<b>Alert system information flow</b><br>
<br>
When you define the actions and the templates you have some generic
fields called: Field1, Field2 and Field3. They are the parameters passed
as input parameters in command execution. The values of this parameters
are propagated from template to action and then to the command. The
value propagation from template to action will only be peformed if the
field defined in the action hasn't got any value, otherwise the value is
used.<br>
<br>
<?php
html_print_image("images/help/alert02.png", false,
array('width' => '550px'));
?>
<br>
This is an example of how template values are ovewritten by the action
values.<br>
<br>
<?php
html_print_image("images/help/alert03.png", false,
array('width' => '550px'));
?>
<br>
For example we can create a template that fires an alert and sends and
email with the following fields:<br>
<br>
<b>Template:</b><br>
Field1: <i>myemail@domain.com</i><br>
Field2: <i>[Alert] The alert was fired</i><br>
Field3: <i>The alert was fired!!! SOS!!!</i><br>
<br>
<b>Action:</b><br>
Field1: <i>myboss@domain.com</i><br>
Field2:<br>
Field3:<br>
<br>
The value that will be passed to the command are:<br>
<br>
<b>Command:</b><br>
Field1: myboss@domain.com<br>
Field2: [Alert] The alert was fired<br>
Field3: The alert was fired!!! SOS!!!<br>
<br>
<b>Defining one Alert</b><br>
<br>
Now, supposing we are in the previous case, we have one need: to monitor
one module that has numerical values. In our case, it's a module that
evaluates the system CPU, in other case, it could be a temperature
sensor that puts the value in degrees Celsius. Let's see first that our
module receives the data correctly:<br>
<br>
<?php
html_print_image("images/help/alert04.png", false,
array('width' => '550px'));
?>
<br>
In this screenshot, we can see that we have a module called sys_cpu with
a current value of 7. In our case, we want that it fires an alert when
it would be higher than 20. For it, we're going to configure the module
to it goes on CRITICAl status when it gets higher than 20. For it, we
should do click in the adjustable wrench to configure the monitor
performance:<br>
<br>
<?php
html_print_image("images/help/alert05.png", false,
array('width' => '550px'));
?>
<br>
For it, we modify the value selected in red in the following
screenshot:<br>
<br>
<br>
<br>
<?php
html_print_image("images/help/alert06.png", false,
array('width' => '550px'));
?>
<br>
Agree and record the change. Now, when the value of the CPU module would
be 20 or higher, it will change its status to CRITICAL and it will be
seen in red color, as we can see here.<br>
<br>
<?php
html_print_image("images/help/alert07.png", false,
array('width' => '550px'));
?>
<br>
We have already done that the system knows how to recognize when
something is right (OK, green color) and when is wrong (CRITICAL, red
color). Now, what we should do is that it send us an email when the
module changes to this status. For it, we will use the Pandora FMS alert
system.<br>
<br>
To do this, the first thing we should do is to make sure that there is
one command that does what we need (to send an email). This example is
easy because it's a predefined command in Pandora FMS to send mails.<br>
<br>
<b>Configuring the Alert</b><br>
<br>
Now, we have to create an action called "Send an email to the operator".
Let's do it: go to the menu -> Alerts -> Actions and click to create a
new action:<br>
<br>
<?php
html_print_image("images/help/alert08.png", false,
array('width' => '550px'));
?>
<br>
This action uses the command "Send email" and it's really simple, so I
only need to fill in one field (Field 1) and leave the other two
empties. This is one of the most confused parts of the Pandora FMS alert
system: What are the fields:field1, field2 and field3?.<br>
<br>
These fields are the ones that are used to "pass" the information of the
alert template to the command, and also from it to the command, so both
the Template and the Command can give different information to the
command. In this case, the command only fix the field 1, and we leave
the field2 and the field 3 to the template, as we see next.<br>
<br>
The field 1 is the one we use to define the operator email, in this
case, a false mail to "sancho.lerena@notexist.com".<br>
<br>
<b>Configuring the Template (Alert template)</b><br>
<br>
Now, we have to create an alert template, as generic as possible, in
order to could use it later. That would be "This is wrong, because I
have a module in Critical status" and that by default, send an email to
the operator. Let's go to the administration menu-> Alerts-> Templates
and click on the button to create a new alert template:<br>
<br>
<?php
html_print_image("images/help/alert09.png", false,
array('width' => '550px'));
?>
<br>
The element that defines the condition is the field "Condition". In this
case, it is selected to "Critical status" so this template, when it
would be associated to a module, will be fired when the associated
module would be in critical status. We have configured the "cpu_sys"
module before in order it becomes to critical status when it would be 20
or more.<br>
<br>
The priority defined here as "Critical" is the priority of the alert,
that has nothing to do with the "Critical" status of the module. The
criticity of alerts is to could visualize them after, in other views,
such as the event view, with different criticities.<br>
<br>
Go to step 2, clicking on the "next" button:<br>
<br>
<?php
html_print_image("images/help/alert10.png", false,
array('width' => '550px'));
?>
<br>
The step 2 defines all the "fines" configuration "values" of the alert
template in the trigger condition. Some of them, the first ones, are
quite simple, and they limit the moment of the action of this alert to
some specific days between different hours.<br>
<br>
The most critical parameters here are these:<br>
<br>
<i>Time threshold:</i> It's one day by default. If one module is always
down, during, for example one day, and we have here a value of 5
minutes, then, it means that it would be sending us alerts every 5
minutes. If we adjust it for one day (24 hours), it will only send us
the alert once, when it downs. If the module recovers and get down
again, it will send us an alert again, but if it continues down from the
second down, then it won't send us alerts any more until 24 hours.<br>
<br>
<i>Min. Number of alerts:</i> Minimum number of times that the condition
should be ( in this case, that the module would be in CRITICAL status)
before Pandora FMS executes the actions associated to the alert
template. Is a way to avoid that false positives "overflow" me with
alerts, or that an erratic performance (now well, now wrong) does that
many alerts would be fired. If we put here 1, it means that until it
happens at least once, I won't consider it. If we put 0, the first time
the module would be wrong, then it will fired the alert.<br>
<br>
<i>Max. Number of alerts:</i> 1 means that it will execute the action
only once. If we have here 10, it will execute the action 10 times. It's
a way to limit the number of times an alert could be executed.<br>
<br>
Now we have fields "field1, field2 and field3" again. Now we can see
that the field1 is blank, that is exactly the one that we've defined
when we configured the action. The field2 and the field3 are used in the
action of sending an email to define the subject and the message text,
whereas the field1 is used to define the receivers (separated by
commas). So the template, using some macros, is defining the subject and
the message alert as in our case we'll receive a message as the one that
follows (supposing that the agent where it's the module is called
"Farscape"):<br>
<br>
<i>To: sancho.lerena@notexist.ocm<br>
Subject: [PANDORA] Farscape cpu_sys is in CRITICAL status with value
20<br>
Texto email:<br>
<br>
This is an automated alert generated by Pandora FMS<br>
Please contact your Pandora FMS for more information. *DO NOT* reply
this email.<br>
</i><br>
Given that the default action is the one we have defined previously, all
the alerts that use this template will use this predefined action by
default, unless it would be modified.<br>
<br>
In case 3, we'll see that it's possible to configure the alert system in
order to it notify when the alert has stopped.<br>
<br>
<?php
html_print_image("images/help/alert11.png", false,
array('width' => '550px'));
?>
<br>
It's almost the same, but in field1 it's not defined, because it'll be
used the same that comes defined in the action that has been executed
previously (when firing the alert). In this case it'll send only an
email when a subject that says that the condition in the cpu-syst module
has been recovered).<br>
<br>
The alert recovery is optional. It's important to say that if in the
alert recovery data are fields (field2 and field3) that are defined,
these "ignore and overwrite the action fields, that's to say, that they
have preference over them. The only valid field that can't be modified
is the field1.<br>
<br>
<b>Associating the Alert to the Command</b><br>
<br>
Now, we have all that we need, we only have to associate the alert
template to the module. For it, go to the alert tab in the agent where
the module is:<br>
<br>
<?php
html_print_image("images/help/alert12.png", false,
array('width' => '550px'));
?>
<br>
It's easy. In this screenshot we can see an alert already configured for
a module named "Last_Backup_Unixtime" to the same template that we have
defined before as "Module critical". Now, in the controls that are
below, we are going to create an association between the module
"cpu-sys" and the alert template "Module critical". By default it'll
show the action that we've defined in this template "Send email to
Sancho Lerena".<br>
<br>
<b>Scaling Alerts</b><br>
<br>
The values that are in the "Number of alerts match from" are to define
the alert scaling. This allows to "redefine" a little more the alert
performance, so if we have defined a maximum of 5 times the times that
an alert could be fired, and we only want that it send us an email, then
we should put here one 0 and one 1, to order it that only send us an
email from time 0 to 1 (that is, once).<br>
<br>
Now we see that we can add more actions to the same alert, defining with
this fields "Number of alerts match from" the alert performance
depending on how many times it would be fired.<br>
<br>
For example: we want that it sends an email to XXXXX the first time it
happens, and if the monitor continues being down, it sends an email to
ZZZZ. For it, after associating the alert, in the assigned alerts table,
I can add more actions to a previously defined alert, as we can see in
the following screenshot:<br>
<br>
<?php
html_print_image("images/help/alert13.png", false,
array('width' => '550px'));
?>
<?php
html_print_image("images/help/alert14.png", false,
array('width' => '550px'));
?>
<br>
<b>Standby alerts</b><br>
<br>
Alerts can be enable, disable or in standby mode. The difference between
the disabled and standby alerts is that the disable alerts just do not
work and therefore will not showed in the alerts view. Standby alerts
will be showed in the alerts view and work, but only at display level.
It will show if are fired or not but will do not engage in configured
actions and will do not generate events.<br>
<br>
Stanby alerts are useful for viewing them without bothering other
aspects<br>
<br>
<b>Using Alert Commands different from the email</b><br>
<br>
The email, as a command is internal to Pandora FMS and can't be
configured, that is, field1, field2 and field3 are fields that are
defined that are used as receiver, subject and text of the message. But,
what happens if I want a different action that is defined by me?<br>
<br>
We're going to define a new command, something completely defined by us.
Imagine that we want to create a lof file with each alert that we find.
The format of this log file should be something like:<br>
<br>
<i>DATE_ HOUR - NAME_AGENT - NAME_MODULE - VALUE - PROBLEM
DESCRIPTION</i><br>
<br>
Where VALUE is the value of the module at this moment. It'll be several
log files, depending on the action that calls to the command. The action
will define the description and the file to which the events go to.<br>
<br>
For it, first we are going to create a command as follows:<br>
<br>
<?php
html_print_image("images/help/alert15.png", false,
array('width' => '550px'));
?>
<br>
And we're going to define an action:<br>
<br>
<?php
html_print_image("images/help/alert16.png", false,
array('width' => '550px'));
?>
<br>
If we take a look at the log that we've created:<br>
<br>
<i>2010-05-25 18:17:10 - farscape - cpu_sys - 23.00 - Custom alert for
LOG#1</i><br>
<br>
<br>
We can see that the alert was fired at 18:17:10 in the " farscape"
agent, in the "cpu_sys" module, with a data of "23.00" and with the
description that we chose when we defined the action.<br>
<br>
As the command execution, the field order and other things could do that
we don't understand well how the command is finally executed, the
easiest thing is to activate the debug traces of the pandora server
(verbose 10) in the pandora server configuration file
/etc/pandora/pandora_server.conf, and restart the server
(/etc/init.d/pandora_server restart) and we take a look to the file
/var/log/pandora/pandora_server.log looking for the exact line with the
alert command execution that we've defined, to see how the Pandora FMS
server is firing the command.<br>
<br>
<?php
/**
* @package Include/help/es
*/
?>
<h1>Pandora FMS’ Quick Guide to Alert Configuration </h1>
<br>
<b>Introduction to the Current Alert System</b><br>
<br>
People usually complain about the complexity of defining alerts on
Pandora FMS. Before, until version 2.0, alerts were easier to
configure. For each alert the condition and what it did when the action was not completed was defined for each case. It was a more "intuitive"
thing (but it also had fields such as the "threshold" alert that caused
many headaches to more than one person!). It was very simple, but, was
it worth it ?<br>
<br>
One of our “star” users (we mention this because he had A LOT of agents installed, and also knew the inner workings of Pandora FMS quite well) mentioned that creating an alert for 2000 modules was tremendously complicated, especially when it was necessary to modify something for all of them. Due to this, and other issues, we decided to modify the alert system so that it could be modular, so that the alert’s definition and its triggering condition (template) could be separated from the action that has to be executed when the alert is triggered (alert action) and from the command that is run within the action (Alert command). The combination of an alert template with a module triggers the alert itself.<br><br>
This way, if I have 1000 devices with a module named “Host Alive” and all of them have a related alert template named “Host Down” that when triggered executes an action named “Warn the Operator”, and I wish to change the minimum number of alerts that must be fired before the Operator is warned, I only have to change the definition on the template instead of going one by one over the 1000 alerts to modify that specific condition.<br><br>
Many users only manage a few dozen devices, but there are many users with hundreds—even thousands—of systems monitored with Pandora FMS, and we have to try and make it so that with Pandora FMS all types of environments can be managed.<br>
<br>
<br>
<br>
<b>Alert structure </b><br>
<br>
<?php
html_print_image("images/help/alert01.png", false,
array('width' => '550px'));
?>
<br>
An alert is composed of:<br>
<br>
<i>Commands</i><br>
<i>Actions</i><br>
<i>Templates </i><br>
<br>
A command defines the operation that will take place when an alert is fired. Examples of commands can be: creating a registry on a log, sending an email, running a script or program, etc.<br><br>
An action links a command to a template and allows the
command execution to be customised using three generic parameters: Field 1, Field 2 and
Field 3. These parameters allow you to tweak the command’s execution
because they are passed as input parameters at the time of said execution.<br><br>
On the template generic alert parameters are defined. These are: Triggering conditions, firing actions, and alert recovery conditions.<br><br>
<i>Triggering conditions:</i> the conditions under which the alert will be triggered,
for example: when the amount of data surpasses a set threshold, when a status is
critical, etc.<br>
<i>Firing actions:</i> configuration for the action that will be
performed when the alert is triggered.<br>
<i>Alert recovery</i> settings for actions that will be performed when the system recovers from the alert.<br>
<br>
<b>Information flow on the alert system</b><br>
<br>
When the actions and templates are defined we have some generic fields available named Field1, Field2 and Field3 that are the ones that will be passed on as input parameters for the command’s execution. The values for these parameters are propagated from the template onto the action, and lastly to the command. The template to action transition only takes place if the field corresponding to the action doesn’t have an assigned value, if the action has an assigned value, it’s kept.<br><br>
<?php
html_print_image("images/help/alert02.png", false,
array('width' => '550px'));
?>
<br>
This is an example of how template values are overwritten by action
values.<br>
<br>
<?php
html_print_image("images/help/alert03.png", false,
array('width' => '550px'));
?>
<br>
For example we can create a template that fires an alert and sends and
email that includes the following fields:<br>
<br>
<b>Template:</b><br>
Field1: <i>myemail@domain.com</i><br>
Field2: <i>[Alert] The alert has been triggered</i><br>
Field3: <i>The alert has been triggered!!! SOS!!!</i><br>
<br>
<b>Action:</b><br>
Field1: <i>myboss@domain.com</i><br>
Field2:<br>
Field3:<br>
<br>
The values passed on to the command would be:<br>
<br>
<b>Command:</b><br>
Field1: myboss@domain.com<br>
Field2: [Alert] The alert has been triggered<br>
Field3: The alert has been triggered!!! SOS!!!<br><br>
For fields “Field2” and “Field3” the values set in the template are kept, but for “Field1” the value defined in the action is used.<br><br>
<b>Defining an Alert</b><br><br>
Now we’re going to play ourselves in the prior situation. We have one necessity: to monitor a module that contains numeric values. In our case, it’s a module that measures the system’s CPU, in another case it can be a temperature sensor that retrieves value in degrees celsius. First, let’s make sure our module receives data correctly:<br><br>
<?php
html_print_image("images/help/alert04.png", false,
array('width' => '550px'));
?>
<br>
So, on this screenshot we can see that we have a module named sys_cpu with a current value of 7. In our case we want an alert to go off when it goes over 20. For this we’re going to set the module so that it enters CRITICAL status when it reaches that 20 mark. For this to happen, we click on the wrench icon in order to access the monitor behaviour settings, and modify it from there:<br>
<br>
<?php
html_print_image("images/help/alert05.png", false,
array('width' => '550px'));
?>
<br>
In this case we modify the value marked in red, shown on the following screenshot:<br>
<br>
<br>
<br>
<?php
html_print_image("images/help/alert06.png", false,
array('width' => '550px'));
?>
<br>
We agree and save the change. Now when the CPU module’s value is 20 or more, it’ll change its status to CRITICAL and it will be marked in red, like what is shown on the screenshot below.<br>
<br>
<?php
html_print_image("images/help/alert07.png", false,
array('width' => '550px'));
?>
<br>
We’ve now made it so that the system can discriminate when something is right (OK status, marked in GREEN) and when something is wrong (CRITICAL status, marked in RED). Now what we have to do is make the system send us an email when the module reaches that status. For this we’ll use Pandora FMS’ alert system.<br>
<br>
For this we need to make sure there is a command available that can do what we need it to (in this case, send an email). This example is easy because there is a predefined command on Pandora FMS that is meant to automate email sending, meaning this is already done.<br>
<br>
<b>Configuring the Alert</b><br>
<br>
Now, we have to create an action called "Send an email to the operator".
To do this, navigate to: Menu -> Alerts -> Actions, and click on the button in order to create a
new action:<br>
<br>
<?php
html_print_image("images/help/alert08.png", false,
array('width' => '550px'));
?>
<br>
This action uses the “send email” command, and is really simple, since only one field from the form needs to be filled out (Field1) leaving the other two empty. This is one of the most confusing parts of the alert system on Pandora FMS: what are field1, field2 and field3?<br>
<br>
These fields are the ones used to “pass” the information on from the alert template to the command, and at the same time from that command to the next. This way both the template and the command can provide different information to the command. In this case, the command only establishes field1 and leaves field2 and field3 to be filled by the template, like what is shown next.<br>
<br>
Field1 is the one used to define te operator’s email address. In this case, a supposed email to “sancho.lerena@notexist.com”<br><br>
<b>Configuring the Template (Alert template)</b><br>
<br>
Now we hace to create the most generic alert template possible (so it can be reused in the future) that is “This is wrong, because there is a module in critical status” and that sends an email to the operator as a default action. To do this we head over to the management menu and navigate to: Alerts -> Templates, and from there we click the button that creates a new alert template:<br><br>
<?php
html_print_image("images/help/alert09.png", false,
array('width' => '550px'));
?>
<br>
What defines the condition is the “Condition” field, which in this case is marked to “Critical Status”. This way,the template, once linked to a module, will be triggered when the related module is in critical status. Before this we have already configured the “cpu_sys” module so that it enters critical status when the value is 20 or more.<br>
<br>
The “Critical” priority defined here is the alert’s priority, which has nothing to do with the module’s “Critical” status. The criticality of alerts are meant to be viewed later, in other displays, like the event view, with different levels of criticality.<br>
<br>
We can proceed to step 2 by clicking on the "next" button:<br>
<br>
<?php
html_print_image("images/help/alert10.png", false,
array('width' => '550px'));
?>
<br>
Step 2 defines all the “fine tuning” configuration “values” for the alert template’s triggering condition. Some of them, the first, are very simple: they restrict the acting moment for this alert to certain days in a certain range of hours.<br><br>
The most critical parameters here are the following:<br>
<br>
<i>Time threshold:</i> Set to one day by default. If a module is constantly down during, for example, one day and and we have set a value of 5 minutes here, it means that alerts would be sent every 5 minutes. If we leave it at one day (24hrs.), it’ll only send the alert once, when it goes down. If the module recovers, and drops again, it’ll send another alert, but if it remains down from the second drop, it won’t send more alerts until 24hrs have gone by.<br>
<br>
<i>Min. Number of alerts:</i> The minimum number of times that a condition will have to be met (in this case, that the module is in CRITICAL status) before Pandora FMS runs the actions linked to the alert template. It’s a way to avoid false positives “flooding” you with alerts, or so that an erratic behaviour doesn’t lead to multiply alerts going off. If we place a ‘1’ here it means that until this doesn’t happen at least once, it won’t be taken into account. If i set a value of ‘0’ the first time the module returns an error, the alert will go off.<br>
<br>
<i>Max. Number of alerts:</i> A value of 1 means that it’ll only execute the action once. If we have ’10’ set here, it’ll run the action 10 times. This is a way to limit the number of times an alert can go off.<br>
<br>
Again, we can see the fields “field1, field2, field3”. Now we can see that field1 is blank, which is precisely the one we’ve defined when configuring the action. Field2 and Field3 are used for the “send mail” action to define the subject and the message’s body, whilst Field1 is used to define the recipient(s) of said message (addresses must be separated by commas). Therefore the template, combined with the use of some macros, is defining the subject and alert message in a way that, in our case, we would receive a message like the following (supposing the agent where the module is placed is named “Farscape”):<br>
<br>
<i>To: sancho.lerena@notexist.ocm<br>
Subject: [PANDORA] Farscape cpu_sys is in CRITICAL status with a value
of 20<br>
Message body:<br>
<br>
This is an automated alert generated by Pandora FMS<br>
Please contact your Pandora FMS operator for more information. *DO NOT* reply to
this email.<br>
</i><br>
Given that the default action is the one we have defined previously, all
the alerts that use this template will use this predefined action by
default, unless it were to be modified.<br>
<br>
In the third situation, we’ll see that this alert system can be set to notify when the alert has stopped.<br>
<br>
<?php
html_print_image("images/help/alert11.png", false,
array('width' => '550px'));
?>
<br>
It’s nearly the same, but Field1 isn’t defined, because the same one that was preset on the previously executed action will be used (when the alert was triggered). In this case it’ll send an email with the subject informing that the condition for the cpu_sys module has recovered itself.<br>
<br>
Alert recovery is optional. It’s important to note that if there are fields (Field2 and Field3) defined, these will ignore and overwrite the action’s fields. This means that they have priority over them. The only field that can’t be modified is Field1.<br>
<br>
<b>Associating the Alert to the Module</b><br>
<br>
Now that we have all we needed, we only need to link the alert template to the module. For this we need to navigate to the “Alerts” tab on the agent where the module is:<br>
<br>
<?php
html_print_image("images/help/alert12.png", false,
array('width' => '550px'));
?>
<br>
It’s simple, in this screenshot we can see an alert that is already configured for a module named “Last_Backup_Unixtime” linked to the same template named “Module critical” that we previously defined. Now, in the underlying controls, we’ll create a link between the “cpu_sys” module and the alert template “Module critical”. By default the action defined on that template (“send email to Sancho Lerena”) will be shown.<br>
<br>
<b>Alert scaling</b><br>
<br>
The values found in the “Number of alerts match from” option are meant to define the alert scaling. This allows “redefining” the alert’s behaviour a bit more, this way, if we’ve defined a maximum of 5 times for an alert to go off, and we only want it to send an email, we’ll set a ‘0’ and a ‘1’ here, to tell it to only send an email when the alert goes off one time (so the message is sent only once).<br>
<br>
Now we see that we can add more actions to a single alert, defining with these “number of alerts match from” fields the alert’s behaviour based on how many times it’s fired.<br>
<br>
For example, we may want the action to send an email to XXXXX the first time that it happens, and if the monitor is still down, we may want it to send a second email to ZZZZZ. For this, after liking the alert, in the assigned alerts chart, we can add more actions to an alert that’s already been defined, like what can be see in the following screenshot:<br>
<br>
<?php
html_print_image("images/help/alert13.png", false,
array('width' => '550px'));
?>
<?php
html_print_image("images/help/alert14.png", false,
array('width' => '550px'));
?>
<br>
<b>Alerts on standby</b><br>
<br>
Alerts can be enabled, disabled, or on standby. The difference between enabled, disabled and standby, is that disabled alerts simply won’t work and therefore will not be shown in the alert view. On the other hand, alerts on standby will always appear on the alert view and will work, but only on a visualisation level. This means that it can be seen whether they’re triggered or not, but they won’t perform their set actions nor will they generate events.<br>
<br>
Alerts in standby are useful because they can be viewed without interfering with other aspects.<br>
<br>
<b>Using Alert Commands other than the “send email” command</b><br>
<br>
The email, as a command is internal to Pandora FMS and can’t be configured, this means Field1, Field2 and Field3 are fields that are preset to be used as the recipient, subject and body for the email alert. But, what happens when we want to execute a different, more customised alert?<br>
<br>
We’ll define a new, totally customised command. Imagine that we want to generate a log file with each alert we find. The format for that log file has to be something like:<br>
<br>
<i>DATE_ HOUR - NAME_AGENT - NAME_MODULE - VALUE - PROBLEM
DESCRIPTION</i><br>
<br>
Where VALUE is the module’s value at that time. There will be multiple log files, depending on the action that calls on the command. The action will define the description and the file the events will be stored in.<br>
<br>
For this, first we’ll create a command like the one shown below:<br>
<br>
<?php
html_print_image("images/help/alert15.png", false,
array('width' => '550px'));
?>
<br>
And we're going to define an action:<br>
<br>
<?php
html_print_image("images/help/alert16.png", false,
array('width' => '550px'));
?>
<br>
If we take a look at the log that we've created:<br>
<br>
<i>2010-05-25 18:17:10 - farscape - cpu_sys - 23.00 - Custom alert for
LOG#1</i><br>
<br>
<br>
We can see that the alert was fired at 18:17:10 because of the " farscape"
agent, in the "cpu_sys" module, with a data value of "23.00" and with the
description that we chose when we defined the action.<br>
<br>
Since the command’s execution, the field order and other affairs can make it so we don’t really understand how it’s executed at the end of the command, the easiest thing to do is to activate the Pandora server debug traces (verbose 10) in the configuration file for the Pandora server ‘/etc/pandora/pandora_server.conf’, and then reset the server
(/etc/init.d/pandora_server restart). After, we take a look at the file
/var/log/pandora/pandora_server.log and look for the exact line with the
alert command execution that we've defined, to see how the Pandora FMS
server is launching and executing the command.<br>
<br>

16
pandora_console/include/help/en/help_autocreate_blacklist.php
View File

@ -1,8 +1,8 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Autocreate blacklist</h1>
A comma separated list of user names that will not be autocreated.
<?php
/**
* @package Include/help/en
*/
?>
<h1>Auto-create blacklist</h1>
A comma separated list of user names that will not be created automatically.

23
pandora_console/include/help/en/help_cascade_protection.php
View File

@ -1,12 +1,11 @@
<h1>Cascade protection</h1>
<?php html_print_image("images/help/cascade_protection_ilustration.png", false); ?>
<br>
<p>
This option is designed to avoid a "storm" of alerts coming because a group of agents are unreachable. This kind of behaviour happen when an intermediate device, as for example a router, is down, and all devices behind it are just not reachable, probably that devices are not down and even that devices are working behind another router, in HA mode, but if you don't do nothing probably Pandora FMS thinks they are down because cannot remotely test it with a Remote ICMP Proc test (a ping).
<br><br>
When you enable <i>cascade protection</i> in an agent, this means that if any of it's parents has a CRITICAL alert fired, then the agent alerts WILL NOT BE fired. If agent's parent has a module in CRITICAL or several alerts with less criticity than CRITICAL, alerts from the agent will be fired if should be. Cascade protection checks parents alerts with CRITICAL criticity, including the correlation alerts assigned to the parent.
<br><br>
If you want to use an advanced cascade protection system, just use correlation between sucesive parents, and just enable the Cascade Protection in the children.
</p>
<h1>Cascade protection</h1>
<?php html_print_image("images/help/cascade_protection_ilustration.png", false); ?>
<br>
<p>
This option should be assigned to avoid an “alert storm” that can come in because a group of agents are unreachable. This type of behaviour occurs when an intermediary device, like for example a router, is down and all devices behind it, therefore, cannot be reached. Probably these devices aren’t down and chances indicate that they’re working with another router in HA mode. But, if nothing is done, it’s likely for Pandora FMS to think that they’re down since they can’t be tested using a Remote ICMP Proc test (a Ping check).
<br><br>
When you enable <i>cascade protection</i> for an agent, this means that if any of its parents has a CRITICAL alert fired, then the agent’s alerts WILL NOT BE fired. If the agent's parent has a module in CRITICAL or several alerts with less criticality than CRITICAL, alerts from the agent will be fired as normal if needed. Cascade protection checks parent alerts with CRITICAL priority, including the correlated alerts assigned to the parent.
<br><br>
If you want to use an advanced cascade protection system, just use correlation among successive parents, and just enable Cascade Protection for the children.
</p>

18
pandora_console/include/help/en/help_categories.php
View File

@ -1,10 +1,8 @@
<?php
/**
* @package Include/help/en
*/
?>
<h1>Categories in Pandora FMS</h1>
A category are configurated on the system, and be assigned to the choosed modules. <br>
Administrator is the only user who has permissions to create and configure categories. Can be used for charging modules depending on the category to which they belong.
<?php
/**
* @package Include/help/en
*/
?>
<h1>Categories in Pandora FMS</h1>
On the system some categories can be created and configured to later be assigned to any module desired. <br>
The only user that has the permits to create and configure these categories is the administrator and they can be used to apply a “fee” to modules depending on the category the are sorted into.

16
pandora_console/include/help/en/help_collection_tab.php
View File

@ -1,8 +1,8 @@
<?php
/* Include Package help/en
*/
?>
<h1>Agent's collections</h1>
<p>A collection is group of files (executables or scripts) that are copied to a specific agent directory. With this you can transfer remotely software to agent's machine in a easy way.</p>
<?php
/* Include Package help/en
*/
?>
<h1>Agent Collections</h1>
<p>A collection is group of files (executables or scripts) that are copied to the agent’s device on a specific directory. With this software can be remotely transferred to the agent’s device in a very simple manner. </p>

20
pandora_console/include/help/en/help_collections.php
View File

@ -1,10 +1,10 @@
<?php
/* Include package help/en/
*/
?>
<h3>Collections</h3>
<p>
A collection is group of files (executables or scripts) that are copied to a specific agent directory. With this you can transfer remotely software to agent's machine in a easy way.
</p>
<?php
/* Include package help/en/
*/
?>
<h3>Collections</h3>
<p>
A collection is group of files (executables or scripts) that are copied to a specific agent directory. With this you can easily transfer software remotely on to an agent’s device.
</p>

18
pandora_console/include/help/en/help_component_groups.php
View File

@ -1,9 +1,9 @@
<?php
/*
* @package Include/help/en
*/
?>
<h1>Component groups</h1>
<p>Components are generic modules that you can apply repeatly to agents like a template. With this view you can create groups for this components.</p>
<?php
/*
* @package Include/help/en
*/
?>
<h1>Component groups</h1>
<p>A component is a generic module that can be applied to agents repeatedly as if it were a template. With this view you can create groups for these components.</p>