Criterios de Observabilidad: Envío de errores a Sentry
/web/login?redirect={{request.httprequest.path}} portal.user_sign_in_redirect
⏯️

📊 Guía de Envío de Errores a Sentry


🎯 Objetivo

Solo enviamos a Sentry los errores que:

  • Rompan el flujo de trabajo del usuario.
  • Puedan tirar la instancia.
  • Sean bugs que requieren intervención inmediata.

Todo lo demás se controla con logs internos (chatter, ir.logging).


🛑 Qué NO se envía a Sentry

  • Errores esperados por mal uso del usuario (UserError, ValidationError).
  • Errores de red controlados (ConnectionError, Timeout).
  • Warnings informativos.
  • Cualquier cosa que ya esté gestionada por lógica de negocio.


✅ Qué SÍ se envía a Sentry

  • Bugs de código (errores inesperados).
  • Errores críticos que bloquean procesos.
  • Fallos de infraestructura que no están controlados.


🧰 Niveles de Logging

Nivel¿Visible al usuario?¿Va a Sentry?Uso
INFONoNoLogs de seguimiento.
WARNINGNoSolo ir.loggingCosas raras pero no críticas.
ERRORNoSí (con alerta)Errores que necesitan revisión.
CRITICALNoSí (con alerta)Peligro inminente (caída de servicio).
UserErrorSíNoFallos de uso (campo vacío, etc.).


🔍 Filtro en Sentry (before_send)

def before_send(event, hint):
    exc_info = hint.get("exc_info")
    if exc_info:
        exc_type, exc_value, _ = exc_info
        if isinstance(exc_value, (UserError, ValidationError, AccessError)):
            return None  # Ignorar errores controlados
    return event  # Solo envía lo que no controlas


📋 Buenas Prácticas

  • UserError → Mensaje al usuario (sin Sentry).
  • Warnings → logger.warning + ir.logging si es necesario auditar.
  • Errores críticos → logger.error/critical → Sentry.
  • Contextualiza SIEMPRE (producto, usuario, URL...).
  • No lances UserError en jobs, solo loguea y sigue.
  • Revisa Sentry semanalmente.


🛠 Herramientas

  • logger → Logs en tiempo real.
  • ir.logging → Trazabilidad en base de datos.