Pandora: Documentation es: Monitorizacion transaccional

From Pandora FMS Wiki
Jump to: navigation, search

1 Monitorización Transaccional

1.1 Introducción

Pandora FMS incorpora desde su versión 7 la posibilidad de monitorizar procesos de negocio.

El componente de servidor transaccional implementado en esta versión permite ejecutar tareas dependientes unas de otras siguiendo un diseño definido por el usuario. Esto significa que es posible coordinar diferentes ejecuciones para comprobar un objetivo en un momento determinado.

Pongamos por ejemplo, un caso práctico. Podría consistir en realizar el seguimiento de un pedido que va pasando por sus diferentes fases, pudiendo llevar un control de los tiempos en cada uno de los pasos, departamentos o etapas:


Trans sq.png


Nos definiría un grafo de 4 etapas. Pandora FMS utilizará este grafo junto con una serie de scripts de control para monitorizar el proceso anteriormente indicado, mostrando visualmente el estado en que está en todo momento cada una de las partes que conforman nuestro proceso de negocio.

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

1.2 Funcionamiento

Definiremos una transacción como un conjunto de pasos que conforman una tarea más compleja. A estos pasos los denominaremos fases.

El conjunto de fases y su flujo de trabajo (relaciones de dependencia) definirá un grafo transaccional.

Pandora FMS, basándose en el grafo transaccional, lanzará una orden de ejecución de scripts de control en cada una de las fases anteriormente definidas. Estos scripts de control realizarán las tareas de monitorización de cada fase.

Los puntos más habituales a comprobar en los scripts de control que pueden darnos información sobre el estado de nuestra transacción son:

  • Entradas en ficheros de log.
  • Presencia de archivos temporales.
  • Consultas directas a bases de datos.
  • Existencia de correos en bandejas de entrada.

El sistema transaccional es distribuido, pudiendo desplegar tantos agentes transaccionales en nuestra infraestructura como necesitemos, y será el servidor de Pandora FMS el que se comunicará con estos agentes, indicándoles los pasos a seguir y los momentos en que deben ejecutar un script de control.

1.3 Configurar una transacción

Para configurar y realizar adecuadamente un proceso de monitorización transaccional se necesitará:

  • Análisis previo del proceso de negocio a monitorizar:
    • Flujo de trabajo.
    • Puntos implicados.
    • Scripts de control.
  • Despliegue de agentes transaccionales en los equipos requeridos, para controlar el flujo de información.
    • Desarrollo y despliegue de los scripts de control en los agentes transaccionales necesarios.
    • Configuración de los agentes transaccionales.
  • Desde la consola de Pandora, crear la transacción introduciendo los datos en los formularios.

1.3.1 Análisis previo

Vamos a realizar un análisis de un caso habitual.

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.

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.

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. 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.3.2 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.3.3 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 FMS 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.3.4 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 primeras en ser ejecutadas.

En la siguiente captura vemos cómo que se inserta el índice 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.3.5 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.3.6 Control de una transacción

1.3.6.1 Iniciar una transacción

Navegaremos hasta 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.3.6.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.3.6.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.4 Configuración

1.4.1 Servidor transaccional

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

transactionalserver 1

transactional_threads 1

transactional_threshold 4

# 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_threads: 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.4.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.

Puede encontrar el agente transaccional en la librería de módulos de Pandora FMS [1]