Saltar al contenido
Explorar conocimiento
Portafolio

concepto · intermedio · 2 min de lectura

Distributed Tracing

El tracing distribuido sigue un request a través de múltiples servicios, registrando cada salto con su duración, permitiendo identificar cuellos de botella en arquitecturas complejas.

No requiere conocimientos previos.

Alcance en breve

Cubre

  • Tracing as a concept

No cubre

  • implementation details

Supone

  • The reader understands relevant fundamentals.

Resumen

En un monolito, un request es un solo proceso: fácil de medir. En microservicios, un request puede tocar 10 servicios distintos. Si un usuario reporta que "la página carga lento", ¿cuál de los 10 servicios es el responsable? El tracing distribuido responde esa pregunta.

Cada request entrante genera un trace ID único que se propaga entre servicios. Cada servicio agrega spans —segmentos con nombre, duración y metadatos—. El trace completo muestra el waterfall: qué servicios se llamaron, en qué orden, cuánto tardó cada uno y dónde está el cuello de botella.

Alcance y supuestos

Cubre distributed tracing, el modelo de traces y spans, y herramientas. Asume familiaridad con microservicios.

Modelo mental

El tracking de un paquete de correo. El paquete pasa por 5 centros de distribución. El tracking number te muestra exactamente en qué centro está, cuándo llegó y cuándo salió. Si el paquete se demora, sabés en qué centro se quedó trabado.

Uso práctico

  • ✅ Microservicios, debugging de latencia, optimización de caminos críticos.
  • ❌ Monolitos: el tracing intra-proceso alcanza con profiling.

Ejemplo trabajado: trace de una compra

GET /checkout → auth service (5ms) → cart service (12ms) → payment service (450ms) → notification service (8ms). El trace muestra que el payment service es el cuello de botella.

Evidencia

  • OpenTelemetry es el estándar. Jaeger y Zipkin fueron los pioneros. Datadog APM y Grafana Tempo son opciones comerciales.

Fuentes citadas