В распределённой системе трассируют случайные 1% запросов, но редкий класс запросов медленный. Какой риск для поиска узких мест создаёт такая выборка?
Случайная выборка может почти не содержать редкие медленные запросы, поэтому узкое место останется незаметным или его вклад будет сильно занижен. Средняя задержка по сохранённым трассам может выглядеть нормальной, хотя именно редкий класс формирует значительную часть проблемного хвоста.
Распределённая трассировка появилась как способ восстановить путь одного запроса через несколько компонентов, где одних логов и метрик часто недостаточно. Полное сохранение трасс быстро становится дорогим по объёму хранения, сетевому трафику и обработке, поэтому применяют выборку трасс.
Исходная задача выборки — снизить стоимость наблюдаемости. Компромисс состоит в том, что уменьшение объёма данных может ухудшить обнаружение редких, но важных событий.
При выборке 1% каждый запрос имеет примерно одну вероятность из ста попасть в систему трассировки. Если медленные запросы редки, в сохраненном наборе их может не оказаться вовсе, особенно на коротком интервале наблюдения.
Это опасно для анализа p95 и p99, поиска редких таймаутов и сравнения версий. Команда может оптимизировать типичный запрос, не заметив зависимость или маршрут, который обслуживает небольшую долю трафика, но вызывает непропорционально много задержек и ошибок.
При простой случайной, или head-based, выборке решение о сохранении принимается в начале обработки запроса. Оно не знает, станет ли запрос медленным, завершится ли ошибкой и какой компонент окажется узким местом. Поэтому вероятность сохранения медленной и быстрой трассы примерно одинакова при одинаковом объёме трафика.
Для редких проблем применяют tail-based sampling: сначала собирают сведения о завершившейся трассе, затем с повышенным приоритетом сохраняют трассы с ошибками, высокой длительностью, большим числом внутренних вызовов или специальными признаками риска. Это лучше обнаруживает аномалии, но требует временно удерживать данные о незавершённых трассах и централизованно принимать решение.
Обычно используют комбинированную стратегию: сохраняют небольшую базовую долю всех трасс для представления обычного трафика, а ошибки и медленные трассы сохраняют почти полностью или по отдельному правилу. Порог задержки должен учитывать тип операции, иначе естественно медленные операции будут постоянно выглядеть аварийными.
Выборка трасс не заменяет метрики. Гистограммы задержки, счётчики ошибок и распределение по маршрутам должны строиться по более полному потоку данных, иначе сама выборка исказит картину. Кроме того, решение о сохранении должно распространяться на всю трассу, а не случайно применяться к отдельным сегментам: иначе цепочка будет неполной.
Главный компромисс — между стоимостью, полнотой диагностики и задержкой появления данных. Слишком агрессивная фильтрация экономит ресурсы, но скрывает редкие события; слишком широкое сохранение увеличивает расходы и может перегрузить систему наблюдаемости.
Платформа обслуживает много быстрых запросов к профилям и небольшую долю запросов к отчётам. Трассируется 1% всех запросов. Пользователи жалуются на периодические задержки отчётов, но сохранённые трассы почти всегда относятся к профилям и показывают нормальную работу базы данных.
Рассматривались три варианта. Увеличить общую долю выборки до 20% — просто, но дорого и всё ещё не гарантирует попадание редкого проблемного запроса. Сохранять все запросы к отчётам — хорошо покрывает известный класс, но не обнаруживает новые проблемные маршруты. Включить хвостовую выборку с повышенным приоритетом для ошибок и трасс выше порога задержки — сложнее по реализации и требует буферизации, зато напрямую ориентируется на наблюдаемый результат.
Выбран третий вариант в сочетании с небольшой базовой выборкой. В результате обычный трафик остался представлен для анализа, а редкие медленные трассы стали регулярно попадать в диагностику без пропорционального роста объёма данных.
Ответ: Нет. Увеличение доли повышает вероятность обнаружения, но не даёт гарантии. Если событие имеет малую частоту, нужный объём выборки может быть экономически неприемлемым, а на коротком окне наблюдения проблема всё равно может не проявиться. Для таких случаев лучше направленно сохранять ошибки и трассы с высокой задержкой, а полноту измерения задержки обеспечивать метриками.
Ответ: Сохранённые трассы — это выборка, а не полный знаменатель для SLO. Если вероятность попадания зависит от результата запроса или его длительности, выборка становится смещённой: ошибки и медленные запросы могут быть пере- или недопредставлены. Для SLO нужны согласованные счётчики общего числа хороших и плохих событий, тогда как трассы служат материалом для расследования причин.
Ответ: Если отдельные сегменты сохраняются независимо, трасса может потерять родительский или дочерний участок. Тогда наблюдаемая длительность цепочки не совпадёт с реальной, а вклад зависимостей будет трудно сравнивать. Решение о сохранении обычно должно распространяться на все связанные сегменты по идентификатору трассы; при этом нужно контролировать объём данных и не дублировать один и тот же запрос в нескольких системах хранения.