Los logs y las métricas (subcapítulos 24.1 y 24.2) están muy bien cuando tu aplicación es una sola pieza. Pero las arquitecturas modernas se componen de muchos servicios que colaboran: una petición pasa por un balanceador, luego por una Lambda, que llama a otra, que consulta una base de datos, que escribe en una cola... Cuando algo va lento o falla, ¿en qué parte del recorrido está el problema? Para responder a eso existe el trazado distribuido, y en AWS la herramienta es X-Ray.

Recuerda los microservicios y las arquitecturas desacopladas que hemos visto (Lambda en el Capítulo 14, mensajería en el 15, contenedores en el 17). Una sola petición de un usuario puede recorrer muchos componentes:

Si esa petición tarda 5 segundos (demasiado), ¿dónde está la lentitud? ¿En Lambda A? ¿En la base de datos? ¿En Lambda B? Con logs sueltos de cada servicio es muy difícil reconstruir el viaje completo y ver dónde se pierde el tiempo. Necesitas seguir el rastro de esa petición concreta a través de todo el sistema.

El trazado distribuido (distributed tracing) consiste en seguir una petición a lo largo de todos los servicios por los que pasa, midiendo cuánto tarda en cada uno. El resultado es una traza: el mapa completo del viaje de esa petición, con los tiempos de cada etapa.

Analogía: el trazado distribuido es como el seguimiento de un paquete que envías por mensajería. No solo sabes que tardó 3 días: ves cada etapa del recorrido —«recogido en origen (1h), en el centro logístico A (2 días ⚠️), en reparto (3h), entregado»— y descubres exactamente dónde se quedó atascado. Sin ese seguimiento, solo sabrías que tardó mucho, sin saber por qué.

AWS X-Ray es el servicio de trazado distribuido de AWS. Sigue las peticiones a través de tus servicios (Lambda, API Gateway, ECS, etc.) y te muestra:

• Un mapa de servicios: un diagrama visual de cómo se conectan tus componentes y cómo fluyen las peticiones entre ellos.
• Las trazas detalladas: el viaje de cada petición, con el tiempo que pasó en cada servicio.
• Dónde están los cuellos de botella y los errores: qué parte es lenta o falla.

X-Ray colorea y marca los servicios según su salud (verde = bien, rojo = problemas), así que de un vistazo ves dónde mirar.

• Encontrar cuellos de botella: ver exactamente qué servicio hace que una petición sea lenta (como la base de datos del ejemplo).
• Localizar errores: ver en qué punto del recorrido se produce un fallo.
• Entender tu arquitectura: el mapa de servicios muestra cómo se conectan realmente tus componentes (a veces sorprende ver dependencias que no recordabas).
• Optimizar el rendimiento: medir y mejorar las partes lentas con datos concretos, no a ojo.

Ejemplo del mundo real: una aplicación de reservas se queja de que «la página de confirmación tarda mucho». El equipo activa X-Ray. La traza revela que la petición pasa por cuatro servicios, y que el 90 % del tiempo se va en una llamada a un servicio externo de pago que responde lento. El problema no estaba en su código, sino en una dependencia externa. Con ese dato, añaden una respuesta «en proceso» mientras el pago se confirma en segundo plano, y la página vuelve a ser rápida. Sin X-Ray, habrían perdido días buscando el problema en el sitio equivocado.

Los tres se complementan y responden preguntas distintas:

Métricas, logs y trazas son los tres pilares de la observabilidad. Las métricas te alertan de que algo va mal en general, las trazas te dicen en qué servicio del recorrido está el problema, y los logs de ese servicio te dan el detalle de la causa.

• En arquitecturas de muchos servicios, una petición recorre varios componentes, y es difícil saber dónde está un problema de lentitud o error solo con logs sueltos.
• El trazado distribuido sigue una petición a lo largo de todos los servicios por los que pasa, midiendo el tiempo en cada uno. El resultado es una traza (el mapa del viaje). Como el seguimiento de un paquete.
• AWS X-Ray es el servicio de trazado distribuido de AWS: ofrece un mapa de servicios visual, trazas detalladas con tiempos por etapa, y marca cuellos de botella y errores.
• Sirve para encontrar cuellos de botella, localizar errores, entender tu arquitectura real y optimizar el rendimiento con datos.
• Métricas (cuánto), logs (qué/detalle) y trazas (por dónde/dónde se ralentiza) son los tres pilares de la observabilidad y se complementan.

En el siguiente subcapítulo veremos un estándar abierto que unifica logs, métricas y trazas sin atarte a un proveedor: OpenTelemetry.