Lección 46 — Métricas, trazas y alertas

La observabilidad de TicketFlow. Sin solutions.md hasta entregar.

Ejercicio 1 — Las métricas RED

1. Implementa el middleware de métricas (§1) con el label route de la plantilla y el histograma de latencia. Verifica el endpoint /metrics y pega las series de un endpoint tras 20 requests.
2. La cardinalidad: rompe a propósito el label (usa el path crudo con UUID) y genera 50 requests: ¿cuántas series crea? Documenta la explosión y el fix.
3. Las métricas de negocio: añade reservations_created_total (counter), sagas_in_unknown (gauge con la query del 32), outbox_pending (gauge), seat_conflicts_total (counter en el handler del 26). El dash: un panel por métrica con la línea vertical del deploy (la 41).

Ejercicio 2 — Las trazas

1. Instrumenta OTel (auto-instrumentation Django + manual en gateway.charge como el §2) y exporta al stack local (Grafana Tempo/Jaeger o el log JSON con spans). Pega la traza del checkout con sus spans y duraciones.
2. El sampling: configura traceidratio=0.1 y verifica (50 requests): ¿cuántas trazas llegaron? ¿La del request con ERROR siempre llega (el sampling de cola/importancia: ¿el error forzar el keep)?
3. El hilo completo: la traza del endpoint → el span del task Celery (la propagación del contexto en la cola) → el span del SQL del poller. El trace_id de la 45 en la traza: ¿la consulta del incidente une log y traza con un id?

Ejercicio 3 — Los SLOs

1. Escribe la tabla de SLOs (§3) como queries PromQL reales: la del p95 del checkout (histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{route="checkout"}[5m])) by (le))), la de disponibilidad, y la de convergencia de saga.
2. El error budget: con el SLO 99.5% (30 d), calcula: ¿cuántos requests lentos puedes gastar al mes? Si el burn actual es 3.2, ¿en cuántos días quemas el presupuesto? Escribe la cuenta.
3. El SLI honesto: mide tu entorno local (k6 del 36) y llena la tabla real: ¿tu sistema CUMPLE los SLOs propuestos? ¿Cuál no y qué mejora del 37-39 la movería?

Ejercicio 4 — Las alertas

1. Implementa las reglas de alerta del §4 (PromQL de burn rate multi-ventana para el checkout; las de gauge para sagas/outbox/dlq; el heartbeat del 29). Pega el YAML de 3 reglas (una page, una ticket, el heartbeat).
2. El falso positivo cazado: simula un spike de 2 min de p95 (k6 corto) y verifica que la regla multi-ventana NO pagea (la ventana de 5 min no confirma). Después: el fallo sostenido → page. La diferencia es la política anti-ruido.
3. El runbook: escribe el runbook de la alerta sagas_in_unknown (dash que confirma, la query de la saga afectada del 32, las 3 causas probables con su fix, y el enlace al rollback). ¿Cuánto tarda un on-call nuevo en llegar a la causa con tu runbook? (que lo lea otro: el test real).

Ejercicio 5 — El game day

1. El ejercicio: en staging, apaga el Redis (el caché y el broker del 29). ¿Qué alertas disparan y en cuánto? ¿El heartbeat de expiración pagea cuando el worker muere? Documenta la cronología del game day (minuto a minuto).
2. La brecha encontrada: ¿qué fallo NO disparó ninguna alerta (¿el outbox_pending con el poller vivo pero sin Redis? ¿el p95 del browse que sube con el caché frío?)? Añade la alerta que faltó.
3. El dashboard final: arma el dash de una pantalla (RED de checkout, negocio, infra, las anotaciones de deploy) y la URL en el runbook. El test del on-call: con el dash + runbook, un tercero diagnostica el game day sin tu ayuda: ¿lo logró en <15 min?

Entrega

Pega las series del /metrics, la traza del checkout, las 3 reglas de alerta y la cronología del game day. Después: Lección 47 — Depurar en producción.