Розвиток методів стабілізації та випуску OpenTelemetry
Короткий огляд
OpenTelemetry є, за будь-якими показниками, одним з найбільших і найцікавіших проєктів у сфері хмарних технологій. Протягом останніх п\яти років ця спільнота обʼєдналася, щоб створити один з найважливіших проєктів з моніторингу в історії. Однак ми не зупиняємося на досягнутому. Проєкт постійно шукає та прислухається до відгуків широкого кола зацікавлених сторін. З ваших відгуків ми розуміємо, що для переходу на наступний рівень нам потрібно скоригувати пріоритети та зосередитися на стабільності, надійності та організації випусків проєкту та артефактів, таких як документація та приклади.
Протягом останнього року ми провели низку інтервʼю з користувачами, опитувань та відкритих дискусій у різних місцях. Ці дискусії продемонстрували, що складність та нестабільність OpenTelemetry створюють перешкоди для впровадження у промислову експлуатацію.
У цій публікації викладено цілі та завдання, які, на думку Керівного комітету, є ключовими для врахування цих відгуків. Ми починаємо з цієї публікації, щоб провести ці дискусії публічно.
Наші цілі
- Забезпечити, щоб усі дистрибутиви OpenTelemetry були “stable by default” (стабільними) і надавали стандартизовані механізми для користувачів, щоб вони могли підключити експериментальні або нестабільні функції.
- Мати єдиний, чіткий і послідовний набір критеріїв стабільності, що включає документацію, тестування продуктивності, тести продуктивності тощо.
- Спростити стабілізацію бібліотек інструментарію та заохочувати обʼєднання семантичних домовленостей.
- Впровадити “epoch releases” («епохальні випуски»), які легше сприймаються організаціями кінцевих користувачів .
Ми будемо вдячні за ваші відгуки!
Супровідники та учасники, ми будемо вдячні за ваші відгуки щодо цієї пропозиції в цілому та щодо конкретних питань, таких як терміни впровадження, вимоги до переходу на інші рівні стабільності та способи обробки міграції телеметричних даних.
Кінцеві користувачі, ми будемо вдячні за ваші відгуки щодо того, як ви бажаєте впроваджувати випуски OpenTelemetry і як ви це робите зараз. Оскільки ми оцінюємо різні стратегії версій та випусків, нам було б корисно зрозуміти, як ви зараз впроваджуєте зміни, особливо в багатомовних середовищах. Ми також будемо вдячні за ваші відгуки щодо документації та тестування продуктивності таких компонентів, як бібліотеки інструментарію, Collector тощо.
Від інтеграторів, постачальників та ширшої екосистеми ми будемо вдячні за відгуки та конструктивні пропозиції щодо інструментування, семантичних домовленостей, метаданих та виявлення. Від інтеграторів, які працюють на базі OpenTelemetry або паралельно з ним, ми хотіли б дізнатися, як ми можемо полегшити вам та вашим користувачам використання OpenTelemetry, а також як ми можемо полегшити вам публікацію та підтримку вашого власного інструментування.
У наступних розділах цього блогу є інші конкретні запити, щодо яких ми будемо вдячні за ваші відгуки. Будь ласка, памʼятайте, що конкретні способи досягнення цих цілей не є остаточними — саме тому ми хочемо отримати ваші відгуки щодо пропозицій! Якщо ви вважаєте, що є кращий спосіб досягнення цих цілей, будь ласка, повідомте нам про це в обговоренні.
Чому ми це робимо?
OpenTelemetry перетворився на величезну, складну екосистему. Ми підтримуємо чотири різні сигнали телеметрії (трасування, метрики, журнали та профілі) у більш ніж десятку мов програмування. Кожна мова має свої вимоги до середовища виконання та середовища роботи. Матриця відповідності специфікаціям показує, скільки ми намагаємося досягти — і це вражає.
Ця складність створює реальні перешкоди для впровадження. Організації, готові розгорнути OpenTelemetry у промисловій експлуатації, стикаються з несподіваними перешкодами: конфігурація, яка змінюється між незначними версіями, регресії продуктивності, які проявляються тільки в масштабі, та проблема координації розгортання сотень або тисяч служб. В результаті багато команд змушені відкладати або скорочувати розгортання OpenTelemetry.
Для розробників ця складність ускладнює їхню роботу. Бракує чітких орієнтирів і вказівок щодо того, що є «найважливішим» у певний момент. Робота над стабільністю вимагає багато зусиль, і часто виникають суперечливі вказівки щодо того, на чому слід зосередити свою увагу.
Вирішення цих проблем має бути пріоритетним завданням для проєкту, як для збереження працездатності наших розробників і учасників, так і для того, щоб ми могли продовжувати рости і масштабуватися в міру нашого розвитку, особливо в міру того, як ми все глибше інтегруємося в хмарну екосистему.
Керівний комітет вважає, що для успіху цих змін необхідна участь спільноти та обговорення, тому ми користуємося цією нагодою, щоб оголосити про наші наміри та розпочати обговорення на GitHub з метою отримання відгуків від користувачів, розробників та учасників. Ми не очікуємо, що ці зміни будуть завершені за одну ніч, і хочемо запевнити всіх, що ми продовжимо надавати пріоритет нашим поточним зобовʼязанням перед користувачами та розробниками, навіть якщо ми розглядаємо необхідні зміни для загального добробуту та розвитку проєкту.
1. Стабільність
Гарантії стабільності є давнім принципом OpenTelemetry, з надзвичайно високими вимогами. Існує певна розбіжність між цим принципом та потребами користувачів, яку ми хотіли б обговорити.
Передісторія
OpenTelemetry — це специфікація, що визначає, як хмарне програмне забезпечення (бібліотеки, фреймворки, абстракції інфраструктури, виконуваний код тощо) генерує та передає телеметричні дані про свою роботу. Ця специфікація є вичерпною, всеосяжною та низькорівневою. Більшість елементів специфікації — це знання, здобуті авторами за десятиліття досвіду у створенні, експлуатації та проєктуванні систем телеметрії в глобальному масштабі.
Однак специфікація без реалізації не є корисною для кінцевих користувачів. Розробники та оператори підходять до телеметрії з різних точок зору. Деякі організації мають високі стандарти спостережуваності, і цілі команди присвячують себе створенню внутрішніх фреймворків моніторингу та інструментування. Інші організації розглядають спостережуваність і моніторинг як пріоритет другого або третього порядку — щось, що має відбуватися, але не є стимулом. OpenTelemetry, як специфікація, має обслуговувати всіх цих користувачів та їхні випадки використання.
Щоб зробити OpenTelemetry корисним, нам потрібно забезпечити «перехід» від вже наявних методів і режимів, інструментів і стратегій, а це означає, що ми повинні надати не тільки реалізацію специфікації, але й її застосування. На практиці це означає, що нам потрібно розповсюджувати бібліотеки для додавання інструментарію OpenTelemetry до наявних HTTP-серверів і клієнтів або приймачів Collector для збору метрик з MySQL і перетворення їх в OTLP.
Найбільшу цінність, яку наша спільнота отримує від OpenTelemetry, складають саме бібліотеки інструментування та компоненти Collector, а не основні SDK. Хоча ми організовуємо їх як репозиторії contrib, щоб відрізнити їх від основних компонентів, кінцеві користувачі не бачать і не переймаються цим розрізненням. Вони просто хочуть інструментування, що працює.
Для адміністраторів та керівників проєктів наші цілі щодо стабільності та природа «contrib» становлять значний виклик. Користувачі хочуть стабільних, добре протестованих та продуктивних випусків, які також виконують ті самі функції, що й комерційні агенти інструментування.
Цілі та завдання
Загалом, у цьому напрямку є три основні пункти:
- Усі компоненти у всіх репозиторіях (включно з семантичними домовленостями) повинні дотримуватися єдиного підходу до повідомлення про стабільність за допомогою файлу/інформації метаданих, які можна знайти та проаналізувати програмним способом. Точний формат повинен бути визначений за допомогою OTEP і включений до специфікації.
- Вимоги до стабільності повинні бути розширені, щоб включити більше вимог щодо документації та місця її розміщення, прикладів коду, тестів продуктивності (де це доречно), посібників з впровадження та інших необхідних артефактів.
- Стабільні дистрибутиви OpenTelemetry повинні підтримувати лише стабільні компоненти. Користувачі повинні мати можливість вибрати бажаний мінімальний рівень стабільності за допомогою документованих та уніфікованих опцій налаштувань.
Ми розуміємо, що це буде великою зміною для розробників, особливо тих, хто випустив версії v1+ своїх бібліотек. Будемо вдячні за ваші відгуки щодо цих цілей у дискусії.
2. Стабільність інструментування та семантичних домовленостей
Щоб досягти наших цілей щодо стабільності, нам також потрібно буде вирішити питання стабільності семантичних домовленостей та процесів.
Проблеми семантичних домовленостей
Семантичні домовленості розвиваються поступово і обережно, оскільки вони повинні працювати в різних телеметричних системах. Хоча OpenTelemetry призначений для взаємоповʼязаних сигналів, що надходять разом, користувачі використовують багато різних механізмів зберігання та аналізу для обробки цих даних. Кожен бекенд має свої обмеження та можливості. Розробники повинні збалансувати суперечливі інтереси — підтримувати керовану кардинальність, забезпечувати корисність атрибутів, але не надто конкретних, та створювати домовленості, які добре працюють незалежно від того, де опиняються дані.
Недоліком цього є те, що прогрес у розробці семантичних домовленостей може бути повільним, а ця повільність впливає на всіх споживачів домовленостей. Багато бібліотек інструментування наразі застрягли на попередніх версіях, оскільки вони залежать від експериментальних семантичних домовленостей. Зовнішні учасники застрягли між випуском невизначеної телеметрії та спробами долучитися до процесу, що вимагає тривалих зусиль. Нарешті, ми маємо внутрішню невідповідність в інструментарії в рамках проєкту; одні бібліотеки відповідають домовленостям, інші існують незалежно від них.
Мета інструментування та домовленостей
Наша мета полягає у досягненні трьох результатів.
- Стабільність інструментування повинна бути відокремлена від стабільності семантичних домовленостей. Ми маємо багато стабільних інструментів, які безпечно використовувати у промисловому масштабі, але дані яких можуть змінитися у майбутньому. Користувачі повідомили нам, що поєднання цих двох рівнів стабільності є заплутаним і обмежує їхні можливості.
- Семантичні домовленості повинні бути більш федеративними; OpenTelemetry не повинно бути остаточним словом щодо того, які домовленості існують, а замість цього повинно зосередитися на створенні основних домовленостей, які можна розширювати та розвивати.
- Розробка та оновлення семантичних домовленостей не повинні бути перешкодою для розробників дистрибутивів.
З цією метою ми маємо кілька рекомендацій, які хотіли б закріпити в специфікації. По-перше, наша позиція щодо бібліотек інструментування в OpenTelemetry полягає в тому, що вони існують як конкретні реалізації семантичних домовленостей. Це дає нам конкретну мету для бібліотек інструментування «first party», які ми хочемо підтримувати в дистрибутивах. Крім того, розробники повинні надавати пріоритет інструментуванню, яке відповідає наявним домовленостям, і знижувати пріоритет інших.
По-друге, ми хотіли б полегшити розробникам постачання стабільних інструментаріїв. Якщо API-інтерфейс інструментування є стабільним, то, на нашу думку, стабільність семантичної домовленості не повинна перешкоджати стабілізації цієї бібліотеки інструментування. Це означає, що нам потрібно буде ретельно продумати шляхи міграції для телеметрії, коли оператори переходять на нові основні версії бібліотек інструментування.
Нарешті, ми хотіли б полегшити третім сторонам публікацію власних семантичних домовленостей шляхом формалізації та стабілізації необхідних частин семантичних домовленостей, щоб інші організації могли поширювати домовленості для своїх бібліотек, фреймворків, технологічних стеків тощо.
Для цього ми очікуємо відгуки від розробників та кінцевих користувачів у кількох сферах, особливо щодо зрілості/життєвого циклу семантичних домовленостей, а також щодо того, чого бракує для федералізації семантичних домовленостей. Ми більш гнучкі щодо пропозицій, але наші висновки — ні. Памʼятайте, що основною метою проєкту є заохочення інших бібліотек, інструментів та фреймворків до впровадження OpenTelemetry — семантичні домовленості відіграють у цьому важливу роль.
3. Впевнені та стабільні випуски
Виклик
OpenTelemetry — це не просто один бінарний файл, розгорнутий у кластері Kubernetes. Незначні відмінності у всьому, від конфігурації до виводу телеметрії, між різними версіями бібліотек інструментування приймачів Collector та SDK можуть стати справжнім головним болем для користувачів. Крім того, швидкий темп випуску багатьох компонентів створює реальні труднощі для кінцевих користувачів, особливо навколо Collector. Розгортання та оновлення в корпоративних середовищах є повільними та виваженими процесами — команди просто не мають достатніх ресурсів для перевірки та впровадження змін з такою швидкістю, з якою ми їх випускаємо.
Цілі та стратегія випуску
Зрештою, наша мета полягає в тому, щоб полегшити великим організаціям розгортання OpenTelemetry. Майте на увазі, що в багатьох організаціях «розгортання» та «оновлення» є нетривіальними завданнями, які вимагають залучення багатьох команд та зацікавлених сторін з різних бізнес-підрозділів або сфер відповідальності, включаючи безпеку.
Наша поточна пропозиція полягає у створенні групи Release SIG, яка буде відповідати за створення графіка «епохальних» випусків для OpenTelemetry. Ці епохальні версії будуть, по суті, маніфестом, що вказує на перевірений, задокументований і стабільний набір компонентів, які відповідають вимогам стабільності проєкту.
Слід зазначити, що це нетривіальне завдання. Адже ці зусилля будуть визначати багато вимог, яким повинні відповідати ці епохальні випуски. Для наших розробників та учасників ця робота не має на меті змінити спосіб встановлення версій або випуску окремих компонентів, SDK або API. Натомість ми хочемо надати перевірені, стабільні комбінації випусків, які добре працюють разом для кінцевих користувачів, які потребують цієї стабільності.
Для кінцевих користувачів ми будемо вдячні за відгуки про те, як ви зараз керуєте оновленнями, що ви хотіли б бачити в цій області, а також про ваші поточні проблеми з розгортанням та оновленням SDK та колекторів.
З надією на майбутнє
Ці зміни є відображенням впливу та важливості OpenTelemetry для спільноти розробників хмарного програмного забезпечення. OpenTelemetry був другим за швидкістю розвитком проєктом у CNCF протягом останніх кількох років, і майже 50% опитаних компаній-кінцевих користувачів хмарних технологій впровадили цей проєкт. Ці зміни відкривають новий розділ нашого успіху і стають справді повсюдними.
Наша місія як проєкту не змінюється, але змінюються наші пріоритети.
- Стабільність і зручність використання для всіх розробників і користувачів.
- Чіткі шляхи пакування, встановлення та використання.
- Передбачуваність і послідовність.
Що це означає для учасників та адміністраторів? Ми будемо прискорювати розгляд пропозицій, які відповідають цим пріоритетам. Якщо є функції або інструменти, які не відповідають цим пріоритетам, це не проблема — ми просимо вас працювати над ними поза проєктом і виявляти, де наші поточні точки інтеграції та шаблони не працюють. Це хороший відгук, який допоможе нам поліпшити специфікацію для всіх.
Для розробників, учасників та інтеграторів — ми будемо вдячні за ваш відгук у цій дискусії на GitHub щодо тем та пропозицій, порушених тут. Ви також можете надіслати відгук щодо цієї пропозиції на feedback@opentelemetry.io або у CNCF Slack в каналі #opentelemetry. Ми також з нетерпінням чекаємо на зустріч із спільнотою cloud native на KubeCon наступного тижня — приєднуйтесь до нас і діліться своїми коментарями!