Por qué un umbral fijo de alertas no funciona en la monitorización de errores
La forma más sencilla de crear una alerta parece bastante inocente: «avísame cuando el número de errores supere los 100 por hora». El problema aparece cuando la aplicación empieza a cambiar. Aumenta el tráfico, se incorporan nuevas funciones, cambia el número de usuarios y, de repente, una cifra establecida unos meses antes deja de tener sentido.
La monitorización de errores debería responder, ante todo, a una pregunta: ¿está ocurriendo algo fuera de lo habitual en esta aplicación concreta? El número de eventos por sí solo no siempre ofrece una buena respuesta.
El mismo umbral no sirve para todas las aplicaciones
Imagina una tienda online que procesa miles de pedidos al día. Incluso cuando todo funciona correctamente, pueden aparecer errores aislados debido a sesiones interrumpidas, intentos de pago fallidos, tiempos de espera agotados en servicios externos o tráfico automatizado de bots.
Si una tienda de este tipo genera decenas o incluso cientos de errores en una hora, no significa necesariamente que haya una incidencia. Configurar una alerta en 100 errores podría provocar notificaciones constantes sobre situaciones que, en realidad, forman parte del tráfico normal.
En el caso contrario, el problema puede ser aún mayor. Un panel de administración utilizado por unas pocas personas puede pasar la mayor parte del día sin generar ni un solo error. Por tanto, un umbral fijo de 100 eventos nunca se alcanzará, incluso si la aplicación empieza a devolver un error 500 en cada solicitud.
Es mejor una alerta basada en desviaciones respecto al comportamiento habitual
En la monitorización conviene separar dos aspectos: el número mínimo de eventos y la desviación respecto al nivel habitual de errores.
El umbral mínimo ayuda a evitar falsas alarmas. Si una aplicación con poca actividad suele generar uno o dos errores al día, un único evento adicional no debería alertar a todo el equipo.
El segundo elemento permite detectar cambios repentinos. Si una aplicación suele generar 20 errores durante un período similar y, de repente, aparecen varias veces más, esta información resulta mucho más útil que una cifra aislada sin contexto.
El comportamiento habitual debe ser independiente de la incidencia actual
Este es un detalle importante al diseñar este tipo de mecanismo. No se debe determinar el comportamiento habitual basándose únicamente en los últimos minutos u horas.
Si una incidencia comienza de forma gradual y el número de errores aumenta durante varias horas, los datos recientes empezarán a elevar el punto de referencia. El sistema podría acabar considerando que el aumento de errores es el nuevo comportamiento normal justo en el momento en que más necesitas recibir una alerta.
Por eso conviene establecer el punto de referencia utilizando un historial más amplio y estadísticas agregadas. De esta forma, una incidencia aislada no modifica inmediatamente la imagen del funcionamiento normal de la aplicación.
Por qué la supresión de alertas es igual de importante
Incluso un buen mecanismo de detección de anomalías puede resultar molesto si cada nuevo intervalo de medición genera otra notificación.
Una incidencia puede durar una hora, varias horas o toda la noche. Si se envía una alerta cada pocos minutos, después de decenas de mensajes resulta difícil distinguir cuándo comenzó realmente el problema de todas las notificaciones posteriores.
Por eso, la monitorización debería aplicar la supresión de notificaciones repetitivas. La primera alerta informa del problema y las siguientes incidencias quedan registradas en el historial de monitorización sin saturar la bandeja de entrada.
Una buena alerta no debería informar de todo
El objetivo de la monitorización no es enviar el mayor número posible de notificaciones. El objetivo es proporcionar información cuando realmente importa.
Un umbral fijo responde a la pregunta «¿se han producido más de X errores?». La monitorización basada en anomalías responde a una pregunta mucho más importante: «¿el comportamiento de la aplicación se desvía claramente de lo que cabe esperar de ella?»
Esta diferencia es precisamente la que determina si las alertas ayudan a reaccionar ante los problemas o si, después de unas semanas, se convierten en otra fuente de notificaciones que se acaba silenciando sin pensarlo.
