Observabilidad real en Django con OpenTelemetry

Tres señales, un contexto

Logs, métricas y trazas solo son útiles si comparten contexto. El pegamento es la propagación: X-Request-ID (o traceparent en W3C Trace Context) debe viajar del edge al worker.

Logs estructurados con request_id

logger.info(
    "request.completed",
    extra={"request_id": rid, "status": 200, "latency_ms": 42.3},
)

Un middleware toma el header, lo deja en un ContextVar y el formatter JSON lo añade a cada línea. Con eso, grep request_id reconstruye el viaje completo de una petición entre servicios.

Métricas RED primero

Antes de dashboards exóticos: Rate, Errors, Duration por endpoint. Con esas tres series y alertas sobre error rate y p99 se cubre el 80% de los incidentes.

Trazas donde duele

Instrumentar todo desde el día uno es ruido. Empiezo por los bordes (HTTP, colas, DB) y profundizo solo en los spans que aparecen en incidentes. En un equipo real esto bajó el MTTR de horas a minutos: la traza señala el servicio culpable antes de abrir un solo log.

Cierre

La observabilidad no es una herramienta que se instala, es una propiedad que se diseña: contexto propagado, señales correlacionadas y hábito de mirar los datos antes de opinar.