Проблема:
В микросервисной архитектуре один запрос пользователя (например, «оформить заказ») может пройти через сервис заказов, сервис платежей, сервис доставки, сервис уведомлений, сервис аналитики. При ошибке стандартные логи каждого сервиса не позволяют восстановить полную картину, так как разные сервисы пишут в разные файлы, а временные метки могут быть рассинхронизированы. Невозможно узнать общее время выполнения и в каком узле возникла задержка.
Что такое распределённая трассировка:
Это метод мониторинга, который назначает каждому внешнему запросу уникальный trace ID. Этот ID передаётся через все сервисы в заголовках HTTP/gRPC. Каждый сервис при обработке запроса записывает span (отрезок работы: начало, конец, метаданные, возможная ошибка). Все спаны отправляются в центральный коллектор (Jaeger, Zipkin). Затем можно визуализировать полную временную диаграмму выполнения запроса, увидеть, сколько времени занял каждый вызов, и найти узкое место.
Как это помогает:
Локализация ошибки – видно, в каком сервисе возникла ошибка и на какой стадии.
Анализ производительности – можно найти медленные вызовы.
Зависимости сервисов – визуализация графа вызовов.
Пример работы (Jaeger):
Клиент отправляет запрос с заголовком
X-B3-TraceId: abc123.Сервис А создаёт спаны для своих действий и вызывает сервис Б, передавая тот же trace ID.
Сервис Б делает то же самое.
В веб-интерфейсе Jaeger можно выбрать trace
abc123 и увидеть всю цепочку с длительностью каждого этапа.Почему не подходят другие варианты:
A (метрики, Prometheus) – показывают агрегированные данные (среднее время ответа сервиса, количество ошибок), но не индивидуальный путь запроса.
C (централизованное логирование, ELK) – можно связать логи по trace ID, но без временных отрезков и визуализации цепочки это менее удобно, требует ручного анализа.
D (health checks) – проверяют доступность сервиса, а не отслеживают запросы.
Реальный пример:
В Uber используется распределённая трассировка Jaeger для отладки сценариев поездок. Инженеры могут взять конкретный failed-запрос, посмотреть, что поиск водителя занял 10 секунд из-за задержки в сервисе геопозиционирования, и оптимизировать именно его.
Что должен зафиксировать аналитик:
Требование: «В архитектуре должна быть реализована распределённая трассировка с использованием стандартов OpenTelemetry».
Каждый сервис должен пробрасывать заголовки trace ID при вызовах.
Временные метки должны быть синхронизированы по всем узлам (NTP).
Вывод: Распределённая трассировка — обязательный компонент отказоустойчивых микросервисных систем, позволяющий видеть «путь» запроса и быстро находить проблемные зоны.