Observabilidad: averiguar qué está haciendo el sistema

La lección anterior terminó con una advertencia que encaja aquí exactamente: una cola esconde fallos. Si el worker de correo muere, nada devuelve un error, y el cliente que lo nota primero es aquel de quien menos quieres oírlo. Todo en esta lección es la respuesta a ese problema: cómo un sistema en marcha te dice qué está haciendo sin que antes tenga que quejarse un usuario.

Hay tres tipos de telemetría, y la forma útil de sostenerlos es por la pregunta que responde cada uno. Las métricas son números muestreados en el tiempo: peticiones por segundo, tasa de error, edad de la cola, memoria usada. Son baratas de guardar y de consultar, y son las únicas que escalan hasta responder a si algo va mal ahora mismo. Los logs son eventos individuales con detalle: esta petición falló con este error, para este usuario, en este momento. Son caros, y son los únicos que te dicen qué tenía de distinto exactamente la petición que se rompió. Las trazas siguen una petición por cada servicio que tocó, registrando cuánto tardó cada paso, y son las únicas que responden a dónde se fue el tiempo.

PILLAR     SHAPE                ANSWERS                        COST

  metric     number over time     is it bad, and since when     cheap
  log        event with fields    what exactly happened here    medium
  trace      spans with parents   where did the 900 ms go       sampledLos tres pilares, la pregunta que cada uno responde mejor y lo que cuesta conservarlos.

La razón de que los logs por sí solos no funcionen es aritmética, y merece la pena hacerla una vez para que el número se quede. Cuarenta pods de aplicación escribiendo quinientas líneas por segundo cada uno son veinte mil líneas por segundo. En una hora son setenta y dos millones de líneas, y a doscientos bytes cada una son unos catorce gigabytes por hora, o sea unos trescientos gigabytes al día. Eso no lo lee nadie. No puedes encontrar una aguja leyendo un pajar cuyo tamaño se duplica mientras lees. Por eso los logs son un almacén de detalle que se consulta con una pregunta concreta en mente, no algo que se mira.

40 pods x 500 lines/s = 20000 lines/s

  1 hour   =  72 000 000 lines
  at 200 bytes each  =  14 GB per hour

  reading by eye: never
  grep across 40 files: minutesPor qué nadie mira los logs en crudo y por qué la respuesta es consultarlos en vez de hojearlos.

El arreglo de los logs es dejar de escribir frases y empezar a escribir registros. Una línea sin estructura como el pedido 9001 falló para el usuario 42 tras 903 ms la lee un humano y es casi inútil para una máquina: extraer el id del pedido significa escribir una expresión regular que se rompe en cuanto alguien cambia el texto. Un registro estructurado escribe cada valor bajo un nombre, así que el sistema de logs puede filtrar por id de pedido, agrupar por tipo de error y contar. Adoptarlo no cuesta casi nada y convierte los logs de algo que lees en algo que consultas. La única disciplina que importa es acordar los nombres, porque user_id en un servicio y uid en otro hacen imposible el cruce justo cuando lo necesitas.

{
  "ts": "2026-10-13T09:14:22.481Z",
  "level": "error",
  "event": "payment_declined",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "user_id": 42,
  "order_id": 9001,
  "amount_cents": 1290,
  "duration_ms": 903
}Una línea de log estructurado, con los campos que la hacen consultable y el trace id que la conecta con todo lo demás.

La distinción que reorganiza la monitorización es la que hay entre síntoma y causa. Un síntoma es algo que experimenta un usuario: el checkout va lento, el login falla, la página está en blanco. Una causa es un mecanismo dentro de tu sistema: la CPU está al noventa por ciento, hay un bloqueo retenido, un pool de conexiones agotado. Las causas son lo que se puede arreglar, y por eso la gente alerta sobre ellas. Ese instinto es erróneo, y la razón es que la mayoría de las causas son inocuas casi siempre. La CPU al noventa por ciento en un día ajetreado es un sistema funcionando bien. Una espera de bloqueo de seis segundos es catastrófica. El número es de la misma clase; solo el efecto visible para el usuario te dice qué estás mirando. Alerta sobre el síntoma, y usa la causa como la explicación que vas a buscar cuando el síntoma salte.

