2013-06-19 Mario Pulido <mario.pulido@artica.es>

*godmode/alerts/alert_list.php,
	godmode/alerts/configure_alert_template.php,
	godmode/alerts/alert_templates.php,
	godmode/alerts/configure_alert_action.php,
	godmode/alerts/configure_alert_command.php,
	godmode/alerts/alert_actions.php,
	godmode/alerts/alert_commands.php,
	include/help/en/help_event_alert.php,
	include/help/en/help_alerts_config.php,
	include/help/es/help_event_alert.php,
	include/help/es/help_alerts_config.php,
	include/help/ja/help_event_alert.php,
	images/help/alert01.png,
	images/help/alert02.png,
	images/help/alert03.png,
	images/help/alert04.png,
	images/help/alert05.png,
	images/help/alert06.png,
	images/help/alert07.png,
	images/help/alert08.png,
	images/help/alert09.png,
	images/help/event01.png,
	images/help/event02.png,
	images/help/event03.png,
	images/help/event04.png,
	images/help/alert10.png,
	images/help/alert11.png,
	images/help/alert12.png,
	images/help/alert13.png,
	images/help/alert14.png,
	images/help/alert15.png,
	images/help/alert16.png: Added new helps



git-svn-id: https://svn.code.sf.net/p/pandora/code/trunk@8353 c3f86ba8-e40f-0410-aaad-9ba5e7f4b01f

pandora_console/ChangeLog

@@ -1,3 +1,38 @@
+2013-06-19 Mario Pulido <mario.pulido@artica.es>	
+
+	*godmode/alerts/alert_list.php,
+	godmode/alerts/configure_alert_template.php,
+	godmode/alerts/alert_templates.php,
+	godmode/alerts/configure_alert_action.php,
+	godmode/alerts/configure_alert_command.php,
+	godmode/alerts/alert_actions.php,
+	godmode/alerts/alert_commands.php,
+	include/help/en/help_event_alert.php,
+	include/help/en/help_alerts_config.php,
+	include/help/es/help_event_alert.php,
+	include/help/es/help_alerts_config.php,
+	include/help/ja/help_event_alert.php,
+	images/help/alert01.png,
+	images/help/alert02.png,
+	images/help/alert03.png,
+	images/help/alert04.png,
+	images/help/alert05.png,
+	images/help/alert06.png,
+	images/help/alert07.png,
+	images/help/alert08.png,
+	images/help/alert09.png,
+	images/help/event01.png,
+	images/help/event02.png,
+	images/help/event03.png,
+	images/help/event04.png,
+	images/help/alert10.png,
+	images/help/alert11.png,
+	images/help/alert12.png,
+	images/help/alert13.png,
+	images/help/alert14.png,
+	images/help/alert15.png,
+	images/help/alert16.png: Added new helps
+
 2013-06-18 Miguel de Dios <miguel.dedios@artica.es>
 
 	* operation/menu.php: showed the message entry in workspace menu for

pandora_console/godmode/alerts/alert_actions.php

@@ -61,7 +61,7 @@ if ((!$copy_action) && (!$delete_action) && (!$update_action)) {
 		alerts_meta_print_header ();
 	}
 	else {	
-		ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alert_action", true);
+		ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alerts_config", true);
 	}
 }
 
@@ -88,7 +88,7 @@ if ($copy_action) {
 					alerts_meta_print_header ();
 				}
 				else {
-					ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alert_action", true);
+					ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alerts_config", true);
 				}
 			}
 		} // If user tries to copy an action of others groups
@@ -106,7 +106,7 @@ if ($copy_action) {
 					alerts_meta_print_header ();
 				}
 				else {
-					ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alert_action", true);
+					ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alerts_config", true);
 				}
 			}
 			else {
@@ -123,7 +123,7 @@ if ($copy_action) {
 			alerts_meta_print_header ();
 		}
 		else {
-			ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alert_action", true);
+			ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alerts_config", true);
 		}
 	}
 	$result = alerts_clone_alert_action ($id);
@@ -201,7 +201,7 @@ if ($update_action) {
 					alerts_meta_print_header ();
 				}
 				else {
-					ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alert_action", true);
+					ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alerts_config", true);
 				}
 			}
 		}
@@ -212,7 +212,7 @@ if ($update_action) {
 			alerts_meta_print_header ();
 		}
 		else {
-			ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alert_action", true);
+			ui_print_page_header (__('Alerts').' » '.__('Alert actions'), "images/gm_alerts.png", false, "alerts_config", true);
 		}
 	}
 	

pandora_console/godmode/alerts/alert_commands.php

