Что такое trace propagation и почему сломанная propagation хуже отсутствия трейсов

Клиент открывает тикет поддержки: «checkout занял 30 секунд». Tracing-инструмент показывает трейсы для каждого сервиса — но каждый из них один span, не связан ни с чем. Все данные есть, ответов нет.

Что такое trace propagation

Trace propagation — практика передачи маленького идентификатора от одного сервиса к другому на каждом запросе, чтобы вся работа, сделанная через много сервисов для одного пользовательского действия, сшилась в одну картинку.

Без propagation медленный checkout выглядит как 50 разных историй. С ней — один трейс, проходимый сверху вниз за 30 секунд.

Идентификатор несётся в HTTP-заголовке traceparent, определённом спецификацией W3C Trace Context. Каждый сервис, получающий запрос, читает traceparent, использует его как parent для своей работы, генерирует новый span-id для себя и пишет новый traceparent перед любым исходящим вызовом. Trace-id остаётся постоянным на каждом hop; span-id’ы формируют parent-child-дерево.

Метафора эстафеты

Представь доставку Amazon с одним tracking number. Посылка покидает склад, прыгает между сортировочными центрами, едет на трёх грузовиках и наконец приезжает к двери. Каждый hop сканирует тот же tracking number, записывая, где она была, когда и куда следующая.

Если какая-то одна остановка забывает просканировать — страница отслеживания замолкает и непонятно, где посылка, даже если она в итоге доедет.

Trace propagation — это сканирование. Каждый сервис обязан:

1. Прочитать входящий traceparent (извлечь trace-id и parent span-id).
2. Создать свой span (новый span-id, parent = входящий span-id).
3. Написать новый traceparent перед любым исходящим вызовом (тот же trace-id, свой span-id как новый parent-id).

Пропустишь любой из этих шагов — цепочка рвётся.

Конкретный сценарий с Bea и Sven

On-call-инженер получает тикет поддержки клиента: «checkout занял 30 секунд». Открывает tracing-инструмент, вводит request-id из тикета, поднимает один трейс. Видит: 50 мс на API gateway, 80 мс в auth-сервисе, 28 секунд в inventory-сервисе на ожидании DB-запроса, 200 мс в payment, 100 мс назад пользователю. 28-секундное узкое место точно названо.

Без propagation пришлось бы вручную сопоставлять 50 log-записей через 7 сервисов и угадывать, какие от этого пользователя. С одним трейсом — знаешь за 30 секунд.

Почему сломанная propagation хуже отсутствия трейсов

Без трейсинга вообще знаешь, что трейсов нет, и идёшь в логи. Со сломанной propagation каждый сервис эмитирует span’ы, но ни один не связан с другим — дашборд утверждает, что наблюдает систему, а каждый трейс покрывает только один сервис.

Думаешь, что отлаживаешь end-to-end, а реально отлаживаешь фрагментами. Пропавший трейс делает медленный сервис невидимым: запрос, быстрый в сервисе A и медленный в B, выглядит как быстрый трейс в A и отдельный медленный трейс в B без причинной связи. Операторы тратят часы, подозревая не тот сервис.

Типичный сценарий сбоя: команда добавляет tracing в один сервис, но забывает включить OTel HTTP-client auto-instrumentation. Каждый span стартует свежий трейс; дашборд показывает трейсы, но каждый — глубиной в один span. Клиенты жалуются на медленный journey, команда не может найти, где время — трейс тихо расщеплён на 50 кусков.