Команди постійно впроваджують програмовані телеметричні канали в продуктивне середовище без можливості виконання тестування в “сухому” режимі. При цьому більшість організацій не мають тестових середовищ, що нагадують продукцію, особливо у відношенні спостережуваності та інших платформних сервісів. Незважаючи на усвідомлення потенційних ризиків, пов’язаних з відсутністю належної системи безпеки, більшість команд не мають альтернативного, безпечного способу визначити, які дані телеметрії вони можуть насправді скоротити, щоб покращити співвідношення сигналу до шуму без ризику пропустити щось важливе.

Тому команди змушені експериментувати з живим трафіком.

Те, що починається як проблема зберігання, швидко стає проблемою витрат через величезний обсяг збережених даних. Це не “ми, напевно, повинні на це подивитися”, а “ця стаття витрат конкурує з нашими витратами на обчислення”.

Програмована інфраструктура зазвичай поставляється з можливістю попереднього перегляду змін. Terraform має план. Бази даних мають EXPLAIN. Компілятори показують попередження. На жаль, OpenTelemetry Collector не має нічого з цього. Програмісти редагують YAML, перезавантажують процес і сподіваються, що не видалили щось, що їм знадобиться під час інциденту. Існують власні рішення, які допомагають зі зменшенням шуму та аналізом витрат, але нічого в відкритому просторі.

Ця прогалина спонукала мене створити Signal Studio.

Signal Studio додає діагностичний шар до OpenTelemetry Collectors – щось схоже на “сухий” або “план” режим для телеметричних каналів. Це реалізовано шляхом поєднання статичного аналізу конфігурації з живими метриками та епімерним OpenTelemetry Protocol (OTLP) доступом для оцінки поведінки фільтрів у порівнянні з спостережуваним трафіком.

Проблема з “просто додати більше фільтрів”

Якщо ви працювали з OpenTelemetry Collectors на значному рівні, ви, напевно, вели розмову, що звучить приблизно так:

“Наші витрати на телеметрію занадто високі.”
“Добре, давайте додамо кілька фільтрів.”
“Які метрики ми видаляємо?”
“…Ті, що нам не потрібні?”

Проблема не в тому, що команди не хочуть зменшити витрати на телеметрію. Справа в тому, що їм не вистачає видимості того, що насправді проходить через канал, які метрики є високими за обсягом, які атрибути підвищують кардинальність, і що насправді зробить даний вираз фільтрації. Звісно, вони можуть це дізнатися шляхом експериментів, але це ризиковано. Якщо вони помиляться, то або ризикують пропустити дані, які їм знадобляться під час інциденту, або не видалять достатньо даних для того, щоб покращити співвідношення сигналу до шуму.

Три рівні аналізу

Signal Studio працює в трьох шарах. Кожен шар додає більше контексту та дозволяє все більш конкретні рекомендації.

Рівень 1: Статичний аналіз

Перше, що робить Signal Studio, це аналізувати ваш Collector YAML та візуалізувати структуру каналу – приймачі, процесори, експортери – які групуються за типом сигналу. Крім того, він запускає набір статичних правил, які виявляють загальні помилки конфігурації, такі як відсутні memory_limiters, невизначені компоненти та необмежені приймачі.

Для кожного виявлення інструмент надає рівень серйозності, пояснення, чому це важливо, та невеликий фрагмент YAML, що пропонує можливе виправлення. На даному етапі, підключення до Collector не потрібно, і жодні зміни до вашої живої конфігурації не потрібні, що робить це дуже малоризикованим у порівнянні з експериментами з живим трафіком.

Рівень 2: Живі метрики

Хоча статичний аналіз інструменту може розповісти вам, що ви налаштували, він не зможе відповісти, що насправді відбувається у вашому каналі. Підключення Signal Studio до вашого Collector’s metrics endpoint додає живий вимір.

Діаграма каналу підсвічується з показниками пропускної спроможності для кожного сигналу, відсотками втрат та використанням черги експортерів. Це дозволяє виявити додаткові правила, щоб виявити високі показники втрат, домінування обсягу журналів, насичення черги та невідповідність між швидкістю приймача та експортером. Це питання виконання, які аналіз YAML не зможе виявити.

Незважаючи на те, що це вимагає встановлення з’єднання з Collector, воно залишається лише для читання, забезпечуючи мінімальний радіус дії, і не може зашкодити вашому живому розгортанню. Signal Studio опитує metrics endpoint з налаштованим інтервалом і обчислює швидкості на стороні сервера. Якщо з’єднання обривається, статична перевірка та всі знайдені дані залишаються в силі, доки не з’явиться з’єднання знову.

Рівень 3: OTLP зразковий доступ

Це те, де стає цікаво.

Signal Studio може створити легкий OTLP приймач, який підтримує як gRPC, так і HTTP, дозволяючи вам підключитися до вашої телеметрії, використовуючи експортера fan-out у вашій конфігурації Collector. Як тільки телеметрія починає проходити, Signal Studio каталогізує імена метрик, типи, кількість точок та – що найважливіше – метадані атрибутів. Вартість повторення на цьому етапі: нічого не зберігається, каталог зберігається тільки в пам’яті.

Запит до серверної частини

“Чому б просто не запитати сервер?” – ви можете запитати. Це законне питання, і хоча це, звичайно, можливо, підхід страждає від одного критичного дефекту. Сервер бачить метрики з кожного джерела, а не тільки з цього Collector.

Як ви можете собі уявити, атрибуція на сервері стає надзвичайно складною, якщо ви не збагачуєте точки даних додатковими метаданими. Цей підхід є інвазивним і залишає артефакти атрибуції на вашому сервері. Це також віддаляє аналіз від каналу, який вам насправді потрібно змінити.

