Наблюдаемость
Trace propagation: тест на свободное воспроизведение
Воспроизведение бьёт перечитывание. Для каждого промпта проговори или запиши полный ответ по памяти, прежде чем открыть модельный, — именно усилие припоминания закрепляет рассуждение о propagation.
Восстанови хребет юнита по памяти — W3C-заголовок, fallback при отсутствии заголовка, consistent sampling, RAM-модель tail-сэмплера, фиксы async-границ и метрики здоровья propagation — не подглядывая в уроки.
- 01Почему сломанная trace propagation хуже, чем полное отсутствие трейсинга, и какая одна метрика её вскрывает?
- 02Пройди по четырём полям traceparent и что сервис обязан сделать с невалидным заголовком.
- 03Как consistent sampling позволяет 12 сервисам договориться о keep/drop без координации и почему частичные трейсы недопустимы?
- 04Дай RAM-модель tail-сэмплера и три независимых рычага OOM.
- 05Назови async-границы, теряющие context, и верный фикс для каждой, включая различие внутрипроцессный vs межпроцессный.
- 06Когда дерево parent-child ломается и как span-links и проблема 30 минут это решают?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: 55-байтный W3C traceparent сшивает сервисы, невалидный заголовок означает «старт заново», а равномерно случайный trace-id заставляет consistent sampling работать без координации. Tail-сэмплер меняет RAM на отбор с учётом исхода — ограничь его через num_traces, реплики и span-linked под-трейсы. Async-границы теряют context (context.bind внутри процесса, inject/extract между процессами), а поскольку propagation падает тихо, orphan-span rate — метрика, доказывающая, что дашборд говорит правду.