@@ -126,7 +126,7 @@ if (is_ajax ()) {
 if (defined('METACONSOLE'))
 	alerts_meta_print_header();
 else
-	ui_print_page_header (__('Alerts').' » '.__('Alert commands'), "images/gm_alerts.png", false, "alert_command", true);
+	ui_print_page_header (__('Alerts').' » '.__('Alert commands'), "images/gm_alerts.png", false, "alerts_config", true);
 
 enterprise_hook('open_meta_frame');
 

pandora_console/godmode/alerts/alert_list.php

@@ -288,7 +288,7 @@ else {
 		}
 		
 		if ($tab == 'list') {
-			ui_print_page_header(__('Alerts') . ' » ' . __('Manage alerts') . ' » ' . __('List'), "images/gm_alerts.png", false, "manage_alert_list", true, $buttons);
+			ui_print_page_header(__('Alerts') . ' » ' . __('Manage alerts') . ' » ' . __('List'), "images/gm_alerts.png", false, "alerts_config", true, $buttons);
 		}
 		else {
 			ui_print_page_header(__('Alerts') . ' » ' . __('Manage alerts') . ' » ' . __('Create'), "images/gm_alerts.png", false, "manage_alert_list", true, $buttons);

pandora_console/godmode/alerts/alert_templates.php

@@ -127,7 +127,7 @@ if (!$delete_template) {
 		alerts_meta_print_header ();
 	}
 	else {
-		ui_print_page_header (__('Alerts')." » ". __('Alert templates'), "images/gm_alerts.png", false, "alert_template", true);
+		ui_print_page_header (__('Alerts')." » ". __('Alert templates'), "images/gm_alerts.png", false, "alerts_config", true);
 	}
 }
 
@@ -172,7 +172,7 @@ if ($delete_template) {
 				else {
 					ui_print_page_header(
 						__('Alerts') . " » " .  __('Alert templates'),
-						"images/gm_alerts.png", false, "alert_template",
+						"images/gm_alerts.png", false, "alerts_config",
 						true);
 				}
 			}
@@ -190,7 +190,7 @@ if ($delete_template) {
 					alerts_meta_print_header ();
 				}
 				else {
-					ui_print_page_header (__('Alerts')." » ". __('Alert templates'), "images/gm_alerts.png", false, "alert_template", true);
+					ui_print_page_header (__('Alerts')." » ". __('Alert templates'), "images/gm_alerts.png", false, "alerts_config", true);
 				}
 			}
 			else {
@@ -206,7 +206,7 @@ if ($delete_template) {
 			alerts_meta_print_header ();
 		}
 		else {
-			ui_print_page_header (__('Alerts')." » ". __('Alert templates'), "images/gm_alerts.png", false, "alert_template", true);
+			ui_print_page_header (__('Alerts')." » ". __('Alert templates'), "images/gm_alerts.png", false, "alerts_config", true);
 		}
 	}
 	

pandora_console/godmode/alerts/configure_alert_action.php

@@ -78,7 +78,7 @@ if ($id) {
 }
 
 // Hidden div with help hint to fill with javascript
-html_print_div(array('id' => 'help_alert_macros_hint', 'content' => ui_print_help_icon ('alert_macros', true, ui_get_full_url(false, false, false, false)), 'hidden' => true));
+html_print_div(array('id' => 'help_alert_macros_hint', 'content' => ui_print_help_icon ('alert_macros', true), 'hidden' => true));
 
 $table->id = 'table_macros';
 $table->width = '98%';

pandora_console/godmode/alerts/configure_alert_command.php

@@ -58,7 +58,7 @@ if (defined('METACONSOLE'))
 	alerts_meta_print_header();
 else
 	ui_print_page_header (__('Alerts') . ' » ' .
-		__('Configure alert command'), "images/gm_alerts.png", false, "", true);
+		__('Configure alert command'), "images/gm_alerts.png", false, "alerts_config", true);
 
 enterprise_hook('open_meta_frame');
 

pandora_console/godmode/alerts/configure_alert_template.php

@@ -59,7 +59,7 @@ if ($a_template !== false) {
 		else {
 			ui_print_page_header (__('Alerts') .
 				' » ' . __('Configure alert template'), "",
-				false, "conf_alert_template", true);
+				false, "alerts_config", true);
 		}
 	}
 	else {
@@ -77,7 +77,7 @@ if ($a_template !== false) {
 				alerts_meta_print_header();
 			}
 			else {
-				ui_print_page_header (__('Alerts').' » '.__('Configure alert template'), "images/gm_alerts.png", false, "", true);
+				ui_print_page_header (__('Alerts').' » '.__('Configure alert template'), "images/gm_alerts.png", false, "conf_alert_template", true);
 			}
 		}
 		else {
@@ -95,7 +95,7 @@ else {
 		alerts_meta_print_header();
 	}
 	else {
-		ui_print_page_header (__('Alerts').' » '.__('Configure alert template'), "images/gm_alerts.png", false, "", true);
+		ui_print_page_header (__('Alerts').' » '.__('Configure alert template'), "images/gm_alerts.png", false, "conf_alert_template", true);
 	}
 }
 
@@ -581,7 +581,7 @@ else if ($step == 3) {
 		false);
 	
 	for($i=2;$i<=10;$i++) {
-	$table->data['field'.$i][0] = sprintf(__('Field %s'), $i);
+	$table->data['field'.$i][0] = sprintf(__('Field %s'), $i). ui_print_help_icon ('alert_macros', true);
 	$table->data['field'.$i][1] = html_print_textarea ('field'.$i, 1, 1, isset($fields_recovery[$i]) ? $fields_recovery[$i] : '', 'style="min-height:40px" class="fields"', true);
 	}
 }
