Трейсинг запросов в микросервисах: как связать логи через correlation ID

Представьте ситуацию: пользователь жалуется на медленную загрузку страницы. Вы открываете дашборд мониторинга и видите только красные точки. Но где именно всё сломалось? В сервисе аутентификации? Или база данных тормозит? Или сеть между двумя контейнерами потеряла пакеты? Без трейсинга вы гадаете на кофейной гуще. А с ним - у вас есть рентген вашей системы.

Микросервисная архитектура ломает привычную модель отладки. В монолите вы просто читали лог сверху вниз. Здесь же один HTTP-запрос может пройти через десять разных сервисов, написать в три очереди сообщений и дернуть две внешние API. Если каждый сервис пишет логи сам по себе, вы получаете набор разрозненных файлов, которые невозможно сопоставить. Решение - сквозная трассировка. Это не просто модное слово из бэклога DevOps-команды, это единственный способ понять, что происходит внутри распределённой системы.

Что такое трейс и зачем он нужен

Трейс (trace) - это полная история обработки одного запроса или события во всей системе. Он состоит из спанов (spans). Спан - это единица работы, например, вызов метода, обращение к базе данных или сетевой запрос. Каждый спан имеет время начала, длительность и теги с метаданными.

Главная проблема микросервисов - потеря контекста при переходе границы сервиса. Когда сервис A вызывает сервис B, информация о том, что эти действия связаны, исчезает, если её явно не передать. Трейсинг решает эту задачу, создавая уникальный идентификатор для всего пути прохождения запроса.

Ключевые компоненты модели трассировки

• Trace ID: Уникальный глобальный идентификатор всего запроса. Он одинаков для всех сервисов, участвующих в обработке.
• Span ID: Идентификатор конкретного шага обработки внутри сервиса.
• Parent Span ID: Ссылка на предыдущий шаг. Так строится дерево зависимостей.
• Context Propagation: Механизм передачи этих ID через границы сервисов (HTTP-заголовки, метаданные gRPC, свойства сообщений).

Correlation ID: мост между логами и трейсами

Часто путают понятия «трейс» и «корреляция». Трейс показывает структуру выполнения (кто кого вызвал), а корреляция позволяет связать текстовые логи с этим треком. Здесь на сцену выходит Correlation ID.

Это уникальный токен, который генерируется на входе в систему (например, в API Gateway) и прокидывается во все последующие вызовы. Зачем он нужен, если есть Trace ID? Потому что логи часто пишутся в агрегаторах вроде ELK Stack или Loki, где поиск по сложным JSON-структурам может быть дорогим или неудобным. Correlation ID обычно добавляется в каждую строку лога как обычное поле.

Практический совет: никогда не используйте случайные UUID для каждого нового запроса, если они не связаны с исходным входящим запросом. Ваша цель - сохранить связь от браузера пользователя до самой глубокой базы данных.

Как пробрасывать контекст технически

Передача контекста зависит от протокола взаимодействия. Вот стандартные подходы для популярных стеков:

HTTP/REST

Используйте заголовок X-Request-ID или стандарт W3C traceparent. Последний выглядит так: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01. Первая часть - версия формата, вторая - Trace ID, третья - Parent Span ID, четвертая - флаги (например, sampled).

gRPC

В gRPC контекст передается через метаданные (metadata). Клиентская библиотека автоматически внедряет текущий контекст в исходящие вызовы, если настроена правильно. Не забудьте настроить интерцепторы (interceptors) на стороне сервера для извлечения контекста из входящих запросов.

Очереди сообщений (RabbitMQ, Kafka)

Здесь сложнее, потому что связь асинхронная. При отправке сообщения в очередь вы должны положить Trace ID в заголовки сообщения (headers/properties). Потребитель должен прочитать эти заголовки и восстановить контекст перед обработкой. Если этого не сделать, цепочка рвется, и вы увидите два отдельных, несвязанных треяса.

OpenTelemetry: единый стандарт

Раньше каждый вендор имел свой формат: Zipkin, Jaeger, Datadog. Сейчас индустрия сошлась на OpenTelemetry (OTel). Это набор библиотек и спецификаций для сбора телеметрии (логи, метрики, трейсы) без привязки к конкретному бэкенду.

Почему стоит использовать OTel прямо сейчас:

• Vendor-neutral: Вы пишете код один раз, но можете переключаться между Jaeger, Tempo, Honeycomb или Cloud Monitoring, меняя лишь конфигурацию экспортера.
• Автоматическая инструментация: Для большинства фреймворков (Spring Boot, Express.js, Gin) есть готовые агенты, которые сами добавляют спаны в HTTP-серверы и клиенты БД.
• Единый API: Один интерфейс для создания спанов, добавления атрибутов и записи логов.

Пример простого спана на Python с использованием OTel SDK:

from opentelemetry import trace
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("process_order"):
    # Ваш бизнес-код здесь
    pass

Типичные ошибки при внедрении

Даже опытные команды наступают на грабли. Вот самые частые:

1. Потеря контекста в потоках. Если вы используете пул потоков или асинхронное программирование (asyncio в Python, goroutines в Go), обычный ThreadLocal может не работать. Нужно использовать механизмы передачи контекста, поддерживаемые вашим языком (например, ContextVar в Python или context.Context в Go).
2. Слишком высокая выборка (Sampling). Трейсить 100% запросов дорого. Обычно берут 1-10%. Но важно использовать head-based sampling (на входе) или tail-based sampling (на выходе, оставляя только ошибки и медленные запросы). Ошибка - оставить только успешные быстрые запросы, потому что именно проблемы мы ищем.
3. Отсутствие тегов. Голый спан бесполезен. Добавляйте атрибуты: user_id, db.query.statement (без параметров, чтобы не светить пароли), http.status_code, error=true/false.

Стратегия семплирования и хранение

Хранение всех трейсов в высоконагруженном проекте стоит денег. Поэтому стратегия семплирования критична.

Рекомендация для старта: начните с Head-based sampling 10%. Как только система стабилизируется, перейдите на Tail-based sampling, чтобы гарантированно ловить все ошибки и запросы дольше 500 мс.

FAQ: Частые вопросы о трейсинге