Buenas prácticas en la monitorización de procesos

La monitorización y la gestión de alarmas debe ser una pieza clave en las arquitecturas de aquellos procesos o despliegues que permiten la recogida y la integración de los datos de nuestros clientes. Tener conocimiento de que el dato que estamos recogiendo llega bien a su destino, y de que el procesado sobre ese dato y su consumo se esta llevando a cabo con éxito, es fundamental si queremos garantizar la integridad del proceso.

Las plataformas Cloud, como Google Cloud Platform o los Amazon Web Services, disponen de recursos para la monitorización de las soluciones desarrolladas, permitiendo saber cuál es el estado y la actividad de estos procesos e identificando si han fallado y cuándo, con el fin de subsanar los errores existentes.

Además de ser fundamental el uso de alarmas o alertas, hacer un buen uso de las mismas no es tan sencillo como parece. Por ello en este post se han decido relatar un par de ejemplos para exponer lo que se conoce como ‘Buenas prácticas (best practices) en la monitorización de procesos’, en este caso para el ecosistema Google Cloud Platform (GCP).

Caso 1: Google Cloud Monitoring

Cloud monitoring es una herramienta, en este caso de GCP, que recopila métricas, eventos y metadatos de todo recurso desplegado dentro de un proyecto en tiempo real e, incluso, es compatible con la monitorización de entornos híbridos y multinube. Es decir, podemos monitorizar recursos de los Amazon Web Services, como por ejemplo la llegada de una determinada información a un repositorio S3.

Permite consultar información de interés a través de paneles de control y gráficos y crear alertas. Dentro de esta herramienta se generan dashboards para cada tipo de recurso del cloud, con los KPIs de funcionamiento principales de ese recurso, permitiendo ver su actividad y estado en un simple vistazo.

La gran funcionalidad del Cloud Monitoring es la posibilidad de crear y administrar alertas especificando simplemente 3 aspectos:

Condiciones que identifican cuándo un recurso permanece en un estado que requiere que se realice una acción.
El tipo de notificación: correo electrónico, sms o una notificación a otro recurso de GCP.
Documentación explicativa para ayudar a conocer qué es lo que puede estar ocurriendo y cómo se podría resolver la incidencia.

Por ejemplo, imaginemos que un determinado recurso, diariamente, lleva a cabo una extracción de datos desde Google Analytics y los deposita en tablas dentro de nuestro proyecto de GCP. Para monitorizar que este proceso se lleva a cabo con éxito podemos generar la siguiente alarma con las siguientes condiciones:

Indicamos el tipo de recurso.
La métrica que caracterice el recurso y queramos medir.
Nombre específico del recurso.
El estado requerido para la métrica (OK, CRASH, TIMEOUT, etc.).
Periodo que debe transcurrir entre una ejecución y la anterior.
Condición que hará saltar la alarma (siempre que se infrinja cualquier serie temporal).
Cuándo saltará la alarma. Qué umbral debe superarse o no alcanzarse. Durante cuánto tiempo.

Finalmente, la alarma estará pendiente de que la Cloud Function de nombre ‘etl_data_import_c4…’ tenga, al menos, una ejecución diaria con status OK y que el tiempo que ha tenido que pasar con respecto a la ejecución inmediatamente anterior, sea de un día y una hora como mucho. Si eso no sucede recibiremos una alerta.

La variedad de alertas que es posible configurar gracias a Cloud Monitoring es muy amplia, tenemos múltiples opciones para cada uno de los recursos en función de sus características. Podemos crear un grupo de alertas, por ejemplo, si tenemos una arquitectura desplegada con varios recursos podemos crear un grupo donde incluiremos todas las alarmas relacionadas con los recursos de esa arquitectura.

Además, la libertad de decidir si las notificaciones que se quieren recibir son para indicar que un proceso se ha ejecutado con éxito, ha fallado o que se reciban en ambos casos es una característica muy importante.

Y, desde luego, la documentación de GCP es un gran recurso a la hora de configurar las alarmas pues algunas de las métricas o las condiciones de activación pueden resultar, en ocasiones, confusas en función de la arquitectura sobre la que estemos trabajando.

Caso 2: CRMint Alarms

CRMint es una plataforma que ayuda a incorporar los datos a los productos de Google. Por lo general, estos productos pueden estar relacionados con el marketing, como Google Ads y Google Marketing Platform, pero también pueden incluir productos en la nube.

Esta plataforma puede jugar varios papeles dentro del ecosistema que se maneje. Puede trabajar como transformador, automatizador e integrador. En varios casos de uso en los que empleamos este recurso actúa como:

Automatizador a la hora de ejecutar y ordenar las distintas tareas de un proceso.
Transformador pues lleva a cabo procesado sobre el dato, para darle el formato o ubicación requeridos.

Un ejemplo podría ser el de la imagen. Es un proceso en el que tenemos varias tareas, cada tarea se crea a partir del botón Add Job. Estas tareas dependen unas de otras. Se presentan dos tareas iniciales (TASK 1.1 y TASK1 .2) cuya ejecución satisfactoria permitirá la ejecución de la segunda tarea y así sucesivamente.

Una vez se han definido las distintas tareas que dan lugar al proceso completo, es posible definir algunos parámetros de configuración sobre el botón Edit. Dentro se puede:

Email al que se desean recibir notificaciones.
Configuración de un scheduler para programar que se ejecute en determinados momentos.
Configuración de variables que luego se pueden aplicar en los jobs/tareas.

El proceso que hemos configurado puede ejecutarse de forma automática todos los días a las ocho de la mañana añadiendo un scheduler con la siguiente forma: 00 08 * * * . Es posible añadir como variable el proyecto de GCP sobre el que se suba un fichero, de tal forma que se asignaría PROJECT_ID=project_data_integraction y luego, simplemente haciendo uso de la sentencia {% PROJECT_ID %}, se recogerá el valor que se ha introducido en esa variable.

Pero, lo realmente interesante, es la posibilidad de recibir notificaciones introduciendo el correo electrónico donde se desean recibir estas notificaciones. En el caso de CRMint, se recibirán notificaciones sobre todas las ejecuciones, sean satisfactorias o fallidas. Un aviso sobre que uno de nuestros procesos se ha ejecutado al completo con éxito, podría ser el siguiente.

En el caso de cloud monitoring, se comenta que es importante poder decidir cuándo se quieren recibir las notificaciones. Esto es porque cuando tenemos una ejecución mensual, semanal o incluso diaria, es muy útil tener conocimiento del estado en el que se ejecutó nuestro proceso. Pero, imaginemos que es un proceso que se ejecuta varias veces al día, ¿qué sucederá? Se recibirían tantas notificaciones como veces se ejecute. Un volumen elevado de notificaciones puede resultar contraproducente, pues si recibimos diez avisos diarios de varios procesos, si uno de esos ha sido fallido puede pasar desapercibido entre tantos otros procesos exitosos. Por ello, lo ideal sería solo recibir notificaciones cuando existiese un fallo, pero CRMint, lamentable, por el momento no dispone de esta alternativa.

-------------------------------------------------------------------------------------------------------------------------------------------------------------