3 сентября 2026 года The New Stack выпустил материал о старой боли SRE-команд: трассировка запросов полезна ровно до того момента, пока объем данных не начинает душить и бюджет, и саму систему. Для русскоязычной IT-аудитории здесь нет сенсации, зато есть неприятно точное напоминание: без sampling трейсов tracing легко превращается из инструмента диагностики в дорогой склад цифрового хлама.
Как пишет The New Stack, у каждого слоя наблюдаемости своя роль. Метрики быстро показывают, здорова ли система в целом. Логи помогают разобрать конкретный сбой. Но если нужно понять, где именно по дороге от пользовательского запроса до цепочки сервисов все пошло не туда, без трассировки не обойтись. Именно трейсы позволяют увидеть путь запроса через данные, микросервисы и пользовательский интерфейс, а значит быстрее локализовать причину инцидента, а не гадать по косвенным признакам.
Проблема в том, что идея «соберем вообще все» в tracing почти всегда звучит лучше на слайде, чем в проде. В материале это сформулировано без дипломатии: хранить все трассировки подряд — это скорее цифровое накопительство, чем разумная инженерная практика. Счет идет на терабайты данных, которые надо собрать, передать, сохранить, проиндексировать и потом еще попытаться в них что-то найти. Цена вопроса растет не только в облачном счете. Сам сбор телеметрии может тормозить систему, за которой команда вообще-то и пытается наблюдать. Ирония здесь довольно злая: чтобы лучше видеть прод, компания рискует сама ухудшить его поведение.
Отсюда главный тезис материала: tracing не сломан, сломана привычка относиться к нему как к бездонной корзине. The New Stack перечисляет три базовых подхода, которые позволяют не тонуть в данных. Первый — head sampling, когда система отбирает только часть трассировок на входе и сразу снижает нагрузку на хранение. Второй — tail sampling, когда решение о сохранении принимается уже после записи трейса, исходя из его ценности для дальнейшего анализа. Такой подход полезен, если команда хочет не просто экономить, а удерживать именно те цепочки запросов, которые указывают на ошибки, деградации или нестандартное поведение. Третий — dynamic sampling, то есть динамическое отсечение однотипных и повторяющихся трейсов, чтобы хранилище не забивалось миллионами почти одинаковых записей.
Почему это важно не только SRE
На первый взгляд тема кажется узкопрофессиональной: ну да, observability, телеметрия, внутренние кухни эксплуатации. Но на практике sampling трейсов давно вышел за пределы чистого SRE. Для разработчиков это вопрос скорости расследования инцидентов. Когда в системе десятки сервисов, асинхронные очереди, внешние API и несколько слоев кэша, разбираться в сбое по логам и метрикам можно долго и мучительно. Трассировка дает связный маршрут запроса. Если же трассировок слишком много, команда тратит время не на поиск причины, а на борьбу с собственным инструментарием.
Для продактов и руководителей инженерных команд это уже разговор про экономику платформы. Полный сбор телеметрии легко кажется безопасным выбором: якобы потом разберемся, данные лишними не бывают. На деле бывают, и еще как. Избыточный tracing ест бюджет на хранение и обработку, усложняет поиск аномалий и подталкивает команды к ложному чувству контроля. Данных много, а ответа на вопрос «почему сервис лег» по-прежнему нет. В этом смысле материал The New Stack попадает в нерв всей современной observability: зрелость платформы измеряется не тем, сколько телеметрии вы собрали, а тем, насколько быстро вы из нее достаете полезный сигнал.
Есть и еще один практический слой. В компаниях, где observability строилась по остаточному принципу, tracing нередко внедряют как модный обязательный пункт: добавили OpenTelemetry, подключили backend, включили экспорт — и будто бы задача закрыта. Но без политики отбора данных трассировка быстро начинает конфликтовать с реальностью продакшена. Чем выше нагрузка, тем дороже становится хранить все подряд. Чем больше микросервисов, тем легче утонуть в шуме. Чем выше цена минуты простоя, тем больнее каждая лишняя минута на поиски нужного трейса. В такой картине sampling трейсов — уже не оптимизация по желанию, а базовая гигиена эксплуатации.
Не максимальный сбор, а умный отбор
Важно и то, чего в материале нет. Это не анонс нового стандарта, не исследование с таблицами и не обещание волшебной кнопки. Скорее, это прагматичный манифест против инженерной жадности к данным. Сам материал помечен как спонсорский, и этот факт тоже полезно держать в голове: перед нами не нейтральная академическая статья, а рыночная постановка проблемы. Но даже в таком формате тезис звучит здраво. Системы наблюдаемости должны помогать искать сбои быстрее, а не превращаться в еще один источник сложности, который команда вынуждена обслуживать ради него самого.
Для российского рынка, где многие команды одновременно считают инфраструктурные затраты, переводят сервисы между площадками и поддерживают гибридные архитектуры без лишнего запаса по ресурсам, вывод особенно практичный. Если трассировка не умеет отбирать ценное, она начинает конкурировать с продом за деньги и внимание инженеров. А когда observability-инструмент сам становится проблемой производительности и стоимости, это уже не observability, а дорогое упражнение в самоуспокоении. Главный вопрос на ближайшее время звучит просто: будут ли команды и дальше мериться объемом собранной телеметрии или наконец начнут мериться скоростью, с которой находят реальный сбой.