Qué es la observabilidad: guía práctica para equipos

Son las 2 de la madrugada. El endpoint de pagos devuelve errores 500 en una de cada veinte peticiones y todos los paneles están en verde. Esa distancia entre «el sistema dice que todo va bien» y «los usuarios dicen que está roto» es lo que la observabilidad intenta cerrar. ¿Qué es la observabilidad? Es la capacidad de entender lo que hace su sistema por dentro a partir de los datos que emite (logs, métricas y trazas), con la precisión suficiente para responder preguntas que no había previsto de antemano.

Esa última idea es el punto central. Todo lo demás en este artículo son detalles.

Observabilidad frente a monitoreo: la pregunta para la que no escribió una alerta

El monitoreo responde a preguntas que ya sabía formular. ¿La CPU supera el 90%? ¿La tasa de errores pasa del 2%? ¿Crece la cola de mensajes? Usted elige las métricas, fija los umbrales y un aviso suena cuando alguna los cruza.

La observabilidad responde a la pregunta que no supo formular. ¿Por qué solo las peticiones de un cliente, en una versión concreta de la aplicación y tras un despliegue determinado, tardan 4 segundos más? Nadie tiene una alerta para eso, porque nadie lo había previsto.

Tampoco son rivales. El monitoreo es la capa de alertas; la observabilidad es lo que le permite investigar cuando salta la alerta, o cuando un cliente escribe y ninguna alerta se disparó. Si su única herramienta es un muro de dashboards prefabricados, tiene monitoreo. Si puede segmentar los datos de producción por cualquier dimensión y seguir una petición a través de varios servicios sin desplegar código nuevo, tiene observabilidad.

Las tres señales: métricas, logs y trazas

La mayoría de las definiciones empiezan por «los tres pilares». La etiqueta suena un poco rígida, pero los tres tipos de datos son reales y cada uno sirve para un trabajo concreto.

• Métricas son números a lo largo del tiempo: tasa de peticiones, latencia p95, memoria en uso. Son baratas de almacenar, rápidas de consultar y muy útiles para saber si algo va mal. Son pobres para responder qué petición falló, y por qué.

• Logs son registros con marca de tiempo de eventos concretos: un pago rechazado, un reintento, un feature flag que cambió. Aportan el detalle, pero los logs sin estructura de un servicio muy usado se convierten en un pajar.

• Trazas siguen una única petición a medida que atraviesa servicios. Cada salto es un span con inicio, duración y atributos. Una traza es lo más parecido a un stack trace para un sistema distribuido.

La encuesta 2025 de Grafana Labs, con 1,255 profesionales, muestra dónde están realmente los equipos. Según el estudio sobre observabilidad de Grafana, el 95% de los encuestados usa métricas y el 87% usa logs, pero solo el 57% usa trazas. Son la señal con más probabilidades de ayudar ante un error distribuido, y la que menos equipos tienen configurada.

Evite el atajo que dice que las métricas indican qué pasa, los logs por qué y las trazas dónde. Suena ordenado, pero falla en la práctica: un buen log estructurado suele decir más sobre el «dónde» que una traza mal instrumentada.

Qué hace observable a un sistema en la práctica

Emitir datos es necesario, pero no basta. Un sistema es observable cuando sus datos cumplen tres propiedades.

Alta cardinalidad. Puede filtrar por ID de usuario, tenant, SHA de la build, región o feature flag. Si su herramienta obliga a agregar previamente por nombre de servicio y código de estado, no encontrará al único tenant que está en mal estado.

Contexto que enlaza las señales. Un ID de traza en cada línea de log permite saltar de un span lento a los logs exactos que produjo. Sin ese enlace, lee dos historias separadas y adivina cómo se relacionan.

Detalle suficiente para ser útil, pero no tanto como para resultar inasumible. Aquí es donde más equipos se atascan. En la misma encuesta de Grafana, los encuestados citaron más de 100 herramientas, servicios y proyectos distintos, y el equipo medio usaba ocho. El coste era uno de los criterios principales al elegir herramientas. Recoger todo es fácil; pagarlo es lo que se descubre después.

Así es el punto de partida con OpenTelemetry, el estándar de instrumentación independiente de proveedor. Este es un ejemplo mínimo en Python que crea un span y añade los atributos que querrá tener a las 2 de la madrugada:

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

Tres atributos marcan la diferencia entre «el checkout va lento» y «el checkout va lento para el tenant 4412 en la versión 3.8.1». La guía de conceptos de observabilidad de OpenTelemetry explica las ideas de fondo con más profundidad y merece una lectura, aunque su proveedor haga la conexión por usted.

Dónde se diferencian las herramientas (y dónde no)

Bajo el marketing, casi todas las plataformas ingieren las mismas tres señales. Se diferencian en el modelo de precios, en la potencia de las consultas y en cuánta instrumentación hacen por usted.

• Las plataformas todo en uno agrupan métricas, logs, trazas, alertas y más. Son cómodas, con la contrapartida de facturas por uso que crecen con el tráfico.

• Los stacks de código abierto, como Prometheus, Loki, Tempo y Grafana, le dan control y no cobran licencia por host, a cambio de tener que instalarlos y afinarlos usted mismo.

• Los backends nativos de OpenTelemetry aceptan el formato estándar directamente, así que cambiar de proveedor no obliga a reinstrumentar cada servicio.

Datadog es la referencia de la categoría todo en uno: cobertura amplia, interfaz pulida y una factura que merece revisarse cada mes. Vale la pena si quiere un solo proveedor y tiene presupuesto. Descártelo si la previsibilidad de costes es su principal restricción.

