В этом материале
Tail sampling требует собрать spans одной trace у одного принимающего sampler. Если разные части попадают в разные Collector instances, решения могут оказаться неполными. Head sampling принимает решение раньше и не умеет восстановить spans, уже отброшенные до tail stage.
Tail sampling требует собрать spans одной trace у одного принимающего sampler. Если разные части попадают в разные Collector instances, решения могут оказаться неполными. Head sampling принимает решение раньше и не умеет восстановить spans, уже отброшенные до tail stage.
Найдите все стадии sampling
Сохраните SDK sampler, промежуточные processors и backend policy. На каждом переходе отметьте, где данные отбрасываются и какие routing keys используются. Отсутствующий span может никогда не экспортироваться из SDK, теряться в очереди или не попадать в выбранную tail decision. Это разные причины. Не увеличивайте decision_wait до выяснения пути: дополнительное ожидание не соединит части trace, которые маршрутизируются к разным независимым процессам и нигде не собираются вместе.
Разделите head и tail решения
Head sampling принимает раннее решение без полного знания будущей trace. Tail sampling учитывает накопленные spans и может выбирать по ошибке или длительности, но требует состояния и памяти. Сочетание возможно, однако tail sampler видит только то, что дошло до него. Раннее head отбрасывание нельзя отменить последующим правилом «сохранять ошибки». Сохраните эту границу в отчёте, чтобы отсутствие ошибочной trace не объяснялось неправильно только tail policy.
Разберите два Collector
В учебном тесте spans одной trace_id отправляются round-robin в два tail-sampling Collector. Один видит начало, другой — error span, и каждый решает по своему неполному набору. Перед tail stage применяют trace-aware routing, например соответствующий load-balancing exporter. Все spans данного trace должны идти к одному sampler. Изменение списка backend instances может перераспределить часть маршрутов; такая топология требует проверки при scale-out, а не только при стабильном составе.
| Проверка | Что выясняет |
|---|---|
| SDK sampling | Какие spans вообще экспортировались |
| Routing key | Собирается ли trace на одном backend |
| Decision timing | Успели ли нужные spans прийти |
| Cache и capacity | Как обрабатываются поздние данные |
Проверьте ожидание и ёмкость
Decision_wait влияет на момент решения в зависимости от версии и выбранной sampling strategy. Сверяйте документацию установленного processor, особенно при новых режимах. Num_traces ограничивает состояние, а поздние spans зависят от decision cache и уже принятого решения. Увеличение ожидания повышает требования к удерживаемым данным и не является универсальным способом избежать потерь. Не переносите defaults из current main в старую установленную сборку без проверки поддерживаемых параметров.
Подтвердите цельную trace
Создайте синтетическую trace с известными spans и задержками, затем проверьте SDK export, выбранный Collector и конечный набор. Отдельно повторите с поздним span и изменением состава sampler instances на стенде. Артефакт содержит topology, routing key, версии и policy, а также ожидаемые решения. Успех означает корректное решение в пределах проверенного потока; он не обещает полноту любых исторических trace. Не сохраняйте чувствительные prompts ради проверки sampling: известной синтетической структуры достаточно.
Связанные разборы: gpu monitoring scorecard; hardware security.