Observabilidad: los logs, las métricas y las trazas que importan

La mayoría de los equipos no tiene un problema de observabilidad. Tiene un problema de datos disfrazado de problema de observabilidad. Envían logs, métricas y trazas a tres proveedores distintos, pagan una factura que crece más rápido que los ingresos y aun así no pueden responder la única pregunta que importa a las 3 de la madrugada: ¿por qué fue lenta esta petición para este cliente? El objetivo no es más telemetría. El objetivo son respuestas más rápidas.

Esta guía tiene una postura clara y es práctica. Aborda qué instrumentar, qué descartar y cómo mantener todo el conjunto a un coste asumible en 2026 sin quedarte a ciegas cuando algo se rompe.

Las tres señales, y para qué sirve realmente cada una

Los logs, las métricas y las trazas no son intercambiables. Los equipos se meten en problemas cuando intentan que una señal haga el trabajo de otra, normalmente logueando todo con la esperanza de reconstruir la verdad más tarde.

• Las métricas responden a «¿hay algo mal, y hasta qué punto?». Son números baratos y agregables a lo largo del tiempo: tasa de peticiones, tasa de errores, percentiles de latencia, profundidad de cola, saturación. Las métricas son aquello sobre lo que alertas, porque son estables y de baja cardinalidad.
• Las trazas responden a «¿en qué se va el tiempo?». Una traza sigue una única petición a través de los servicios, mostrando qué span fue lento y qué estaba esperando. Las trazas son la forma de encontrar el cuello de botella una vez que las métricas te dicen que existe uno.
• Los logs responden a «¿qué ocurrió exactamente en este caso concreto?». Cargan el contexto detallado que una métrica no puede llevar: el mensaje de error exacto, la entrada que lo desencadenó, la rama de código que se ejecutó. Los logs son para el último tramo de una sesión de depuración, no para el primero.

Un modelo mental útil: las métricas detectan, las trazas localizan, los logs explican. Si tu equipo recurre a la búsqueda de texto completo en los logs cada vez que algo va lento, estás pagando por la señal más cara para que haga el trabajo de la señal más barata.

Parte de las preguntas, no de las herramientas

La forma más rápida de malgastar dinero en observabilidad es instalar un agente, activar cada integración y dejar las preguntas para después. En su lugar, anota las preguntas que necesitas responder antes de un incidente y luego instrumenta solo lo justo para responderlas.

Un buen conjunto inicial para la mayoría de los sistemas web y SaaS:

1. ¿Está el servicio disponible y sirviendo tráfico dentro de su presupuesto de latencia?
2. Cuando los errores se disparan, ¿qué endpoint, dependencia o versión es responsable?
3. Para una petición lenta o fallida concreta, ¿qué camino tomó y dónde se atascó?
4. ¿Nos estamos acercando a un límite de recursos (conexiones, memoria, profundidad de cola) antes de que se convierta en una caída?
5. ¿El despliegue que acabamos de lanzar empeoró algo?

Cada panel, cada alerta y cada decisión de instrumentación debería remitir a una de esas preguntas. Si una pieza de telemetría no responde a ninguna pregunta real, es coste sin valor.

Estructura todo, y correlaciónalo

El cambio de mayor apalancamiento que la mayoría de los equipos puede hacer es dejar de emitir texto libre y empezar a emitir datos estructurados y correlacionados. Tres hábitos hacen casi todo el trabajo:

• Logs estructurados. Emite JSON con nombres de campo consistentes, no concatenación de cadenas. "user_id": "u_123", "route": "/checkout", "latency_ms": 812 es consultable. Una frase no lo es.
• Un identificador de petición compartido. Genera un trace ID en el borde y propágalo a través de cada servicio, cada línea de log y cada tarea en segundo plano. Cuando puedes saltar de un gráfico de latencia que se dispara a la traza exacta y a las líneas de log exactas de esa petición, el tiempo medio de resolución cae de forma acusada. Esta correlación lo es todo.
• Etiquetas de métricas consistentes y de baja cardinalidad. Etiquetas como route, status_code y region están bien. Etiquetas como user_id o request_id en una métrica dispararán la cardinalidad y tu factura. El contexto de alta cardinalidad pertenece a las trazas y los logs, no a las métricas.

Adoptar OpenTelemetry como capa de instrumentación es la opción por defecto sensata en 2026. Te da una manera neutral respecto al proveedor de emitir las tres señales, de modo que puedes cambiar de backend sin reinstrumentar toda tu base de código. Esa portabilidad es un apalancamiento real cuando llega el presupuesto de renovación.

Los SLO convierten el ruido en señal

Los paneles llenos de verde y rojo no son una estrategia. Los Objetivos de Nivel de Servicio sí lo son. Un SLO define el nivel de fiabilidad que en realidad persigues, por ejemplo «el 99,9 por ciento de las peticiones de pago se completan en menos de 500 ms durante 28 días móviles». Todo lo demás se deriva de él.

El beneficio práctico es el presupuesto de error. Si tu objetivo es el 99,9 por ciento, tienes un 0,1 por ciento de peticiones para gastar en fallos. Ese presupuesto cambia la conversación de dos maneras:

• Las alertas se vuelven sensatas. Alertas sobre la tasa de consumo, es decir, con qué rapidez estás agotando el presupuesto, no sobre cada error individual. Un solo 500 no despierta a nadie. Consumir una semana de presupuesto en una hora, sí.
• Las prioridades se vuelven honestas. Cuando el presupuesto está sano, lanza funcionalidades. Cuando está agotado, el trabajo de fiabilidad sube a lo más alto del backlog. Decide el número, no la voz más alta de la sala.