Grafana es la opción pragmática de código abierto. Puede empezar con dashboards sobre los datos que ya tiene y añadir logs y trazas cuando los necesite. Espere invertir algo de tiempo de ingeniería.

SigNoz está construido sobre OpenTelemetry desde el principio y reúne métricas, logs y trazas en una sola interfaz de código abierto. Es una elección razonable si quiere la experiencia de una sola pantalla sin el precio de las plataformas todo en uno.

New Relic está a medio camino entre ambos mundos, con una plataforma alojada y un nivel gratuito lo bastante generoso para hacer una evaluación real. Júzguela por si su equipo puede responder a una pregunta real de producción dentro de ella, y no por la demo.

Ninguna de estas herramientas le hará observable por sí sola. La herramienta es una interfaz de consulta; la instrumentación es el producto.

La parte que la mayoría de las guías omite: la observabilidad se detiene en la frontera del código

Hay una brecha que notará la primera vez que use estas herramientas en serio. Una traza le dice que charge_card tardó 3.9 segundos y que la parte lenta era una llamada a payment_client. No le dice qué hace realmente payment_client, quién lo escribió ni por qué reintenta tres veces sin backoff.

Para eso sale de la herramienta de observabilidad y lee código. En un servicio pequeño, eso lleva diez minutos. En un repositorio de 100K líneas que mantienen cuatro equipos, la lectura suele ser la parte más larga del incidente. Sabe exactamente qué span es lento y aun así dedica una hora a averiguar cómo está conectado el código que hay detrás.

Ese es el problema de traspaso entre los datos de ejecución y el código fuente, y por eso pensamos en la observabilidad y en la comprensión del código como dos mitades de un mismo flujo de trabajo:

1. La observabilidad le dice dónde ocurre en tiempo de ejecución: qué servicio, qué span, qué tenant.

2. La comprensión del código le dice por qué en el código fuente: qué función, qué política de reintentos, qué configuración.

Los equipos que cierran ese círculo (el nombre del span se corresponde con un archivo, y el archivo con un responsable y una explicación) reducen el tiempo entre «saltó la alerta» y «se entendió el fallo». Es sobre todo un problema de disciplina. Nombre los spans según las funciones, incluya la ruta del repositorio en un atributo del span y mantenga una nota corta de arquitectura por servicio. Un asistente de IA que pueda responder preguntas sobre su repositorio, como «¿dónde se define la política de reintentos para los pagos?», tiene entonces algo concreto en lo que apoyarse.

Tres errores que hacen pensar que la observabilidad no funciona

Tratar los dashboards como el objetivo. Un dashboard es la respuesta guardada a una pregunta antigua. Los equipos que construyen cuarenta y nunca practican consultas ad hoc acaban con monitoreo en un envoltorio más bonito. En cada incidente, pregúntese: ¿lo respondimos con un dashboard o explorando los datos en bruto?

Muestrear demasiado pronto, o nunca. Conservar el 100% de las trazas en un servicio muy usado sale caro muy rápido, y conservar el 1% al azar descarta la rara petición fallida que más le importa. El muestreo basado en cola, que conserva las trazas lentas y fallidas y descarta la mayoría de las sanas, es el compromiso habitual. Decídalo antes de la primera factura, no después.

Dejar que los nombres de los atributos se desvíen. Un servicio escribe user_id, otro userId y un tercero uid. Entonces la consulta que debería abarcar los tres devuelve un tercio del cuadro. Acuerde una pequeña convención de nombres para los atributos de tenant, usuario, versión y flag, y escríbala en el repositorio, donde la gente la encuentre.

Ninguno de estos errores es un problema de herramientas. Son hábitos, y los hábitos cuestan menos de corregir que cambiar de proveedor.

Un comienzo realista, sin querer abarcarlo todo

Si hoy no tiene nada, resista la tentación de instrumentarlo todo en la primera semana. Esta secuencia funciona para equipos de 5 a 50 ingenieros:

1. Elija un flujo crítico para el usuario. El pago, el registro o la llamada principal a la API. No el sistema entero.

2. Añada logs estructurados con un ID de petición. En JSON, un evento por línea, con un ID de traza o de petición en cada línea.

3. Instrumente ese flujo con trazas de OpenTelemetry. Incluya los atributos de tenant, versión y flag del ejemplo anterior.

4. Defina dos o tres objetivos de nivel de servicio (SLO). Por ejemplo, que el 99.5% de las peticiones de pago se completen con éxito en menos de 800 ms. Las alertas deben colgar de ahí, no de la CPU.

5. Revise un incidente real contra los datos. ¿Podría haber encontrado la causa sin código nuevo? Si no, la brecha que encuentre es su siguiente tarea de instrumentación.

El paso 5 es el que se suele saltar, y es el único que le dice si su sistema es observable. Todo lo demás es fontanería.

Lo que haríamos nosotros

Si su equipo tiene menos de 20 ingenieros, empiece con instrumentación de OpenTelemetry y con un backend cuyo precio pueda prever. La instrumentación es portable, así que la elección del backend es reversible. No compre la plataforma más grande solo porque lo hizo un competidor.

Si ya paga una herramienta todo en uno, no la arranque de cuajo. Audite qué ingiere, elimine los logs que nadie consulta y destine el ahorro a instrumentar los flujos que importan.

Y, sea cual sea el camino, documente cómo se corresponde un span con el código. El dashboard le muestra el incendio. Alguien tiene que leer el código fuente para averiguar por qué empezó.