Observabilidad: hazle mejores preguntas a producción

El monitoreo pregunta si están pasando condiciones malas ya conocidas. La observabilidad te ayuda a investigar condiciones que no anticipaste. La prueba útil es simple: cuando un cliente dice que el checkout se quedó colgado a las diez catorce, ¿puedes encontrar esa petición, ver cada dependencia que llamó y explicar en qué se fue el tiempo?

User symptom: checkout took 18 seconds

Questions:
Which requests were affected?
Did errors or latency change by region or release?
Which operation consumed the time?
Which dependency returned slowly or failed?
Was the user impact inside the reliability objective?
What changed just before the symptom?

Recoge telemetría para responder preguntas operativas, no porque tres tipos de señal aparezcan en el diagrama de un proveedor. Una métrica revela un pico a nivel de población. Una traza ubica el trabajo lento en peticiones representativas. Un log preserva eventos detallados y errores. Sus identificadores compartidos de servicio, entorno, release, ruta y traza convierten registros separados en evidencia.

Un evento de log útil tiene nombre estable, timestamp, severidad, servicio, entorno, release, identificador de petición o de traza, resultado, duración y contexto de negocio acotado. Escribe JSON estructurado para que las máquinas filtren campos sin parsear oraciones. Conserva el mensaje humano, pero que no sea el esquema.

{
  "timestamp": "2026-07-25T10:14:32.481Z",
  "level": "error",
  "event": "payment_authorization_failed",
  "service": "checkout",
  "release": "2026.07.25.3",
  "trace_id": "4f92c6...",
  "order_id": "ord_8132",
  "provider": "acquirer_a",
  "duration_ms": 3002,
  "error_type": "deadline_exceeded"
}

Registra una sola vez, en la frontera que puede agregar contexto útil. Si cuatro capas capturan y vuelven a lanzar la misma excepción, cuatro stack traces idénticos suben el costo sin sumar evidencia. Preserva la causa original al envolver errores. No registres contraseñas, cookies de sesión, headers de autorización, tokens de acceso, datos completos de pago ni cuerpos de petición sin revisar.

Los contadores solo suben y sirven para peticiones, fallos y trabajos. Los gauges suben y bajan y sirven para profundidad de cola o memoria en uso. Los histogramas cuentan observaciones en buckets y te permiten agregar latencia entre instancias. Usa tasas para los contadores. Un conteo acumulado crudo de peticiones te dice, más que nada, cuánto tiempo lleva vivo el proceso.

http_requests_total{service="checkout",route="/orders/{id}",status_class="5xx"}
http_request_duration_seconds_bucket{service="checkout",route="/orders/{id}",le="0.5"}
queue_depth{service="fulfillment",queue="shipments"}
build_info{service="checkout",release="2026.07.25.3"} 1

# Useful views
error rate = 5xx request rate / all request rate
p95 latency from histogram buckets
queue age alongside queue depth

Los promedios esconden a los usuarios que esperan en la cola larga. Reporta una distribución de latencia y revisa el percentil noventa y cinco o noventa y nueve cuando el volumen de tráfico lo permita. Elige los límites del histograma alrededor de umbrales del producto, no números redondos heredados de otro servicio. Un job de treinta segundos y una API de cincuenta milisegundos necesitan buckets distintos.

Una traza representa una operación de punta a punta. Los spans representan piezas de trabajo medidas, con relaciones padre-hijo, atributos, eventos y estado. El span de servidor entrante debería contener spans hijos para base de datos, caché, cola y llamadas HTTP salientes. La forma muestra dónde se acumuló el tiempo y dónde apareció primero un error.

POST /checkout                         3.24 s
├─ validate basket                     0.02 s
├─ SELECT inventory                    0.08 s
├─ POST payment-provider /authorize    3.01 s  ERROR
└─ publish order-failed                0.03 s

trace_id: shared by every span
span_id: unique operation
parent_span_id: causal relationship
baggage: propagated context; use sparingly

La propagación de contexto es la parte que los equipos subestiman. Reenvía el contexto de traza estándar a través de las librerías de HTTP y de mensajería. Para trabajo asíncrono, enlaza el span del consumidor con el contexto del productor. No inventes un header de trace ID si tu instrumentación ya soporta uno estándar. Nunca pongas secretos ni payloads sin límite en los atributos de un span.

Empieza donde el trabajo entra y sale del servicio. Instrumenta servidores y clientes HTTP, consultas a base de datos, llamadas a caché, productores y consumidores de mensajes, trabajos programados y proveedores externos. Esas fronteras revelan latencia, errores, reintentos y fan-out. Poner un span alrededor de cada función auxiliar crea ruido y sobrecarga sin explicar el sistema.

Minimum service telemetry:
request count, outcome, and duration
in-flight work and queue age
dependency count, outcome, and duration
retries and timeouts
resource saturation
release and configuration version

Useful span attributes:
service.name, deployment.environment, service.version
http.request.method, http.route, http.response.status_code
db.system, db.operation.name
messaging.system, messaging.destination.name

Prefiere la instrumentación automática para librerías estándar y después agrega spans manuales alrededor de operaciones de negocio, como el cálculo de precios o la autorización de pago. Revisa los nombres de ruta generados y las sentencias de base de datos antes de publicar. Las plantillas de ruta parametrizadas son dimensiones seguras; las URLs crudas y los valores SQL pueden exponer datos y hacer explotar la cardinalidad.

Un indicador de nivel de servicio mide el éxito visible para el usuario, como la proporción de peticiones de checkout que se completan bien en menos de dos segundos. Un objetivo de nivel de servicio fija la meta en una ventana. El presupuesto de error es la fracción de fallo permitida. Habilita un intercambio explícito: gasta fiabilidad en cambios, pero frena cuando los fallos consumen el presupuesto demasiado rápido.

