Наблюдаемость
Trace propagation: тест с множественным выбором
Суть Синтез юнита trace propagation в формате множественного выбора — W3C-заголовок, consistent sampling, лимиты tail-sampling-коллектора, async-границы и тихие production-сбои.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, прошивающих весь юнит. Каждый отражает решение, которое ты принимаешь в реальном инциденте, — не определение для пересказа, а выбор по propagation, который надо взвесить, пока дашборд врёт тебе о том, сколько ты на самом деле видишь.
Цель
Убедись, что можешь связать формат W3C-заголовка, consistent sampling, экономику tail-sampling-коллектора, сбои на async-границах и наблюдаемость самой propagation — синтез, к которому вели отдельные уроки.
Викторина
Completed
Сервис получает 'traceparent: 99-aaaaaaaa-bbbbbbbb-01'. Что он обязан сделать по W3C-спеке и почему это правило важно для всего флота?
Heads-up traceparent — это подсказка, а не контроль доступа. Спека предписывает игнорировать невалидный заголовок и стартовать свежий trace; отклонение запроса сломало бы пользовательский поток из-за телеметрической детали.
Heads-up Использование кривого trace-id молча сливает или портит трейсы в бэкенде, который ключует все span по trace-id. Неверный id хуже свежего валидного.
Heads-up Спека не определяет поведение «починки»; trace-id или parent-id из одних нулей сам по себе невалиден. Единственно верное действие — отбросить и сгенерировать заново.
Викторина
Completed
Команда гоняет вероятностный head sampling на 1% по 12 сервисам без центрального координатора. Как все 12 независимо договариваются оставить или отбросить один и тот же trace?
Heads-up Head sampling решает до того, как span покидают сервис; пост-фактум сверки нет. Согласованность даёт детерминированное хеширование trace-id в каждом сервисе, а не коллектор.
Heads-up Независимые посервисные «броски кубика» оставят span сервиса A и дропнут span сервиса B для одного trace — ровно тот частичный trace, ради предотвращения которого и существует consistent sampling.
Heads-up Нижестоящие уважают sampled-флаг в trace-flags — но более глубокая гарантия в том, что даже пере-хеширование того же trace-id даёт тот же ответ, поэтому система согласована по построению.
Викторина
Completed
Tail-sampling-коллектор OOM-ится каждые несколько часов. Число трейсов ровное, но spans-per-trace растёт. В чём причина и какой «фикс» делает только хуже?
Heads-up Дубликаты подняли бы число span по многим трейсам, а не сконцентрировали бы его на нескольких. Сигнатура здесь — несколько трейсов, каждый с тысячами span, это проблема долгоживущего trace.
Heads-up Реплики за load-balancing-экспортёром делят активные трейсы между инстансами, но один жирный trace всё равно целиком падает на одну реплику. Реальный фикс — разбить работу на span-linked под-трейсы.
Heads-up Round-robin разбрасывает span одного trace по репликам, так что ни один инстанс не видит весь trace — это ломает tail sampling напрочь. Хеширование по trace-id обязательно; оно не причина.
Викторина
Completed
Node-сервис использует OTel HTTP-автоинструментацию. И работа, отложенная через setTimeout, и сообщения, которые он публикует в Kafka, появляются как orphan-трейсы. Какой правильный двухчастный фикс?
Heads-up context.bind оживляет context только внутри процесса. Kafka пересекает межпроцессную границу без общей памяти, поэтому trace-id надо записать в заголовки сообщения через inject и прочитать обратно через extract.
Heads-up inject/extract — для сериализуемых носителей вроде заголовков сообщений. Колбэк setTimeout исполняется в том же процессе на новом async-стеке; ему нужен context.bind, а не инъекция в заголовки.
Heads-up Автоинструментация прекрасно держит HTTP; пробелы именно в необёрнутых async-колбэках и границах очередей. Фикс — точечный bind и inject/extract, а не отказ от автоинструментации.
Викторина
Completed
Orphan-span rate внутреннего сервиса держится на 5% целый квартал, а дашборды показывают на вид целые трейсы. Команда добавляет tail sampling в надежде это вычистить. В чём ключевое заблуждение?
Heads-up Входные сервисы законно корнят трейсы, но здоровый внутренний сервис должен быть около 0%. Устойчивые 5% на внутреннем сервисе — это регрессия propagation, а не baseline.
Heads-up Это ровно ловушка тихого сбоя из юнита: дашборды продолжают рисовать трейсы, пока половина из них разорвана. Метрика orphan-rate — это правда; нарисованные трейсы — иллюзия.
Heads-up Ставка sampling управляет тем, экспортируются ли span, а не тем, несут ли они корректный parent-id. Экспорт большего числа orphan'ов их не связывает.
Викторина
Completed
Консьюмер тянет 1000 Kafka-сообщений и обрабатывает их одним batch. Моделирование этого как один parent span с 1000 детей OOM-ит коллектор. Какой идиоматичный фикс и что он сохраняет?
Heads-up num_traces ограничивает число активных трейсов, а не spans-per-trace. Trace с 1000 детей всё равно затопляет один буфер; поднятие лимита откладывает OOM, а не убирает fan-in.
Heads-up Сброс всех batch-трейсов сбрасывает и те с ошибками и медленные, которые нужны команде. span-links держат batch наблюдаемым, ограничивая его размер.
Heads-up Полностью независимые трейсы теряют причинность fan-in — ты больше не видишь, что одна batch-операция обработала именно эти сообщения. span-links существуют ровно ради сохранения этой связи.
Итог
Сквозная линия юнита — одна цепочка: 55-байтный W3C traceparent сшивает сервисы, невалидный заголовок означает «старт заново», а равномерно случайный trace-id позволяет каждому сервису захешировать один и тот же вердикт keep/drop для consistent sampling. Tail-sampling-коллектор меняет RAM (активные трейсы × span × байты × окно) на отбор с учётом исхода, поэтому долгоживущие трейсы и fan-in надо разбивать через span-links. Async-границы (setTimeout требует context.bind, очереди — inject/extract) — главный источник orphan’ов, а поскольку propagation падает тихо, orphan-span rate — единственная метрика, которая говорит, что дашборд врёт.