¿Cuántos datos sobre errores necesitas realmente para monitorizar una aplicación?
En la monitorización es fácil caer en la trampa de pensar que más datos siempre significan una mejor monitorización. Cada stack trace, cada solicitud y cada transacción pueden parecer datos que merece la pena conservar para siempre.
En la práctica, almacenar todos los eventos sin procesar a largo plazo tiene un coste. El volumen de datos aumenta, los costes de almacenamiento crecen y analizar la información histórica se vuelve cada vez más difícil.
Por eso, un sistema de monitorización bien diseñado debería separar los datos necesarios para resolver un problema concreto de aquellos destinados a mostrar tendencias a largo plazo.
¿Para qué sirven los eventos sin procesar?
Un evento sin procesar resulta especialmente útil cuando intentas responder a la pregunta: «¿qué ocurrió exactamente en la aplicación?»
El stack trace, el mensaje de la excepción, la dirección de la solicitud, el entorno y el contexto adicional permiten encontrar la causa del problema y reconstruir lo ocurrido. Son datos necesarios principalmente al analizar un error concreto.
Sin embargo, normalmente no necesitas un stack trace completo de hace dos años para saber si la aplicación ha funcionado de forma más estable este mes que hace seis meses.
Los datos sin procesar y las estadísticas responden a necesidades diferentes
Por eso conviene separar la retención de datos detallados del historial de estadísticas.
Los eventos sin procesar pueden conservarse durante un período limitado. Durante ese tiempo tienes acceso a los detalles necesarios para depurar errores: el mensaje de error, el stack trace y el contexto de la solicitud.
Al mismo tiempo, la información básica puede agregarse y conservarse durante períodos más largos. En lugar de almacenar un millón de eventos individuales, basta con guardar la información de que en un determinado día se produjeron 12.438 errores.
¿Qué conviene conservar en el historial?
El historial a largo plazo no tiene por qué ser complicado. Dependiendo del tipo de monitorización, puede ser suficiente conservar información como:
- el número de errores de un determinado día,
- el número de solicitudes procesadas,
- el número de veces que se ha producido un problema concreto,
- el tiempo de respuesta medio o representativo,
- los resultados de las mediciones de disponibilidad y rendimiento,
- el momento de inicio y finalización de un problema.
Este tipo de datos ocupa mucho menos espacio que los eventos completos y, al mismo tiempo, es suficiente para crear gráficos y analizar tendencias.
¿Por qué los datos agregados son importantes para la monitorización de errores?
La agregación no sirve únicamente para ahorrar espacio. También resulta útil para detectar anomalías.
Si quieres determinar si el número de errores de hoy es inusual, necesitas un historial con el que compararlo. Sin embargo, no es necesario conservar todos los eventos detallados de cada día anterior.
El número diario de errores puede utilizarse como punto de referencia para futuras alertas, incluso cuando los eventos detallados de ese período ya se hayan eliminado.
Retención de datos y límites
Hay otro aspecto importante: el límite del número de eventos no debería depender de la retención de los datos sin procesar.
Si los eventos detallados se eliminan periódicamente, su número en la base de datos deja de indicar cuántos eventos se recibieron durante un determinado período de facturación. Por eso, el consumo del límite debería contar con un contador independiente que no desaparezca junto con los datos eliminados debido a la política de retención.
De esta forma, eliminar errores antiguos no «reduce» el consumo del límite ni modifica el historial de uso.
¿Cómo encontrar un equilibrio razonable?
Un buen enfoque consiste en hacerse una pregunta sencilla: ¿necesitaré esta información para resolver un problema concreto o únicamente para analizar una tendencia?
Si necesitas depurar errores, conserva el evento detallado durante un período adecuado. Si lo que te interesa es el historial de funcionamiento de la aplicación, basta con conservar estadísticas agregadas.
Separar ambos tipos de datos permite reducir la cantidad de información almacenada sin perder aquella que realmente importa para mantener la aplicación.
La monitorización no tiene por qué almacenarlo todo
El mejor sistema de monitorización no es el que recuerda cada detalle indefinidamente. Es aquel que conserva los datos adecuados durante el tiempo adecuado.
Los detalles ayudan a solucionar un error concreto. Los datos agregados permiten comprender el historial de la aplicación. Separar estas dos capas permite disponer de una monitorización útil, una política de retención razonable y acceso a estadísticas a largo plazo.
