OpenTelemetry: cómo las trazas distribuidas te salvan la guardia en microservicios

Hace años, migrando la telefonía de un cliente a una red nueva, me tocó un caso que resume esta profesión: las llamadas “entraban” —el tablero en verde, todo aparentemente bien—, pero un dato clave se rompía en el camino. La petición cruzaba mi equipo, el gateway, la red del proveedor y el destino, y en alguno de esos saltos algo fallaba. Cada quien juraba que su parte estaba impecable: yo la mía, el proveedor la suya. Nos llevó días de prueba y error —con el proveedor echándome la culpa a mí— hasta poder demostrar en qué salto exacto se rompía: era una configuración de su lado. 🎯

No eran microservicios; era una llamada de voz. Pero el principio es idéntico al de una traza distribuida bien hecha: una sola petición cruza muchos sistemas, “todo se ve verde”, y hasta que no sigues el hilo salto por salto no sabes en cuál se rompió. Lo que a mí me costó días de discusión, hoy una traza lo enseña en minutos.

De eso trata OpenTelemetry (OTel), y por qué en 2026 dejó de ser una apuesta para volverse el estándar de facto de la observabilidad. Si operas microservicios, esto te toca directo. Y no es teoría: más abajo bajamos todo a tierra con un ejemplo servicio por servicio, con configuración de verdad.

¿Qué es una traza distribuida y por qué te salva la guardia?

Una traza distribuida es el registro completo del viaje de una sola petición a través de todos los servicios, colas y bases de datos que atraviesa. Cada salto se registra como un span (con su nombre, duración y metadatos), y todos los spans de una misma petición comparten un trace ID. El resultado es una línea de tiempo donde ves, de un vistazo, dónde se fue el tiempo. 👀

Si vienes de operaciones como yo, piénsalo así: el monitoreo clásico te dice que algo está lento; la traza te dice dónde y por qué. Es la diferencia entre una alarma que suena y un mapa que te lleva al problema. Si quieres el fundamento completo, lo desarrollo en ¿Qué es observabilidad y por qué no es solo monitoreo?.

En mis años en el NOC, la mitad de los incidentes largos no eran por falta de datos, sino por datos que no conversaban entre sí. Tenías el gráfico de CPU de un equipo, los logs de otro y las quejas del cliente en un tercero. La traza une esas tres realidades en un solo hilo: el trace ID que viaja pegado a la petición. Cuando ese hilo existe, dejas de discutir de quién es la culpa y empiezas a arreglar.

OpenTelemetry ya no es una apuesta: graduó en la CNCF

En mayo de 2026 OpenTelemetry alcanzó el nivel “Graduated” dentro de la Cloud Native Computing Foundation, el mismo estatus que Kubernetes, según el anuncio oficial de la CNCF. No es un detalle de comunidad: es la señal que un líder técnico necesita para justificar la adopción ante su comité de arquitectura sin miedo a apostar por algo que muera en un año.

Las cifras que publicó la propia CNCF dan la dimensión del proyecto:

¿Por qué debería importarte una “graduación” a ti, que estás apagando incendios en producción? Porque graduar en la CNCF significa gobernanza estable, releases predecibles y compatibilidad hacia atrás como compromiso serio. La cobertura de InfoQ sobre la madurez del proyecto lo resume bien: cuando un estándar llega a este nivel, los vendors dejan de tratarlo como “opcional” y empiezan a soportarlo de origen. Eso, para quien firma contratos, es dinero y tranquilidad.

Cuando el problema no está de tu lado (y hay que probarlo)

Hace años me tocó una serie de ventanas de mantenimiento para migrar troncales de telefonía de H.323 a SIP, con cambio de proveedor incluido. Recibir la troncal nueva, configurarla en el gateway y en el conmutador, ajustar los planes de marcación, y validar con llamadas de prueba.

Las llamadas entraban. Pero el identificador del llamante —el número que ves en la pantalla— llegaba bien en H.323 y se rompía en SIP. Una prueba de “¿entra la llamada?” pasaba sin problema: el servicio estaba arriba. Lo que estaba roto era un pedazo de información que viajaba dentro de la llamada, y eso ningún semáforo lo iba a mostrar.

Lo que siguió fue prueba y error con los ingenieros del carrier. Y lo primero que hicieron fue echarme la culpa: “son tus comandos, es tu configuración”. No lo era. La pieza que faltaba estaba de su lado, no del nuestro.

