Production-сбои propagation, span links и платформенный дизайн

GitHub держал регрессию propagation целый квартал, когда 50% внутренних трейсов были orphan-спанами. Дашборды показывали трейсы всё это время. Никто не заметил, пока инженер не проверил orphan-span rate в рутинном ревью.

Реальные production-сбои propagation

Uber 2019: частичный rollout OTel привёл к тому, что 30% трейсов обрывались на границе между инструментированными и неинструментированными сервисами. Постмортем обязал добавить gate «ни один сервис не выходит в prod без W3C propagation», проверяемый в CI. Паттерн: инструментированные сервисы отдают идеальные спаны; неинструментированные отдают orphan-спаны; обе группы показывают разную глубину трейсов на дашбордах, но автоматических алертов на граничный сбой нет.

GitHub 2022: кастомная обёртка HTTP-клиента обходила хуки OTel и молча дропала traceparent у половины внутренних сервисов целый квартал — пока кто-то не заметил, что orphan-span rate вырос с 1% до 50%. Фикс — одна строка: обернуть клиент в OTel-aware версию. Урок: кастомные обёртки — самый частый пробел propagation в зрелых сервисах. Фикс всегда однострочный; найти его занимает квартал.

Slack 2023: tail-sampling Collector’ы упали по OOM и снесли pipeline трейсинга во время крупного инцидента — именно тогда, когда трейсинг был нужнее всего. Постмортем добавил лимиты num_traces и отдельный always-keep-тир для высокоприоритетных трейсов. Пробел мониторинга: health-метрики OTel Collector не были ни на одном SLO-дашборде.

Datadog 2024 (customer report): крупная Java-нагрузка использовала thread pool, который не переносил контекст через submitted tasks, поэтому 80% трейсов background-задач были orphan-спанами. Фикс: переключиться на executor с поддержкой CurrentTraceContext. Баг существовал месяцами; обнаружен в ходе квартального ревью orphan-rate.

Общий паттерн: баги propagation молчат. Дашборды продолжают показывать трейсы. Единственный механизм обнаружения — метрика orphan-span rate, и эта метрика должна быть на дашборде и желательно на алерте — OTel defaults её не выставляет автоматически.

Observability для самой propagation

Ключевые health-метрики propagation:

Span links: когда дерево родитель-потомок ломается

Модель родитель-потомок предполагает линейную причинность: A вызывает B, B вызывает C. Это ломается в трёх сценариях:

1. Batch-обработка: consumer вытягивает 1 000 сообщений из Kafka и обрабатывает их в одном батче. Нет единственного осмысленного «родителя» — 1 000 входящих trace-контекстов питают один batch-спан.
2. Fan-in: несколько параллельных подзадач сходятся в точке join. Каждая подзадача — потомок собственной ветви; у точки join несколько причинных участников.
3. Async follow-ups: исходящий запрос завершается и возвращает ответ пользователю, но порождает follow-up, который выполняется спустя часы. Контекст исходного запроса закрыт; follow-up’ам нужна причинная связь без того, чтобы быть потомками «мёртвого» спана.

Span-links в OTel решают всё это: спан объявляет дополнительные ссылки на SpanContext, с которыми он причинно связан, но от которых не наследуется. Tracing-бэкенды визуализируют links как пунктирные линии рядом с деревом родитель-потомок.

Senior-паттерн: любой трейс длиннее 30 секунд или шире 100 спанов — кандидат на рефакторинг с span-links. Разбейте длинный workflow на sub-трейсы, каждый из которых умещается в окно принятия решения tail-sampler’а, и используйте links для сохранения причинной цепочки. Трейсы остаются небольшими, sampler’у хорошо, следственная связь сохраняется.

Long-running трейсы и проблема 30 минут

Tail-sampler’ы имеют окна принятия решения 30 с–5 мин. Batch-задача, работающая 30 минут, отдаёт спаны уже после закрытия окна; поздние спаны выглядят для sampler’а как orphan-спаны.

Два production-паттерна:

1. Разбить работу: разделить длинные workflows на sub-трейсы, связанные span-links, каждый умещается в окно принятия решения. Чистая архитектура, корректная по построению.
2. Поддержка поздних спанов бэкендом: Tempo, Honeycomb и Datadog поддерживают поздно прибывшие спаны до 24 ч после старта трейса. Для long-running трейсов пропустить tail-sampling; использовать head sampling на 100% для batch-нагрузок. Практический retrofit для legacy batch-задач.

Окно принятия решения — это рычаг, который нужно настраивать, когда batch-нагрузки ломают tail-sampling. Увеличение его вверх увеличивает RAM Collector’а; правильный ответ чаще всего — разбить работу.

# Запрос: trace_id == "4bf92f3577b34da6a3ce929d0e0e4736"
# Результат: 7 спанов

#  сервис             span_id           parent_id           длительность   статус
1  api-gateway       1a2b3c4d5e6f7890  -                   18ms           OK
2  auth              7890abcdef123456  1a2b3c4d5e6f7890    14ms           OK
3  inventory         abcdef1234567890  1a2b3c4d5e6f7890    1200ms         OK
4  payment           fedcba0987654321  -                   80ms           OK    # ORPHAN
5  postgres-client   1111222233334444  fedcba0987654321    55ms           OK
6  email-job         5555666677778888  -                   240ms          OK    # ORPHAN
7  audit-log         9999aaaabbbbcccc  -                   12ms           OK    # ORPHAN

# Также отдельные orphan-трейсы с одним спаном:
# trace_id 9981a... сервис payment, 78ms
# trace_id ab32c... сервис email-job, 280ms
# trace_id ff8e1... сервис audit-log, 14ms