Clasifica errores de producción cada mañana sin tocar Sentry

Programa a Zero para que se ejecute diariamente. Obtiene errores no resueltos de Sentry y Axiom, los deduplica entre fuentes, abre un issue en GitHub con el stack trace completo y lo asigna al ingeniero adecuado automáticamente.

Zero conecta:

Por qué la clasificación matutina de errores consume la primera hora de ingeniería

Cada mañana, alguien tiene que abrir Sentry, recorrer los errores no resueltos, determinar cuáles son nuevos, cuáles son duplicados, cuáles son realmente serios y decidir quién debería encargarse de cada uno. Eso son 20 a 30 minutos de tiempo de ingeniería enfocado antes de que comience cualquier trabajo real. Zero se ejecuta a las 8:45 AM, revisa Sentry y Axiom, deduplica entre ambos, selecciona los errores que importan, abre issues en GitHub con el stack trace completo ya adjunto y asigna cada uno antes de que alguien abra su laptop.

Cómo configurar la clasificación diaria automatizada de errores con Zero

@Zero cada día laborable a las 8:45am, obtén los errores no resueltos de Sentry y Axiom de las últimas 24 horas. Deduplica entre fuentes. Para cualquiera con 5+ ocurrencias, abre un issue en GitHub en vm0-ai/vm0 con el stack trace completo y asígnalo al propietario del código relevante.

pruébalo

Cómo Zero obtiene, deduplica y registra errores de Sentry y Axiom

Zero obtiene errores de Sentry y Axiom

Zero consulta ambas fuentes para errores no resueltos dentro de la ventana de tiempo especificada. Aplica tu umbral de ocurrencia para filtrar el ruido y enfocarse en errores que realmente están ocurriendo a escala.

Errores deduplicados entre fuentes

El mismo error a menudo aparece tanto en Sentry como en Axiom con diferente formato. Zero identifica duplicados y los fusiona en un único registro con datos de ambas fuentes.

Issues de GitHub creados y asignados

Para cada error único que califica, Zero abre un issue estructurado en GitHub con el stack trace completo, conteo de ocurrencias, marcas de tiempo de primera y última vez visto, y lo asigna al ingeniero que más probablemente es responsable de esa área del código.

Asigna issues, ajusta umbrales o combina con tu informe de standup

Ajustar el umbral

Cambiar el filtro de ocurrencia para reducir ruido o detectar más problemas

@Zero actualiza el horario de clasificación diaria para solo crear issues para errores con 10+ ocurrencias. Cualquier cosa por debajo de eso, solo publica un resumen en #dev.

pruébalo

Agregar al informe matutino

Combinar con el caso de uso de informe de salud del producto

@Zero incluye la salida de clasificación de errores de hoy en el informe de salud del producto de las 9am que publicas en #standup.

pruébalo

Verificación de seguridad post-deploy

Ejecutar clasificación inmediatamente después de un deploy a producción

@Zero cada vez que un PR se fusione a main en vm0-ai/vm0, espera 15 minutos y luego ejecuta una verificación de errores en Sentry para errores nuevos.

pruébalo

Integraciones requeridas: Sentry, GitHub y Axiom

Sentry

Zero consulta Sentry para errores no resueltos y lee stack traces y conteos de eventos.

Obligatorio

GitHub

Zero crea issues estructurados en GitHub con detalles completos de errores y los asigna a propietarios de código.

Obligatorio

Axiom

Zero consulta Axiom para logs de errores para hacer referencia cruzada y deduplicar contra hallazgos de Sentry. Opcional pero recomendado.

Opcional

Buenas prácticas para la clasificación programada de errores de producción

●Establece un umbral de ocurrencia para mantener manejable la cantidad de issues. 5+ es un buen punto de partida; ajusta según tu volumen.

●Usa las etiquetas de proyecto o ambientes de Sentry para limitar la consulta de Zero solo a producción, no a staging.

●Encadena esto con el informe de salud del producto: ejecuta la clasificación a las 8:45, incluye la salida en el informe de las 9:00 para que el equipo vea todo en un solo lugar.