Agrupación de errores y contador de apariciones
Un único problema en una aplicación puede generar cientos o miles de excepciones idénticas. Cuando cada aparición se muestra por separado, resulta difícil distinguir un incidente aislado de un problema que afecta a una gran parte del tráfico.
Por eso los informes se agrupan según su huella (fingerprint). Las apariciones repetidas del mismo problema se agrupan en un único informe, y un contador muestra su magnitud.
¿Qué determina la agrupación?
La huella se genera a partir de información que permite reconocer un tipo concreto de problema, entre otros datos, el proyecto, el tipo de excepción y el mensaje de error.
Esto es importante porque un mensaje idéntico que aparece en dos aplicaciones distintas sigue representando dos problemas independientes.
¿Por qué es importante la agrupación?
Imagina un error que se ha producido 3500 veces en una hora. No necesitas 3500 entradas idénticas en la lista. Necesitas saber qué problema se ha producido, cuándo ha aparecido y con qué frecuencia ocurre.
La agrupación es precisamente lo que permite este enfoque. Una entrada representa el problema, y el contador muestra su magnitud.
Historial de apariciones
Los detalles del informe te permiten analizar el historial de un problema y ver cómo ha cambiado con el tiempo el número de sus apariciones.
Esto facilita relacionar un aumento en el número de errores con un despliegue, un cambio de configuración o un evento concreto en la aplicación.
Errores repetidos y notificaciones
Un error repetido no debería generar un correo independiente por cada aparición. Las notificaciones deben llamar la atención sobre problemas nuevos o relevantes, no inundar la bandeja de entrada con copias del mismo evento.
Esto es especialmente importante durante una caída del servicio, cuando un solo problema puede generar un número muy elevado de excepciones en poco tiempo.