Unos SLO bien definidos son también lo que mantiene tu trabajo sobre la latencia anclado en la experiencia del usuario y no en métricas de vanidad. Si te importa el lado frontend de esa ecuación, nuestra guía de campo sobre Core Web Vitals cubre las señales de latencia del mundo real que Google y tus usuarios sienten de verdad.

Muestreo: cómo ver con claridad sin almacenarlo todo

No necesitas el 100 por cien de tus trazas y logs de depuración. Almacenarlo todo es el camino más rápido hacia una factura desbocada, y la mayor parte nunca se lee. El truco está en conservar los datos interesantes y descartar a propósito los datos aburridos.

• El muestreo basado en la cola (tail based sampling) decide si conservar una traza después de que se complete, de modo que puedes conservar cada error y cada petición lenta mientras muestreas las peticiones rápidas y exitosas hasta un porcentaje pequeño. Esto es lo que quieres para las trazas.
• Niveles de log con intención. Mantén los errores y las advertencias con fidelidad total. Muestrea o agrega los logs de info y depuración de alto volumen, y haz que la verbosidad de depuración sea algo que puedas subir por servicio durante un incidente en lugar de dejarla siempre activa.
• Las métricas permanecen completas. Como las métricas están preagregadas y son baratas, por lo general las conservas todas. Son tu red de seguridad.

Una buena regla: nunca descartes con el muestreo la evidencia de un problema. Descarta la confirmación de que todo va bien. Hay mucho más de esto último.

Controla el coste antes de que él te controle a ti

Las facturas de observabilidad tienen la costumbre de duplicarse en silencio. La cardinalidad se cuela, el volumen de logs crece con el tráfico y los valores de retención por defecto son generosos porque el proveedor se beneficia de ellos. Trata el coste de la telemetría como una preocupación de ingeniería, no como una sorpresa contable.

1. Ajusta la retención por señal. Las métricas pueden vivir meses de forma barata; los logs en bruto rara vez necesitan más de unas pocas semanas en almacenamiento caliente.
2. Audita trimestralmente tus principales combinaciones de etiquetas de métricas y elimina las de alta cardinalidad que no responden a ninguna pregunta.
3. Descarta o agrega tus fuentes de logs más ruidosas y menos leídas en el colector, antes de que siquiera lleguen al proveedor.
4. Enruta los datos a largo plazo y rara vez consultados a un almacenamiento de objetos barato en lugar de a un almacenamiento indexado premium.
5. Pon la factura mensual de telemetría en un panel que el equipo vea, del mismo modo que vigilas la tasa de errores.

La misma disciplina que mantiene sensatas las facturas de cómputo se aplica aquí. Nuestro manual de optimización de costes en la nube profundiza en el filtrado a nivel del colector y en la estratificación del almacenamiento, que son lo que marca la mayor diferencia.

Modos de fallo comunes que seguimos viendo en 2026

Incluso los equipos maduros caen en un conjunto familiar de trampas. Según nuestra experiencia, estas explican la mayor parte del gasto malgastado y los incidentes lentos:

• Fatiga por alertas. Docenas de alertas ruidosas enseñan a la gente a ignorar el buscapersonas. Menos alertas, basadas en el presupuesto, que siempre significan algo, restauran la confianza.
• Paneles que nadie posee. Pantallas llenas de gráficos que nadie sabe interpretar durante un incidente. Cada panel debería corresponder a una pregunta y tener un responsable.
• La instrumentación como ocurrencia tardía. Añadir la telemetría después de una caída, en lugar de tratarla como parte de la definición de terminado de cada servicio.
• Tres herramientas, ninguna correlación. Los logs en un proveedor, las trazas en otro, las métricas en un tercero, sin un identificador compartido que las una. Solo el cambio de contexto te cuesta minutos que no tienes.

Cómo puede ayudar Innovation T

Una buena observabilidad no es un producto que compras, es una práctica que integras en la forma en que se diseñan y despliegan tus sistemas. En Innovation T ayudamos a los equipos a instrumentar sus servicios con OpenTelemetry, a definir SLO que reflejen la experiencia real del usuario y a cablear logs, métricas y trazas correlacionados para que un ingeniero de guardia pueda pasar de «algo va lento» a «aquí está el span exacto» en minutos en lugar de horas.

Lo abordamos de principio a fin: endureciendo tu arquitectura para que los incidentes sean más raros, construyendo paneles y alertas de tasa de consumo que solo se disparan cuando importan, y ajustando el muestreo y la retención para que obtengas la visibilidad que necesitas a una factura que puedas defender. Como también construimos el software y la infraestructura en la nube subyacentes, diseñamos la instrumentación desde el principio en lugar de añadirla después de la primera caída dolorosa. Esa mentalidad se traslada a cómo abordamos el diseño de sistemas en general, desde las migraciones de monolito a microservicios hasta la plataforma que hay debajo.

Si tu factura de telemetría sube mientras tus incidentes siguen sintiéndose como conjeturas, esa brecha es exactamente lo que resolvemos. Explora nuestros servicios o ponte en contacto: una breve conversación suele bastar para señalar dónde tu observabilidad te está costando dinero sin comprarte respuestas.