Monitorización transaccional de negocio

Volver al Índice de Documentación Pandora FMS

Pandora FMS incorpora desde su versión 7 (hasta la versión 767) 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:

Esto define un grafo de 4 etapas:

1. Portal: Recepción del pedido.
2. EMI01: Proceso del pedido.
3. ORAMON: Guardado en base de datos.
4. Correo electrónico: Notificación a logística.

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.

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.

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 FMS, crear la transacción introduciendo los datos en los formularios.

Análisis de un caso habitual:

La transacción se inicia cuando se recibe un pedido en la máquina Portal. Se tiene, 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 (trigger) de transacción.

En el siguiente paso de la transacción se lanza una labor de procesado del pedido en la máquina EMI01, empleando diferentes códigos identificadores del pedido realizado en el paso anterior. Se necesita 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 con alta seguridad 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 electrónico 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, se realizarán las consultas desde otra que sea capaz de acceder a ella. Se puede utilizar un plugin clásico de Pandora FMS con pequeñas variaciones para realizar la verificación de la llegada del correo electrónico.

En este ejemplo se identifican cuatro fases, y se necesitan cuatro scripts:

• 1. Trigger 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 electrónico en la bandeja de entrada de Logística.

El trigger 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:

#!/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 se tengan todos los scripts funcionando correctamente, se procede a desplegar los Agentes transaccionales en las máquinas que se necesiten.

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

Puede encontrar el Agente transaccional en la librería de módulos de Pandora FMS.

Se debe 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.

Para iniciar el servicio del Agente transaccional:

/etc/init.d/transactional_daemon start

Vaya a la Consola web de Pandora FMS. Acceda al menú Topology maps → Transactional map:

Haga clic en Create transactions y complete los campos:

• Agent: Agente de Pandora FMS donde se guardarán los Módulos generados por el sistema (histórico).
• Group: Para control de la visibilidad y accesos mediante grupos.
• Loop interval: Tiempo de espera antes de lanzar de nuevo la transacción.

Una vez creada la transacción, vaya al listado y haga clic en el icono de llave ajustable (Edit phases) y proceda a dar forma al árbol de fases

En el formulario debe introducir los datos de cada fase:

• Index: Identificador único de la fase en la transacción actual.
• Agent: Donde se ejecutará el script de control correspondiente.
• Dependencies: 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.
• Enabled: 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.
• Actions: Guardar cambios.

Por defecto existe una fase inicial START, esta fase se utiliza únicamente para definir qué fases serán las primeras en ser ejecutadas. Presione el botón Add para insertar el índice de la primera fase a ejecutar(1) Recepción de pedido:

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

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

En el 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 se crean todas las fases:

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

En la captura aparece una advertencia en color amarillo que indica que hay algo pendiente de ser configurado: serán los scripts de control.

Se debe configurar los scripts de control asociados a cada fase. Estos deben haber sido previamente definidos para realizar las comprobaciones deseadas, y mantener una estructura básica determinada.

La salida estándar ( STDOUT ) 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.

Teniendo esto presente, acceda al formulario mediante el icono de edición:

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

• Launch script: Ubicación o ruta completa del script de control, llamada, comando, etc. Puede utilizar la macro _name_ para indicar al script, como argumento, el nombre de la transacción en curso.
• Retries: Número máximo de reintentos de ejecución hasta conseguir una respuesta positiva.
• Timeout: Valor máximo, en segundos, que permanecerá en ejecución el script de control (característica no disponible para el Agente transaccional en Windows®).

En este ejemplo se utiliza un script personalizado ( echo1.sh ) para simular las acciones del trigger de transacción y de los scripts de control de cada fase:

Una vez tenga configurado correctamente el entorno puede iniciar la transacción.

Navegue hasta la lista de transacciones y pulse el icono de iniciar:

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

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

Para detener la transacción solo tiene que accionar el botón correspondiente. Tras pocos segundos puede volver a iniciarla mediante el botón de ejecución.

Acceda a la vista pulsando en el nombre de la transacción, en el listado de transacciones.

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

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

Vista de transacción completa:

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 solo 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 debe tener activos tanto el servidor de datos ( dataserver ) como el servidor transaccional ( transactionalserver ). Puede comprobarlo en la vista táctica de servidores:

El Agente transaccional tiene un fichero de configuración en su directorio de trabajo, por defecto en:

/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 FMS.
• server_port: Puerto de escucha el servidor Tentacle.
• temporal: Directorio auxiliar para ficheros de trabajo temporales.
• log: Ruta del archivo de registro.
• 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 registro. Por defecto, se vuelca al fichero cualquier salida en STDERR que generen los 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.

Volver al Índice de Documentación Pandora FMS