Hace quince años, depurar una aplicación lenta era relativamente directo. Había un servidor web, una base de datos, quizá un par de cachés. Si algo iba mal, los registros y las métricas bastaban para encontrar el culpable. La arquitectura era vertical: todo vivía en el mismo lugar o muy cerca.
Hoy esa simplicidad es un recuerdo lejano. Una petición típica en una arquitectura de microservicios puede pasar por una pasarela, un servicio de autenticación, tres o cuatro servicios de negocio, un par de bases de datos diferentes, una cola de mensajes y un servicio externo de terceros. Cada salto añade latencia. Cada componente puede fallar de formas distintas. Y cuando algo va mal, los registros individuales de cada servicio cuentan solo una parte de la historia.
El rastreo distribuido reconstruye esa historia completa. Asigna un identificador único a cada petición entrante y lo propaga a través de todos los servicios que intervienen. Cada servicio registra qué hizo, cuánto tardó y a quién llamó después. Al final, todas esas piezas se ensamblan en una traza: una representación visual del recorrido completo de la petición, con tiempos, errores y dependencias.
No se trata solo de encontrar problemas. También sirve para entender el comportamiento real del sistema: qué servicios son críticos, dónde están los cuellos de botella habituales, qué optimizaciones tendrían impacto real. Es la diferencia entre tener un mapa del territorio y caminar a ciegas.
Un poco de historia: de dónde viene todo esto
El rastreo distribuido no es una invención reciente ni es propiedad de ningún fabricante concreto. Su origen se remonta a 2010, cuando Google publicó el artículo académico sobre Dapper, su sistema interno de rastreo. Ese documento describía cómo seguir el recorrido de una petición a través de un sistema distribuido masivo, y sentó las bases de prácticamente todas las herramientas de rastreo que existen hoy.
Dos años después, en 2012, Twitter publicó como código abierto Zipkin, inspirado directamente en Dapper. Fue el primer proyecto de rastreo distribuido de código abierto. En 2015, Uber lanzó Jaeger (palabra alemana que significa «cazador»), también inspirado en Dapper pero con un enfoque más modular y preparado para escalar. Jaeger se convirtió en un proyecto graduado de la Cloud Native Computing Foundation (CNCF) y sigue siendo una de las referencias del sector.
La lección importante aquí es que el rastreo distribuido es una técnica, no un producto. No pertenece a Dynatrace, ni a Datadog, ni a ningún fabricante concreto. Es un concepto que se implementa con diferentes herramientas, tanto de código abierto como comerciales. Dynatrace lo incorpora como parte de su plataforma de rendimiento de aplicaciones, igual que lo hacen Datadog, New Relic, Honeycomb o Elastic. Pero también se puede montar una solución completa con herramientas de código abierto como Jaeger o Grafana Tempo sin gastar un euro en licencias (aunque sí en infraestructura y tiempo de gestión, claro).
Cómo funciona sin entrar en detalles de implementación
La idea central es sencilla: cada petición recibe un identificador de traza cuando entra al sistema. Ese identificador viaja en las cabeceras de las llamadas entre servicios. Cada servicio que participa genera tramos (spans), fragmentos de la traza que representan una operación concreta: una consulta a base de datos, una llamada a otro servicio, un cálculo interno.
Los tramos se organizan jerárquicamente. El tramo raíz representa la petición completa. Los tramos hijos representan las operaciones que se ejecutan dentro de ella. Si un servicio llama a otros dos en paralelo, esos dos servicios generan tramos hermanos. Si uno de esos servicios llama a su vez a un tercero, ese tercer tramo es hijo del anterior.
Toda esa información se envía a un componente de almacenamiento que la indexa y permite consultarla. Cuando algo va mal, se busca la traza problemática y se analiza: qué tramos tardaron más de lo esperado, dónde aparecieron errores, qué dependencias estaban involucradas.
La parte complicada no es el concepto, sino la instrumentación. Hay que modificar el código para que genere tramos, o usar bibliotecas que lo hagan automáticamente. Hay que asegurarse de que el identificador de traza se propaga correctamente en todas las llamadas. Y hay que lidiar con el coste: generar y almacenar trazas consume recursos, especialmente en sistemas con mucho tráfico.
OpenTelemetry: el estándar que unifica la instrumentación
Hasta hace pocos años, cada herramienta de rastreo tenía su propia forma de instrumentar aplicaciones. Si usabas Jaeger, instrumentabas con las bibliotecas de Jaeger. Si usabas Zipkin, con las de Zipkin. Cambiar de herramienta significaba reescribir la instrumentación.
OpenTelemetry (OTel) resolvió ese problema. Es un proyecto de código abierto mantenido por la CNCF que proporciona un conjunto unificado de API, bibliotecas y agentes para generar trazas, métricas y registros. La idea es instrumentar una sola vez y poder exportar los datos de telemetría a cualquier sistema compatible: Jaeger, Tempo, Datadog, Dynatrace, Honeycomb o el que prefieras.
En 2026, OpenTelemetry es el estándar de facto para la instrumentación de aplicaciones en la nube. Tiene soporte para prácticamente todos los lenguajes y entornos de ejecución habituales, y la mayoría de fabricantes —tanto de código abierto como comerciales— lo soportan de forma nativa. Si hoy estás empezando a instrumentar tus servicios, OpenTelemetry es la elección obvia: instrumentas una vez y te quitas de encima la dependencia con un fabricante concreto.
Cuándo tiene sentido y cuándo es excesivo
El rastreo distribuido no es gratis. Instrumentar servicios lleva tiempo. Almacenar trazas consume espacio. Analizarlas requiere aprender nuevas herramientas. Y en sistemas pequeños o monolíticos, el retorno de esa inversión puede ser cuestionable.
Si la aplicación corre en un solo proceso o en un puñado de servidores con dependencias claras, los registros estructurados y las métricas tradicionales suelen bastar. El rastreo distribuido brilla cuando la complejidad crece: cuando hay más de cinco o seis servicios interactuando, cuando las dependencias no son obvias, cuando los problemas de latencia son difíciles de localizar con métricas agregadas.
También importa el tipo de problema que se quiere resolver. Si el objetivo es detectar caídas de servicios, las métricas y las comprobaciones de salud son suficientes. Pero si lo que se busca es entender por qué una petición concreta tardó tres segundos cuando debería haber tardado trescientos milisegundos, el rastreo es la herramienta adecuada.
Hay otra consideración práctica: el volumen de tráfico. En sistemas con millones de peticiones por segundo, almacenar todas las trazas es inviable. La solución habitual es el muestreo: solo se captura un porcentaje de las trazas, suficiente para tener visibilidad estadística sin ahogarse en datos. Eso implica aceptar que no todas las peticiones problemáticas quedarán registradas, pero en la práctica suele ser un equilibrio razonable.
Sobre el muestreo hay un matiz que merece la pena conocer: existen dos estrategias principales. El muestreo por cabecera (head-based sampling) decide al inicio de la petición si se va a rastrear o no, lo cual es sencillo pero tiene el inconveniente de que puede descartar trazas que luego resultan ser interesantes (por ejemplo, peticiones que acaban en error). El muestreo por cola (tail-based sampling) espera a que la traza esté completa antes de decidir si la conserva, lo que permite guardar selectivamente las trazas con errores o latencias altas, pero a costa de mayor complejidad y consumo de recursos en el colector.
El panorama de herramientas en 2026
Una de las dudas más frecuentes es qué herramienta elegir. El ecosistema se divide básicamente en dos grandes grupos: soluciones de código abierto autoalojadas y plataformas comerciales de tipo SaaS.
Herramientas de código abierto:
- Jaeger: creado originalmente por Uber, es probablemente la referencia en rastreo de código abierto. Ofrece una interfaz web para buscar y visualizar trazas, soporta múltiples sistemas de almacenamiento (Elasticsearch, Cassandra, Kafka) y tiene soporte nativo de OpenTelemetry. La contrapartida es que requiere gestionar la infraestructura: desplegar, escalar y mantener los componentes. Es la opción recomendada para quien empieza con rastreo distribuido y quiere control total.
- Grafana Tempo: un sistema de almacenamiento de trazas pensado para integrarse con el ecosistema Grafana (Loki para registros, Mimir/Prometheus para métricas). Su ventaja principal es que solo necesita almacenamiento de objetos (S3, GCS, Azure Blob), lo que reduce costes significativamente. Incorpora TraceQL, un lenguaje de consulta propio inspirado en PromQL y LogQL. La desventaja: no tiene interfaz propia y depende de Grafana para la visualización.
- Zipkin: el veterano. Sigue siendo funcional y es el más sencillo de desplegar (puede ejecutarse como un único binario), pero su desarrollo ha perdido ritmo frente a Jaeger y Tempo. Buena opción para aprender los conceptos o para entornos muy pequeños.
Plataformas comerciales:
- Datadog APM: plataforma integral que conecta trazas con registros, métricas, infraestructura y monitorización de usuarios. Muy potente y cómoda, pero con un modelo de precios que puede escalar rápidamente y sorprender si no se vigila.
- Dynatrace: destaca por su automatización y análisis con inteligencia artificial para identificar causas raíz. Muy orientada a grandes empresas con poca capacidad de gestión manual. La instrumentación automática mediante agentes simplifica la adopción, pero genera dependencia del fabricante.
- Honeycomb: toma un enfoque diferente, tratando cada tramo como un evento en un almacenamiento columnar de alta cardinalidad. Excelente para depuración exploratoria y preguntas del tipo «¿por qué esta clase de peticiones se comporta diferente?». Requiere invertir en una instrumentación rica para sacarle partido.
- New Relic, Elastic APM, SigNoz (este último de código abierto con opción gestionada): otras alternativas que cubren distintos puntos del espectro coste-funcionalidad.
La elección depende del contexto: presupuesto, tamaño del equipo, complejidad de la arquitectura y si ya se tiene un ecosistema de observabilidad establecido. Lo que sí es universal es que cualquier herramienta moderna debería soportar OpenTelemetry, para evitar quedar atado a un fabricante concreto.
Errores habituales y cómo evitarlos
El primer error es instrumentar demasiado tarde. Añadir rastreo a un sistema en producción con docenas de servicios ya desplegados es un proyecto de meses. Lo ideal es incorporarlo desde el principio, cuando la arquitectura todavía es manejable y los equipos están definiendo estándares de desarrollo.
El segundo error es instrumentar demasiado poco. Generar un tramo por petición HTTP está bien, pero si no se capturan las operaciones internas importantes (consultas a base de datos, llamadas a cachés, procesamiento pesado), la traza cuenta solo la mitad de la historia. La tentación de instrumentar lo mínimo para salir del paso es grande, pero el valor real aparece cuando la granularidad es suficiente para identificar problemas específicos.
El tercer error es ignorar el contexto. Una traza muestra qué pasó, pero no siempre explica por qué. Si un tramo tarda mucho, ¿es porque el servicio está sobrecargado, porque la consulta era compleja, porque había contención en la base de datos? Sin atributos adicionales en los tramos (identificadores de usuario, tamaños de respuesta, códigos de error), interpretar las trazas se convierte en un ejercicio de adivinación.
El cuarto error es tratar el rastreo como una solución aislada. El rastreo es más potente cuando se combina con registros y métricas. Una traza identifica el servicio problemático, los registros de ese servicio explican qué falló, y las métricas muestran si es un problema puntual o una tendencia. Las tres patas de la observabilidad se complementan; ninguna es suficiente por sí sola.
Y el quinto, que suele pasar desapercibido: no formar al equipo. De nada sirve tener la mejor instrumentación del mundo si nadie sabe leer una traza ni entiende cuándo recurrir al rastreo en lugar de a los registros. La inversión en formación es tan importante como la inversión en herramientas.
El coste oculto de no tener visibilidad
Hay equipos que posponen la adopción del rastreo porque parece un lujo, algo que se puede añadir más adelante cuando haya tiempo. Esa decisión tiene un coste que no siempre se contabiliza: las horas perdidas investigando incidentes sin las herramientas adecuadas, los problemas de rendimiento que pasan desapercibidos hasta que los usuarios se quejan, las optimizaciones que nunca se hacen porque no está claro dónde aplicarlas.
En sistemas complejos, la falta de visibilidad no es solo un inconveniente técnico. Afecta a la velocidad de desarrollo, a la confianza en los despliegues y a la capacidad de escalar. Cuando nadie sabe con certeza cómo se comporta el sistema bajo carga, cada cambio es un salto al vacío.
El rastreo distribuido no resuelve todos los problemas de observabilidad, pero resuelve uno especialmente difícil: entender qué ocurre cuando una petición atraviesa un sistema distribuido. Y en un mundo donde casi todo es distribuido, esa capacidad deja de ser opcional.
Para seguir aprendiendo
- «Distributed Systems Observability» de Cindy Sridharan (O’Reilly, 2018): un libro electrónico breve (unas 36 páginas) pero denso, con una introducción práctica a los pilares de la observabilidad. Se distribuía como descarga gratuita a través de Humio, pero ese enlace ya no funciona (CrowdStrike adquirió Humio y el PDF dejó de estar disponible). Se puede acceder con suscripción a O’Reilly o buscando en Goodreads referencias y resúmenes. Enlace en O’Reilly: https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ — Enlace en Goodreads: https://www.goodreads.com/book/show/40182805-distributed-systems-observability
- Documentación oficial de OpenTelemetry: el estándar de facto para instrumentación de aplicaciones, mantenido por la Cloud Native Computing Foundation. Incluye guías de integración para la mayoría de lenguajes y entornos. Enlace: https://opentelemetry.io/docs/
- Repositorio de Jaeger en GitHub: uno de los sistemas de rastreo más utilizados, con documentación extensa sobre arquitectura, despliegue y buenas prácticas. Enlace: https://github.com/jaegertracing/jaeger
- Documentación de Grafana Tempo: sistema de almacenamiento de trazas diseñado para integrarse con el ecosistema Grafana, con enfoque en costes reducidos y escalabilidad. Enlace: https://grafana.com/docs/tempo/latest/
- Artículo original de Google Dapper (2010): el documento académico que inició todo esto. Lectura imprescindible para entender los fundamentos teóricos del rastreo distribuido. Enlace: https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/