Después de ese caso aprendí el patrón. Con cada troncal SIP nueva que se rompía igual, ya podía decirles con seguridad: “no sé todavía cuál es el detalle, pero esta falla está de su lado.” Y acertaba. Eso es reconocimiento de patrones ganado a los golpes, y también aprender a no aceptar una culpa que no me tocaba.

Cuento esto porque es exactamente el problema que resuelven las trazas distribuidas, aunque yo entonces no tuviera esa palabra. Una petición que cruza sistemas de organizaciones distintas, cada uno viendo solo su tramo, y nadie con la foto completa. Sin traza, esa discusión se gana con terquedad y semanas de prueba y error. Con traza, abres el detalle del salto y señalas dónde se perdió el dato. Deja de ser tu palabra contra la del proveedor y se vuelve un hecho con evidencia.

Anatomía de una traza: un checkout que cruza tres servicios

Bajemos todo a tierra con el ejemplo que lo deja más claro: un checkout. Y da igual si vienes del e-commerce o, como yo, de la telefonía y las redes: el patrón se repite idéntico —una petición que atraviesa varios sistemas y falla en uno de los saltos—. En este ejemplo la petición cruza tres servicios: frontend (recibe el clic de “pagar”), pagos (habla con un proveedor externo) e inventario (descuenta stock). Un solo trace ID los recorre los tres. Así es como se ve el problema cuando por fin tienes trazas.

Imagina la traza en la pantalla: el span raíz del frontend dura 1.150 ms. Dentro, el span de inventario tarda 120 ms y el de pagos se lleva 810 ms. Y dentro de pagos, el span hijo que llama al proveedor externo marca 800 ms. Traducción directa: el 70% del tiempo total se va en un servicio de terceros que ni siquiera controlas. Sin traza, habrías culpado a tu base de datos durante horas.

Ese es el momento “ajá” que convierte escépticos. No es un gráfico bonito: es el fin de la discusión sobre de quién es la culpa. Aquí un span manual en el servicio de pagos, con los atributos que de verdad sirven cuando estás de guardia a las 3 a.m.:

// Servicio "pagos" - span manual (pseudocódigo)
tracer.enSpan("cobrar_tarjeta", (span) => {
  span.setAttribute("checkout.id", pedido.id);
  span.setAttribute("pago.proveedor", "stripe");
  span.setAttribute("pago.monto_mxn", pedido.total);
  span.setAttribute("pago.reintentos", intentos);

  const respuesta = proveedorExterno.cobrar(pedido);

  span.setAttribute("pago.estado", respuesta.estado);
  if (respuesta.estado !== "aprobado") {
    span.setStatus({ code: ERROR });
    span.recordException(respuesta.error);
  }
});

Fíjate en el detalle: los atributos describen el negocio (proveedor, monto, reintentos, estado), no solo la máquina. Cuando ese span falla, la traza te dice qué pedido, con qué proveedor y tras cuántos reintentos. Eso es lo que reduce el MTTR de verdad, un tema que aterrizo con números en cómo Datadog reduce el MTTR en equipos SRE.

Cómo instrumentar microservicios sin volverte loco

OpenTelemetry tiene tres piezas que conviene no confundir. En la práctica, esta separación es justo lo que te da la libertad de cambiar de proveedor después:

• API: las interfaces con las que tu código genera spans y métricas. Es lo único que “toca” tu aplicación.
• SDK: la implementación que recolecta, procesa y muestrea esos datos.
• Collector: un intermediario que recibe la telemetría y la reenvía a uno o varios backends (Datadog, Splunk, Grafana, lo que sea).

Y tienes tres caminos para instrumentar, con distinto costo y esfuerzo:

El corazón de todo: el pipeline del Collector

El Collector es donde se gana o se pierde la batalla del costo. Ahí decides qué telemetría entra, cómo la muestreas y a dónde la mandas, todo sin tocar el código de tus servicios. Este es un pipeline mínimo y realista para el checkout de arriba: recibe por OTLP, aplica un muestreo por probabilidad y exporta a un backend OTLP.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  # Muestrea el 20% de las trazas para controlar volumen y factura
  probabilistic_sampler:
    sampling_percentage: 20
  # Agrupa spans en lotes antes de exportar (menos llamadas de red)
  batch:
    timeout: 5s
    send_batch_size: 1024

