Head sampling и tail sampling: кто решает, какие трейсы выживают

Сервис обрабатывает 10 000 запросов в секунду. Хранить каждый трейс непомерно дорого. Но при случайном sampling в 1% один медленный запрос, вызвавший жалобу клиента, с вероятностью 99% будет тихо выброшен.

Head-based sampling

Решение keep/drop принимается на старте трейса — кодируется в бите 01 (sampled) trace-flags заголовка traceparent. Решение пропагируется на все downstream-сервисы, которые уважают его по умолчанию.

Типовые стратегии:

• Вероятностная: хранить N% трейсов (1–5% типично). Простая, предсказуемая, масштабируется линейно с трафиком.
• Rate-limiting: хранить не более K трейсов в секунду независимо от объёма трафика.

Стоимость: дёшево — решение принимается один раз на root span, до выполнения какой-либо работы. Несэмплированные запросы не генерируют span’ов вообще, экономя CPU, сеть и хранение.

Недостаток: решение слепо к исходу. Медленный или error-запрос, попавший в несэмплированные 99%, невидим в tracing-backend. Если инцидент затрагивает 0.5% трафика, а sampling 1% — сохранишь примерно половину инцидентных трейсов; но можешь не сохранить ни одного, если инцидент кратковременный.

Sampled-флаг: когда флаг 01, downstream-сервисы записывают и экспортируют span’ы. Когда 00, OTel SDK создают span’ы внутри, но по умолчанию не экспортируют. Это consistent sampling: либо весь трейс хранится, либо ничего — никогда фрагмент. Downstream-сервис может переопределить входящий флаг (например, всегда сэмплировать свои ошибки), но частичные переопределения дают фрагментарные трейсы, почти бесполезные для отладки.

Tail-based sampling

OTel Collector буферизует все span’ы для trace-id в течение настраиваемого decision-окна (30с–5мин), затем решает, хранить ли трейс, по policy:

• Есть ошибка → хранить 100%.
• Duration > порог → хранить 100%.
• Конкретный атрибут (например user.tier=premium) → хранить 100%.
• Вероятностный top-up → хранить 1% остального для базовой видимости.

Преимущества:

• Ловит каждый error-трейс даже при 0.1% трафика.
• Ловит каждый медленный трейс выше latency-порога.
• Даёт избирательность, делающую tail sampling доминирующим паттерном у high-traffic-сервисов.

Стоимость: collector обязан держать все span’ы каждого трейса в RAM до decision-time.

Модель памяти: active_traces × avg_spans_per_trace × bytes_per_span. При 50 000 in-flight трейсов × 100 span’ов × 1 KB на span = 5 GB RAM. Decision-окно напрямую управляет RAM-footprint’ом.

Требование load-balancing exporter: с несколькими репликами collector’а случайное распределение span’ов разбрасывает span’ы одного трейса по разным instance’ам. Каждый видит только фрагменты и не может принять корректное решение. Решение — load-balancing exporter, хэширующий по trace-id и направляющий все span’ы одного трейса на один и тот же collector instance. Это обязательно для корректной работы tail sampling.

Гибридный паттерн (доминирует в production)

Head-sample на 100% (каждый запрос входит в pipeline), затем tail-sample по policy:

• Error-трейсы → хранить 100%.
• Latency > 99-й перцентиль → хранить 100%.
• Всё остальное → 1% вероятностно.

Это даёт volume-контроль head sampling и избирательность tail sampling, за счёт одной дополнительной инфры: tier tail-sampling Collector с load-balancing exporter и достаточной RAM.

При 10k req/s с 30с decision-окном, 10 span’ами/трейс, 1 KB/span: 10 000 × 30 × 10 × 1 024 B ≈ 3 GB RAM collector’а. Реализуемо с 4–8 репликами collector’а.