Что такое распределённая трассировка (distributed tracing) и зачем она нужна в микросервисной архитектуре?

Короткий ответ

Распределённая трассировка — это способ отследить путь одного запроса через множество сервисов, записывая для каждого шага отдельный "спан" (span) с временем начала/конца и привязкой к общему trace_id; это позволяет увидеть, через какие сервисы прошёл запрос и сколько заняла каждая часть.

Как это работает подробнее

когда запрос входит в систему, ему присваивается уникальный trace_id; при каждом вызове между сервисами этот идентификатор передаётся дальше (через HTTP-заголовки или метаданные gRPC), и каждый сервис создаёт свой span с временем начала/окончания операции, родительским span_id и дополнительными атрибутами. Собранные спаны складываются в дерево — трейс, который можно визуализировать как временную диаграмму (например, в Jaeger, Tempo или Zipkin).

Пример кода

example.txtКопировать

trace_id=9f1c span=api-gateway            duration=620ms
  └─ span=auth-service                    duration=40ms
  └─ span=checkout-service                duration=560ms
       └─ span=payment-service            duration=510ms
            └─ span=db-query (SELECT ...) duration=480ms

Что использовать на практике

• Практика. трассировка особенно полезна, когда нужно понять, где именно в цепочке из 5–10 сервисов "потерялось" время при обработке одного медленного запроса — без трейса пришлось бы вручную сопоставлять логи по времени из разных сервисов. Для внедрения обычно используют стандарт OpenTelemetry, который единообразно инструментирует код и экспортирует спаны в совместимый backend.
• Практика. Дерево спанов явно показывает, что почти всё время (480 из 620 мс) ушло на один медленный SQL-запрос внутри payment-service — без трассировки эту причину было бы трудно локализовать, глядя только на общий показатель latency api-gateway.

Подводные камни

• Частые ошибки. считать, что трассировка нужна только "сложным" компаниям с сотнями микросервисов — она полезна и при 3–5 сервисах, если запросы между ними медленные или ненадёжные; забывать передавать trace_id через асинхронные очереди сообщений, из-за чего трейс "разрывается" на границе синхронного и асинхронного взаимодействия; включать трассировку 100% трафика без оценки нагрузки на хранение данных.