Организациям абсолютно необходимо извлечь из своих телеметрических данных как можно больше пользы по ряду причин. Сбор телеметрических данных или возможность наблюдения также является, по меньшей мере, очень сложной задачей.
С одной стороны, включение крана для быстрого получения всех метрик, которые генерирует среда, становится, мягко говоря, громоздкой и неуправляемой ситуацией, не говоря уже о том, что она недоступна для большинства, если не для всех, организаций.
Слишком малая выборка данных метрик означает, что в данных, скорее всего, отсутствуют ключевые элементы для отладки, интерпретации или мониторинга потенциальных сбоев и других проблем. Оптимизация операций и развития становится некорректной, неточной или ненадежной. Кроме того, использование неправильных данных выборки для показателей практически не помогает.
Эта проблема усугубляется, или эта динамика или дилемма усугубляется, для очень крупных предприятий, таких как, в данном случае, Capital One Bank.
Во время мероприятия Observability Day в преддверии KubeCon + CloudNativeCon North America инженеры Capital One Джозеф Найт и Сатиш Мамидала показали, как они использовали OpenTelemetry для решения задач трассировки выборочных данных и смогли внедрить это во всех операциях Capital One по всему миру.
Их усилия окупились: они сообщили о сокращении объемов данных отслеживания на 70%.
Это была непростая задача, но OpenTelemetry послужила основой их гигантского проекта, который они подробно описали в своей презентации на KubeCon.
Переход Capital One на @OpenTelemetry: Джозеф Найт и Сатиш Мамидала обсудили, почему это было необходимо, во время своего доклада «От перегрузки данных к оптимизированному анализу: реализация выборки OTel для более разумной наблюдаемости» перед #KubeCon NA. @linuxfoundation pic.twitter.com/qZMtmn4Jdx
— BC Gain (@bcamerongain), 11 ноября 2025 г.
Как сказал Найт во время своего выступления, показатели Capital One предусматривали обработку «более петабайта в день без какой-либо выборки».
Решение потребовало развертывания выделенной инфраструктуры. Выборка на основе хвоста требует превращения ее в проблему горизонтального масштабирования, поскольку вы должны «соединить все интервалы для трассировки, прежде чем сможете принять решение о выборке», — сказал Найт.
Это, добавил он, привело к тому, что сборщики были разделены на несколько слоев: экспортер с балансировкой нагрузки, уровень сборщика, а затем уровень процессора выборки, и все они полностью посвящены трассировке.
Почему Capital One предпочла OpenTelemetry инструментам поставщика
Прежде чем внедрить OpenTelemetry, инженеры Capital One полагались на инструменты поставщиков, которые реализовали свои собственные, часто разрозненные стратегии выборки, обычно обеспечивая только выборку на основе головы, в которой решение сохранять отслеживание или нет принимается в начале запроса.
OpenTelemetry «дала нам новую точку зрения на то, что отбор проб с головы не очень эффективен», — сказал Найт.
Нынешний подход с OTel предлагает два ключевых преимущества, сказал Найт. Во-первых, централизованная команда теперь может контролировать стоимость распределенной трассировки. Этот контроль гарантирует, что широкое внедрение возможно при имеющихся ресурсах.
Во-вторых, команда может предоставить командам разработчиков приложений гарантии того, что «они смогут увидеть определенное поведение в своем инструменте», например конкретные ошибки, что создает «гораздо больше уверенности в том, как выборка влияет на трассировки, поступающие из их приложения», — сказал Найт. Этого, добавил он, «невозможно достичь с помощью микро-, вероятностных или смертельных выборок».
Рекомендации по обеспечению полезности выборочных данных трассировки
Ключом к повышению полезности выборочных данных является добавление тегов. Команда Capital One добавляет теги к выбранным трассировкам, чтобы указать, как они были выбраны и с каким вероятностным соотношением они были выбраны. По словам Найт, это полезно в двух отношениях.
- Оценка: Команды могут оценить исходные данные трассировки, сгенерированные путем умножения значения трассировки на вероятностное соотношение, которое дает оценку того, сколько трассировок или запросов было сгенерировано до выборки.
- Историческая достоверность: По словам Найт, при непосредственной маркировке данных, если коэффициенты выборки изменяются с течением времени, исходные соотношения «включаются в исходные данные», что позволяет командам оглядываться назад, не замечая скачков с течением времени.
Более того, вместо того, чтобы полагаться на каждый интервал для получения информации о скорости, команды следует научить использовать метрики вместе с интервалами, чтобы получить более точную картину поведения системы.
«Мы экспортируем метрики семантического изобретения, гистограммы для каждого отдельного диапазона, который мы генерируем, как с сервера, так и на стороне вашего клиента», — сказал Найт.
Использование этих показателей для точных подсчетов означает, что «вам не нужен каждый интервал, чтобы понять скорость вашей системы», — сказал он. «Создание правил и руководств по переводу инструментов, оповещений и информационных панелей для использования показателей может облегчить этот переход».
Стратегический переход от выборки на основе «головы» к «хвосту»
По словам Найт, переход от выборки на основе головы к выборке на основе хвоста, при которой выборка происходит в конце трассы, оказался успешным. Команды теперь «очень рады, что теперь они получают гораздо лучшую картину от гонок, чем раньше», сказал он. Это связано с тем, что хвостовая выборка позволяет принять решение после получения всех промежутков и просмотра всей трассы.
Несмотря на трудности поиска правильного баланса между высокоскоростными и низкоскоростными приложениями, ключевым моментом является постоянная ориентация на динамическую адаптацию процессора хвостовой выборки. Команда Capital One намерена опубликовать это исследование в открытом доступе.
Текущие проблемы и будущие цели в области выборки данных
Это сокращение объема следов на 70% может быть впечатляющим, но команда смотрит на оставшиеся 30% и задается вопросом: «Как мы можем добиться большего?» — сказал Найт.
По его словам, главной проблемой является «перетягивание каната» между высокочастотными (высокочастотными) и низкочастотными (низкочастотными) событиями в вероятностных соотношениях. Высокоскоростные приложения могут обрабатывать гораздо меньшую вероятностную скорость, в то время как низкоскоростные приложения «голодают» при более низком коэффициенте. В масштабе адаптировать набор правил для каждого конкретного приложения невозможно.
В настоящее время основное внимание уделяется созданию усовершенствований процессора хвостовой выборки, которые дадут системе возможность, как сказал Найт, «адаптироваться к частоте событий, которые мы видим динамически, без изменений конфигурации с нашей стороны».
Современный цифровой мир требует устойчивости и исключительной производительности. Цифровые предприятия обращаются к платформе и опыту Catchpoint IPM, чтобы активно выявлять и решать проблемы в Интернет-стеке до того, как они повлияют на клиентов или сотрудников. Интернет полагается на Catchpoint. Узнайте больше Последние новости от Catchpoint. ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. BC Gain — основатель и главный аналитик ReveCom Media. Его одержимость компьютерами началась, когда в начале 1980-х он взломал консоль Space Invaders, чтобы играть весь день за 25 центов в местном игровом зале. Затем он… Подробнее от Б. Кэмерона Гейна.
