Observabilidad: qué es y cómo usar logs, métricas y trazas

La observabilidad es la capacidad de inferir el estado interno de un sistema a partir de las señales que produce. En una aplicación distribuida, esas señales ayudan a investigar una demora, un error o un cambio de comportamiento sin depender de una única vista del servicio.

También puede servirte: CI/CD: qué es y cómo funciona un pipeline de software

No es una herramienta específica ni un tablero único. Es una práctica que combina instrumentación, recolección, contexto y preguntas operativas. El objetivo es poder pasar de un síntoma visible para una persona usuaria a la parte del sistema que lo explica.

Una métrica puede mostrar que la latencia subió, un log puede aportar el mensaje de error y una traza puede unir la solicitud con varios servicios. Cada señal responde una pregunta diferente; juntas permiten formular una hipótesis y comprobarla con datos del mismo evento.

Un log es un registro de un hecho ocurrido en un programa. Puede incluir una hora, un nivel, un mensaje y campos estructurados como el identificador de una solicitud. Los logs detallan casos concretos, pero su volumen y formato deben controlarse para que sean buscables y no expongan datos sensibles.

Una métrica es una medición agregada a lo largo del tiempo, como solicitudes por segundo, errores o duración. Sirve para observar tendencias y activar alertas con un costo menor que guardar cada evento. Prometheus, por ejemplo, distingue tipos de métricas según cómo se registran y consultan.

Una traza representa el recorrido de una operación y sus spans, que describen partes de ese recorrido. Los spans pueden mostrar cuánto tardó cada servicio o llamada externa. Un identificador común permite vincular una traza con logs y métricas sin suponer que todas las señales viven en la misma herramienta.

La instrumentación agrega el código o la configuración que produce señales. OpenTelemetry ofrece APIs, SDK y componentes para generar y transportar telemetría, y permite mantener el código de la aplicación separado de la herramienta donde se consulta. La elección del exportador queda en la arquitectura del equipo.

Primero conviene identificar operaciones importantes: una petición HTTP, una consulta a base de datos, una cola o una llamada a otro servicio. Esas operaciones necesitan nombres consistentes y atributos útiles, como ambiente, versión y resultado. Los atributos deben evitar secretos, tokens y datos personales que no sean necesarios para investigar.

La instrumentación automática puede cubrir bibliotecas conocidas, mientras la manual agrega contexto propio del negocio. Conviene empezar por un recorrido completo y comprobar que el identificador se conserva entre servicios. Una señal que no puede asociarse con la operación que la originó pierde gran parte de su valor durante un incidente.

Una alerta debe representar una condición que requiere una decisión. El porcentaje de errores, la latencia de una ruta crítica o la falta de capacidad pueden ser buenos indicadores cuando tienen un umbral, una ventana y una persona responsable. Un tablero lleno de números no reemplaza una pregunta concreta.

Las señales necesitan una referencia para interpretar un cambio. Google SRE recomienda observar el comportamiento del sistema con indicadores que ayuden a detectar problemas y responderlos. La ventana elegida debe evitar que una fluctuación breve genere ruido, sin esconder una degradación sostenida.

Cuando una alerta se dispara, los enlaces a la traza, los logs y la versión desplegada reducen el tiempo de diagnóstico. También hay que registrar qué acción se tomó y si la alerta seguía siendo necesaria. El ciclo de revisión evita que los umbrales sobrevivan a cambios de tráfico o arquitectura.

Elegí un recorrido de usuario y definí qué significa que funcione. Nombrá operaciones, servicios y ambientes de manera estable. Decidí qué señales vas a conservar, cuánto tiempo y con qué nivel de detalle. La retención y el costo son parte del diseño, igual que el código que produce la telemetría.

Validá que los identificadores conecten logs, métricas y trazas sin incluir información sensible. Probá un error controlado, una demora y una respuesta correcta. En cada caso deberías poder encontrar el evento desde el síntoma hasta la operación que lo produjo y la versión que estaba activa.

Por último, creá pocas alertas accionables y asignalas a una respuesta documentada. Medí falsos positivos, consultas lentas y datos ausentes. La observabilidad queda lista cuando ayuda a explicar un cambio real del sistema y no sólo a acumular telemetría en un tablero que nadie revisa.