@@ -988,4 +988,4 @@ elseif ($step == 3) {
 ?>
 })
 /* ]]> */
-</script>
+</script>

pandora_console/include/help/en/help_alerts_config.php

@@ -0,0 +1,198 @@
+<?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>
+
+
+

pandora_console/include/help/en/help_event_alert.php

@@ -4,6 +4,63 @@
 */
 ?>
 
-<h1>Event alert</h1>
+<h1>Event Alerts</h1>
+
+From Pandora FMS 4.0 version, it is possible to define alerts on events, that allows to work from a completely new approach much more flexible. This is an Enterprise feature.<br>
+
+To create the new event alerts, click on the Create button in the Event alerts menu from the Administration menu. <br><br>
+
+ 
+<br><br>
+
+
+<?php html_print_image ("images/help/event01.png", false, array('width' => '250px')); ?>
+
+
+<br>
+An event alert is composed by different rules, linked between them by logical operators (and, or, xor, nand, nor, nxor).
+<br><br>
+
+<?php html_print_image ("images/help/event02.png", false, array('width' => '550px')); ?>
+
+<br>
+To could work easier with them, the configuration parameters of an event alert are identical to the module alert. Here could be find a detailed explanation of any of them. There are only two specific parameters of the event alerts:
+<br><br>
+    <b>Rule evaluation mode:</b> There are two options Pass and Drop. Pass means that if a event fullfilled with a alert the alerts bellow are evaluated. Drop means that if a event fullfilled with a alert the alerts bellow stop to evaluated.  
+<br><br>
+    <b>Group by:</b> Allows to group the rules by agent, module, alert or group. For example, if a rule is configured to it fires when we receive two critical events, and it's grouped by agent, there should arrive two critical events from the same agent. It's possible to switch off.  
+<br><br>
+Each rule is configured to fire with an specific kind of event. The alert will be fired when the logical equation defined by the rules and its operators is fulfilled 
+<br><br>
+
+
+<?php html_print_image ("images/help/event03.png", false, array('width' => '550px')); ?>
+
+<br>
+
+The configuration parameters of one rule that are possible are: 
+<br><br>
+    <b>Name:</b> Name of the rule.<br>
+    <b>User comment:</b> Free comment. <br>
+    <b>Event:</b> Regular expression that matches with the event text. <br>
+    <b>Window: </b>The events that have been generated out of the time window will be rejected<br>
+    <b>Count:</b> Number of events that have to match with the rule to it could be fired.<br>
+    <b>Agent: </b>Regular expression that matches with the name of the agent that generated the event. <br>
+    <b>Module:</b> Regular expression that matches with the name of the module that generated the event. <br>
+    <b>Module alerts:</b> Regular expression that matches with the name of the alert that generated the event. <br>
+    <b>Group: </b>Group the agent belongs to. <br>
+    <b>Criticity:</b> Event criticity. <br>
+    <b>Tag:</b> Tags associated to the event. <br>
+    <b>User:</b> User associated to the event. <br>
+    <b>Event type:</b> Kind of event.  <br><br>
+
+For example, we could configure a rule that matches with the events generated by any module that is named cpu_load of any agent of the Servers group that has associated the tag System when the module goes to critical status:
+<br><br>
+
+
+<?php html_print_image ("images/help/event04.png", false, array('width' => '550px')); ?>
+
+<br>
+<p>Given the high number of events that the Pandora FMS database could store, the server works on an event window that is defined in the pandora_server.conf configuration file through the parameter event_window. The events that have been generated out of this time window won't be processed by the server, so it doesn't make sense to specify in a rule a time window higher to the one configured in the server </p>
+
 
-<p>Allows to trigger a Pandora FMS reaction that match with an event. Event alerts are composed by various rules and logical operators.</p>

pandora_console/include/help/es/help_alerts_config.php

