Buenas Prácticas de Observabilidad

Señales accionables, no ruido, significan que el equipo de guardia se despierte por problemas que impactan al cliente, no por volumen de logs o cardinalidad de métricas ilimitada.

Cómo Usar Esta Lista

• Implementa antes de declarar listo para producción.
• Revisa el enrutamiento de alertas trimestralmente: elimina reglas ruidosas.
• Combina con runbooks que enlacen dashboards con pasos de remediación.

A - Logging

• Emite logs en formato JSON en producción. Un objeto por línea con timestamp, nivel, evento, servicio, entorno.
• Vincula request_id en cada solicitud HTTP. Devuelve X-Request-ID a los clientes.
• Incluye trace_id/span_id en los logs cuando el tracing esté habilitado. Salta entre logs y traces con un solo clic.
• Nunca registres secretos, tokens o números completos de tarjeta. Permite campos en lista blanca; depura en Sentry before_send.
• Registra el contexto de negocio como campos, no como f-strings interpoladas. Permite el filtrado de la plataforma de logs.

B - Métricas

• Expón métricas RED por plantilla de ruta. Tasa, errores, histogramas de duración.
• Mantén baja la cardinalidad de las etiquetas. No uses IDs de usuario ni URLs crudas como etiquetas.
• Elige buckets de histograma alrededor de los umbrales del SLO. p95/p99 visibles en Grafana.
• Protege el endpoint /metrics. Red interna o autenticación, no internet público.
• Añade contadores de negocio con moderación. Solo etiquetas de enumeración pequeñas (country, plan).

C - Traces y Errores

• Muestrea traces en producción (ej. 5-20%). Favorece los errores si hay muestreo de cola disponible.
• Instrumenta las llamadas HTTP salientes y boto3. Los spans faltantes ocultan la latencia downstream.
• Establece release de Sentry al SHA de git. Divide las regresiones por despliegue.
• Alerta sobre nuevos issues en Sentry en producción, no sobre eventos duplicados. Reduce la fatiga.
• Propaga el contexto de trace a través de colas. Las cabeceras SQS/Kafka transportan traceparent.

D - Salud y Despliegues

• Separa /health/live y /health/ready. Las dependencias se comprueban solo en la readiness.
• El fallo de readiness devuelve 503. El balanceador de carga elimina el pod sin bucle de reinicio ante un pequeño problema en la base de datos.
• Sonda de inicio para importaciones lentas de Python. Modelos de ML de carga perezosa o sonda de inicio que tolera retrasos.
• Prueba de humo de salud después del despliegue en CI/CD. Bloquea la promoción si falla.
• Dashboard por servicio: RPS, 5xx, latencia p95, saturación. Página de aterrizaje predeterminada para el equipo de guardia.

E - Proceso y SLOs

• Define SLOs con presupuestos de error. Ejemplo: 99.9% de disponibilidad mensual.
• Notifica sobre la tasa de consumo del presupuesto, no sobre un solo pico. Las alertas multiventana reducen las notificaciones falsas.
• Ejecuta pruebas de carga antes de lanzamientos importantes. Valida p99 bajo el pico esperado.
• Documenta la propiedad de la observabilidad por servicio. Quién recibe las notificaciones, qué dashboards, qué runbooks.
• Revisa el coste de la observabilidad mensualmente. Elimina métricas de alta cardinalidad no utilizadas y muestreo de trace del 100%.

Preguntas Frecuentes

Relacionados

• Conceptos Básicos de Observabilidad - introducción a los tres pilares
• Logging Estructurado - patrones de structlog
• Métricas - instrumentación de Prometheus
• Salud y Readiness - diseño de sondas
• Buenas Prácticas de Despliegue - señales de despliegue en producción

Versiones de Stack: Esta página fue escrita para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, y uv 0.6+.