¿Qué es Observability?

¿Qué es observability?

Observability es la propiedad de un sistema que te permite entender su estado interno desde sus outputs externos sin tener que enviar código nuevo para investigar. Los tres outputs externos son logs (qué eventos pasaron), métricas (series temporales numéricas como RPS, latencia, CPU) y traces (desgloses por request a través de services). Un sistema es observable cuando un engineer sin contexto previo puede responder preguntas arbitrarias sobre un incident de producción solo desde esas tres señales.

El término viene de la control theory: un sistema es observable si su estado interno es plenamente determinable desde un historial finito de outputs. En software la barra práctica es más baja pero el principio se mantiene. Si un cliente reporta un checkout lento y tu única respuesta es añadir log lines, redesplegar y esperar a que el error vuelva, tu sistema no es observable.

Observability vs monitoring

Monitoring y observability solapan pero no son lo mismo:

• Monitoring hace preguntas predefinidas: ¿está la homepage up, CPU bajo 80%, error rate bajo 1%? Configuras dashboards y alerts por adelantado contra failure modes que predices. Mejor para failure modes conocidos.
• Observability hace preguntas arbitrarias a datos high-cardinality después del hecho: "muéstrame todos los requests p99 de la última hora agrupados por customer_id y región donde el downstream call a stripe.com excedió 800 ms." Mejor para failure modes desconocidos.

Un sistema de monitoring puede decirte que algo está roto. Un sistema observable te permite encontrar qué. Producción saludable necesita ambos.

Los tres pillars (y la trampa de cardinality)

• Logs: registros de events discretos. Fáciles de escribir, caros de query a escala, débiles en correlación entre services salvo que propagues trace IDs en cada log line.
• Métricas: series temporales numéricas. Baratas de almacenar, rápidas de query, pero pierden contexto per-request. La cardinality (número de combinaciones únicas de tags) es el driver de costo.
• Traces: árboles de spans per-request a través de services. La señal más fuerte para investigación de incidents. Sampleados a menudo (1-10%) porque almacenar cada trace es prohibitivo.

Las herramientas modernas de observability (Honeycomb, Datadog, Grafana, Splunk, New Relic, Elastic) intentan unificar las tres alrededor de un trace ID compartido, de forma que un click salta de un spike de métrica al trace lento a los logs correspondientes.

Qué cubre observability en la práctica

1. Investigación de incidents: producción en llamas, on-call engineer correlaciona el spike de métrica al trace a la query lenta al mal deploy en bajo 10 minutos.
2. Medición de SLO: error rate y percentiles de latencia por endpoint, por customer tier, sliced como necesites.
3. Detección de regresión de performance: comparar latencia p95 del endpoint X antes y después de un deploy, scoped a una sola cohorte de customer.
4. Escalación de soporte: "este usuario reporta que su checkout fue lento a 14:32 UTC" mapeado al trace exacto.
5. Capacity planning: métricas históricas correlacionadas con patrones de tráfico. Ver capacity testing.

Cómo volverse observable

Comienza propagando un trace ID a través de cada request: HTTP header (W3C traceparent), dentro de queue messages, dentro de background jobs. Luego instrumentar con un SDK OpenTelemetry (vendor-neutral) que emita traces y métricas a tu backend de elección. Luego estandarizar log lines para incluir trace_id y customer_id.

Observability complementa el load testing. Correr load testing o soak testing contra un staging completamente instrumentado y los mismos dashboards que usas en producción se convierten en tus resultados de test. Ver también latencia.

Si tu equipo necesita correr load tests de producción correlacionados contra tu stack de observability existente, LoadFocus ofrece servicios de load testing donde ingenieros diseñan los scenarios y documentan contra tus datos APM y de tracing.