Difference between revisions of "Pandora: Documentation en: Transactional Monitoring"

From Pandora FMS Wiki
Jump to: navigation, search
(Configuración de los scripts de control)
(Transaction agents)
 
(25 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
[[Pandora:Documentation_en|Go back to Pandora FMS documentation index]]
 
= Transaction monitoring =
 
= Transaction monitoring =
 
 
== Introduction ==
 
== Introduction ==
  
Pandora FMS v. 7 now incorporates transaction monitoring.
+
Pandora FMS v. 7 now features transaction monitoring.
  
The transactional server component implemented in this version allows you to execute dependent tasks following a user-defined design. This means that it is possible to coordinate different executions to test a target at a given time.
+
The transactional server component implemented in this version allows to execute tasks, which are dependent upon one another, following a user-defined design. This means that it is possible to coordinate different executions to test a target at a given time.
  
Let's take a case study, for example. It could consist of tracking an order that goes through its different phases, being able to keep track of the times in each of the steps, departments or stages:
+
The following case study consists of tracking an order that goes through different stages, being able to keep track of the time in each of the steps, departments or stages:
  
 
<br>
 
<br>
Line 13: Line 13:
 
<br>
 
<br>
  
A four-step graph will be defined which Pandora FMS will use network along with a series of control scripts to monitor the previously indicated process, visually showing the status in which each one of the parts that conform our business process is at all times.
+
A four-step graph will be defined, which Pandora FMS will use along with a series of control scripts to monitor the previously indicated process, visually showing the status in which each one of the parts that make up the business process is at all times.
  
Below we will look at how to fully monitor a transaction process.
+
Below there is an explanation on how to fully monitor a transaction process.
  
== Functioning ==
+
== Operation ==
  
We will define a '''transaction''' as a set of steps that make up a more complex task. We will call these steps '"phases'".
+
A '''transaction''' can be defined as a set of steps that make up a more complex task. These steps will be called '''stages'''.
  
The set of phases and their workflow (dependency relations) will define a '''transactional graph'''.
+
The set of stages and their workflow (dependency relations) will define a '''transactional graph'''.
  
Pandora FMS, based on the transactional graph, will launch an order to execute control scripts in each of the previously defined phases. These control scripts will perform the monitoring tasks for each phase.
+
Pandora FMS, based on the transactional graph, will launch an order to execute control scripts in each of the previously defined stages. These control scripts will perform the monitoring tasks for each stage.
  
The most common points to check in the control scripts that can give us information on the status of our transaction are:
+
The most common points to check in control scripts that can provide information on the status of a transaction are:
 
*Entries in log files.
 
*Entries in log files.
 
*Presence of temporary files.
 
*Presence of temporary files.
Line 31: Line 31:
 
*Existence of mail in inboxes.
 
*Existence of mail in inboxes.
  
The transactional system is distributed, being able to deploy as many '''transactional agents''' in our infrastructure as we need, and it will be the Pandora FMS server that will communicate with these agents, indicating the steps to follow and the moments in which they must run a control script.
+
The transactional system is distributed, being able to deploy as many '''transactional agents''' in an infrastructure as needed, and it will be the Pandora FMS server the one that will communicate with these agents, indicating the steps to follow and the time when they must run a control script.
  
 
== Configuring a transaction ==
 
== Configuring a transaction ==
  
In order to configure and execute transaction monitoring, it will be necessary:
+
In order to configure and execute transaction monitoring, these will be necessary:
  
 
*Previous analysis of the business process to be monitored:
 
*Previous analysis of the business process to be monitored:
Line 41: Line 41:
 
**Points involved.
 
**Points involved.
 
**Control scripts.
 
**Control scripts.
*Deployment of transactional agents in the required equipment to control the information flow.
+
*Transactional agent deployment in the required equipment to control the information flow.
 
**Development and deployment of control scripts in the required transactional agents.
 
**Development and deployment of control scripts in the required transactional agents.
**Configuration of the transactional agents.
+
**Configuration of transactional agents.
*From the Pandora FMS console, create the transaction by entering the data in the forms.
+
*From Pandora FMS console, create the transaction by entering the data in the forms.
  
=== Prior analysis ===
+
=== Previous analysis ===
  
Let's analyze a regular case:
+
Let us analyze a regular case:
  
The transaction begins when an order is received on the '''web portal''', where a transactional agent must be deployed, or at least on a machine capable of carrying out remote checks. During this first phase a critical script is executed; the '''transaction trigger'''.
+
The transaction begins when an order is received on the '''web portal''', where a transactional agent must be deployed, or at least on a machine capable of carrying out remote checks. During this first stage, a critical script is executed: the '''transaction trigger'''.
  
In the next phase, a virtualization of the order processing launches in the ''EMI01'' machine, using different ID codes for the order placed in the previous phase. There needs to be another transactional agent installed on this machine, or, if not, on a machine capable of executing remote checks. The control script checks that the process has been correctly completed for this phase by searching for registry file entries, events or temporary files.
+
In the next stage, a virtualization of the order processing is launched in the ''EMI01'' machine, using different ID codes for the order placed in the previous stage. There must be another transactional agent installed on this machine, or, if not, on a machine capable of executing remote checks. The control script checks that the process has been correctly completed in this stage by searching for registry file entries, events or temporary files.
  
The third phase of the transaction is to save the processed order on an Oracle database, on the ''ORAMON'' machine. These machines are usually highly protected and it's difficult to install additional software on them, so a transactional agent should be deployed on a remote machine with permission to launch data base queries.
+
The third stage of the transaction is to save the processed order on an Oracle database, on the ''ORAMON'' machine. These machines are usually highly protected and it is difficult to install additional software on them, so a transactional agent should be deployed on a remote machine with permissions to launch data base queries.
  
The last step is to confirm whether there is mail in the Logistic department's inbox in the ''public'' mail server. Since we can't deploy an agent on this machine, we'll run the queries from another machine that is able to access it. We can use Pandora FMS classic [http://library.pandorafms.com/index.php?sec=Library&sec2=repository&lng=en&action=view_PUI&id_PUI=791 plugins] slightly modified to check for incoming emails.
+
The last stage is to confirm whether there is mail in the Logistic department's inbox in the ''public'' mail server. Since an agent cannot be deployed on this machine, the queries will have to be run from another machine that is able to access it. Pandora FMS classic [http://library.pandorafms.com/index.php?sec=Library&sec2=repository&lng=en&action=view_PUI&id_PUI=791 plugins] slightly modified can be used to check incoming emails.
  
 
=== Deployment and development ===
 
=== Deployment and development ===
  
In the example there are four phases which require four scripts:
+
In this example, there are four stages which require four scripts:
#Transaction trigger: makes a virtual order to the '''web portal'''in order to subsequently trace it.
+
#Transaction trigger: makes a virtual order to the '''web portal''' in order to subsequently trace it.
#Control script: looks for a chain in the log file.
+
#Control script: looks for a string in the log file.
 
#Control script: queries the data base.
 
#Control script: queries the data base.
 
#Control script: confirms whether the corresponding email reached the Logistics inbox.  
 
#Control script: confirms whether the corresponding email reached the Logistics inbox.  
  
In the above example the transaction trigger leaves a file copy of an order in a specific point.  
+
In the above example, the transaction trigger leaves a file copy of an order on a specific point.  
  
 
Control scripts share a basic structure as in the following example:
 
Control scripts share a basic structure as in the following example:
Line 79: Line 79:
 
  ########################  
 
  ########################  
 
  function check_flag() {  
 
  function check_flag() {  
     # Condiciones del script de control
+
     # Control script conditions
 
     if [ "a" == "a" ]; then  
 
     if [ "a" == "a" ]; then  
 
       return 1;  
 
       return 1;  
Line 106: Line 106:
 
  ./pandora_transactional_installer --install
 
  ./pandora_transactional_installer --install
  
We will only have to modify the agent configuration file  (by default /etc/pandora/pandora_transaccional.conf) to point to the Pandora FMS server that will direct the transaction process. And we'll start the agent's service:
+
Just modify the agent configuration file  (/etc/pandora/pandora_transaccional.conf by default) to point to the Pandora FMS server that will direct the transaction process. And start the agent's service:
  
 
  /etc/init.d/transactional_daemon start
 
  /etc/init.d/transactional_daemon start
Line 132: Line 132:
 
* '''Agent''': Pandora FMS agent where the modules generated by the system will be saved (History).
 
* '''Agent''': Pandora FMS agent where the modules generated by the system will be saved (History).
 
* '''Group''': to control visibility and access.
 
* '''Group''': to control visibility and access.
* '''Loop interval''': waiting time before launching the transaction again .
+
* '''Loop interval''': waiting time before launching the transaction again.
  
=== Creating the phase tree ===
+
=== Creating the stage tree ===
  
  
Line 141: Line 141:
  
 
<br>
 
<br>
[[File:trans4.JPG|center|800px]]
+
[[File:Trans111.png|center|800px]]
 
<br>
 
<br>
  
We must enter the data for each phase:
+
Enter the data for each stage:
  
 
<br>
 
<br>
[[File:trans5.JPG|center|800px]]
+
[[File:Trans222.png|center|800px]]
 
<br>
 
<br>
  
* '''Index''': sole ID for the phase of the current transaction.
+
* '''Index''': sole ID for the stage of the current transaction.
 
* '''Name'''.
 
* '''Name'''.
 
* '''Agent''': where the corresponding control scripts will be executed.
 
* '''Agent''': where the corresponding control scripts will be executed.
* '''Dependencies''': prior phases that must be completed before the phase in question initiates; indexes are separated by commas.
+
* '''Dependencies''': prior stages that must be completed before that stage begins; indexes are separated by commas.
* '''Enables''': phases that are enabled when a phase being edited is completed; the indexes of the phases are separated by commas.
+
* '''Enables''': stages that are enabled when a stage being edited is completed; the indexes of the stages are separated by commas.
 
* '''Actions''': save changes.
 
* '''Actions''': save changes.
  
'''START''' is the default initial phase, used only to define which phases will be the first to be executed.
+
'''START''' is the default initial stage, used only to define which stages will be the first to be executed.
  
In the following screenshot, you can see how to insert the index of the first phase to execute (1) Order received.
+
In the following screenshot, you can see how to insert the index of the first stage to execute (1) Order received.
  
 
<br>
 
<br>
Line 165: Line 165:
 
<br>
 
<br>
  
When saving the change we see that the phase with error status is marked automatically. This is because, in our definition, there is no stage with index 1. Click "Add" to create it:
+
When saving the modification, the stage with error status is marked automatically. That happens because, in the definition, there is no stage with index 1. Click "Add" to create it:
  
 
<br>
 
<br>
Line 171: Line 171:
 
<br>
 
<br>
  
Once the changes are saved, create the phase by updating the previsualization of the transaction graph and correcting the previous warning:
+
Once the changes are saved, create the stage by updating the previewing of the transaction graph and correcting the previous warning:
  
 
<br>
 
<br>
Line 177: Line 177:
 
<br>
 
<br>
  
Note that in the phase 1 dependencies field '0' is shown to indicate that the phase will begin when the ''START'' phase has successfully finished.
+
Note that in stage 1, dependencies field '0' is shown to indicate that the stage will begin when the ''START'' stage is successfully finished.
  
Create all the phases following the same procedure:
+
Create all the stages following the same procedure:
  
 
<br>
 
<br>
Line 185: Line 185:
 
<br>
 
<br>
  
The final phase does not enable anything, it means the transaction is finished.
+
The final stage does not enable anything, it means the transaction is finished.
 
 
In the screenshot a yellow warning icon can be seen, indicating that an element is pending configuration (the control scripts).
 
 
 
Once the transaction has been created, a tree chart can be shaped by accessing the corresponding form:
 
  
<br>
+
In the screenshot, a yellow warning icon can be seen, indicating there is something yet to be configured (control scripts).
[[File:trans4.JPG|center|800px]]
 
<br>
 
 
 
enter the data for each phase:
 
 
 
<br>
 
[[File:trans5.JPG|center|800px]]
 
<br>
 
 
 
* '''Index''': sole ID for the phase of the current transaction.
 
* '''Name'''.
 
* '''Agent''': where the corresponding control scripts will be executed.
 
* '''Dependencies''': prior phases that must be completed before the phase in question initiates; indexes are separated by commas.
 
* '''Enables''': phases that are enabled when a phase being edited is completed; the indexes of the phases are separated by commas.
 
* '''Actions''': save changes.
 
 
 
'''START''' is the default initial phase, used only to define which phases will be the first to be executed.
 
 
 
In the following screenshot, you can see how to insert the index of the first phase to execute (1) Order received.
 
 
 
<br>
 
[[File:trans6.JPG|center|800px]]
 
<br>
 
 
 
When saving the change we see that the phase with error status is marked automatically. This is because, in our definition, there is no stage with index 1. Click "Add" to create it:
 
 
 
<br>
 
[[File:trans7.JPG|center|800px]]
 
<br>
 
 
 
Once the changes are saved, create the phase by updating the previsualization of the transaction graph and correcting the previous warning:
 
 
 
<br>
 
[[File:trans8.JPG|center|800px]]
 
<br>
 
 
 
Note that in the phase 1 dependencies field '0' is shown to indicate that the phase will begin when the ''START'' phase has successfully finished.
 
 
 
Create all the phases following the same procedure:
 
 
 
<br>
 
[[File:trans9.JPG|center|800px]]
 
<br>
 
 
 
The last phase will not enable anything, it will mean that the transaction is complete.
 
 
 
In the screenshot we also observe a yellow warning, indicating that there is something pending to be configured, (the control scripts).
 
  
 
=== Control scripts configuration ===
 
=== Control scripts configuration ===
  
We will have to configure the control scripts associated with each phase, these must have been previously defined to perform the desired checks, and maintain a specific basic structure. The standard output of the script will determine the central value shown in the phase, while the status (correct or incorrect) will be determined by the ''result of the execution'' of the script itself, '''NOT''' to be confused with the ''result of the execution'' (also called ''errorlevel'', or ''execution code'') with the standard output of the script (the value returned by the screen when executing it).  
+
Configure the control scripts associated with each stage, these must have been previously defined to perform the desired checks and maintain a specific basic structure. The standard output of the script will determine the central value shown in the stage, while the status (correct or incorrect) will be determined by the ''result of the execution'' of the script itself. Do'''NOT''' mistake the ''execution result'' (also called ''errorlevel'', or ''execution code'') with the standard output of the script (the value returned by the screen when executing it).  
  
 
The run result or error level can be checked by running "echo $?" on Linux systems and ''echo %ERRORLEVEL%'' on Windows systems.
 
The run result or error level can be checked by running "echo $?" on Linux systems and ''echo %ERRORLEVEL%'' on Windows systems.
  
With this in mind, we access the form using the edit icon:
+
With this in mind, access the form using the edit icon:
  
 
<br>
 
<br>
Line 252: Line 201:
 
<br>
 
<br>
  
In the configuration form of the control scripts we can adjust the command to be executed, number of retries and the maximum execution time allowed for the indicated script:
+
In the configuration form of the control scripts, the command to be executed,  
 +
the number of retries and the maximum execution time allowed for the selected script can be adjusted:
  
 
<br>
 
<br>
Line 258: Line 208:
 
<br>
 
<br>
  
*'''Launch script''': location or complete path of the control script, call, command, etc. We can use the _name_ macro to indicate the name of the current transaction as an argument to our script.
+
*'''Launch script''': location or complete path of the control script, call, command, etc. The _name_ macro can be used to point out the name of the current transaction as an argument to the script.
 
*'''Reattempts''': maximum number of execution retries until a positive response is obtained.
 
*'''Reattempts''': maximum number of execution retries until a positive response is obtained.
*'''Maximum waiting time''': maximum value, in seconds, that the control script will remain running (feature not available for the Windows transactional agent).
+
*'''Maximum waiting time''': maximum value, in seconds, that the control script will remain running (feature not available for Windows transactional agent).
  
In our example we will use a custom script (echo1.sh) to simulate the actions of the transaction trigger and control scripts for each phase:
+
In this example, a custom script (echo1.sh) will be used to simulate the actions of the transaction trigger and control scripts for each stage:
  
 
<br>
 
<br>
Line 268: Line 218:
 
<br>
 
<br>
  
Once we have configured our environment correctly, we can initiate the transaction.
+
Once the environment has been correctly configured, the transaction can be initiated.
  
 
<br>
 
<br>
Line 274: Line 224:
 
<br>
 
<br>
  
{{Warning|Any changes made to the configuration of a transaction will not be effective until the transaction is restarted.}}
+
{{Warning|Any changes made to the transaction configuration will not be effective until the transaction is restarted.}}
  
 
=== Transaction control ===
 
=== Transaction control ===
Line 292: Line 242:
 
<br>
 
<br>
  
The status of the transaction can be seen on the display by clicking the transaction's name:
+
The status of the transaction can be displayed by clicking on the transaction's name:
  
 
[[File:trans16.JPG|center|800px]]
 
[[File:trans16.JPG|center|800px]]
Line 298: Line 248:
 
==== Stopping a transaction ====
 
==== Stopping a transaction ====
  
To interrupt a transaction you only have to click the corresponding button, and, after a few seconds, click the "launch" icon to restart it.
+
To interrupt a transaction, click on the corresponding button, and, after a few seconds, click the "launch" icon to restart it.
  
 
<br>
 
<br>
Line 306: Line 256:
 
==== Viewing a transaction ====
 
==== Viewing a transaction ====
  
Go to the view by clicking the name of the transaction on the transaction list.
+
Go to the view by clicking on the name of the transaction on the transaction list.
  
Viewing an execution in progress (initial phase of transaction):
+
View an execution in progress (initial phase of transaction):
  
 
<br>
 
<br>
Line 314: Line 264:
 
<br>
 
<br>
  
Viewing an execution in progress (intermediate phase):
+
View an execution in progress (intermediate phase):
  
 
<br>
 
<br>
Line 320: Line 270:
 
<br>
 
<br>
  
Viewing a completed transaction:
+
View a completed transaction:
  
 
<br>
 
<br>
Line 342: Line 292:
 
  transactional_pool trans
 
  transactional_pool trans
  
* ''transactionalserver'': initiates the transaction server component upon initiating the pandora_server service.
+
* ''transactionalserver'': starts the transaction server component upon starting the pandora_server service.
* ''transactional_threads'': added to the field by agreement, only one internal thread is necessary to manage active transactions from the server. The agent has a subsystem of dynamic threads to manage configured transaction executions.
+
* ''transactional_threads'': added to the field by agreement. Only one internal thread is necessary to manage active transactions from the server. The agent has a subsystem of dynamic threads to manage configured transaction executions.
* ''transactional_threshold'': wait time between status updates. This field defines the time, in seconds, that the system will wait between changes in status of the elements which make up a transaction (recommended threshold: 4 seconds).
+
* ''transactional_threshold'': waiting time between status updates. This field specifies the time, in seconds, that the system will wait between changes in status of the elements which make up a transaction (recommended threshold: 4 seconds).
 
* ''transactional_pool'': directory where “lock” files are saved. The system uses these files to communicate among the different logical components (default location: /var/spool/pandora/data_in/trans).
 
* ''transactional_pool'': directory where “lock” files are saved. The system uses these files to communicate among the different logical components (default location: /var/spool/pandora/data_in/trans).
  
Line 351: Line 301:
 
[[File:trans21.JPG|center|800px]]
 
[[File:trans21.JPG|center|800px]]
  
=== transactional agent ===
+
=== Transaction agents ===
  
The transactional agents have  a configuration file in their work directory (by default at: ''/etc/pandora/pandora_transactional.conf'') with the following content:
+
Transactional agents have  a configuration file in their work directory (by default at: ''/etc/pandora/pandora_transactional.conf'') with the following content:
  
 
  ############################################################
 
  ############################################################
Line 387: Line 337:
 
  verbose=2
 
  verbose=2
  
* ''server_ip'': IP address or the name of Pandora's transactional server.
+
* ''server_ip'': IP address or the name of Pandora FMS's transactional server.
 
* ''server_port'': port where the tentacle server listens in.
 
* ''server_port'': port where the tentacle server listens in.
 
* ''temporal'': auxiliary directory for temporary work files.
 
* ''temporal'': auxiliary directory for temporary work files.
Line 393: Line 343:
 
* ''tentacle_bin'': tentacle client's binary route.
 
* ''tentacle_bin'': tentacle client's binary route.
 
* ''agent_name'': optional, use a custom name to ID this agent. The name of the machine is the default ID.
 
* ''agent_name'': optional, use a custom name to ID this agent. The name of the machine is the default ID.
* ''pause'': default time , in seconds, between phases. Adjusts to the configuration received by the server to maintain synchrony.
+
* ''pause'': default time, in seconds, between stages. It adjusts to the configuration received by the server to maintain synchrony.
* ''verbose'': controls the quantity of information displayed in the log files. Any output in ''STDERR'' will overflow to this file by default:
+
* ''verbose'': it controls the amount of information displayed on the log files. Any output in ''STDERR'' will overflow to this file by default:
 
** 0: only show critical error messages.
 
** 0: only show critical error messages.
 
** 1: show control script executions.
 
** 1: show control script executions.
 
** 2: show all messages.
 
** 2: show all messages.
  
All transaction configurations will be published in the Pandora FMS server, and the agent is in charge of scanning these files and initiating the necessary data structures to initiate the transactions solicited.
+
All transaction configurations will be published in the Pandora FMS server, and the agent is in charge of scanning these files and starting the necessary data structures to start the requested transactions.
 +
 
 +
In the face of any updates during an active transaction, the agent will interrupt the transaction, and start a new process to instantiate a new one. All previous progress will be lost.
 +
 
 +
The transaction system executes the complete transaction, which is to say, that if there is an error executing a script, the transaction will continue to be executed, indicating the stage during which the error took place. A transaction is considered failed when all stages are indicated as errors.
 +
 
 +
Download the transactional agent component from the plugin library [https://pandorafms.com/library/transactional-agent-2/]
  
In the face of any updates during an active transaction the agent will interrupt the transaction, and initiate a new process to instantiate a new one. All previous progress will be lost.
 
  
The transaction system executes the complete transaction, which is to say, that if there's an error executing a script the transaction will continue to execute, indicating the phase during which the error occurred. A transaction is considered failed when all phases are indicated as errors.
+
[[Pandora:Documentation_en|Go back to Pandora FMS documentation index]]

Latest revision as of 09:57, 10 September 2019

Go back to Pandora FMS documentation index

1 Transaction monitoring

1.1 Introduction

Pandora FMS v. 7 now features transaction monitoring.

The transactional server component implemented in this version allows to execute tasks, which are dependent upon one another, following a user-defined design. This means that it is possible to coordinate different executions to test a target at a given time.

The following case study consists of tracking an order that goes through different stages, being able to keep track of the time in each of the steps, departments or stages:


Trans sq.png


A four-step graph will be defined, which Pandora FMS will use along with a series of control scripts to monitor the previously indicated process, visually showing the status in which each one of the parts that make up the business process is at all times.

Below there is an explanation on how to fully monitor a transaction process.

1.2 Operation

A transaction can be defined as a set of steps that make up a more complex task. These steps will be called stages.

The set of stages and their workflow (dependency relations) will define a transactional graph.

Pandora FMS, based on the transactional graph, will launch an order to execute control scripts in each of the previously defined stages. These control scripts will perform the monitoring tasks for each stage.

The most common points to check in control scripts that can provide information on the status of a transaction are:

  • Entries in log files.
  • Presence of temporary files.
  • Direct database queries.
  • Existence of mail in inboxes.

The transactional system is distributed, being able to deploy as many transactional agents in an infrastructure as needed, and it will be the Pandora FMS server the one that will communicate with these agents, indicating the steps to follow and the time when they must run a control script.

1.3 Configuring a transaction

In order to configure and execute transaction monitoring, these will be necessary:

  • Previous analysis of the business process to be monitored:
    • Workflow.
    • Points involved.
    • Control scripts.
  • Transactional agent deployment in the required equipment to control the information flow.
    • Development and deployment of control scripts in the required transactional agents.
    • Configuration of transactional agents.
  • From Pandora FMS console, create the transaction by entering the data in the forms.

1.3.1 Previous analysis

Let us analyze a regular case:

The transaction begins when an order is received on the web portal, where a transactional agent must be deployed, or at least on a machine capable of carrying out remote checks. During this first stage, a critical script is executed: the transaction trigger.

In the next stage, a virtualization of the order processing is launched in the EMI01 machine, using different ID codes for the order placed in the previous stage. There must be another transactional agent installed on this machine, or, if not, on a machine capable of executing remote checks. The control script checks that the process has been correctly completed in this stage by searching for registry file entries, events or temporary files.

The third stage of the transaction is to save the processed order on an Oracle database, on the ORAMON machine. These machines are usually highly protected and it is difficult to install additional software on them, so a transactional agent should be deployed on a remote machine with permissions to launch data base queries.

The last stage is to confirm whether there is mail in the Logistic department's inbox in the public mail server. Since an agent cannot be deployed on this machine, the queries will have to be run from another machine that is able to access it. Pandora FMS classic plugins slightly modified can be used to check incoming emails.

1.3.2 Deployment and development

In this example, there are four stages which require four scripts:

  1. Transaction trigger: makes a virtual order to the web portal in order to subsequently trace it.
  2. Control script: looks for a string in the log file.
  3. Control script: queries the data base.
  4. Control script: confirms whether the corresponding email reached the Logistics inbox.

In the above example, the transaction trigger leaves a file copy of an order on a specific point.

Control scripts share a basic structure as in the following example:


Script1.JPG


#!/bin/bash
########################
# Check Control Set 
######################## 
function check_flag() { 
   # Control script conditions 
   if [ "a" == "a" ]; then 
      return 1; 
   fi 
   return 0; 
} 
max_tries=100 
wait=3 
try=0 
while [ $try -le $max_tries ]; do 
   if [ check_flag == 1 ]; then 
      echo 1 
      exit 0 
   fi 
   sleep 
   $wait 
   try=`expr $try + 1` 
done 
echo 0 
exit 1

Once the scripts are working correctly, proceed to deploy transactional agents on the necessary machines and devices.

tar xvzf pandorafms_transactional.tar.gz
cd pandora_transactional 
./pandora_transactional_installer --install

Just modify the agent configuration file (/etc/pandora/pandora_transaccional.conf by default) to point to the Pandora FMS server that will direct the transaction process. And start the agent's service:

/etc/init.d/transactional_daemon start

1.3.3 Creating a transaction

Using the Pandora FMS web console.

Go to Maps -> Transactional map.


Trans1.JPG


Trans2.JPG


Create the new transaction and fill in the required fields.


Trans3.JPG


  • Name.
  • Description.
  • Agent: Pandora FMS agent where the modules generated by the system will be saved (History).
  • Group: to control visibility and access.
  • Loop interval: waiting time before launching the transaction again.

1.3.4 Creating the stage tree

Once the transaction has been created, a tree chart can be shaped by accessing the corresponding form:


Trans111.png


Enter the data for each stage:


Trans222.png


  • Index: sole ID for the stage of the current transaction.
  • Name.
  • Agent: where the corresponding control scripts will be executed.
  • Dependencies: prior stages that must be completed before that stage begins; indexes are separated by commas.
  • Enables: stages that are enabled when a stage being edited is completed; the indexes of the stages are separated by commas.
  • Actions: save changes.

START is the default initial stage, used only to define which stages will be the first to be executed.

In the following screenshot, you can see how to insert the index of the first stage to execute (1) Order received.


Trans6.JPG


When saving the modification, the stage with error status is marked automatically. That happens because, in the definition, there is no stage with index 1. Click "Add" to create it:


Trans7.JPG


Once the changes are saved, create the stage by updating the previewing of the transaction graph and correcting the previous warning:


Trans8.JPG


Note that in stage 1, dependencies field '0' is shown to indicate that the stage will begin when the START stage is successfully finished.

Create all the stages following the same procedure:


Trans9.JPG


The final stage does not enable anything, it means the transaction is finished.

In the screenshot, a yellow warning icon can be seen, indicating there is something yet to be configured (control scripts).

1.3.5 Control scripts configuration

Configure the control scripts associated with each stage, these must have been previously defined to perform the desired checks and maintain a specific basic structure. The standard output of the script will determine the central value shown in the stage, while the status (correct or incorrect) will be determined by the result of the execution of the script itself. DoNOT mistake the execution result (also called errorlevel, or execution code) with the standard output of the script (the value returned by the screen when executing it).

The run result or error level can be checked by running "echo $?" on Linux systems and echo %ERRORLEVEL% on Windows systems.

With this in mind, access the form using the edit icon:


Trans10.JPG


In the configuration form of the control scripts, the command to be executed,

the number of retries and the maximum execution time allowed for the selected script can be adjusted:


Trans11.JPG


  • Launch script: location or complete path of the control script, call, command, etc. The _name_ macro can be used to point out the name of the current transaction as an argument to the script.
  • Reattempts: maximum number of execution retries until a positive response is obtained.
  • Maximum waiting time: maximum value, in seconds, that the control script will remain running (feature not available for Windows transactional agent).

In this example, a custom script (echo1.sh) will be used to simulate the actions of the transaction trigger and control scripts for each stage:


Trans12.JPG


Once the environment has been correctly configured, the transaction can be initiated.


Trans13.JPG


Template warning.png

Any changes made to the transaction configuration will not be effective until the transaction is restarted.

 


1.3.6 Transaction control

1.3.6.1 Initiate a transaction

Go to the transactions list and click on the "initiate" icon (the black doughnut):


Trans14.JPG


Once the transaction has been initiated the "stop transaction" icon will appear:


Trans15.JPG


The status of the transaction can be displayed by clicking on the transaction's name:

Trans16.JPG

1.3.6.2 Stopping a transaction

To interrupt a transaction, click on the corresponding button, and, after a few seconds, click the "launch" icon to restart it.


Trans17.JPG


1.3.6.3 Viewing a transaction

Go to the view by clicking on the name of the transaction on the transaction list.

View an execution in progress (initial phase of transaction):


Trans18.JPG


View an execution in progress (intermediate phase):


Trans19.JPG


View a completed transaction:


Trans20.JPG


1.4 Configuration

1.4.1 Transaction server

The transaction server's configuration parameters are as follows:

transactionalserver 1

transactional_threads 1

transactional_threshold 1

# Work directory
# By default in icomingdir/trans
transactional_pool trans
  • transactionalserver: starts the transaction server component upon starting the pandora_server service.
  • transactional_threads: added to the field by agreement. Only one internal thread is necessary to manage active transactions from the server. The agent has a subsystem of dynamic threads to manage configured transaction executions.
  • transactional_threshold: waiting time between status updates. This field specifies the time, in seconds, that the system will wait between changes in status of the elements which make up a transaction (recommended threshold: 4 seconds).
  • transactional_pool: directory where “lock” files are saved. The system uses these files to communicate among the different logical components (default location: /var/spool/pandora/data_in/trans).

For the system to be 100% operational, both the data server (dataserver) and the transaction server (transactionalserver) must be active. Go to tactical server view to check:

Trans21.JPG

1.4.2 Transaction agents

Transactional agents have a configuration file in their work directory (by default at: /etc/pandora/pandora_transactional.conf) with the following content:

############################################################
#  Base config file for Pandora FMS transactional agent 
#  Version 2.0                                      
#  Copyright (c) 2003-2016 Artica Soluciones Tecnologicas  
#  http://www.pandorafms.com                          
#############################################################

server_ip=localhost
server_port=41121

# Temporal directory
temporal=/tmp
#temporal=C:\Program Files\pandora_transactional\tmp

# Log directory
log=/var/log/pandora/pandora_transactional.log

# Tentacle binary
tentacle_bin=/usr/bin/tentacle_client

###############################
# Set the name of the agent
###############################
#agent_name=transactional_agent
agent_interval=300

# Performance (in seconds) internal clock
pause=5

# Show all log messages (0 - show none, 1 - show script execution messages, 2 - show all)
verbose=2
  • server_ip: IP address or the name of Pandora FMS's transactional server.
  • server_port: port where the tentacle server listens in.
  • temporal: auxiliary directory for temporary work files.
  • log: log file route.
  • tentacle_bin: tentacle client's binary route.
  • agent_name: optional, use a custom name to ID this agent. The name of the machine is the default ID.
  • pause: default time, in seconds, between stages. It adjusts to the configuration received by the server to maintain synchrony.
  • verbose: it controls the amount of information displayed on the log files. Any output in STDERR will overflow to this file by default:
    • 0: only show critical error messages.
    • 1: show control script executions.
    • 2: show all messages.

All transaction configurations will be published in the Pandora FMS server, and the agent is in charge of scanning these files and starting the necessary data structures to start the requested transactions.

In the face of any updates during an active transaction, the agent will interrupt the transaction, and start a new process to instantiate a new one. All previous progress will be lost.

The transaction system executes the complete transaction, which is to say, that if there is an error executing a script, the transaction will continue to be executed, indicating the stage during which the error took place. A transaction is considered failed when all stages are indicated as errors.

Download the transactional agent component from the plugin library [1]


Go back to Pandora FMS documentation index