Los traces distribuidos son el cuarto tipo de dato en telemetría y te permiten reconstruir, paso a paso, qué ocurre dentro de un sistema cuando una transacción atraviesa múltiples componentes. Si trabajas en DevOps, observabilidad o monitoreo de aplicaciones, entender este concepto te ayuda a encontrar cuellos de botella que un evento aislado nunca te mostraría.

Qué son los traces y por qué se llaman distribuidos

En DevOps, cuando alguien menciona traces casi siempre se refiere a distributed traces, porque ocurren a través de varios componentes de tu sistema al mismo tiempo [0:18].

Piensa en cuando pierdes el celular y rehaces tus pasos: pasaste por el baño, la cocina, la sala y tu cuarto. Un trace funciona igual, pero dentro de una aplicación. Conecta cadenas de eventos entre el carrito de compras, la pasarela de pagos y cualquier otro componente involucrado.

Al igual que los eventos y los logs, los traces son discretos e irregulares: no sabes cuándo van a ocurrir, solo sabes que debes guardarlos cuando pasen.

¿Qué es un trace distribuido? Es un registro que sigue una transacción a través de múltiples componentes de un sistema, mostrando cada paso y cuánto tardó.

Por qué un evento no basta para encontrar el problema

Imagina una máquina expendedora que acepta efectivo y tarjeta de crédito. Para procesar un pago con tarjeta ocurren varios pasos [1:30]:

• La máquina recibe el input del usuario.
• El backend contacta al procesador de tarjetas, como Visa o Mastercard.
• El procesador contacta al banco emisor para validar el cupo.
• La respuesta regresa por el mismo camino en reversa.

Si registras solo el evento, verás algo como credit card purchase event con una duración de 23 segundos [2:11]. Sabes que algo va lento, pero no sabes dónde. El evento no te dice cuánto tardó contactar al banco ni cuánto demoró el procesador. El problema está ahí, escondido.

Cómo los traces resuelven esa ceguera

Los traces unen los eventos especiales en una cadena a lo largo del sistema. Cada servicio pasa un identificador llamado correlation ID, que viaja como metadata en forma de atributo dentro del evento [3:05].

Ese identificador enlaza todas las piezas, sin importar que vivan en componentes distintos. Así, en lugar de ver un bloque opaco de 23 segundos, descompones la transacción paso por paso:

• Procesador de tarjeta: 5 segundos.
• Banco emisor: 3 segundos.
• Backend de la máquina expendedora: 15 segundos.

Ahí está el culpable. El backend propio, no el banco ni la red de tarjetas. Y esa es la diferencia entre adivinar y observar con datos.

Cómo se estructura un trace por dentro

Un trace se apoya en varios atributos que aparecen en la tabla de telemetría: el event type es el span, y lo acompañan el trace ID, el span ID, el parent ID y los servicios involucrados [4:18].

De todos esos campos, hay uno que manda: el trace ID. Es la pieza que une todo el rastro y permite que exista como una sola historia coherente. Plataformas como New Relic se encargan de generarlo y manejarlo por ti, así que no necesitas construirlo a mano.

¿Qué es un span en un trace? Es una espera de tiempo durante la que ocurre una acción específica dentro de la transacción, como contactar al banco o validar el pago.

La analogía de Hansel y Gretel para entender el span

Un span es como una migaja de pan. Hansel y Gretel iban dejando migajas para regresar por el bosque; tus servicios van dejando spans para que puedas reconstruir qué ocurrió dentro de tu sistema [5:32].

Cada span representa un paso, y el conjunto de spans, unidos por el mismo trace ID, te da el mapa completo. Esa es la base de la observabilidad: no solo saber que algo falló, sino poder rastrear exactamente dónde y por qué.

¿Has tenido que depurar una transacción lenta sin saber qué componente la estaba ralentizando? Cuéntame en los comentarios cómo lo resolviste.