Observabilidad no es tener dashboards lindos, es poder responder qué pasó a las 3 AM

Son las 3:05 AM y ninguna alerta despertó a nadie. El aviso llega desde soporte en Brasil: quien lidera el equipo escribe que unas decenas de clientes tienen sus pedidos trabados en "processing" desde más o menos la medianoche.

Abres el dashboard principal. El CPU está plano, la latencia p99 es normal y la tasa de error está en un cómodo 0.2%. Todo está en verde, y los clientes siguen esperando.

Así que empiezas a hacer las preguntas que trae todo incidente. ¿Qué clientes? ¿Desde cuándo, exactamente? ¿Qué cambió cerca de la medianoche? ¿En qué parte del flujo de pedidos se están quedando esas requests?

Veinte minutos después estás haciendo grep en logs que no incluyen el ID del pedido, recorriendo traces donde las requests que fallaron nunca entraron en la muestra, y preguntando en el canal del equipo si alguien hizo un deploy.

Esa distancia entre las preguntas que necesitas responder y lo que tus datos realmente pueden responder es de lo que se trata la observabilidad.

Incluso hay un nombre para una pared de paneles que sigue en verde mientras pasa esto: watermelon metrics, métricas sandía, verdes por fuera y rojas por dentro. Cada panel es preciso sobre CPU, latencia o tasa de error, y ninguno muestra si un pedido logra atravesar la cola.

Observabilidad vs. monitoreo: la diferencia aparece en pleno incidente

El monitoreo responde preguntas que ya sabías que ibas a hacer. ¿El servicio está arriba? ¿La latencia pasó el umbral? ¿La cola está creciendo?

Defines el chequeo de antemano, y un dashboard o una alerta te avisa cuando falla. Eso es útil, y lo necesitas.

La observabilidad es la capacidad de responder preguntas para las que no te preparaste. Honeycomb la define como poder investigar un sistema "haciéndole cualquier pregunta sobre su comportamiento", sin agregar instrumentación nueva "cada vez que surge una pregunta nueva".

Los pedidos trabados son una pregunta nueva. Nadie armó un panel para "pedidos de un proveedor de pagos que entraron a la cola después del deploy de las 23:50 y nunca recibieron confirmación". Un sistema es observable cuando igual puedes llegar a esa respuesta en minutos, cruzando los datos que ya tienes.

Por eso "tenemos dashboards para todo" y "tenemos observabilidad" son afirmaciones distintas: una pared de paneles en verde solo cubre lo que anticipaste, y lo que se rompe a las 3 AM es, casi por definición, algo que no anticipaste.

Cómo se acumula telemetría que no responde nada

A los sistemas que fallan a las 3 AM rara vez les faltan datos. Tienen meses de métricas, logs y traces. Lo que falta es una decisión sobre para qué sirven esos datos, así que cada pieza llegó ahí por costumbre.

El libro de SRE de Google tiene una regla directa para esto: las señales que recolectas pero que no aparecen en ningún dashboard ni alerta son "candidatas a eliminarse". Puedes seguir esa regla, o ir un paso antes y decidir para qué sirve cada señal antes de recolectarla.

Seguramente reconoces algunas de estas:

• Dashboards por defecto. El vendor o el Helm chart vinieron con paneles de CPU, memoria y request rate. Nadie los eligió, así que nadie sabe qué pregunta responden.
• Logs escritos para quien desarrolla, no para el incidente. "Processing order..." tenía sentido mientras depurabas la feature. Sin el ID del pedido, el cliente, la región o la versión, no puedes filtrar esa línea ni cruzarla con nada más.
• Traces muestreados para ahorrar. Guardar el 1% de los traces al azar baja la factura, y también hace que la request que falla, que es rara, casi nunca entre en la muestra, y ese es justo el trace que vas a querer a las 3 AM.
• Labels eliminados por cardinalidad. Alguien sacó el label de cliente de una métrica porque hacía explotar el almacenamiento. Fue una decisión razonable, y también es la razón por la que no puedes saber si un pico afecta a todos o a una sola cuenta.
• Contexto perdido en la cola. El trace sigue a la request hasta la API y se corta en el message broker, porque el contexto del trace nunca llegó al consumer. En el escenario de las 3 AM, ahí es exactamente donde estaban trabados los pedidos.

Cada una de estas decisiones tuvo sentido cuando alguien la tomó, y juntas dan como resultado un sistema que produce muchísima telemetría y aun así no puede decirte a quién afecta el problema, ni por qué.

Lo mismo pasa con los patrones de resiliencia: un circuit breaker que nadie mira parece protección en el diagrama de arquitectura mientras descarta tráfico en silencio.

Las cinco preguntas que trae todo incidente

Aquí es donde alguien suele objetar: si la observabilidad se trata de preguntas que no anticipaste, ¿cómo diseñas para eso, si nadie puede listar todas las fallas de antemano?

No hace falta. Se rompa lo que se rompa, las preguntas durante el incidente son casi siempre las mismas cinco, y cada una depende de datos que tienen que existir antes de que empiece:

1. ¿A quién afecta y quién lo está causando? Qué clientes, tenants, regiones o servicios internos. Eso requiere un ID de cliente o de tenant en tus eventos, más la identidad de quien hace la llamada, incluidos tus propios servicios.
2. ¿Desde cuándo? El momento exacto en que empezó, no "más o menos a la medianoche". Eso requiere timestamps confiables entre servicios y métricas con suficiente resolución para ver dónde cambia la curva.
3. ¿Qué cambió? Un deploy, un feature flag, un cambio de configuración, un cambio en el tráfico. Eso requiere la versión y una marca de deploy en tu telemetría, más un registro de los cambios de configuración y de flags.
4. ¿Dónde se rompe? Qué servicio, qué salto, qué paso del flujo. Eso requiere contexto de trace que sobreviva a colas y jobs asíncronos.
5. ¿Está mejorando o empeorando? Si el alcance del problema está creciendo. Eso requiere las mismas dimensiones de "a quién afecta" medidas en el tiempo, como la tasa de error por tenant, no solo un número global.

