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

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

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

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

Ця прогалина стала причиною створення Signal Studio.

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

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

Якщо ви працювали з OpenTelemetry Collectors на значному масштабі, ви, напевно, мали розмову, яка виглядає приблизно так:

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

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

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

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

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

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

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

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

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

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

Рівень 3: OTLP sampling tap

Саме тут стає цікаво.

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

Запит до бекенду

«Чому б не просто запитати бекенд?» – можливо, ви подумали. Це зрозуміле питання, і хоча це безумовно можливо, підхід має одну серйозну недолік. Бекенд бачить метрики з усіх джерел, а не тільки цього Collectora.

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

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

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

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

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

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

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

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

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

Розрахунок рівня впевненості простий і свідомий: менше 5,000 спостережуваних точок даних вважаються «низьким» рівнем, 5k-50k – «середнім», а понад 50k – «високим». Жодна хибна точність. Пороги навмисно є евристичними та видимими; мета – комунікувати розмір вікна, а не статистичну певність.

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

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

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

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

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

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

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

Мета полягає в тому, щоб полегшити ухвалення рішення, чи діяти, чи відкласти.

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

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

Навмисно тільки для читання.

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

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

Єдиний бінарний файл, без збереження даних

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

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

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

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

Що далі?

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

мене цікавить, як інші перевіряють вплив змін фільтрів перед їх впровадженням у виробничі OpenTelemetry Collectors?

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