Un fallo, una incidencia, un recuento fiable.
Agrupar es todo el trabajo de un rastreador de errores, y el recuento que produce es lo que te dice cuál de cuatrocientos problemas arreglar un martes por la mañana. Bugtail agrupa por la forma del fallo, mantiene la traza fuera de la base de datos y nunca pierde el recuento cuando la traza se limpia.
Agrupado por lo que hace que sea el mismo fallo
Una excepción se identifica por su tipo y por los marcos de tu propio código que la produjeron, no por el mensaje. Eso importa porque un mensaje suele llevar un identificador: "Usuario 8812 no encontrado" y "Usuario 913 no encontrado" son un fallo, y un rastreador que los muestra como dos ha convertido un problema en una lista.
Cuando la agrupación no encaja con tu aplicación, puedes decirlo por colector. Lo que no puedes es hacerla depender del payload, porque el payload no siempre está.
La traza nunca entra en la base de datos
Las tablas de incidencias y eventos guardan títulos, niveles, recuentos, marcas de tiempo y un puntero. La traza en sí, el contexto de la petición y las migas de pan son JSON comprimido en tu bucket. Eso no es una optimización, es la restricción sobre la que se apoya todo el diseño: mantiene la base de datos lo bastante pequeña para seguir siendo rápida, convierte la retención en dos decisiones separadas y convierte borrar la parte sensible en un borrado y no en un cambio de esquema.
Una fila de evento tiene que seguir siendo útil cuando su payload ya no está, y lo es: el título, el nivel, la versión, la URL sin su cadena de consulta y el recuento siguen ahí un año después, mucho tiempo después de que la traza se haya limpiado.
Dos ventanas de retención
Cuánto vive una fila de evento y cuánto vive su payload, fijadas por separado, por colector.
Los recuentos sobreviven a los payloads
Los gráficos vienen de agregados y no de contar filas, así que la limpieza nunca cambia el historial.
Limpiado antes de escribirse
Contraseñas, tokens, cookies, números de tarjeta e IBAN, a cualquier profundidad, a la entrada.
Una regresión es un estado, no una incidencia nueva
Resuelve una incidencia y se cierra. Si llega otra vez la misma huella, la incidencia se reabre como regresión y dice qué versión la trajo de vuelta, en lugar de aparecer como algo nuevo que alguien tiene que triar desde cero. También puedes posponerla hasta la próxima versión, que es lo que de verdad quieres para un fallo ya arreglado pero aún no publicado.
Preguntas que la gente hace de verdad
¿Puedo cambiar cómo se agrupan los errores?
Por colector, sí. La huella por defecto usa el tipo de excepción y tus propios marcos; puedes estrecharla o ensancharla cuando tu aplicación necesite otra cosa.
¿Qué pasa con una incidencia cuando se limpian sus trazas?
Se queda. Título, nivel, versión, recuentos y gráficos están todos en la base de datos y ninguno viene del payload. Abrir una incidencia antigua muestra todo salvo la traza en sí, y dice con claridad que se ha limpiado.
¿Cobráis los eventos que agrupáis juntos?
Cada evento registrado cuenta una vez, agrupado o no. Los eventos rechazados por tu lista de permitidos del navegador no se te cuentan, y los descartados por muestreo tampoco.
Catorce días de Team, sin tarjeta.
Regístrate con tu dirección de trabajo, demuestra tu dominio con un registro DNS y pega una DSN. La primera traza suele llegar antes que el café.
Sin tarjeta. La prueba termina sola y pasa a Free; no se cobra nada salvo que elijas un plan.
