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

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

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

Програмовані інфраструктури зазвичай постачаються зі способом попереднього перегляду змін. 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 додає жив вимір.

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

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

Рівень 3: Пробне підключення OTLP

Тут стає цікаво.

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

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

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

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

Передбачуваність пам’яті

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У свідомій формі тільки для читання.

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

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

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

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

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

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

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

Що далі?

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

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