Стратегии сэмплирования: head, tail и parent-based

При 10к запросов в секунду запись 100% трассировок заполняет бэкенд за часы и генерирует пятизначный ежемесячный счёт. Но если сбросить 99% трассировок, именно ошибки и медленные запросы, нужные для отладки, будут потеряны. Сэмплирование — это компромисс между стоимостью и точностью.

Head-сэмплирование: решение быстро и дёшево

Sampler SDK запускается на самом первом спане трассировки (корневом спане) и решает, записывать ли трассировку. Решение распространяется на нижестоящие сервисы через флаг sampled в заголовке W3C traceparent.

AlwaysOn — записывает каждую трассировку. Полная точность, максимальная стоимость.

AlwaysOff — ничего не записывает. Полезен для канарейки или сервиса под нагрузочным тестом.

TraceIdRatioBased(p) — записывает случайную долю p на основе хэша trace_id. Детерминировано между сервисами: если два сервиса оба используют TraceIdRatioBased(0.1), они независимо принимают одинаковое решение для одной трассировки, потому что хэш берётся от trace_id, который разделяется по всему запросу. При p=0.1 записывается 10% трассировок.

ParentBased — следует решению о сэмплировании родительского спана (через traceparent.sampled). Когда вышестоящий сервис решает сэмплировать, все нижестоящие следуют за ним. Когда вышестоящий не сэмплирует, нижестоящие обычно тоже нет, если локальный сэмплер не переопределяет. Предотвращает несогласованные частичные трассировки.

Production-комбинация: ParentBased(root=TraceIdRatioBased(0.2)). Корневой спан сэмплирует 20% трассировок. Все нижестоящие спаны наследуют решение. Результат: либо вся трассировка записана, либо ничего — никаких частичных трассировок с осиротевшими дочерними спанами.

Tail-сэмплирование: решение поздно, дорого

Tail-сэмплирование выполняется в Collector после того, как все спаны трассировки прибыли и трассировка завершена (или близка к этому). Оно может анализировать полный контекст трассировки: финальный статус-код, общую задержку, наличие спанов с ошибками где-либо в дереве, бизнес-атрибуты на любом спане.

Типичные политики tail-сэмплирования:

• status_code=ERROR — сохранять 100% трассировок с любым спаном ERROR
• latency > 1000ms — сохранять 100% медленных трассировок
• probabilistic 1% — сохранять 1% всего остального как базовый трафик

Комбинация покрывает весь интересный трафик (ошибки, медлительность) и обеспечивает ограниченный по стоимости базовый уровень для нормального трафика.

Ограничение sticky-маршрутизации

Tail-сэмплирование требует, чтобы все спаны трассировки прибывали на один и тот же экземпляр Collector-шлюза. Если спаны одной трассировки попадают на два разных экземпляра, ни один из них не может оценить полный контекст трассировки, и решение о сэмплировании будет неверным.

Экспортёр loadbalancing OTel Collector на агентном уровне решает эту проблему: он хэширует по trace_id и маршрутизирует детерминировано на один и тот же pod шлюза для всех спанов трассировки.

Компромисс: шлюз становится с состоянием. Перезапуск pod или событие масштабирования перетасовывает кольцо хэшей и теряет трассировки в полёте. Production-меры защиты:

• Предварительный прогрев новых podов перед включением в кольцо балансировки нагрузки
• Консервативные политики масштабирования (избегать частых масштабирований во время пиков трафика)
• Размер буфера num_traces шлюза = пиковая_скорость × decision_wait × защитный_коэффициент (~2x)

Числа

• Буфер tail-сэмплирования: ~1-2 ГБ на 50к активных трассировок (100 спанов по ~1 КБ/спан)
• decision_wait: 30-60 секунд (должен превышать p99 длительности трассировки)
• num_traces: размер = пиковая_скорость × decision_wait × 2 — при 2000 трассировок/с и окне 30с: ~120к
• Head-сэмплирование в production: 10-20%
• Tail-сэмплирование сохраняет: 100% ошибок + 100% медленных (порог 1с) + 1-5% базового трафика
• Итого удержано: ~3-5% от общего объёма, 100% интересного трафика