Análisis Inteligente de Logs, la nueva iniciativa para anticipación de incidentes en aplicaciones Bancolombia
¿Sabías que ya es posible detectar potenciales incidentes antes de que ocurran? Tal como en la película Minority Report, ahora los miembros de los equipos de soporte y operaciones pueden recibir alertas predictivas de posibles incidentes en sus aplicaciones, componentes relacionados y proveedores de servicio. En nuestra nueva aplicación Agatha, se pueden ver los alertamientos y comportamientos anómalos que ponen en riesgo la disponibilidad de tu aplicación, de manera gráfica y dinámica.
La nueva iniciativa para detección de anomalías y predicción de posibles fallos en aplicaciones Bancolombia se encuentra en periodo de prueba y con ella, se busca apoyar y optimizar los tiempos de los equipos de monitoreo y soporte para impactar positivamente la disponibilidad de las aplicaciones.
Actualmente, la mayoría de las aplicaciones y servicios del banco generan una gran cantidad de información en logs, los cuales permiten realizar un rastreo y diagnóstico para anticiparse a posibles fallas en la infraestructura o en las aplicaciones; no obstante, detectar comportamientos extraños o predecir futuras caídas no es una tarea sencilla, especialmente si no se cuenta con herramientas óptimas de monitoreo y trazabilidad o si no se realiza un correcto análisis de la información obtenida por medio de estos logs.
Gracias a los avances tecnológicos, han surgido diferentes alternativas que permiten analizar la información de logs técnicos con información almacenada de las aplicaciones. Estas varían en el grado de complejidad para su construcción, el tipo de datos que utilizan para su análisis y en la forma de consumirlas.
Basados en esto, Análisis Inteligente de Logs (AIL) nace como una plataforma serverless que permite centralizar logs de distintos tipos, tanto On-Premises como Cloud, y analizarlos en tiempo real para detectar anomalías y posibles fallos en las aplicaciones. Así, los equipos de monitoreo encargados tienen la posibilidad de actuar de manera proactiva y no reactiva ante una afectación.
Para el desarrollo de esta implementación se ha tenido en cuenta dos aplicaciones del banco, la primera es una aplicación transaccional (App1) y la segunda un asistente virtual vía Whatsapp (App2), de las cuales se obtiene información de tres flujos que son: API Connect para la primera aplicación y CloudWatch Metrics y CloudWatch Logs correspondientes a la segunda aplicación. La información proveniente de estas aplicaciones llega a un servicio de AWS llamado Kinesis Data Analytics (KA), que sirve para la analítica de datos y es utilizado para agruparlos, procesarlos y discriminarlos en tiempo real. Estos datos son entregados por un Kinesis Data Stream y son recolectados en una ventana de tiempo de 15 minutos para adaptarlos y procesarlos.
Diferencia entre procesamiento por lotes (batch) y en tiempo real (streaming)
De manera tradicional, los modelos analíticos emplean un procesamiento por lotes. Esto representa el entrenamiento de los modelos a intervalos regulares como semanal, quincenal, mensual, trimestral, etc. Los datos se acumulan durante un período de tiempo y luego, los modelos se entrenan con los datos acumulados, de vez en cuando, a intervalos periódicos. Los modelos entrenados mediante el procesamiento por lotes pasan a producción solo a intervalos regulares en función del rendimiento de los modelos entrenados con nuevos datos.
La creación de modelos por lotes requiere de un entrenamiento con todo el conjunto de datos. Una de sus características es que son de naturaleza estática, lo que significa que una vez se entrenan su rendimiento no mejorará hasta que se vuelva a entrenar un nuevo modelo. Este tipo de modelos se implementan en el entorno de producción pues se reemplaza el antiguo con el recién entrenado.
En el proyecto AIL se emplea un procesamiento en tiempo real. Aquí el entrenamiento ocurre de manera incremental mediante la alimentación continua de datos (en la medida que llegan) o en un grupo pequeño. Cada paso de aprendizaje es rápido y económico, por lo que el sistema puede aprender nuevos datos y sobre la marcha.
El procesamiento en tiempo real es excelente para los sistemas de aprendizaje automático que reciben datos como un flujo continuo (por ejemplo, registros generados por los clientes que utilizan sus aplicaciones móviles o web) y que necesitan adaptarse para cambiar de forma rápida o autónoma. Esta también es una buena opción si tiene recursos informáticos limitados; una vez que un sistema de aprendizaje en línea ha aprendido acerca de nuevas instancias de datos, ya no las necesita, por lo que puede descartarlas (a menos que desee volver a una versión anterior) o mover los datos a otra forma de almacenamiento. Esto puede ahorrar una gran cantidad de espacio y costos.
El procesamiento de datos en tiempo real resulta beneficioso en la mayoría de las situaciones en las que se generan datos nuevos y dinámicos de forma continua. Por lo general, los procesos comienzan con aplicaciones sencillas, como la implementación de cálculos mín.-máx. En un principio, las aplicaciones pueden procesar transmisiones de datos para producir informes básicos y realizar acciones sencillas como respuesta; por ejemplo, pueden emitir alertas cuando las medidas clave superan ciertos umbrales.
Modelo no supervisado: detección de anomalías
Posterior al procesamiento de la información, desde Kinesis Data Analytics se ejecuta un algoritmo llamado RANDOM_CUT_FOREST_WITH_EXPLANATION (RCF), el cual es un algoritmo derivado del Random Forest. Este está basado en un conjunto de árboles de decisión combinados. El Random Forest funciona de tal manera que distintos árboles ven distintas porciones de los datos. Ningún árbol ve todos los datos de entrenamiento. Esto hace que cada árbol se entrene con distintas muestras de datos para un mismo problema. De esta forma, al combinar sus resultados, unos errores se compensan con otros y tenemos una predicción que generaliza mejor.
El RCF es un algoritmo en tiempo real, de tipo no supervisado, que calcula una puntuación de anomalía y la explica para cada registro en el flujo de datos. La puntuación de anomalía de un registro indica qué tan diferente es de las tendencias que se han observado recientemente. La función también devuelve una puntuación de atribución para cada columna de un registro, en función de la anomalía de los datos de esa columna. Para cada registro, la suma de las puntuaciones de atribución de todas las columnas, es igual a la puntuación de anomalía.
El algoritmo de RANDOM_CUT_FOREST_WITH_EXPLANATION recibe como entrada los siguientes parámetros:
NumberOfTrees: especifica el número de árboles aleatorios en el bosque. El algoritmo construye un numero de árboles y cada uno de estos es construido usando una muestra de un número determinado de registros (parámetro SubSampleSize). El algoritmo usa cada árbol para asignar un puntaje de anomalía. El promedio de todos estos puntajes es el puntaje final de anomalía.
SubSampleSize: especifica el tamaño de muestra aleatoria que el algoritmo va a usar cuando construye cada árbol. Cada árbol en el bosque es construido con una muestra diferente aleatoria de registros.
TimeDecay: con este parámetro es posible especificar cuantos datos del pasado reciente se van a considerar cuando se calcula un puntaje de anomalía. Los datos continuos naturalmente evolucionan a través del tiempo y por esta razón, se requiere que una anomalía sea detectada acorde con esos datos recientes y no con datos de un pasado distante.
ShingleSize: un shingle (que llamaremos teja por una de las acepciones de shingle en español) corresponde a la cantidad de muestras en el tiempo que se consideran en cada instante. A modo de ejemplo, si fijamos un shingleSize de 10 y un timeDecay de 25, le estamos diciendo al RCF que para cada muestra que llega, tome los últimos 10 valores que llegaron y ese objeto de 10 elementos es el que se analiza por el algoritmo para detectar anomalías. Por otro lado, el decaimiento dice que tome las 25 últimas tejas como historia relevante para comparar con futuras anomalías, siendo la teja más reciente la más importante, mientras que la última es casi irrelevante.
WithDirectionality: un parámetro booleano que por defecto es falso. Cuando se establece en verdadero, indica la dirección en la que cada dimensión individual contribuye con la puntuación de anomalía. También proporciona la fuerza (STRENGTH) de la recomendación para esa direccionalidad.
La función devuelve una puntuación de anomalía de 0 o más y una explicación en formato JSON. El puntaje de anomalía comienza en 0 para todos los registros en el flujo mientras el algoritmo pasa por la fase de aprendizaje. A continuación, empieza a detectar valores positivos para la puntuación de anomalía. No todas las puntuaciones de anomalías positivas son significativas; solo las más altas. Para obtener una mejor comprensión de los resultados sugiero revisar ANOMALY_EXPLANATION.
ANOMALY_EXPLANATION proporciona los siguientes valores para cada columna en el registro:
Puntuación de atribución (ATRIBUTION_SCORE): un número no negativo que indica cuánto ha contribuido esta columna a la puntuación de anomalía del registro. En otras palabras, indica qué tan diferente es el valor de esta columna de lo que se espera, según la tendencia observada recientemente. La suma de las puntuaciones de atribución de todas las columnas del registro es igual a la puntuación de anomalía.
Fuerza (STRENGTH): un número no negativo que representa la fuerza de la recomendación direccional. Un valor alto de fuerza indica una confianza alta en la direccionalidad que devuelve la función. Durante la fase de aprendizaje, la fuerza es 0.
Direccionalidad (DIRECTION): esto es HIGH si el valor de la columna está por encima de la tendencia observada recientemente o LOW si está por debajo. Durante la fase de aprendizaje, el valor predeterminado es LOW.
La salida del algoritmo genera una secuencia similar a la Fig. 1.
Se define un umbral de puntaje de anomalía para discretizar entre el comportamiento de “sanidad” de la aplicación y la anomalía detectada. Así, cuando la puntuación de anomalía asignada supera ese umbral, se genera una alerta vía correo electrónico o por medio de la aplicación Teams de Microsoft (como podemos observar en la figura 2). Además, se proporciona un tablero que brinda analítica básica para tener un panorama de lo que está sucediendo, en tiempo real, en cada una de las aplicaciones.
Cómo ejemplo de la precisión y el funcionamiento del modelo de detección de anomalías, en una de las aplicaciones podemos observar un incidente presentado el día 26 de mayo, el cual presentó una afectación parcial a partir de las 20:04 (inicio de la franja aguamarina) hasta las 20:30 (final franja aguamarina), momento en el que se presentó una caída total de la aplicación. Los puntos en la gráfica de la figura 3 corresponden a los puntajes de anomalía asignados a cada uno de los logs provenientes del flujo CloudWatch Logs y los cuales tienen 3 colores diferentes:
El gris corresponde a aquellos registros cuyo puntaje de anomalía no supera el umbral establecido (línea roja horizontal), es decir, tienen un comportamiento normal o esperado de la aplicación.
Los puntos azules representan aquellos registros que superaron el umbral y generaron una alerta vía correo electrónico.
Los puntos blancos son registros que también superaron el umbral pero no habían pasado por lo menos 5 min para generar una nueva alerta (esto con el fin de evitar mucho ruido cuando haya ráfagas de logs en poco tiempo en las aplicaciones).
Como podemos apreciar, el AIL envió su primera alerta aproximadamente a las 18:45, es decir, 90 min antes de que se presentara la afectación e interrupción del servicio de cara al cliente. Así como en este evento, AIL fue capaz de detectar la mayoría de las afectaciones de las aplicaciones evaluadas, en rangos que oscilan entre 10 y 90 minutos antes del incidente.
Modelo supervisado: clasificación
Posteriormente, se realiza un análisis para correlacionar las anomalías detectadas con cada uno de los incidentes presentados en las aplicaciones. Esto permite identificar patrones que nos pudieran llevar a crear un segundo modelo, cuyo objetivo es predecir cuándo habrá una incidencia y así poder adelantarnos a un posible fallo con hasta 90 minutos de anticipación. Para ello, se realizó un modelo supervisado cuyos datos de entrada son la salida del modelo no supervisado encargado de la detección de anomalías (RCF). Se trata de un modelo de clasificación con 7 clases que son:
Normal: log que corresponde a un estado de sanidad de la aplicación.
Incidente: log recibido en el momento en que se está presentando afectación parcial o total en la aplicación.
Anomalía — no incidente: log que obtuvo un puntaje de anomalía mayor al umbral pero no representó una caída.
10–0 min antes del incidente: log que se encuentra en un rango entre 10 y 0 min antes de una afectación.
30–10 min antes del incidente: log que se encuentra en un rango entre 30 y 10 min antes de una afectación.
60–30 min antes del incidente: log que se encuentra en un rango entre 60–30 min antes de una afectación.
90–60 min antes del incidente: log que se encuentra en un rango entre 90–60 min antes de una afectación.
Un factor muy importante a tener en cuenta es que al emplearse un modelo supervisado, es decir, que aprende de un conjunto de datos histórico previamente etiquetados, es necesario contar con datos históricos de salidas del algoritmo de detección de anomalías que contengan datos correspondientes a incidentes en la aplicación. Además, se debe contar con un numero de incidentes adecuado de manera que sea posible entrenar, hacer pruebas y validaciones al modelo supervisado. El tiempo para entrenar este modelo va depender, directamente, del tiempo que se demore la aplicación en brindar la información de ese número “adecuado” de afectaciones. Por ejemplo, en este caso, específicamente, fue necesario esperar aproximadamente 4 meses correspondientes a tener 8 incidentes, de los cuales 4 se usan para entrenar, 2 para hacer pruebas y las 2 restantes para validar.
El objetivo del modelo de clasificación es brindar la probabilidad de que cada log se encuentre en cada una de las categorías mencionadas anteriormente, de manera que sea posible predecir cuándo habrá una afectación en la aplicación (como podemos observar en la figura 5). Este modelo supervisado muestra resultados prometedores con métricas como ROC AUC score y Precision score por encima del 85%, además de Accuracy score, Recall y F1-Score por encima del 70%, tanto en el conjunto de entrenamiento como en los de prueba y validación. Se espera que a medida que se presenten afectaciones en el servicio, el modelo aumente su precisión pues está utilizando todo el histórico para aprender de los patrones en los datos y asignar correctamente la probabilidad de que cada registro se encuentre en cada una de las clases en el modelo.
Los resultados obtenidos con esta iniciativa son positivos y los números respaldan el potencial que tiene la aplicación para llevarlo a un entorno productivo, además, es altamente escalable a otras aplicaciones. Es importante resaltar que el proyecto aún se encuentra en periodo de prueba, por lo tanto, no se encuentra disponible para uso interno del banco.
Seguimos trabajando en tareas de refinamiento de los modelos de detección de anomalías y predicción de caídas que permitan obtener mejores resultados. Si tienes dudas o anotaciones, escríbelas en la caja de comentarios y estaremos muy atentos para responderlas.