Прогнозування пам’яті

Відстежувач атрибутів обмежений за дизайном: він зберігає до 25 прикладів значень на ключ атрибута на метрику, перш ніж перейти в режим лише підрахунку. Це зберігає пам’ять прогнозованою, все ще надаючи достатньо даних для значущих рекомендацій.

Якщо вираз фільтрації посилається на значення атрибута, яке не було спостережене в межах обмеженого вікна, результат стає “невідомим”, а не екстраполюється. Інструмент не намагається вгадати непомічені значення або прогнозувати поведінку у довгих хвостах. Це обмежена симуляція на основі спостережуваного трафіку, а не ймовірнісний оцінювач.

Аналіз фільтрів для вашого каналу

Зі знайденими іменами метрик та атрибутами, Signal Studio може зробити щось, що неможливо зробити лише зі статичним аналізом: передбачити, що зробить фільтр під час його застосування.

Він аналізує як застарілу синтаксис включення/виключення, так і сучасні вирази OpenTelemetry Transformation Language (OTTL), такі як name == "...", IsMatch(name, "..."), атрибути, що дорівнюють, regex патерни та HasAttrKeyOnDatapoint.

Для кожної виявленої метрики інструмент прогнозує, чи збережеться фільтр або буде видалений – або ж він просто не може це сказати, оскільки атрибута була надто високою кардинальності, і вибірка не зафіксувала відповідні значення.

Результат з’являється як пігулка на картці каналу: щось на зразок -34%, означаючи, що “цей фільтр зменшить обсяг точок даних приблизно на 34%, на основі того, що ми спостерігали.” Наведіть курсор на неї і ви негайно отримаєте повну картину – вікно спостереження, загальна кількість оцінених точок даних та рівень упевненості на основі розміру вибірки.

Розрахунок упевненості є простим та обдуманим: менше 5,000 спостережуваних точок даних вважаються “Низькими”, 5к-50к – “Середніми”, а понад 50к – “Високими”. Ніякої неправдивої точності. Пороги спеціально є евристичними та видимими; мета – донести розмір вікна, а не статистичну точність.

Якщо фільтри вже застосовані вище в каналі, ці точки даних ніколи не досягнуть доступу, і їхній вплив не може бути оцінений.

Рекомендації, які знають ваші дані

Третій рівень правил – каталожні правила – це те, де статичний аналіз стикається з живим відкриттям. Ці правила спрацьовують тільки коли фактичні дані метрик доступні, дозволяючи виявляти ризики кардинальності через високу кількість атрибутів, певні метрики, що домінують у даних, або збереження внутрішньої телеметрії Collector.

Ці правила переставляють розмову з “вам, напевно, слід додати фільтр”, до “метрика X має атрибут http.route з високою кардинальністю і є сильним кандидатом для зменшення атрибутів.” У кількох продуктивних впровадженнях, які я тестував, окремі метрики становили близько 60% загального обсягу телеметрії через Collector. Це важко зрозуміти, читаючи тільки YAML.

Точні рекомендації

Рекомендації є корисними лише тоді, коли їх читач може швидко зрозуміти та оцінити.

Signal Studio використовує просту модель: доказ → наслідок → рекомендація, обрамлену показником впевненості та тегом обсягу.

Метою є спростити рішення, виконати чи відкласти.

Загальні цілі

Працюючи над першою ітерацією Signal Studio, я зробив кілька виборів, які вплинули на інструмент:

Уважно лише для читання.

Signal Studio ніколи не записує у ваш Collector. OTLP доступ є опціональним і вимагає, щоб ви модифікували власну конфігурацію. Це було свідоме рішення – інструмент має бути безпечним для використання у продукції, без непотрібних переживань.

Аналогічно, немає кнопки “застосувати”, немає інтеграції GitOps, немає конвеєра розгортання. Користувач зберігає контроль. Це може здаватися відсутньою функцією, але це свідомий межовий обсяг – інструмент діагностує, людина вирішує. Хоча кожне діюче виявлення включає фрагмент YAML, який можна безпосередньо вставити у вашу конфігурацію Collector, ви вирішуєте, чи, і коли, це коли-небудь потрапить у ваші канали.

Одиничний бінарний файл, жодного збереження

Все живе в пам’яті. Ніякої бази даних, жодних файлів стану. Це робить розгортання тривіальним і зберігає малий радіус дії. На даний момент я не хочу мати справу з аспектами безпеки роботи з тіньовими сховищами телеметричних даних з усіма наслідками для ПІІ та пов’язаною складністю – і, майже напевно, ви також.

Чесність щодо невизначеності

Наприклад: коли трекер атрибутів досягає максимуму у 25 вибіркових значень, аналіз фільтрації повертає “невідомо”, замість того, щоб здогадуватись. Показники проекції показують рівні впевненості. Виявлення містять застереження, коли рекомендація залежить від контексту (наприклад, контейнерна мережа змушує зв’язування 0.0.0.0 бути необхідним).

Перебільшення обіцянок підриває довіру швидше, ніж незадоволення, і коли справа доходить до спостережуваності, ви часто отримуєте лише один шанс виконати обіцянки – що цілком заслужено.

Що далі?

Інструмент вже виконує те, що я спочатку уявляв, і буде отримувати нові функції тільки якщо вони вважаються достатньо корисними. Існують відкриті питання про перевірку сповіщень, виявлення ПІІ та оцінку кардинальності. Я розгляну їх окремо. Програмована інфраструктура без діагностичного шару виглядає неповною, і хоча я вірю, що результати цього експерименту були досить позитивними.

Мене цікавить, як інші перевіряють вплив змін фільтрів перед розгортанням їх у продуктивних OpenTelemetry Collectors.

Ви можете зв’язатися з нами через репозиторій проєкту.