Distributed Tracing

Uber запрос от пользователя проходит через 20+ микросервисов за 500ms. Когда запрос занимает 3 секунды, как найти где потеряно 2.5 секунды? До Jaeger - часы сравнения логов из разных сервисов. После - 10 секунд в UI: открыть медленный трейс, найти самый длинный span, открыть тикет в команду этого сервиса.

• **Shopify** использует OpenTelemetry для трейсинга платёжных транзакций через 30+ микросервисов - tail-based sampling гарантирует 100% сохранение каждого failed payment независимо от общего sampling rate
• **Twitter/X** интегрировал distributed tracing в свой ad serving pipeline - удалось обнаружить что 15% задержки было в одном legacy сервисе, который никто не подозревал, просто наблюдая aggregate метрики
• **Datadog APM** использует OTel SDK как основу своей инструментации - пользователи могут перейти с Datadog на другой backend без изменения кода приложения

Jaeger

Jaeger - open-source система distributed tracing, разработанная Uber. Собирает трейсы (записи о прохождении запроса через сервисы), хранит их (Elasticsearch, Cassandra или BadgerDB) и визуализирует в UI. Позволяет видеть полный путь запроса: frontend → API Gateway → Order Service → Payment Service → Database, с точными временными метками каждого шага.

Jaeger UI показывает waterfall-диаграмму вызовов: сразу видно где задержка - в сети, в БД или в бизнес-логике. Ключевые метрики: total duration, longest span, spans count. Поиск трейсов по service, operation, tag (`http.status_code=500`), duration (>1s). В production рекомендуют sampling 1-10% для баланса между покрытием и нагрузкой.

OpenTelemetry

OpenTelemetry (OTel) - CNCF-стандарт для сбора traces, metrics и logs из приложений. Единый SDK, который работает с любым backend: Jaeger, Zipkin, Datadog, Honeycomb, AWS X-Ray. Раньше переход с Jaeger на Datadog требовал переписать инструментацию; с OTel - меняется только экспортёр.

OTel Collector - агент/gateway, который принимает телеметрию (OTLP протокол), трансформирует и отправляет в несколько backend одновременно. Типичная схема: сервисы → OTel Collector (DaemonSet) → Jaeger (traces) + Prometheus (metrics) + Elasticsearch (logs). Collector также делает sampling, фильтрацию и обогащение данных.

Trace Context Propagation

Trace context propagation - механизм передачи trace_id и span_id между сервисами через HTTP заголовки. W3C Trace Context (`traceparent`, `tracestate`) - стандартный формат. Без propagation каждый сервис создаёт отдельный несвязанный трейс - нет возможности увидеть полный путь запроса.

Заголовок traceparent: `00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01`. Части: version (00) - trace-id (128 бит) - parent-span-id (64 бит) - flags (01 = sampled). OTel SDK автоматически читает и пишет эти заголовки при HTTP вызовах через авто-инструментацию.

Spans и Sampling

Span - единица работы внутри трейса: HTTP запрос, SQL запрос, Redis call, внешний API вызов. Каждый span имеет: name, start/end timestamp, attributes (key-value), status (OK/ERROR), events (лог-сообщения с timestamp). Дерево spans составляет трейс - иерархическое отображение работы системы.

Sampling (выборка) - ключевое решение в production: записывать 100% трейсов нереалистично при высоком RPS. Head-based sampling (решение до начала трейса): 1% random. Tail-based sampling (решение в OTel Collector после завершения трейса): всегда записывать трейсы с ошибками или latency > 1s, остальные - 1%. Tail-based умнее но требует больше памяти в Collector.

Ключевые идеи

• **Jaeger** хранит и визуализирует трейсы - waterfall-диаграмма показывает где именно теряется время в цепочке микросервисов
• **OpenTelemetry** - vendor-neutral стандарт: одна инструментация, любой backend; авто-инструментация HTTP/SQL/Express без написания кода
• **Trace Context + Tail Sampling** - propagation через traceparent заголовок связывает сервисы; tail-based sampling в OTel Collector гарантирует сохранение ошибок при 1% выборке

Связанные темы

Distributed tracing - один из трёх столпов observability:

• ELK Stack и логирование — trace.id в структурированных логах ELK связывает лог-записи с spans в Jaeger
• Service Mesh: Istio, Linkerd — Istio автоматически генерирует spans для каждого межсервисного вызова и propagate context через Envoy

Вопросы для размышления

• При каком RPS и сложности системы distributed tracing начинает окупаться по сравнению с traditional logging?
• Как tail-based sampling влияет на точность p99 latency метрик в Jaeger?
• Если БД является bottleneck по трейсам - какие действия следуют из этой информации?

Связанные уроки

• dist-05-vector-clocks
• dist-06-ordering