¿Qué es la observabilidad? Guía práctica para equipos SRE
Resumen
La observabilidad es la capacidad de responder preguntas nuevas sobre el comportamiento de un sistema en producción, sin desplegar instrumentación adicional. La monitorización vigila fallos conocidos; la observabilidad sirve también para los desconocidos. Para lograrla hacen falta logs, métricas y trazas correlacionados, eventos anchos con alta cardinalidad y una política de muestreo y retención. Empieza por un camino crítico, no por una herramienta.
¿Qué es la observabilidad? Es la capacidad de explicar por qué tu sistema se comporta mal usando solo la telemetría que ya emite, incluso para fallos que nadie había previsto. La monitorización te dice que la latencia del checkout superó los 800 ms. La observabilidad te permite preguntar qué cliente, qué dependencia o qué despliegue lo causó, sin escribir código nuevo a las 3 de la madrugada para averiguarlo.
Imagina la escena. Salta la alerta: el p99 de la API de pagos ha subido de 180 ms a 1.4 s. El dashboard está en verde en CPU, memoria y tasa de errores. Todos los paneles predefinidos dicen que el servicio está bien, y todos los clientes dicen que no. Lo que hagas en los diez minutos siguientes es el tema de este artículo.
¿Por qué importa la definición antes que las herramientas?
El término viene de la teoría de control: un sistema es observable si puedes inferir su estado interno a partir de sus salidas externas. El software lo tomó prestado, y después los proveedores lo estiraron hasta que significó "un producto de dashboards". Ignora ese estiramiento.
La definición de trabajo para un equipo de ingeniería es más estrecha y más útil. Un sistema es observable cuando puedes responder una pregunta nueva sobre su comportamiento, en producción, sin desplegar nueva instrumentación. La palabra que importa es "nueva". Una alerta por umbral responde a una pregunta que alguien escribió el trimestre pasado. Un sistema observable responde a la que estás haciendo ahora mismo.
No es un test de pureza. Nadie tiene un sistema perfectamente observable, y el objetivo no es una puntuación. El objetivo es un camino más corto desde "algo va mal" hasta "este es el cambio que lo provocó". El tiempo medio para detectar y el tiempo medio para entender son números distintos, y la mayoría de los equipos solo mide el primero.
¿En qué se diferencia la observabilidad de la monitorización?
La monitorización es un conjunto de comprobaciones sobre modos de fallo que ya conoces: CPU por encima del 90% durante cinco minutos, tasa de errores por encima del 1%, cola por encima de 10.000 mensajes. Es barata, fiable, y la necesitas. La observabilidad no la reemplaza.
La diferencia aparece cuando el fallo es nuevo. La monitorización se construye a partir de tus incidentes pasados. La observabilidad se construye para el siguiente, que por definición todavía no has visto.
Una prueba útil: mira tus últimos tres incidentes y pregúntate cómo se encontró la causa raíz.
Si alguien leyó un dashboard predefinido y la respuesta estaba allí, la monitorización hizo su trabajo.
Si alguien buscó en los logs de seis hosts, formuló una hipótesis, añadió una línea de log, desplegó de nuevo para confirmarla, eso fue un hueco de observabilidad.
Si la respuesta real salió de una captura de pantalla de un cliente, tienes los dos problemas.
Deja de lado el debate sobre si son rivales. Son capas. La monitorización es el detector de humo. La observabilidad es la capacidad de recorrer el edificio después y averiguar qué circuito provocó el fuego.
¿Cuáles son las tres señales y dónde falla cada una?
Logs, métricas y trazas forman el trío estándar. Cada una responde a una pregunta distinta, y cada una tiene un modo de fallo que las guías de los proveedores suelen omitir.
Las métricas son mediciones numéricas agregadas en el tiempo: tasa de peticiones, tasa de errores, percentiles de latencia, saturación. Son baratas de almacenar y rápidas de consultar, por eso las alertas viven sobre ellas. Su modo de fallo es la agregación. Un p99 de 1.4 s te dice que algo va lento, pero no puede decirte que todas las peticiones lentas pertenecen a un mismo cliente en un mismo shard.
Los logs son registros con marca de tiempo de eventos discretos. Llevan el máximo detalle y la mínima estructura, salvo que la impongas. Su modo de fallo es el volumen y el coste. Los logs sin estructura solo los pueden buscar personas que ya saben qué cadena buscar, lo que los convierte en una herramienta de monitorización disfrazada de herramienta de depuración.
Las trazas siguen una única petición a través de los límites de los servicios, con un span por cada salto y su tiempo. Son la única señal que muestra la forma de una petición: esta llamada esperó 900 ms a una dependencia que reintentó tres veces. Su modo de fallo es la cobertura. Un servicio que pierde el contexto de la traza rompe la cadena, y una traza con un hueco es peor que inútil, porque parece autoritativa.
Tener las tres no equivale a ser observable. El punto es la correlación. Necesitas pasar de un pico en una métrica a las trazas que contribuyeron, y de una traza a los logs de esa petición exacta. Si las tres viven en herramientas separadas sin un identificador común, tienes tres sistemas de monitorización y un ingeniero haciendo de unión.
¿Por qué la cardinalidad decide si puedes depurar algo?
La cardinalidad es el número de valores distintos que puede tomar un campo. status_code tiene unos veinte. customer_id tiene cientos de miles. request_id tiene uno por petición.
Los campos que más necesitas durante un incidente son los de alta cardinalidad. "¿Qué cliente está afectado?" es una pregunta sobre customer_id. "¿Qué build sirve las peticiones lentas?" es una pregunta sobre deploy_version. Si tu modelo de almacenamiento penaliza los campos de alta cardinalidad, cobrándolos por serie única o descartándolos en silencio, no podrás hacer la pregunta que resuelve el incidente.
Esta es la línea arquitectónica real entre una configuración basada solo en métricas y una configuración observable. Las métricas preagregadas tiran las dimensiones que querrás más tarde. Los eventos anchos y estructurados las conservan, y tú segmentas los datos después.
Así es un evento útil en el borde de un servicio: un registro por petición, con contexto suficiente para segmentar por cualquier cosa que te importe más adelante:
logger.info("request.completed", {
trace_id: span.traceId,
route: "/v1/payments",
customer_id: ctx.customerId,
deploy_version: process.env.BUILD_SHA,
flag_variant: flags.get("new-ledger-path"),
db_ms: timings.db,
upstream_ms: timings.upstream,
status: res.statusCode,
duration_ms: elapsed,
});Fíjate en la variante del feature flag. Una parte importante de los incidentes que aparecen en post-mortems publicados empieza con un cambio, y evaluar un flag es un cambio. Si la variante no está en el evento, no puedes preguntar si las peticiones lentas son las que van por la nueva ruta.
¿Cómo es un incidente con y sin observabilidad?
Volvamos al escenario de pagos. La misma alerta, el mismo p99 de 1.4 s.
Sin observabilidad, el bucle es este: abres el dashboard del servicio y no encuentras nada; abres el dashboard de la base de datos y tampoco; preguntas en el canal del incidente si algo se desplegó. Alguien recuerda un cambio de configuración. Otro no está de acuerdo. Cuarenta minutos después, revierte el último despliegue para ver si ayuda. No ayuda, porque la causa era un despliegue gradual de un flag a un subconjunto de tenants.
Con observabilidad, el bucle es otro: agrupas las peticiones lentas por flag_variant y ves que el 100% están en new-ledger-path; agrupas por customer_id y ves que tres tenants grandes concentran la mayor parte del volumen; abres una traza y ves que la llamada al ledger se abre en 40 consultas secuenciales. Tiempo total: unos minutos. Apagas el flag, no el despliegue.
Fíjate en lo que el segundo bucle no necesitó. No necesitó un dashboard preparado. No necesitó que alguien hubiera previsto de antemano que "variante de flag" era una dimensión interesante. Necesitó que los datos estuvieran ahí, anchos y consultables.
Ese es el argumento de Honeycomb en un párrafo, y se sostiene. Lo que no dice es que sea gratis.
¿Cuánto cuesta y quién debería saltarse la versión cara?
La telemetría es primero un problema de volumen de datos y después un problema de herramientas. Según la encuesta de observabilidad 2025 de Grafana Labs, con 1.255 profesionales encuestados, la organización media usa ocho herramientas de observabilidad distintas, y el coste es el criterio más citado al elegir otras nuevas. Ambos datos están relacionados. Los equipos acumulan herramientas porque cada una resuelve un fragmento, y luego pagan por ingestas solapadas en todas.
Reglas prácticas que se sostienen en la mayoría de tamaños de equipo:
Instrumenta con OpenTelemetry, no con un agente propietario. El collector te da un único punto para muestrear, filtrar y enrutar. Cambiar de backend se convierte en un cambio de configuración y no en un proyecto de re-instrumentación.
Muestrea las trazas con criterio. Conserva todos los errores y todas las peticiones lentas, y muestrea las rápidas y sanas. Un muestreo head-based fijo al 1% descartará justo la traza que necesitas.
Da estructura a los logs en el momento de escribirlos. Parsear texto libre en el momento de consultar es la forma cara de obtener campos.
Define una política de retención por señal. Métricas durante un año, eventos anchos durante dos semanas, logs de depuración durante tres días. Nadie ha necesitado nunca los logs de depuración del trimestre pasado.
Evita el enfoque de plataforma completa si gestionas unos pocos servicios y una única rotación de guardia. Un equipo pequeño obtiene casi todo el beneficio con logs estructurados, métricas RED y trazas en los dos o tres caminos críticos. El contrato caro, que lo hace todo, solo compensa cuando tienes tantos servicios que nadie mantiene en la cabeza toda la topología, lo que en nuestra experiencia ocurre a partir de unos 30 o 40 servicios.
¿Qué herramientas merecen una mirada?
La elección depende de cuánto quieras operar tú mismo, de cómo sea tu cardinalidad y de lo que pueda soportar tu factura. Un recorrido breve y con criterio:
Datadog es la opción comercial más amplia: métricas, logs, trazas y profiling bajo un mismo techo, con buena correlación entre ellos. El precio de esa integración es una factura que escala con los hosts, las métricas personalizadas y el volumen de logs ingeridos. Merece la pena si quieres un solo proveedor y tienes presupuesto para ello. Revisa la partida de métricas personalizadas antes de comprometerte.
Grafana es la opción por defecto cuando quieres componentes abiertos que puedas alojar tú o contratar como stack gestionado. Encaja bien con métricas tipo Prometheus y con pipelines de OpenTelemetry. El precio es operativo: tú llevas más del ensamblaje, y la dispersión de herramientas que mide la encuesta también te afecta a ti.
SigNoz es una opción de código abierto y nativa de OpenTelemetry que reúne logs, métricas y trazas en un mismo almacén. Eso importa para el punto de correlación de antes, porque un almacén compartido convierte el salto de métrica a traza y de traza a log en una consulta y no en un cambio de pestaña. Es razonable para equipos que quieren alojar la herramienta sin unir cuatro proyectos.
Better Stack combina monitorización de disponibilidad, alertas de incidentes y gestión de logs a un precio pensado para equipos pequeños. Es un primer paso sensato si pasas de "nos enteramos por los clientes" a algo estructurado, y menos adecuado para una malla de servicios grande con necesidades intensas de trazas.
¿Cómo empezar sin abarcar todo a la vez?
No empieces con una evaluación de herramientas. Empieza con los últimos tres incidentes y una pregunta honesta: ¿qué nos habría gustado poder preguntar?
Una secuencia que funciona para un equipo de 50 a 200 ingenieros:
Elige un camino de petición crítico e instrumentalo de extremo a extremo con OpenTelemetry. Checkout, login, lo que te despierta a las 3 de la madrugada.
Emite un evento estructurado y ancho por petición en el borde del servicio, con cliente, versión, variantes de flags y tiempos de las dependencias.
Define un SLO en ese camino y alerta por tasa de consumo del presupuesto (burn rate), no por umbrales en bruto. Las alertas de burn rate te avisan por impacto en el usuario, y la telemetría del paso 2 te dice por qué.
Haz un simulacro. Inyecta un fallo que no tengas alertado y mide cuánto tarda alguien que no escribió el código en encontrarlo. Ese número es tu línea base.
Expande hacia fuera un camino cada vez, solo cuando el primero se haya pagado solo en un incidente real.
La observabilidad se compra como plataforma y se adopta como hábito. El hábito consiste en preguntar "¿qué necesitaría saber para explicar esto?" en la revisión de código, antes del incidente y no durante él.
Revisa tu última retrospectiva de incidente y busca la frase que dice "después añadimos logging para confirmarlo". Cada una de esas frases es una pregunta que tu sistema no pudo responder en producción. ¿Cuántas tienes archivadas, y cuáles seguirían sin respuesta hoy?