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

From Pandora FMS Wiki
Jump to: navigation, search
(Prior analysis)
(Test case)
Line 53: Line 53:
 
== Prior analysis ==
 
== Prior analysis ==
  
=== Test case ===
+
'''Test 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 phase a critical script is executed; the '''transaction trigger'''.
  
Nuestra transacción se inicia cuando se recibe un pedido en la máquina ''Portal''. Tendremos por tanto que desplegar un agente transaccional en ''Portal'' o bien en una máquina capaz de realizar consultas remotas. En esta primera fase se ejecutará un script crítico, el '''disparador de transacción'''.
+
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. You'll need to have 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.
  
En el siguiente paso de nuestra transacción se lanza un proceso de procesado del pedido en la máquina ''EMI01'', empleando diferentes códigos identificadores del pedido realizado en el paso anterior. Necesitaremos otro agente transaccional en esta máquina o en una capaz de consultarla remotamente. El script de control de esta fase deberá comprobar que el proceso se ha completado correctamente, para ello buscará entradas en archivos de registro, eventos o archivos temporales.
+
The third phase of the transaction is to save the processed order in 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 transactional agent should be deployed on a remote machine with permission to launch data base queries.
  
El tercer paso de la transacción será almacenar el pedido ya procesado en una base de datos Oracle, en la máquina ''ORAMON''. Es habitual que estas máquinas estén securizadas y no sea posible la instalación de software adicional en ellas, por lo que desplegaremos el agente transaccional en una máquina remota con permisos para lanzar consultas contra la base de datos.
 
  
 
El último paso es confirmar la existencia de un correo en la bandeja de entrada del departamento de Logística en un servidor de correo ''público''.
 
El último paso es confirmar la existencia de un correo en la bandeja de entrada del departamento de Logística en un servidor de correo ''público''.

Revision as of 12:30, 27 February 2017

Template warning.png

Pending translate.

 


1 Transactional monitoring

1.1 Introduction

Pandora FMS v. 7 now incorporates transactional 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.


Trans sq.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 information on the status of each part of the transaction.


A continuación veremos cómo monitorizar de forma completa un proceso transaccional.

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 transactional network.

Pandora FMS, based on these transactional 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 consultations.
  • If there is mail in any inbox.


The transactional system is distributed, meaning that as many transactional 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 transactional monitoring the following will be necessary:

    • A prior analysis of the process to monitor.
    • Workflow.
    • Puntos implicados.????????????/////////????????//////?/?//?/?////?////?/?//?/
    • Control scripts.
    • Deployment of transactional agents over any necessary machines, to control the workflow.
    • Development and deployment of control scripts on the necessary transactional agents.
    • Transactional agents configured.
    • 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 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.

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. You'll need to have 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.

The third phase of the transaction is to save the processed order in 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 transactional agent should be deployed on a remote machine with permission to launch data base queries.


El último paso es confirmar la existencia de un correo en la bandeja de entrada del departamento de Logística en un servidor de correo público. Dado que no podemos desplegar un agente en esta máquina, realizaremos las consultas desde otra que sea capaz de acceder a ella. Podemos utilizar los plugins clásicos de Pandora FMS con pequeñas variaciones para realizar la verificación de la llegada del correo electrónico.

1.4.1 Despliegue y desarrollo

En nuestro ejemplo identificamos cuatro fases, y necesitaremos cuatro scripts:

  • 1. Disparador de transacción: dejar un pedido ficticio en la máquina Portal para poder rastrearlo.
  • 2. Script de control: buscar una cadena en un archivo de log.
  • 3. Script de control: realizar una consulta a la base de datos.
  • 4. Script de control: confirmar la existencia de un correo en la bandeja de entrada de Logística.

En nuestro caso el disparador de transacción dejará una copia de un fichero de un pedido en un punto determinado (por ejemplo mediante FTP).

Todos los scripts de control deben tener una estructura básica como la del siguiente ejemplo:

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

Una vez tengamos todos los scripts funcionando correctamente, procederemos a desplegar agentes transaccionales en las máquinas que necesitemos.

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

Únicamente tendremos que modificar el fichero de configuración del agente (por defecto /etc/pandora/pandora_transaccional.conf) para apuntar al servidor Pandora FMS que dirigirá el proceso de la transacción. E iniciaremos el servicio del agente:

/etc/init.d/transactional_daemon start

1.4.2 Creación de transacción

Lo haremos a través de la consola web de Pandora FMS.

Accedemos al menú Maps -> Transactional map.


Trans1.JPG


Trans2.JPG


Creamos la nueva transacción y completamos los campos solicitados.


Trans3.JPG


  • Nombre.
  • Descripción.
  • Agente: agente de pandora donde se guardarán los módulos generados por el sistema (histórico).
  • Grupo: para control de la visibilidad y accesos.
  • Intervalo de bucle: tiempo de espera antes de lanzar de nuevo la transacción.

1.4.3 Creación del árbol de fases

Una vez creada la transacción podremos dar forma al árbol de fases accediendo al formulario correspondiente:


Trans4.JPG


En el formulario debemos introducir los datos de cada fase:


Trans5.JPG


  • Índice: identificador único de la fase en la transacción actual.
  • Nombre.
  • Agente: donde se ejecutará el script de control correspondiente.
  • Dependencias: fases anteriores que deben estar completadas antes de iniciar la fase en cuestión. Se indicarán los índices de las fases correspondientes separados por comas.
  • Habilitadores: descendientes, fases que se habilitarán cuando se complete la fase que estamos editando. Se indicarán los índices de las fases separados por comas.
  • Acciones: guardar cambios.

Por defecto tenemos una fase inicial START, esta fase se utiliza únicamente para definir qué fases serán las priemras en ser ejecutadas.

En la siguiente captura vemos cómo que se inserta el ínidice de la primera fase a ejecutar, (1) Recepción de pedido.


Trans6.JPG


Al guardar el cambio vemos que automáticamente se nos marca la fase con estado de error. Esto es debido a que, en nuestra definición, no existe ninguna fase con índice 1. Presionamos “Agregar” para crearla:


Trans7.JPG


Una vez guardados los cambios, creamos la fase, actualizando la previsualización del grafo de transacción y corrigiendo el aviso previo:


Trans8.JPG


Podemos observar que en campo dependencias de la fase 1, se ha establecido '0' para indicar que esta fase iniciará cuando la fase START se haya completado con éxito.

Siguiendo el mismo procedimiento crearemos todas las fases:


Trans9.JPG


La última fase no habilitará nada, significará que la transacción ha terminado.

En la captura también observamos una advertencia en color amarillo, indicándonos que hay algo pendiente de ser configurado, serán los scripts de control.

1.4.4 Configuración de los scripts de control

Deberemos configurar los scripts de control asociados a cada fase, éstos deben haber sido previamente definidos para realizar las comprobaciones deseadas, y mantener una estructura básica determinada. La salida estándar del script determinará el valor central mostrado en la fase, mientras que el estado (correcto o incorrecto) será determinado por el resultado de la ejecución del propio script, OJO no confundir el resultado de la ejecución (también llamado errorlevel, nivel de error, o código de ejecución) con la salida estándar del script (el valor que devuelve por pantalla al ejecutarlo).

El resultado de ejecución o errorlevel puede comprobarse ejecutando echo $? en sistemas Linux y echo %ERRORLEVEL% en sistemas Windows.

Teniendo esto claro, accedemos al formulario mediante el icono de edición:


Trans10.JPG


En el formulario de configuración de los scripts de control podremos ajustar el comando a ejecutar, número de reintentos y el tiempo máximo de ejecución permitido para el script indicado:


Trans11.JPG


  • Lanzar script: ubicación o ruta completa del script de control, llamada, comando, etc. Podremos utilizar la macro _name_ para indicar como argumento a nuestro script el nombre de la transacción en curso.
  • Reintentos: número máximo de reintentos de ejecución hasta conseguir una respuesta positiva.
  • Tiempo máximo de espera': valor máximo, en segundos, que permanecerá en ejecución el script de control (característica no disponible para el agente transaccional de Windows).

En nuestro ejemplo utilizaremos un script personalizado (echo1.sh) para simular las acciones del disparador de transacción y de los scripts de control de cada fase:


Trans12.JPG


Una vez tenemos configurado correctamente nuestro entorno, podemos iniciar la transacción.


Trans13.JPG


Template warning.png

Cualquier cambio realizado sobre la configuración de una transacción no será efectivo hasta que se reinicie la misma.

 


1.4.5 Control de una transacción

1.4.5.1 Iniciar una transacción

Navegaremos ahsta la lista de transacciones y pulsaremos el icono de iniciado:


Trans14.JPG


Una vez iniciada la transacción aparecerá el botón "detener transacción":


Trans15.JPG


Podemos visualizar el estado de la transacción desde el visor pulsando sobre el nombre de la transacción:


Trans16.JPG


1.4.5.2 Detener una transacción

Para detener la transacción solo tendremos que accionar el botón correspondiente, tras pocos segundos podremos volver a lanzarla mediante el botón de lanzado.


Trans17.JPG


1.4.5.3 Visualizar una transacción

Accederemos a la vista pulsando en el nombre de la transacción en el listado de transacciónes.

Vista de ejecución en curso (inicio de transacción):


Trans18.JPG


Vista de ejecución en curso (fase intermedia):


Trans19.JPG


Vista de transacción completa:


Trans20.JPG


1.5 Configuración

1.5.1 Servidor transaccional

Los parámetros de configuración del servidor transaccional son los siguientes:

transactionalserver 1

transactional_threads 1

transactional_threshold 1

# Work directory
# By default in icomingdir/trans
transactional_pool trans
  • transactionalserver: para iniciar el componente de servidor transaccional al iniciar el servicio pandora_server.
  • transactional_trheads: se agrega el campo por convenio, internamente sólo es necesario un hilo para gestionar las transacciones activas desde el servidor. Es el agente el que tiene el subsistema de hilos dinámico para la gestión de ejecuciones de las transacciones configuradas.
  • transactional_threshold: tiempo de espera entre cambios de estado. Este campo nos define el tiempo (en segundos) que el sistema esperará entre los cambios de estado de los elementos que componen una transacción (recomendado 4).
  • transactional_pool: directorio en que se almacenarán los archivos “lock” que internamente utiliza el sistema para realizar las comunicaciones entre los diferentes componentes lógicos (por defecto en /var/spool/pandora/data_in/trans).

Para que el sistema esté totalmente operativo debemos tener activos tanto el servidor de datos (dataserver) como el servidor transaccional (transactionalserver), podremos comprobarlo en la vista tactica de servidores:


Trans21.JPG


1.5.2 Agente transaccional

El agente transaccional tiene un fichero de configuración en su directorio de trabajo (por defecto /etc/pandora/pandora_transactional.conf) con el siguiente contenido:

############################################################
#  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: dirección IP o nombre del servidor transaccional de Pandora.
  • server_port: puerto en que el servidor de tentacle está escuchando.
  • temporal: directorio auxiliar para ficheros de trabajo temporales.
  • log: ruta del archivo de log.
  • tentacle_bin: ruta del binario del cliente tentacle.
  • agent_name: opcional, utilizar un nombre personalizado para identificar este agente. Por defecto utiliza el nombre de máquina.
  • pause: tiempo por defecto en segundos entre pasos. Se ajustará a la configuración recibida por el servidor para mantener la sincronía.
  • verbose: control de la cantidad de información mostrada en los archivos de log. Por defecto se vuelcan al fichero cualquier salida en STDERR que generen nuestros scripts de control:
    • 0: mostrar solo mensajes de error crítico.
    • 1: mostrar ejecuciones de los scripts de control.
    • 2: mostrar todos los mensajes.

Toda la configuración de transacciones se publicará en el servidor de Pandora FMS. Será el agente el que se encargue de rastrear estos ficheros e iniciar las estructuras de datos necesarias para iniciar las transacciones solicitadas.

Ante cualquier actualización en una transacción activa, el agente detendrá esta transacción, iniciando un nuevo proceso para instanciar una nueva. Se descartará todo progreso previo.

El sistema transaccional ejecuta la transacción completa. Es decir, si falla en la ejecución de un script se seguirá ejecutando la transacción, marcando como errónea la fase donde se ha detectado el fallo. Por tanto, interpretaremos una transacción como con fallo completo cuando a partir de una fase hasta el final todas aparecen marcadas como erróneas.