Observabilidad: métrica, log y trace, y qué responde cada uno

La monitorización responde "¿está funcionando?". La observabilidad responde "¿por qué no lo está?".

La diferencia importa porque la segunda pregunta es la que haces durante un incidente, y exige datos que necesitabas haber recogido antes.

Los tres pilares y sus preguntas#

La métrica responde "qué" y "cuánto".

Es un número agregado a lo largo del tiempo: tasa de peticiones, tasa de error, latencia por percentil, uso de recursos. Barata de guardar, porque la agregación descarta el detalle. Excelente para alertas y para paneles.

Mala para investigar un caso específico: justamente porque el detalle se descartó en la agregación.

El log responde "qué pasó en este caso".

Un evento con contexto. Caro en volumen, porque no agrega nada.

Y aquí va el consejo más práctico de este artículo: log estructurado. JSON, con campos consistentes, siempre con el identificador de correlación. Un log en texto libre es imposible de consultar exactamente cuando más lo necesitas: durante el incidente, cuando quieres filtrar por cliente, por ruta y por franja de tiempo a la vez.

El trace responde "dónde se fue el tiempo".

Sigue una petición por todos los servicios y muestra el árbol de llamadas con la duración de cada tramo. Es la herramienta que responde "por qué esa petición tardó dos segundos" en treinta segundos, en vez de en dos horas.

Si tienes arquitectura distribuida y no tienes trace, estás investigando incidentes con una mano atada a la espalda.

1. Métricaqué y cuántoNúmero agregado en el tiempo. Barata, porque la agregación descarta el detalle. Buena para alerta y panel, mala para el caso específico.
2. Logqué pasó aquíEvento con contexto. Caro en volumen, porque no agrega nada. Estructurado, o es imposible de consultar en el incidente.
3. Tracedónde se fue el tiempoEl árbol de llamadas de una petición, con la duración de cada tramo. Responde en treinta segundos lo que llevaría dos horas.

Lo que une a los tres#

El identificador de correlación: el trace id.

Nace en el borde, viaja en una cabecera por todas las llamadas internas, y aparece en todos los logs.

Con él, miras una métrica anómala, encuentras un trace lento de ese periodo, y saltas directo a los logs de esa petición concreta, en todos los servicios. Sin él, cada pilar es una isla.

Si tu sistema no propaga el trace id, es lo primero que hay que implementar. Es barato, es mecánico, y cambia el juego. OpenTelemetry lo resuelve de forma estandarizada en la mayoría de los lenguajes.

Las cuatro señales doradas#

Si solo vas a tener cuatro métricas por servicio, que sean estas, del libro de SRE de Google:

Latencia. Por percentil, y separando las peticiones exitosas de las que fallaron. Un error rápido puede enmascarar una latencia mala en la media.

Tráfico. Peticiones por segundo. Sin eso, no sabes si la caída de errores fue una mejora o fue que nadie estaba usando el sistema.

Errores. Tasa, no conteo. Y cuidado con lo que cuenta como error: un 4xx del cliente y un 5xx del servidor cuentan historias distintas.

Saturación. Cuán lleno está el recurso más limitado. La cola es el indicador más honesto de saturación, más que el uso de CPU.

El método USE, para bajar un nivel#

Cuando las cuatro señales apunten a un problema de recursos, usa el método de Brendan Gregg. Para cada recurso (CPU, memoria, disco, red):

Utilización: cuánto tiempo está ocupado.

Saturación: cuánto trabajo está esperando en la cola.

Errores: conteo de fallos.

La idea clave es que una utilización alta con saturación baja está bien: significa que estás usando lo que pagaste. El problema es la saturación. Un disco al 90% de utilización sin cola está sano; un disco al 60% con cola creciente no lo está.

Alerta sobre el síntoma, no sobre la causa#

Este es el error más común al configurar alertas.

"La tasa de error del checkout pasó del 1%" es un síntoma. Importa, el usuario lo está sintiendo, alguien debe despertarse.

"La CPU de la máquina 3 está al 80%" es una causa posible. Puede no significar nada. Puede ser exactamente el comportamiento esperado bajo carga.

La alerta de causa genera fatiga. Y un equipo con fatiga de alertas ignora la alerta que importaba. Eso convierte tu sistema de alertas en ruido caro.

La regla: alerta sobre lo que el usuario percibe. Usa las causas como contexto para investigar después de que la alerta se dispare.

Y amárralo al SLO: si definiste que el 99,9% de las peticiones responden en menos de 300ms, la alerta debe ser sobre quemar el presupuesto de error demasiado rápido, no sobre un pico aislado de treinta segundos.

El guion de "está lento"#

Método, no corazonada:

1. ¿Es CPU o es espera? Mira la utilización de CPU del proceso. Si está baja y aun así va lento, es espera de I/O, de lock o de cola.

2. Si es CPU, saca un perfil y mira el flamegraph. El ancho de cada barra es el tiempo gastado en esa función y en las que ella llama. Buscas barras anchas. Leer uno lleva treinta segundos una vez que entiendes el eje, y es la herramienta más eficiente que existe para encontrar adónde se va el tiempo.

3. Si es espera, el trace responde de qué.

4. Si es lock, mide el tiempo de contención. Si añades CPU y el rendimiento no sube, es aquí.

5. Si es cola, encuentra cuál: la del balanceador, la del pool de conexiones, la del ejecutor, la de la mensajería.

No te saltes etapas y no empieces optimizando. La intuición sobre rendimiento se equivoca con una frecuencia humillante.

Cardinalidad: la trampa de coste#

Una métrica con una etiqueta por usuario genera una serie temporal por usuario. Con un millón de usuarios, un millón de series.

Eso dispara el coste y tumba el sistema de métricas. La regla: la etiqueta de métrica es para dimensiones de baja cardinalidad (ruta, estado, región, versión). El identificador de usuario, de pedido y de petición van al log y al trace, nunca a la métrica.

Es el error más caro que se comete en observabilidad, y solo aparece en la factura.

Por dónde empezar#

Si hoy tienes poco, el orden de mayor retorno:

1. Trace id propagado de punta a punta, apareciendo en todos los logs.

2. Log estructurado con campos consistentes.

3. Las cuatro señales doradas por servicio, con latencia por percentil.

4. Tracing distribuido en las rutas críticas.

5. Alertas sobre síntomas, amarradas al SLO.

Un ejercicio concreto para esta semana: implementa la propagación del trace id en una ruta. Provoca un error. Confirma que consigues seguir ese identificador desde el log del borde hasta el log de la base de datos.

Si lo consigues, ya estás por delante de la mayoría.