Así que la regla es: despierta a una persona cuando se está haciendo daño a un usuario, y deja todo lo demás como un panel o un ticket. En concreto, eso significa que la tasa de error del checkout pasando del dos por ciento merece despertar a alguien, y la CPU al ochenta por ciento no, porque lo segundo puede estar perfectamente bien y desde luego no significa por sí solo que alguien esté sufriendo. Esto no es cuestión de gusto. Un aviso es la afirmación de que algo va mal ahora mismo y hace falta una persona. Si alertas sobre causas, alertarás sobre cosas que no están mal, los ingenieros empezarán a ignorar el buscapersonas, y la única alerta que importaba se quedará sin leer mientras el sitio está caído.

ALERT ON (symptom)            DO NOT PAGE ON (cause)

  checkout error rate > 2%      cpu above 80 percent
  p99 checkout latency > 2 s    disk above 75 percent
  queue age > 5 minutes         one pod restarted
  login success rate < 99%      memory above 70 percent

  a cause that hurts nobody pages nobodyLa columna izquierda merece despertar a alguien. La derecha merece un gráfico en una pantalla.

La última idea es la que convierte todo esto en un número con el que se puede discutir. Un SLI es un indicador: una proporción que puedes medir, expresada como eventos buenos divididos por eventos válidos, medida en el punto donde la experimenta el usuario. Para un checkout, eso significa checkouts con éxito divididos por todos los intentos, contados en el borde del sistema y no dentro de algún servicio interno sano. El punto de medición importa enormemente. Un servicio puede informar de cien por cien de éxito mientras el balanceador que tiene delante manda a timeout la mitad de las peticiones, y solo la medición en el borde ve eso.

SLI   good requests / valid requests
      measured at the edge, not inside

SLO   99.9 percent over 30 days

BUDGET
  30 days          =  43200 minutes
  allowed bad      =  43.2 minutes
  burn 10x         =  page now
  burn 1x          =  ticket tomorrowLa aritmética de un objetivo del 99,9 por ciento durante treinta días y las dos velocidades de consumo sobre las que merece la pena reaccionar.

Un SLO es un objetivo para ese indicador, como el 99,9 por ciento durante treinta días, y el presupuesto de error es lo que queda: la cantidad de fallo que has decidido tolerar. Treinta días son 43 200 minutos, así que el 99,9 por ciento deja 43,2 minutos de maldad permitida, que es un número que puedes gastar de verdad. El presupuesto cambia las conversaciones. Cuando está sano, el equipo puede desplegar rápido y asumir riesgos, porque el sentido del presupuesto es que se use. Cuando está casi agotado, los despliegues se vuelven más cuidadosos, y cuando se agota, el movimiento estándar es congelar el trabajo de funcionalidad y dedicar el tiempo a la fiabilidad. Ese es todo el mecanismo, y sustituye una discusión sobre sentimientos por una decisión sobre un número.

Esta es la respuesta a la frase más antigua del software. En mi máquina funciona no es una afirmación sobre el código, es una afirmación sobre dos entornos distintos. La petición de producción pasa por otra ruta de red, otro conjunto de datos, otra configuración y otra carga concurrente. Y es un problema de medición porque la petición que falla nunca se capturó con suficiente contexto para comparar: qué usuario, qué versión del código, qué réplica, qué fila de la base de datos. La respuesta de la observabilidad no es discutir sobre la frase, es hacerla innecesaria. Si cada petición lleva un trace id y cada línea de log lleva el mismo id, un solo ejemplo de la petición que falla en producción vale más que una hora de intentos de reproducción, porque contiene los hechos en vez de una hipótesis.

Una consecuencia práctica merece mención porque cambia tu comportamiento durante un incidente. La primera pregunta útil nunca es qué deberíamos cambiar, sino qué sabemos. Un trace id de un informe, una plantilla de la petición que falla, el momento exacto en que empezó y si afecta a todos o a un subconjunto: esos cuatro hechos suelen estrechar la búsqueda lo bastante como para que el arreglo sea obvio. Los equipos que se saltan este paso pasan el incidente cambiando cosas, lo cual destruye la evidencia para el siguiente intento con el mismo problema, y luego el incidente se repite un mes después sin que nadie pueda decir si es el mismo.