@@ -0,0 +1,196 @@
+<?php
+/**
+ * @package Include/help/es 
+ */
+?> 
+ <h1>Guía rápida de configuración de alertas para Pandora FMS</h1>
+<br>
+
+<b>Introducción al sistema de alertas actual</b><br><br>
+
+Uno de los problemas más frecuentes y que ocasiona mayor número de quejas por parte de los usuarios es la complejidad de definir alertas en Pandora FMS. Antes, hasta la version 2.0, las alertas eran bastante más sencillas de configurar.Para cada alerta, se definía la condición y lo que hacía cuando la acción no se cumplía, para cada caso. Era más intuitivo (aun así habia campos como el alert "threshold" que daban dolores de cabeza a más de uno). Era sencillo, pero ¿merecía la pena?.<br><br>
+
+Uno de nuestros mejores usuarios (cuando digo mejor, es porque tenía muchísimos agentes instalados, y además conocía muy bien el funcionamiento de Pandora FMS), nos comentó que crear una alerta en 2000 modulos, era enormemente complicado, especialmente cuando habia que modificar algo en todas ellas. Debido principalmente a este y otros problemas, modificamos el sistema de alertas para que fuera modular, para que se pudiera separar la definición de la condición de disparo de la alerta (Alert template), de la acción a ejecutar cuando esta se dispara (Alert action) y del comando que se ejecuta dentro de la acción (Alert comnmand). La combinación de una plantilla de alerta (Alert template) con un módulo desencadena la alerta en sí.<br><br>
+
+De esta forma, si yo tengo 1000 máquinas con un modulo llamado "Host alive" y todos ellas tienen asociada una plantilla de alerta llamada "Host down" que ejecuta por defecto una acción llamada "Avisar al operador", y quiero cambiar el número mínimo de alertas que se deben disparar antes de avisar al operador, sólo tengo que hacer un cambio en la definicion de la plantilla, no ir una por una, en las 1000 alertas para modificar esa condición.<br><br>
+
+Muchos usuarios sólo gestionan algunas decenas de máquinas, pero existen usuarios con cientos, incluso miles de sistemas monitorizados con Pandora FMS, y tenemos que intentar hacer posible que con Pandora FMS se puedan gestionar todo tipo de entornos.<br><br><br><br>
+<b>Estructura de una alerta</b><br><br>
+
+<?php html_print_image ("images/help/alert01.png", false, array('width' => '550px')); ?>
+<br>
+Las alertas se componen de:<br><br>
+
+    <i>Comandos</i><br>
+    <i>Acciones</i><br>
+    <i>Plantillas</i> <br><br>
+
+Un comando defined la operación a realizar cuando se dispara la alerta. Ejemplos de comandos pueden ser: escribir en un log, envíar un email o SMS, ejecutar un script o programa, etc.<br><br>
+
+Una acción relaciona un comando con una plantilla y permite personalizar la ejecución del comando usando tres parámetros genéricos Field 1, Field 2 y Field 3. Estos parámetros permiten personalizar la ejecución del comando ya que son los que se pasarán en el momento de la ejecución como parámetros de entrada.<br><br>
+
+En la plantilla se definen parámetros genéricos de la alertas que son: las condiciones de disparo, acciones de disparo y recuperación de la alerta.<br><br>
+
+    <i>Condiciones de disparo:</i> son las condiciones bajos las que se disparará la alerta, por ejemplo: superar cierto umbral, estar en estado crítico, etc.<br>
+    <i>Acciones de disparo:</i> es la configuración de las acciones que se realizarán al disparar la alerta.<br>
+    <i>Recuperación de alerta:</i> es la configuración de las acciones que se realizarán cuando el sistema se recupere de la alerta. <br><br>
+
+<b>Flujo de información en el sistema de alertas</b><br><br>
+
+Al definir las acciones y las plantillas disponemos de unos campos genéricos llamados Field1, Field2 y Field3 que son los que se pasarán como parámetros de entrada en la ejecución del comando. Los valores de estos parámetros se propagan de plantilla a la acción y por último al comando. La propagación de la plantilla a la acción sólo se realiza si el campo correspondiente de la acción no tiene un valor asignado, si la acción tiene un valor asignado se conserva.<br><br>
+
+<?php html_print_image ("images/help/alert02.png", false, array('width' => '550px')); ?>
+<br>
+Este seria un ejemplo de como se sobreescriben los valores de la plantilla usando los de la acción.<br><br>
+
+<?php html_print_image ("images/help/alert03.png", false, array('width' => '550px')); ?>
+<br>
+Por ejemplo creamos una plantilla que dispara la alerta y envía un email con los siguientes campos:<br><br>
+
+    <b>Plantilla:</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>Acción:</b><br>
+        Field1: <i>myboss@domain.com</i><br>
+        Field2:<br>
+        Field3: <br><br>
+
+Los valores que llegarían al comando serían:<br><br>
+
+    <b>Comando:</b><br>
+        Field1: myboss@domain.com<br>
+        Field2: [Alert] The alert was fired<br>
+        Field3: The alert was fired!!! SOS!!! <br><br>
+
+Para los campos Field2 y Field3 se conservan los valores definidos en la plantilla, pero para el campo Field1 usa el valor definido en la acción.<br><br>
+<b>Definiendo una Alerta</b><br><br>
+
+Bien, ahora vamos a ponernos en el caso anterior. Tenemos una necesidad: monitorizar un módulo que contiene valores numéricos. En nuestro caso, es un modulo que mide la CPU del sistema, en otro caso puede ser un sensor de temperatura, que engrega el valor en grados centígrados. Veamos primero que nuestro módulo recibe datos correctamente:<br><br>
+
+<?php html_print_image ("images/help/alert04.png", false, array('width' => '550px')); ?>
+<br>
+Bien. En esta captura vemos que tenemos un modulo llamado sys_cpu con un valor actual de 7. En nuestro caso queremos que salte una alerta cuando supere los 20. Para ello vamos a configurar el módulo para que se ponga en estado CRITICAL cuando supere los 20. Para ello hacemos click en la llave inglesa para configurar el comportamiento del monitor:<br><br>
+
+<?php html_print_image ("images/help/alert05.png", false, array('width' => '550px')); ?>
+<br>
+Para ello, modificamos el valor marcado en rojo en la captura siguiente:<br><br>
+<br><br>
+
+<?php html_print_image ("images/help/alert06.png", false, array('width' => '550px')); ?>
+<br>
+Aceptamos y grabamos la modificación. Ahora cuando el valor del módulo CPU sea 20 o mayor, cambiará su estado a CRITICAL y se verá en color rojo, tal y como vemos aquí.<br><br>
+
+
+<?php html_print_image ("images/help/alert07.png", false, array('width' => '550px')); ?>
+<br>
+Ya hemos hecho que el sistema sepa discriminar cuando algo está bien (OK, color VERDE) y cuando está mal (CRITICAL, color rojo). Ahora lo que debemos hacer es que nos envíe un email cuando el modulo se ponga en este estado. Para ello utilizaremos el sistema de alertas de Pandora FMS.<br><br>
+
+Para esto, lo primero que debemos hacer es asegurarnos de que existe un comando que hace lo que necesitamos (enviar un email). Este ejemplo es fácil porque existe un comando predefinido en Pandora FMS para enviar mails. Asi que ya lo tenemos.<br><br>
+<b>Configurando la acción</b><br><br>
+
+Ahora tenemos que crear una acción que sea "Enviar un email al operador". Vamos a ello: Vamos al menu de administracion -> Alertas -> Acciones y le damos al botón para crear una nueva acción:<br><br>
+
+<?php html_print_image ("images/help/alert08.png", false, array('width' => '550px')); ?>
+<br>
+Esta acción utiliza el comando "Enviar email", y es realmente sencillo, ya que sólo relleno un campo (Field 1) dejando los otros dos vacíos. Esta es una de las partes más confusas del sistema de alertas de Pandora FMS: ¿Qué son los campos field1, field2, y field3?.<br><br>
+
+Esos campos son los que se usan para "pasar" la información de la plantilla de alerta al comando, y a su vez, de éste al comando. De forma que tanto Plantilla como Comando, puedan aportar diferente información al comando. En este caso el comando sólo establece el campo 1, y dejaremos el campo 2 y el campo 3 a la plantilla, como veremos a continuación.<br><br>
+
+El campo 1 es el que usamos para definir el email del operador, en este caso un supuesto mail a "sancho.lerena@notexist.com".<br><br>
+
+<b>Configurando la plantilla (Alert template)</b><br><br>
+
+Ahora tenemos que crear una plantilla de alerta lo más genérica posible (para poderla reutilizar más adelante, como veremos) que sea "Esto está mal, porque tengo un módulo en estado Crítico" y que por defecto, envíe un email al operador. Vamos a ello: Vamos al menu de administracion -> Alertas -> Templates y le damos al botón para crear una nueva plantilla (template) de alerta:<br><br>
+
+<?php html_print_image ("images/help/alert09.png", false, array('width' => '550px')); ?>
+<br>
+Lo que define la condición es el campo "Condition", en este caso está marcado a "Estado crítico", de forma que esta plantilla, cuando se asocie a un módulo, se disparará cuando el modulo asociado esté en estado crítico. Antes hemos configurado el modulo "cpu_sys" para que entre en estado crítico cuando valga 20 o más.<br><br>
+
+La prioridad definida aqui "Critical" es la prioridad de la alerta, que no tiene que ver con el estado "Critico" del módulo. Las criticidades de las alertas son para visualizarlas luego, en otras vistas, como la vista de eventos, con diferentes criticidades.<br><br>
+
+Pasemos al paso 2, pulsando el boton "next":<br><br>
+
+<?php html_print_image ("images/help/alert10.png", false, array('width' => '550px')); ?>
+<br>
+El paso 2 define todos los "valores" de configuración "finos" de la plantilla de alerta, de la condición de disparo. Algunos de ellos, los primeros, son bastante sencillos, restringen el momento de actuación de esta alerta a ciertos días entre diferentes horas.<br><br>
+
+Los parámetros más críticos aquí son los siguientes:<br><br>
+
+    <i>Time threshold:</i> Por defecto es un día. Si un módulo permanece todo el rato caído, durante, por ejemplo un día, y tenemos aquí un valor de 5 minutos, significa que nos estaría mandando alertas cada 5 minutos. Si lo dejamos en un día (24 horas), sólo nos enviará la alerta una vez, cuando se caiga. Si el modulo se recupera, y luego se vuelve a caer, nos enviará una alerta de nuevo, pero si sigue caída desde la 2º caida, no enviará mas alertas hasta dentro de 24 horas. <br><br>
+
+    <i>Min. Número de alertas:</i> El nº mínimo de veces que se tendrá que dar la condición (en este caso, que el modulo esté en estado CRITICAL) antes de que Pandora FMS me ejecute las acciones asociadas a la plantilla de alerta. Es una forma de evitar que falsos positivos me "inunden" a alertas, o que un comportamiento errático (ahora bien, ahora mal) haga que se disparen muchas alertas. Si ponemos aquí 1, significa que hasta que no ocurra al menos una vez, no lo tendré en cuenta. Si pongo 0, la primera vez que el modulo esté mal, disparará la alerta. <br><br>
+
+    <i>Max. Numero de alertas:</i> 1 significa que sólo ejecutará la acción una vez. Si tenemos aquí 10, ejecutará 10 veces la acción. Es una forma de limitar el número de veces que una alerta se puede ejecutar. <br><br>
+
+De nuevo volvemos a ver los campos: "campo1, campo2 y campo3". Ahora podemos ver que el campo1 está en blanco, que es justamente el que hemos definido al configurar la acción. El campo2 y el campo3 se usan en la acción de enviar un mail para definir el subject y el texto del mensaje, mientras que el campo1 se usa para definir el o los destinatarios (separados por comas). Asi que la plantilla, usando algunas macros, está definiendo el subject y el mensaje de alerta de forma que en nuestro caso nos llegaría un mensaje como el que sigue (suponiendo que el agente donde está el modulo se llama "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>
+
+Dado que la acción por defecto es la que he definido previamente, todas las alertas que usen esta plantilla, usarán esa acción predeterminada por defecto, a no ser que la modifique.<br><br>
+
+En el caso 3, veremos que se puede configurar el sistema de alertas para que notifique cuando la alerta ha cesado.<br><br>
+
+<?php html_print_image ("images/help/alert11.png", false, array('width' => '550px')); ?>
+<br>
+Es casi igual, pero el campo1 no está definido, porque se usará el mismo que venga definido en la acción ejecutada previamente (al disparar la alerta). En este caso solo enviará un mail con un subject que informa que la condición en el modulo cpu_sys se ha recuperado.<br><br>
+
+La recuperación de alertas es opcional. Es importante destacar que si en los datos de recuperación de la alerta, hay campos (field2 y field3) definidos, estos ignoran y sobreescriben los campos de la acción, es decir, tienen preferencia sobre ellos. El único campo válido que no se puede modificar es el campo1.<br><br>
+<b>Asociando la alerta al módulo</b><br><br>
+
+Ya tenemos todo lo que necesitábamos, ahora sólo tenemos que asociar la plantilla de alerta al módulo. Para ello vamos a la solapa de alertas dentro del agente donde está el módulo:<br><br>
+
+<?php html_print_image ("images/help/alert12.png", false, array('width' => '550px')); ?>
+<br>
+Es sencillo, en esta captura vemos una alerta ya configurada para un módulo llamado "Last_Backup_Unixtime" asociado al mismo template que hemos definido antes "Module critical". Ahora en los controles que hay debajo, vamos a crear una asociación entre el modulo "cpu_sys" y la plantilla de alerta "Module critical". Por defecto mostrará la acción que tenemos definida en esa pantilla "Enviar email a Sancho Lerena".<br><br>
+<b>Escalado de alertas</b><br><br>
+
+Los valores que hay en la opcion de "Number of alerts match from" son para definir el escalado de alertas. Esto permite "redefinir" un poco más el comportamiento de la alerta, de forma que si hemos definido un máximo de 5 veces las veces que se puede disparar una alerta, y sólo queremos que nos envie un email, pondremos aquí un 0 y un 1, para decirle que sólo nos envie un email desde la vez 0 a la 1 (osea, una vez).<br><br>
+
+Ahora veremos que podemos añadir más acciones a la misma alerta, definiendo con estos campos "Number of alerts match from" el comportamiento de la alerta en función de cuantas veces se dispare.<br><br>
+
+Por ejemplo, podemos querer que mande un email a XXXXX la primera vez que ocurra, y si sigue caído el monitor, envíe un email a ZZZZ. Para ello, despues de asociar la alerta, en la tabla de alertas asignadas, puedo añadir mas acciones a una alerta ya definida, tal y como podemos ver en la siguiente captura:<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>Alertas en Standby</b><br><br>
+
+Las alertas pueden estar activadas, desactivadas o en standby. La diferencia entra las alertas desactivadas y las que están en standby es que las desactivadas simplemente no funcionarán y por lo tanto no se mostrarán en la vista de alertas. En cambio, las alertas en standby se mostrarán en la vista de alertas y funcionarán pero solamente a nivel de visualización. Esto es, se mostrará si están o no disparadas pero no realizarán las acciones que tengan programadas ni generarán eventos.<br><br>
+
+Las alertas en standby son útiles para poder visualizarlas sin que molesten en otros aspectos.<br><br>
+<b>Utilizando comandos de alertas distintos del email</b><br><br>
+
+El email, como comando es interno a Pandora FMS y no se puede configurar, es decir, field1, field2 y field3 son campos que están definidos que se usan como destinatario, subject y texto del mensaje. Pero, ¿que ocurre si yo quiero ejecutar una acción diferente, definida por mi?.<br><br>
+
+Vamos a definir un nuevo comando, algo totalmente definido por nosotros. Imaginemos que queremos generar un fichero log con cada alerta que encontremos. El formato de ese fichero log tiene que ser algo como:<br><br>
+
+<i>FECHA_HORA - NOMBRE_AGENTE - NOMBRE_MODULO - VALOR - DESCRIPCION DEL PROBLEMA</i><br><br>
+
+Donde VALOR es el valor del modulo en ese momento. Habrá varios ficheros log, dependiendo de la acción que llame al comando. La acción definirá la descripcion y el fichero al que van los eventos.<br><br>
+
+Para ello, primero vamos a crear un comando como sigue:<br><br>
+
+<?php html_print_image ("images/help/alert15.png", false, array('width' => '550px')); ?>
+<br>
+Y vamos a definir una acción:<br><br>
+
+<?php html_print_image ("images/help/alert16.png", false, array('width' => '550px')); ?>
+<br>
+Si vemos el fichero de log que hemos creado:<br><br>
+
+<i>2010-05-25 18:17:10 - farscape - cpu_sys - 23.00 - Custom alert for LOG#1</i><br><br>
+
+La alerta se disparó a las 18:17:10 en el agente "farscape", en el modulo "cpu_sys" con un dato de "23.00" y con la descripcion que pusimos al definir la acción.<br><br>
+
+Dado que la ejecución del comando, el orden de los campos y otros asuntos pueden hacer que no entendamos bien cómo se ejecuta al final el comando, lo más sencillo es activar las trazas de debug del servidor de pandora (verbose 10) en el fichero de configuracion de pandora server en /etc/pandora/pandora_server.conf, reiniciemos el servidor (/etc/init.d/pandora_server restart) y que miremos el fichero /var/log/pandora/pandora_server.log buscando la línea exacta con la ejecución del comando de la alerta que hemos definido, para ver como el servidor de Pandora FMS está lanzando el comando. <br><br>
+
+

pandora_console/include/help/es/help_event_alert.php

@@ -6,5 +6,59 @@
 
 <h1>Alerta de evento</h1>
 
-<p>Permite disparar una reaccion de Pandora FMS que coincide con un evento. Las alertas de evento estan compuestas por varias reglas y operadores logicos.</p> 
+Desde la versión 4.0 de Pandora FMS se pueden definir alertas sobre los eventos, lo que permite trabajar desde una perspectiva completamente nueva y mucho más flexible. Esta es una característica Enterprise.<br><br>
+
+Las Alertas de evento nuevas se crean pinchando en el botón Create en el menú Event alerts en el menú de Administración.
+<br><br>
+
+
+<?php html_print_image ("images/help/event01.png", false, array('width' => '250px')); ?>
+
+
+<br>
+Una alerta de eventos está compuesta por distintas reglas, relacionadas entre sí por operadores lógicos (and, or, xor, nand, nor, nxor).
+<br><br>
+
+<?php html_print_image ("images/help/event02.png", false, array('width' => '550px')); ?>
+
+<br>
+Para hacer más fácil trabajar con ellas, los parámetros de configuración de una alerta de eventos son idénticos a los de una alerta de módulo. Aquí se puede encontrar una explicación detallada de cada uno de ellos. Únicamente existen dos parámetros específicos de las alertas de eventos:
+<br><br>
+    <b>Rule evaluation mode:</b> Hay dos opciones Pass y Drop. Pass significa que en caso de que un evento coincida con una alerta se sigan evaluando el resto de alertas. Drop significa que en caso de que un evento coincida con una alerta no se evaluen el resto de alertas. 
+<br><br>
+    <b>Group by:</b> Permite agrupar las reglas por agente, módulo, alerta o grupo. Por ejemplo, si se configura una regla para que salte cuando se reciban dos eventos críticos y se agrupa por agente, deberán llegar dos eventos críticos de un mismo agente. Se puede desactivar. 
+<br><br>
+Cada regla se configura para saltar ante un determinado tipo de evento, cuando se cumple la ecuación lógica definida por las reglas y sus operadores, la alerta se dispara.
+<br><br>
+
+
+<?php html_print_image ("images/help/event03.png", false, array('width' => '550px')); ?>
+
+<br>
+
+Los posibles parámetros de configuración de una regla son:
+<br><br>
+    <b>Name:</b> Nombre de la regla.<br>
+    <b>User comment:</b> Comentario libre.<br>
+    <b>Event:</b> Expresión regular que casa con el texto del evento.<br>
+    <b>Window: </b>Los eventos que se hayan generado fuera de la ventana de tiempo serán descartados.<br>
+    <b>Count:</b> Número de eventos que tienen que casar con la regla para que ésta se dispare.<br>
+    <b>Agent: </b>Expresión regular que casa con el nombre del agente que generó el evento.<br>
+    <b>Module:</b> Expresión regular que casa con el nombre del módulo que generó el evento.<br>
+    <b>Module alerts:</b> Expresión regular que casa con el nombre de la alerta que generó el evento.<br>
+    <b>Group: </b>Grupo al que pertenece el Agente.<br>
+    <b>Criticity:</b> Criticidad del evento.<br>
+    <b>Tag:</b> Tags asociados al evento.<br>
+    <b>User:</b> Usuario asociado al evento.<br>
+    <b>Event type:</b> Tipo de evento. <br><br>
+
+Por ejemplo, podríamos configurar una regla que case con los eventos generados por cualquier módulo que se llame cpu_load de cualquier agente del grupo Servers que lleve asociado el tag System cuando el módulo pasa al estado crítico:
+<br><br>
+
+
+<?php html_print_image ("images/help/event04.png", false, array('width' => '550px')); ?>
+
+<br>
+<p>Dado el elevado número de eventos que puede llegar a albergar la base de datos de Pandora FMS, el servidor trabaja sobre una ventana de eventos que se define en el fichero de configuración pandora_server.conf mediante el parámetro event_window. Los eventos que se hayan generado fuera de esta ventana de tiempo no serán procesados por el servidor, de modo que no tiene sentido especificar en una regla una ventana de tiempo superior a la configurada en el servidor </p>
+
 

pandora_console/include/help/ja/help_event_alert.php

@@ -4,6 +4,63 @@
 */
 ?>
 
-<h1>イベントアラート</h1>
+<h1>イベントアラート、イベント相関</h1>
+
+Pandora FMS バージョン 4.0 から、イベントにアラートを定義できるようになりました。より柔軟な完全に新たなアプローチです。これはエンタープライズ版の機能です。
+
+新たなイベントアラートを作成するには、システム管理メニューのイベントアラートメニューで作成ボタンをクリックします。 <br><br>
+
+イベントアラートは、論理式(and、or、xor、nand、nor、nxor)で結合されたルールで組み立てられます。 
+<br><br>
+
+
+<?php html_print_image ("images/help/event01.png", false, array('width' => '250px')); ?>
+
+
+<br>
+簡単にいうと、イベントアラートのパラメータ設定はモジュールアラートと同様です。
+<br><br>
+
+<?php html_print_image ("images/help/event02.png", false, array('width' => '550px')); ?>
+
+
+イベントアラート特有のパラメータとしては、以下の 2つがあります。 
+<br><br>
+    <b>ルール評価モード: </b> drop モードでは、一つのルールが満たされなければ、残りのアラートルールは評価されません。pass モードでは、残りのルールも評価されます。  
+<br><br>
+    <b>グループごと:</b> エージェント、モジュール、アラート、またはグループによって、ルールをグループ化します。例えば、2つの障害イベントを受け取ったときに、通知するようなルールが設定されていてエージェントでグループ化されていた場合は、同じエージェントから 2つの障害イベントが届きます。これは off にすることができます。  
+<br><br>
+それぞれのルールは、特定の種類のイベントで通知されるように設定されます。アラートは、ルールで定義された論理式および条件を満たした場合に通知されます。
+<br><br>
+
+
+<?php html_print_image ("images/help/event03.png", false, array('width' => '550px')); ?>
+
+
+
+一つのルールの設定パラメータは次の通りです。 
+<br><br>
+    <b>名前(Name)</b> ルール名。<br>
+    <b>ユーザコメント(User comment):</b> 任意のコメント。<br>
+    <b>イベント(Event):</b> イベントテキストにマッチする正規表現。<br>
+    <b>ウインドウ(Window): </b>イベントの生成時間範囲。この時間範囲外のイベントは拒否されます。* <br>
+    <b>回数(Count):</b> ルールにマッチし通知されるイベントの数。 <br>
+    <b>エージェント(Agent): </b>イベントを生成したエージェント名にマッチする正規表現。<br>
+    <b>モジュール(Module):</b>  イベントを生成したモジュール名にマッチする正規表現。 <br>
+    <b>モジュールアラート(Module alerts):</b> イベントを生成したアラート名にマッチする正規表現。 <br>
+    <b>グループ(Group): </b>エージェントが属するグループ。 <br>
+    <b>重要度(Criticity):</b> イベントの重要度。 <br>
+    <b>タグ(Tag):</b> イベントに関連づけられたタグ。 <br>
+    <b>ユーザ(User):</b> イベントに関連づけられたユーザ。 <br>
+    <b>イベントタイプ(Event type):</b> イベントの種類。  <br><br>
+
+例えば、System タグに関連づけられたサーバグループの任意のエージェントの cpu_load という名前の任意のモジュールが障害状態になったときに、生成されたイベントにマッチするルールを設定できます。 
+<br><br>
+
+
+<?php html_print_image ("images/help/event04.png", false, array('width' => '550px')); ?>
+
+
+<p>* Pandora FMS データベースに保存できるイベント数に関しては、pandora_server.conf ファイルの event_window パラメータにて定義します。この時間範囲を越えるイベントが発生した場合は、サーバは処理を行いません。そのため、サーバの設定よりも大きな時間間隔を設定しても意味がありません。 </p>
+
 
-<p>イベントにマッチさせて Pandora FMS を動かすことができます。イベントアラートは、さまざまなルールおよび論理式によって組み立てられます。</p>