Транспорт бэкенда

Distributed Tracing и Observability

Uber 2017: P99 latency checkout вырос на 20%. 100 инженеров смотрят в логи. Без distributed tracing поиск занял 3 дня. После внедрения Jaeger аналогичный инцидент был диагностирован за 20 минут: один из 7 upstream сервисов начал медленно отвечать из-за новой неудачной DB индексации.

  • **Uber** разработал Jaeger (2016) и open-source'ил его. Сейчас Jaeger - CNCF graduated проект, используется в тысячах компаний.
  • **Shopify** использует OpenTelemetry для трейсинга всех Ruby on Rails запросов. Spans автоматически создаются для каждого ActiveRecord запроса и HTTP вызова.
  • **Cloudflare** публикует распределённый трейсинг через Workers Tracing API - каждый Edge Worker участвует в trace цепочке.

Зачем distributed tracing

В монолите медленный запрос виден в profiler. В микросервисах запрос проходит через 5-10 сервисов - где потеряна задержка? Logs не дают ответ без корреляции. Distributed tracing отслеживает весь путь запроса: от API Gateway до БД, с временными метками каждого шага.

Netflix: в их микросервисной архитектуре средний запрос проходит через 6+ сервисов. Без distributed tracing поиск bottleneck занимал часы. С Zipkin/Jaeger - минуты.

Почему логи сами по себе недостаточны для диагностики медленных запросов в микросервисах?

OpenTelemetry: стандарт наблюдаемости

OpenTelemetry (OTel) - CNCF стандарт для traces, metrics и logs. Заменяет разрозненные SDK (Jaeger client, Zipkin client, Prometheus client). Одна инструментация -> любой backend (Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic).

Auto-instrumentation OTel автоматически создаёт spans для: HTTP запросов (express, koa, fastify), DB запросов (pg, mysql2, mongoose), очередей (kafka-node, amqplib), Redis. Не нужно менять существующий код для базовой трассировки.

Преимущество OpenTelemetry перед vendor-specific SDK (Datadog agent, New Relic agent):

Spans и Context Propagation

Span - единица работы с временными метками: start, end, attributes, events, status. Trace = дерево spans. Context propagation передаёт trace ID между сервисами через HTTP заголовки (W3C TraceContext стандарт: traceparent, tracestate).

Baggage - механизм передачи кастомных данных через все сервисы в trace: user ID, tenant ID, feature flag. Доступен в любом span без явной передачи через параметры функций. OTel Baggage соответствует W3C Baggage спецификации.

Как trace ID сохраняется при переходе от Order Service к Payment Service?

Jaeger и Zipkin

Jaeger (Uber, 2016) и Zipkin (Twitter, 2012) - системы хранения и визуализации distributed traces. Оба принимают spans через OTel collector. Jaeger более популярен в Kubernetes окружении, Zipkin - проще в setup.

Grafana Tempo (2020) - бесплатное хранилище traces совместимое с Jaeger API. Хранит traces в object storage (S3, GCS) - дёшево для больших объёмов. Интегрируется с Loki (logs) и Prometheus (metrics) в Grafana для корреляции.

Почему важно коррелировать traces с logs и metrics в одном инструменте?

Метрики транспорта

Ключевые метрики для мониторинга транспортного слоя: RED метод (Rate, Errors, Duration) для сервисов, USE метод (Utilization, Saturation, Errors) для ресурсов. Prometheus + Grafana - стандарт для сбора и визуализации.

Google SRE Four Golden Signals: Latency (P99), Traffic (req/s), Errors (error rate), Saturation (utilization). RED метод - упрощение Golden Signals. Начинать monitoring с этих 4 сигналов для каждого сервиса.

Distributed tracing заменяет логи и метрики

Трейсы, метрики и логи - три разных и взаимодополняющих столпа observability. Каждый нужен.

Метрики: aggregate view (error rate 0.5%). Трейсы: конкретный медленный запрос и его путь. Логи: детали конкретной ошибки. Диагностика: metric alert -> найти trace -> прочитать log. Без одного из трёх - пазл неполный.

Kafka consumer lag резко вырос с 1K до 500K за последние 10 минут. Что это означает?

Итоги

  • **Distributed tracing** решает фундаментальную проблему микросервисов: корреляция запроса через несколько сервисов. Без trace ID логи несвязанны.
  • **OpenTelemetry** - стандарт: одна инструментация, любой backend. Auto-instrumentation покрывает HTTP, DB, Kafka без изменений кода.
  • **Три столпа**: metrics (aggregate health), traces (specific request path), logs (detailed events). Корреляция в Grafana: metric -> trace -> log.

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

Observability применяется к всем транспортным протоколам и паттернам:

  • API Gateway — API Gateway генерирует первый span и request ID - начало distributed trace через все downstream сервисы
  • Отладка транспорта — Когда трейсы показывают проблему на сетевом уровне - tcpdump и Wireshark помогают исследовать глубже

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

  • Как реализовать sampling трейсов (не трейсить 100% запросов) не теряя важные ошибки и медленные запросы?
  • Как distributed tracing помогает при post-mortem анализе инцидента, произошедшего 3 дня назад?
  • Когда overhead distributed tracing (CPU, сеть, хранилище) становится неприемлемым?

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

  • devops-14
Distributed Tracing и Observability

0

1

Войти