Trazado: qué es, principios y recopilación de datos

Qué es el trazado en monitorización

El trazado es un método de observación distribuida donde cada solicitud entrante se rastrea a través de todos los servicios y componentes del sistema. A diferencia de las métricas, que muestran valores agregados (tiempo medio de respuesta, número de errores), el trazado conserva el contexto completo de una solicitud específica.

Cada paso de procesamiento — una llamada a la base de datos, una solicitud HTTP a otro microservicio, la ejecución de una tarea en segundo plano — se registra como una unidad separada con marca de tiempo, estado y atributos. Según Google Dapper (publicación original de 2010), el trazado permite localizar retrasos en sistemas distribuidos con precisión a nivel de una sola llamada.

El trazado es especialmente importante para aplicaciones móviles donde el backend consta de docenas de microservicios. Una acción del usuario — como iniciar sesión en una cuenta — puede pasar a través de API Gateway, servicio de autenticación, base de datos y servicio Push. Sin trazado, determinar qué componente está ralentizando la respuesta es prácticamente imposible.

Spans y traces: estructura básica de datos

La unidad básica de trazado es un span. Cada span representa una operación lógica: una solicitud HTTP, una consulta SQL, una llamada gRPC, una serialización JSON. Un span contiene un identificador único, identificador padre, nombre de la operación, hora de inicio, duración, estado y un conjunto de atributos.

Jerarquía de spans en un trace

Todos los spans relacionados con una misma solicitud raíz se agrupan en un trace. El span raíz representa el punto de entrada — una solicitud HTTP desde el cliente móvil a la API. Los spans hijos forman un árbol, donde cada span referencia a su padre mediante el campo parent_span_id.

La duración de un trace es igual a la suma de las duraciones de los segmentos temporales únicos de todos los spans. Si dos spans hijos se ejecutan en paralelo, su tiempo no se suma — esto es crítico para analizar correctamente los retrasos causados por llamadas paralelas a microservicios.

Atributos y eventos de span

Cada span puede contener atributos — pares clave-valor con meta-información: URL de la solicitud, ID de usuario, versión de API, nombre del host. Los atributos se utilizan para filtrar y agrupar trazas. Además de los atributos, los spans admiten eventos — marcas de tiempo con descripciones textuales, como "fallo de caché" o "reintento de conexión".

Cómo funciona el distributed tracing

Distributed tracing resuelve el problema de enlazar spans que se crean en diferentes procesos y en diferentes máquinas. El mecanismo se basa en la propagación de contexto: cuando el servicio A llama al servicio B, se añade una cabecera con el ID del trace actual y el ID del span padre a la solicitud saliente.

Los protocolos estándar de propagación de contexto son W3C Trace Context (cabeceras traceparent y tracestate) y Zipkin B3 (cabeceras X-B3-TraceId, X-B3-SpanId). W3C Trace Context fue adoptado como estándar por el consorcio W3C en 2021 y es compatible con todos los principales proveedores de telemetría.

Al recibir la solicitud, el servicio B extrae el trace_id de la cabecera y crea un span hijo con ese trace_id. Así, al completarse la solicitud, todos los spans de diferentes servicios se combinan en un solo trace en el lado del colector. Para ello, cada servicio debe estar instrumentado con la misma biblioteca de trazado.

Propagación de contexto en microservicios

En el desarrollo móvil, la propagación de contexto abarca no solo el backend sino también la interacción cliente-servidor. Una aplicación móvil puede enviar un trace_id en la cabecera de cada solicitud API, permitiendo vincular una acción del cliente con el procesamiento del servidor. El SDK de OpenTelemetry para iOS y Android admite la creación y propagación automática del contexto de trace a través de clientes HTTP.

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

El interceptor Kotlin presentado crea un span para cada solicitud HTTP al servidor. El contexto padre se propaga desde el código llamante a través de Context.current(), lo que permite vincular el trazado del cliente con el del servidor.

