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

From Pandora FMS Wiki
Jump to: navigation, search
Line 132: Line 132:
  
 
[[File:trans4.JPG|center|800px]]
 
[[File:trans4.JPG|center|800px]]
 +
  
 
Introduce the information for each phase:
 
Introduce the information for each phase:

Revision as of 08:57, 13 June 2017

1 Transaction monitoring

1.1 Introduction

Pandora FMS v. 7 now incorporates transaction monitoring.

The transactional server implemented in the latest version of Pandora FMS allows the user to sequence dependency tasks, making it possible to coordinate different executions in order to check objectives at a given time, e.g. follow an online transaction from start to finish and get feedback on the timings of every stage in the process.

Monitorizacion transaccional EN.png

A four-step network will be defined which Pandora FMS will use, together with a series of control scripts, to monitor the process outlined above, and give visual feedback on the status of each part of the transaction.

1.2 Functioning

Monitoring a transaction from start to finish.

Transaction, in this case, means a series of steps, hereafter known as phases, that form a more complex task.

The set of phases and their workflow, or dependency relations, define a transaction network.

Pandora FMS, based on these transaction networks, launches a series of control scripts during each of the previously defined phases. These control scripts carry out the monitoring tasks corresponding to each phase.

The most commonly checked points in the control scripts are:

  • Log entries.
  • If temporary files are present.
  • Data base queries.
  • Whether there is mail in any inbox.


The transaction system is distributed, meaning that as many transaction agents as the user wishes may be deployed over the infrastructure, and the Pandora FMS server will communicate with them, indicating the steps to follow and when to execute the control scripts.

1.3 Configuring a transaction

In order to configure and execute transaction monitoring the following will be necessary:

    • A prior analysis of the process to be monitored.
    • Workflow.
    • All elements and components implicated.
    • Control scripts.
    • Deployment of transaction agents on any necessary machines, to control the workflow.
    • Development and deployment of control scripts on the necessary transaction agents.
    • To configure the transaction agents.
    • To create the transaction, by filling out the forms from the Pandora FMS console.

1.4 Prior analysis

Test case

The transaction begins when an order is received on the web portal, where a transaction 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.

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 transaction 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.

The third phase of the transaction is to save the processed order on an Oracle data base, on the ORAMON machine. These machines are usually highly protected and it's difficult to install additional software on them, so a transaction agent should be deployed on a remote machine with permission 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. Given that we can't install an agent on this machine, queries will have to come from another device capable of accessing it, e.g. using the classic Pandora FMS plugins slightly modified to check incoming emails.


1.4.1 Deployment and development

In the example there are four phases which require four scripts:

  • 1.Transaction trigger: makes a virtual order to the web portalin order to subsequently trace it.
  • 2.Control script: looks for a chain 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 in a specific point (e.g. by FTP).

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

Script1.JPG
#!/bin/bash
########################
# Check Control Set 
######################## 
function check_flag() { 
   # Condiciones del script de control 
   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 transaction agents on the necessary machines and devices.

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

Only the agent configuration file needs to be modified (by default /etc/pandora/pandora_transaccional.conf) to prepare the Pandora FMS server which will direct the transaction process. Initiate the agent:

/etc/init.d/transactional_daemon start

1.4.2 Creating a transaction

By means of the Pandora FMS web console.

Go to Maps -> Transactional map.

Trans1.JPG
Trans2.JPG

Create the new transaction and fill out 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: Time between each new launch .

1.4.3 Create a chart of the phases

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

Trans4.JPG


Introduce the information for each phase:

Trans5.JPG
  • 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; indices are separated by commas.
  • Enables: phases that are enabled when a phase being edited is completed; the indices 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.

Trans6.JPG

When you save the changes the phase is automatically marked as error, due to there not being any phase with index 1. Click 'Add' to create it:

Trans7.JPG

Once the changes are saved, create the phase by updating the previsualization of the transaction network and correcting the previous warning:

Trans8.JPG

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:

Trans9.JPG

The final phase 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).

1.4.4 Configuring control scripts

The control scripts associated to each phase must be configured, and the phases previously defined in order to carry out checks, and to maintain a basic set structure. The standard script output will determine the main value shown during the phase, while the status (correct or incorrect) is determined by the execution result of the script itself. NOTE don't confuse execution result (AKA errorlevel or execute code) with the standard script output (the value returned by the screen when executed).

The errorlevel result can be checked by executing echo $? on Linux systems, and echo %ERRORLEVEL% on Windows systems.

Go to the form by clicking on the Edit icon:

Trans10.JPG

With the Configure control scripts form you can adjust the command you want to execute, the number of retries, and the maximum execute time allowed for the script in question:

Trans11.JPG
  • Launch script: control script route, location, call, command, etc. The macro _name_ can be used to indicate the transaction in process as the argument for the script.
  • Retries: maximum number of executions till a positive reply is attained.
  • Timeout: Maximum value, in seconds, that a script will continue executing (not available for Windows transaction agent).

In the example, a custom script (echo1.sh) is used to simulate the transaction trigger and the control scripts in each phase:

Trans12.JPG

Once everything is configured correctly the transaction may be initiated.

Trans13.JPG


Template warning.png

Any changes made to the transaction configuration won't take effect until it's reinitiated.

 


1.4.5 Transaction control

1.4.5.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 seen on the display by clicking the transaction's name:

Trans16.JPG

1.4.5.2 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.

Trans17.JPG

1.4.5.3 Viewing a transaction

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

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

Trans18.JPG

Viewing an execution in progress (intermediate phase):

Trans19.JPG

Viewing a completed transaction:

Trans20.JPG

1.5 Configuration

1.5.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: initiates the transaction server component upon initiating 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: 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_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.5.2 Transaction agent

The transaction 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'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 phases. 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:
    • 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 initiating the necessary data structures to initiate the transactions solicited.

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.