Трассировка под нагрузкой: где теряются данные и растёт цена

При всплеске запросов трассировка может начать терять трейсы именно тогда, когда они нужнее всего: очередь экспортёра переполняется, а объём данных раздувает нагрузку на сеть и хранилище. Ни одного универсального порога здесь нет: результат зависит от числа запросов, количества спанов на запрос, размера атрибутов и настроек сбора. Ниже — разбор на модели OpenTelemetry и OpenTelemetry Collector Contrib 0.120.0; это версия для ориентира, а перед настройкой проверьте актуальный релиз и документацию.

Почему трассировка чувствительна к нагрузке

Один входящий запрос может породить спаны в приложении, прокси, очереди сообщений и базе данных. Чем больше таких запросов и чем подробнее инструментация, тем больше телеметрии нужно передать, обработать и сохранить. При этом данные проходят не одним потоком: приложение создаёт спаны, SDK может накапливать их для отправки, коллектор принимает, обрабатывает и экспортирует данные дальше.

Перегрузка на любом участке распространяется назад. Если хранилище отвечает медленно, очередь экспортёра растёт. Когда её ёмкость заканчивается, коллектор может начать отбрасывать данные. Если приложение не успевает отправлять спаны, часть данных может потеряться ещё до коллектора — в зависимости от SDK, процессного завершения и конфигурации.

Спан — запись об отдельной операции или её части: например, обработке HTTP-запроса или вызове базы данных. Несколько связанных спанов образуют трейс — путь запроса через систему.

Трейс, который не дошёл до хранилища, не поможет найти причину инцидента. Поэтому проверяйте не только задержку сервиса, но и путь самой телеметрии.

Где возникают потери и задержки

Очередь экспортёра и медленный приёмник

Коллектор может принимать данные быстрее, чем экспортёр успевает передать их в backend. Очередь сглаживает короткие задержки, но не устраняет постоянный дефицит пропускной способности. Когда очередь заполняется, растут задержка экспорта и число отброшенных данных. Повышение размера очереди даст больше времени на восстановление, но потребует больше памяти и не спасёт при длительной перегрузке.

Смотрите на заполнение очереди, количество ошибок экспорта, время ответа приёмника и метрики отброшенных данных. Названия метрик зависят от версии Collector и конфигурации: сверяйте их с документацией именно установленного релиза, а не копируйте дашборд для другой версии.

Слишком подробные спаны и атрибуты

Частая причина перерасхода — не только большое число запросов, но и избыточные данные на каждый запрос. Запись тела запроса, большие сообщения об ошибках или множество атрибутов увеличивают размер спана. Атрибуты с уникальными значениями — например, идентификаторы пользователей и заказов — способны резко увеличить кардинальность в хранилище. Это влияет на стоимость и скорость запросов к телеметрии.

Высокая кардинальность не означает автоматически, что данные потеряются в коллекторе. Но хранить и запрашивать их может стать дороже, а некоторые backend-системы ограничивают допустимые значения и объём данных. Уточняйте ограничения конкретного хранилища.

Sampling скрывает часть картины

Sampling — выбор, какие трейсы сохранять. Head-based sampling решает это в начале трассы: он экономнее и предсказуемее по объёму, но не знает заранее, завершится ли запрос ошибкой или окажется медленным. Tail-based sampling принимает решение после сбора спанов и может сохранять интересные трейсы по результату, но требует буферизовать данные и собирать связанные спаны вместе.

Для tail sampling важны время ожидания решения, размер буфера и распределение спанов между экземплярами коллектора. Если части одного трейса попадают в разные места, правило отбора может не увидеть полную картину. Настройка должна учитывать маршрутизацию телеметрии и доступную память, а не только условия «сохранять ошибки».

Сравнение подходов к отбору трейсов

Сравнение условное: реальная цена зависит от размера спанов, реализации SDK, конфигурации Collector и тарифов хранилища. Sampling также меняет статистическую полноту данных: долю сохранённых трейсов нельзя автоматически трактовать как долю всех запросов без учёта схемы отбора.

Как измерить поведение под нагрузкой

Не начинайте с настройки «на глаз». Сначала зафиксируйте исходные условия: поток запросов, среднее число спанов на запрос, размер телеметрии, число экземпляров коллектора, параметры очередей и доступную память. Затем воспроизведите нагрузку, близкую к реальной, и наблюдайте систему при штатном режиме и при замедлении приёмника.

1. Проверьте полноту. Сравните число запросов в приложении с числом принятых и экспортированных трейсов, учитывая настроенный sampling. Проверка: вы можете объяснить расхождение, а не списываете его на «погрешность».
2. Следите за очередями. Запишите их заполнение, задержки экспорта и число ошибок. Проверка: видно, растёт ли очередь кратковременно или продолжает увеличиваться при стабильной нагрузке.
3. Проверьте ресурсные пределы. Наблюдайте память и CPU коллектора, размер сообщений и состояние приёмника. Проверка: замедление backend не приводит к незамеченному росту памяти или постоянным потерям.
4. Смоделируйте деградацию. На тестовой среде замедлите или временно отключите приёмник, затем восстановите его. Проверка: вы понимаете, что произойдёт с очередью, сколько времени займёт восстановление и какие данные будут потеряны.

Не называйте результат универсальным пределом вроде «этот коллектор выдерживает N трейсов в секунду», если не указали окружение и профиль данных. Для воспроизводимого замера фиксируйте железо, версии, конфигурацию, параллельность, размер спанов и поведение приёмника. Сравнивайте до и после на одном и том же сценарии.

Граничные случаи: где подход ломается

• Резкий всплеск. Очередь может сгладить краткий пик, но при устойчивом превышении пропускной способности она заполнится. Увеличение буфера лишь откладывает момент отказа.
• Медленный backend. Повторные попытки экспорта помогают при временных сбоях, но под нагрузкой могут добавить трафик. Настройку повторов и очередей проверяйте вместе: отдельный параметр не гарантирует восстановление.
• Tail sampling на нескольких коллекторах. Если связанные спаны распределяются между экземплярами без подходящей маршрутизации, решение по неполному трейсу может оказаться неверным.
• Принудительное завершение процесса. Буферизованные данные не обязательно успеют экспортироваться при аварийной остановке. Проверьте поведение при перезапуске и не считайте память очереди постоянным хранилищем.
• Неограниченные атрибуты. Уникальные значения увеличивают объём и могут ухудшить работу backend даже при умеренном количестве запросов.

Инвалидация трейсов и выбор конкретного backend зависят от вашей системы хранения; здесь рассматриваем только сбор и передачу телеметрии.

Что делать дальше

Начните с дашборда для самого контура трассировки: очередь, ошибки экспорта, задержка доставки, память коллектора и объём отброшенных данных. Добавьте оповещение не только на высокий уровень очереди, но и на её устойчивый рост. Затем прогоните нагрузочный сценарий с замедлением приёмника и отдельно проверьте, как sampling влияет на долю сохранённых ошибок и медленных запросов.

Версию Collector Contrib 0.120.0 используйте только как обозначенный ориентир: перед внедрением сверьте настройки и доступные компоненты с документацией установленного релиза. Следующий практический шаг — измерить цену одного трейса на вашей нагрузке и определить, какую потерю детализации команда готова принять ради ограничения затрат.