Detección de picos repentinos en el número de errores
El número de errores por sí solo no siempre indica que algo va mal. Una aplicación con mucho tráfico puede generar más eventos que un proyecto pequeño, y un aumento puntual de excepciones no siempre significa una caída del servicio.
Por eso las alertas de errores deben tener en cuenta no solo el número de eventos, sino también el nivel habitual de errores de cada proyecto.
¿Por qué un umbral fijo no siempre funciona?
Un umbral del tipo «100 errores» puede ser adecuado para un proyecto y completamente inútil para otro. En una aplicación grande, 100 errores pueden ser un nivel normal, mientras que en un servicio pequeño incluso una decena de eventos similares puede indicar un problema serio.
Resulta mucho más útil detectar una desviación respecto al comportamiento habitual de la aplicación.
¿Cómo es la respuesta ante un pico?
Cuando el número de eventos se aparta claramente del nivel observado, el sistema puede tratarlo como una señal que requiere atención. El mecanismo también tiene en cuenta un número mínimo de eventos, para que una única excepción aislada no provoque una alerta innecesaria.
¿Por qué no recibes un correo por cada error?
Un problema recurrente puede generar cientos de eventos. Enviar una notificación independiente por cada uno convertiría rápidamente la monitorización en una fuente de ruido.
Por eso las notificaciones se limitan en el tiempo. Una incidencia en curso no debería generar mensajes idénticos cada pocos segundos.
¿Qué conviene hacer al recibir una alerta?
Primero comprueba qué error es responsable del pico y cuándo apareció por primera vez. Después compara ese momento con los últimos despliegues y cambios de configuración.
El historial del número de repeticiones te permite valorar rápidamente si el problema sigue creciendo o fue solo un pico puntual.