Implementación del trazado con OpenTelemetry

OpenTelemetry es el estándar de facto para la recopilación de datos de trazado. Proporciona una API unificada para generar spans, instrumentación automática de bibliotecas populares y un mecanismo flexible para exportar datos a varios backends: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Instrumentación automática

OpenTelemetry admite la creación automática de spans para frameworks populares: Spring Boot, Ktor, Flask, Express, gRPC. El desarrollador solo necesita añadir una dependencia al proyecto, y la biblioteca intercepta automáticamente las solicitudes entrantes y salientes. La auto-instrumentación para Java utiliza un javaagent que modifica el bytecode sobre la marcha sin cambiar el código fuente.

Para plataformas móviles, OpenTelemetry proporciona Swift SDK y Kotlin SDK. Crean automáticamente spans para solicitudes de red (URLSession, OkHttp), operaciones de base de datos (CoreData, Room) y tareas en segundo plano. El desarrollador puede añadir spans personalizados para la lógica de negocio.

Exportación de datos

Los spans recopilados se envían a un colector mediante el protocolo OTLP (OpenTelemetry Protocol). El colector puede almacenar en búfer, filtrar y redirigir datos a uno o más sistemas de almacenamiento. Según la documentación de OpenTelemetry, la latencia típica desde la generación de un span hasta su visualización en un panel es de 2 a 5 segundos cuando se utiliza exportación gRPC.

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

El código Swift activa la instrumentación automática de la capa de red y crea un span personalizado para la operación de obtención del perfil de usuario. El atributo user.id permite filtrar trazas por un usuario específico posteriormente.

Estrategias de muestreo de trazas

En sistemas de alta carga, es imposible trazar cada solicitud — esto crea una carga inaceptable en el almacenamiento y la red. El muestreo resuelve este problema guardando solo un subconjunto de trazas. La elección de la estrategia afecta directamente a la integridad de los datos y al coste de la infraestructura.

Muestreo head-based

La decisión de guardar una traza se toma en el momento de su creación — en el span raíz. El enfoque más simple y común: un porcentaje fijo de solicitudes (por ejemplo, 5%) se guarda, el resto se descarta. El inconveniente es que no se puede garantizar que los errores raros sean capturados. El Probability sampler en OpenTelemetry admite configuración de probabilidad de 0.0 a 1.0.

Muestreo tail-based

La decisión se pospone hasta que se completan todos los spans de la traza. Un analizador evalúa si la traza contiene errores, superación de tiempo o atributos interesantes, y solo entonces la guarda. Este enfoque requiere almacenar en búfer todos los spans en el colector, lo que aumenta el consumo de memoria. Según Grafana Labs, el muestreo tail-based es 40–60% más eficiente en términos de "coste por dato útil" en sistemas con errores raros pero críticos.

Diferencia entre trazado y registro

El registro (logging) registra eventos individuales con niveles de gravedad (info, warn, error) pero no los vincula en el contexto de una sola solicitud. El trazado, por el contrario, crea un árbol estructurado de operaciones pertenecientes a una solicitud de extremo a extremo. En la práctica, estos dos enfoques no son mutuamente excluyentes sino que se complementan.

Los registros son efectivos para el análisis detallado de un error específico: un desarrollador ve el mensaje exacto, el stack trace y los valores de las variables. El trazado responde a la pregunta "por qué la solicitud tarda 5 segundos" — muestra qué microservicio o llamada ocupó más tiempo. Según Honeycomb (2024), los equipos que utilizan el trazado junto con el registro encuentran la causa raíz de los incidentes 2.3 veces más rápido.

El enfoque moderno — la observabilidad — combina trazado, métricas y registros en un solo sistema. OpenTelemetry admite la correlación entre estas tres señales: cada span puede contener enlaces a registros relacionados, y las métricas pueden etiquetarse con trace_id para profundizar en trazas específicas.