SLI = good checkout requests / eligible checkout requests
SLO = 99.9% over a rolling 28-day window

Allowed bad fraction = 0.1%
At 10,000,000 eligible requests:
error budget = 10,000 bad requests

Burn rate = observed bad rate / allowed bad rate
burn rate 1  → budget consumed exactly across the window
burn rate 14 → budget disappearing fourteen times too fast

Define con precisión qué cuenta como elegible y como bueno. Excluye los health checks y las peticiones rechazadas antes de entrar al flujo del producto. Decide cómo cuentan las cancelaciones y los fallos del proveedor desde la perspectiva del usuario, no según quién es dueño del componente. Un checkout fallido por una dependencia sigue siendo un checkout fallido.

Una alerta que despierta a alguien debe significar que una persona tiene que actuar ya. Alerta por consumo rápido del presupuesto de error, latencia sostenida visible para el usuario, o un backlog que pronto incumplirá su plazo. La CPU alta, una réplica caída o poco disco pueden importar, pero suelen ser señales de causa. Despierta a alguien por ellas solo cuando actuar de inmediato evite un impacto conocido.

PAGE:
Checkout SLO burn rate is 18 over 5 minutes
and 7 over 1 hour, affecting 3 regions.
Runbook: /runbooks/checkout-slo
Dashboard: /d/checkout
Recent releases: 2026.07.25.3 at 10:08 UTC

TICKET:
Search cluster disk projected to reach 80% in 4 days.
Owner: search-platform
Capacity procedure: /runbooks/search-capacity

Usa juntas una ventana corta y una larga. La corta detecta rápido una caída severa; la larga evita despertar a alguien por un parpadeo de un minuto. Toda alerta necesita dueño, declaración de impacto, evidencia actual y primera acción de diagnóstico. Si quien la recibe no puede actuar, mándala a otro lado o quítala.

Cada combinación única de etiquetas de una métrica crea una serie temporal. Una etiqueta con IDs de usuario, IDs de petición, URLs crudas, stack traces o timestamps puede crear millones de series y saturar el almacenamiento o el motor de consultas. Las métricas necesitan dimensiones acotadas. Pon los identificadores de alta cardinalidad en trazas muestreadas o en logs indexados, donde puedas consultarlos a propósito.

# Bad: one series per user and raw path
http_requests_total{user_id="813294",path="/orders/998123"}

# Better: bounded route and status class
http_requests_total{route="/orders/{id}",status_class="2xx"}

# Estimate series before shipping
services × routes × methods × status_classes × regions
40 × 80 × 5 × 5 × 4 = 320,000 possible series

Controla el costo con niveles de retención, muestreo, agregación y responsables. Guarda telemetría detallada donde responda preguntas activas. Reduce la resolución de las métricas viejas. Conserva los registros de seguridad y auditoría según su política aparte. "Guardar todo para siempre" no es una estrategia de observabilidad.

Supón que la latencia del checkout salta después de un release. Empieza por el impacto, no por inspeccionar hosts al azar. Confirma rutas, regiones, releases y rango de tiempo afectados. Compara trazas exitosas y fallidas. En las trazas lentas, el span de pago corre tres segundos y termina con un error de deadline. Ahora revisa los resultados de la dependencia y el número de reintentos.

rpc error: code = DeadlineExceeded desc = context deadline exceeded

10:08  release 2026.07.25.3 begins
10:11  checkout p95: 0.8 s → 6.4 s
10:11  payment attempts/request: 1.0 → 2.8
10:11  payment deadline errors increase

Trace evidence:
attempt 1: 3.0 s deadline
attempt 2: 3.0 s deadline
request deadline: 6.5 s

El texto crudo te dice que la operación local excedió el deadline de su contexto. No demuestra que el proveedor estuviera caído. La traza demuestra dos esperas secuenciales. El marcador de release y el rollback demuestran que la regresión sigue al nuevo comportamiento de reintentos. El buen trabajo de incidentes separa observación, hipótesis, prueba y conclusión.

Construye desde el recorrido del usuario hacia adentro. Un solo camino de checkout bien instrumentado vale más que dashboards de hosts en cincuenta servicios cuando nadie puede conectar esos hosts con un pedido fallido.

BUILD
1. Name critical user journeys and owners
2. Define good events and an SLO for each journey
3. Measure rate, errors, duration, and saturation
4. Instrument inbound, outbound, database, cache, and queue boundaries
5. Propagate trace context across HTTP and messaging
6. Add structured events with safe identifiers and release version
7. Link metrics to traces and traces to logs
8. Set retention, sampling, redaction, and series budgets
9. Test telemetry loss; the product must keep working
10. Page on fast user-impact burn with a usable runbook

INCIDENT
1. State user impact and exact time window
2. Check SLI, traffic, regions, routes, and release markers
3. Compare healthy and unhealthy populations
4. Open representative traces; locate the slow or failed span
5. Query correlated logs by trace ID and event
6. Check dependency, retry, queue, and saturation metrics
7. Mitigate with rollback, flag, traffic shift, or capacity
8. Verify user metrics recover
9. Preserve timestamps, queries, traces, and decisions
10. Fix the missing test and missing signal

El estándar útil no es tener telemetría perfecta. Es tener un camino corto entre el síntoma de un usuario y una explicación defendible. Mantén los identificadores conectados, las dimensiones acotadas, las alertas accionables y los cambios de release visibles. Así producción puede responder preguntas en lugar de solo producir gráficas.