exporters:
  otlp/backend:
    endpoint: colector.tu-backend.com:4317
    tls:
      insecure: false

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [probabilistic_sampler, batch]
      exporters: [otlp/backend]

Un matiz que aprendí a golpes: el muestreo probabilístico es fácil, pero ciego. Descarta el 80% sin mirar qué descarta. Para producción crítica conviene el tail sampling, que decide después de ver la traza completa y así te garantiza quedarte con las que tienen errores o latencia alta. Empieza simple con probabilístico, migra a tail cuando el volumen y la factura lo pidan.

La otra pieza clave del Collector es que puedes tener varios exporters a la vez. En una migración real de managed services, esto te deja mandar la misma telemetría a tu backend viejo y al nuevo en paralelo durante semanas, comparar, y cortar el viejo sin drama ni ventana de riesgo. Eso es exactamente lo que discuto al comparar arquitecturas en observabilidad en la nube vs. on-premise.

La novedad de 2026 que vale la pena vigilar aquí es OBI (OpenTelemetry eBPF Instrumentation, sucesor de Grafana Beyla), hoy en beta según el blog oficial de OpenTelemetry sobre los objetivos de OBI. En paralelo avanza OpenTelemetry Profiles, la cuarta señal (perfilado continuo) que ya está en fase alpha, con un agente eBPF donado por Elastic. Ambos prometen observabilidad sin tocar el código, algo especialmente valioso en empresas latinoamericanas con mucho software heredado que nadie quiere arriesgarse a modificar.

El error que veo siempre: cardinalidad y factura

Aquí es donde muchos equipos tropiezan. Cada etiqueta única que agregas a un span (un user_id, un session_id) multiplica las combinaciones que tu backend debe indexar. A eso se le llama alta cardinalidad, y es el motor silencioso detrás de las facturas de observabilidad que se disparan.

Estandarizar con OpenTelemetry te da algo que ningún agente propietario te da: la palanca de negociación. Si tu telemetría es portátil, el proveedor lo sabe.

Vuelve al span de pagos del ejemplo. Un atributo como checkout.id es oro para depurar un pedido concreto, pero si lo indexas como métrica con millones de valores únicos, tu costo explota. La regla que uso: atributos de alta cardinalidad viven en las trazas (donde son baratos y útiles), nunca como dimensiones de métricas agregadas. Confundir esos dos mundos es el clásico “bill shock” de fin de mes.

Precisamente por esto OTel es la mejor defensa contra la factura fuera de control. El muestreo (sampling) y el Collector te dejan decidir qué mandas y a dónde, en vez de pagarle a un vendor por cada byte que generas. La instrumentación es tuya, portátil y estándar; el backend es una decisión que puedes revisar cada año.

Preguntas frecuentes

¿OpenTelemetry reemplaza a Datadog o Splunk?

No. OpenTelemetry es el estándar para generar y transportar la telemetría; Datadog, Splunk o Grafana son los backends donde la almacenas y visualizas. De hecho, todos ellos ya aceptan datos en formato OTel. La gracia es que puedes cambiar de backend sin re-instrumentar tu código.

¿Sirve OpenTelemetry si no uso microservicios?

Sí. Aunque brilla en sistemas distribuidos, también instrumenta monolitos y te da métricas, logs y trazas bajo un mismo estándar. La inversión se paga sola el día que decides dividir ese monolito.

¿Qué es eso de que OpenTelemetry “graduó”?

Es el nivel máximo de madurez dentro de la CNCF (la fundación detrás de Kubernetes). Graduar significa que el proyecto es estable, tiene gobernanza sólida y adopción masiva: una señal fuerte para adoptarlo sin miedo, según la propia CNCF.

¿Cómo evito que la factura de trazas se dispare?

Con dos palancas del Collector: muestreo (empieza con probabilístico, migra a tail sampling) y disciplina de cardinalidad. Los atributos de alta cardinalidad (IDs de usuario o pedido) van en trazas, no como dimensiones de métricas. Así conservas el detalle útil sin pagar por indexar millones de combinaciones.

✍️ Creado por Ethel Méndez — Senior Product Manager en observabilidad, 20+ años entre NOC, managed services y producto B2B para LATAM.

Imagen destacada generada con inteligencia artificial.