Si un campo no está ahí a las 3 AM, ninguna query ni ninguna herramienta lo va a producir. Dos postmortems públicos del último año muestran cómo se ve eso.

¿Quién lo está causando? En abril de 2026, caídas intermitentes en el data plane de Bluesky afectaron a cerca de la mitad de sus usuarios durante unas ocho horas, y encontrar la causa raíz llevó unos cuatro días. Un servicio interno nuevo estaba enviando lotes enormes de requests desde un solo data center.

Como lo resumió Jim Calabro, el ingeniero de Bluesky que escribió el postmortem: "no teníamos métricas por cliente en el data plane". Las métricas confirmaban la caída y no daban forma de ver qué cliente estaba detrás.

¿Qué cambió? Durante la caída global de Cloudflare en noviembre de 2025, las fallas iban y venían en oleadas, y la primera lectura del equipo fue un ataque DDoS masivo. Su status page, alojada fuera de Cloudflare, se cayó al mismo tiempo por pura coincidencia, y eso hizo que la teoría del ataque pareciera todavía más sólida.

La causa real fue un cambio de permisos en un cluster de ClickHouse. Una query que arma el feature file de Bot Management empezó a devolver filas duplicadas, el archivo duplicó su tamaño, y el proxy llegó a su límite de 200 features y empezó a devolver errores 5xx. Las oleadas venían de que algunos nodos de la base de datos todavía generaban un archivo bueno mientras otros generaban uno malo.

Cada falla quedó registrada en la telemetría; lo difícil fue conectar esas fallas con el cambio de permisos.

Eso es instrumentar con intención: asegurarte de que, sea cual sea el bug, esas cinco preguntas tengan respuesta en los datos.

Cómo se ve instrumentar con intención en la práctica

Empieza por las preguntas y trabaja hacia atrás hasta llegar a la telemetría. En la práctica, eso se reduce a unas pocas decisiones concretas.

Prefiere wide events a muchas líneas de log sueltas. Un solo evento estructurado por unidad de trabajo (lo que suele llamarse wide event), con request ID, cliente o tenant, región, versión, feature flags activos y resultado, responde más preguntas que veinte líneas que dicen "step 3 done". También es mucho más fácil de filtrar y agrupar.

Adjunta el deploy a todo. Cada evento y cada span deberían llevar la versión del servicio o el commit. Cuando aparezca "¿qué cambió?", quieres comparar antes y después del deploy, no salir a preguntar en Slack.

Propaga el contexto en cada frontera. Las llamadas HTTP suelen tenerlo gracias a la auto-instrumentación de OpenTelemetry. Las colas, los jobs programados y los webhooks normalmente no, y ahí es donde se esconden incidentes como el de los pedidos trabados.

Muestrea con intención. Si necesitas hacer sampling de traces, guarda todos los errores y todas las requests lentas, y muestrea solo las sanas, para que los traces que guardas sean los que un incidente te va a pedir.

El tail-based sampling hace esto, y no es gratis: el collector tiene que retener cada trace hasta que termina para decidir si lo guarda, lo que cuesta memoria y suma un componente más que operar. Compáralo con qué tan seguido necesitas los traces que hoy descartas.

Decide dónde viven los datos de alta cardinalidad. Los IDs de cliente no van en cada label de métrica, pero tienen que vivir en algún lugar donde puedas consultarlos, como eventos estructurados o traces. Descartarlos en todos lados es la forma de perder "¿a quién afecta?".

Todas estas son decisiones sobre lo que emite tu código, y puedes tomarlas con las herramientas que ya tienes.

Un test que puedes hacer esta semana

Toma el último incidente real que tuvo tu equipo. Abre el canal del incidente, no el postmortem, y anota cada pregunta que alguien hizo mientras estaba pasando: "¿Esto es solo en Android?", "¿Empezó con el release 2.14?", "¿De cuántos clientes estamos hablando?".

Los postmortems llegan después y tienden a saltarse los callejones sin salida, que es donde suelen aparecer los datos que faltan.

Después intenta responder cada una con los datos que tienes hoy, con un cronómetro corriendo.

Anota cuáles te toman dos minutos, cuáles veinte y cuáles no puedes responder. Las que no puedes responder son tu backlog de instrumentación, ordenado por qué tan seguido aparecen.

Es más útil que auditar tus dashboards, porque parte de lo que necesitaste cuando algo se rompió.

Dónde entra el presupuesto de herramientas

El costo es el principal criterio para elegir una herramienta de observabilidad por tercer año seguido, según el 65% de quienes respondieron la encuesta de observabilidad 2026 de Grafana Labs. Es un filtro razonable para aplicar una vez que sabes qué preguntas tiene que responder la herramienta.

Ninguna plataforma puede producir un ID de tenant que nadie logueó o un trace que nadie guardó, por más bien que almacene y visualice todo lo demás.

Así es como un stack caro y un sistema que no puede responder "¿a quién afecta?" terminan conviviendo durante meses: el presupuesto se fue a almacenar telemetría antes de que alguien decidiera qué preguntas tenía que responder.

Vuelve por un momento a los pedidos trabados. Con un ID de cliente en cada evento, la versión en cada span y contexto de trace que atraviesa la cola, las preguntas de las 3:05 AM (qué pedidos, desde cuándo, después de qué cambio) se resuelven con una o dos queries, y quien está de guardia vuelve a la cama antes de que soporte en Brasil tenga que mandar un segundo mensaje.