Adobe: Конвеєр OpenTelemetry, розроблений для простоти в масштабі

Від Johanna Öjeling (Grafana Labs), Juliano Costa (Datadog), Tristan Sloughter (community), Damien Mathieu (Elastic), Bogdan Stancu (Adobe) | 8 квітня, 2026

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

Організаційна структура

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

Конвеєр на базі OpenTelemetry був представлений як новий варіант поряд із поточними рішеннями для моніторингу, призначений переважно для нових застосунків і розгортань. Використання є добровільним, а не обовʼязковим. Застосунки з налагодженим моніторингом не були переведені на нову систему.

Впровадження OpenTelemetry

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

“Це повністю відповідало всьому, що ми хотіли,” сказав Богдан.

Оператор OpenTelemetry, модель компонентів Collector та Helm чарти від спільноти забезпечили будівельні блоки для пропозиції спостережуваності на рівні платформи, яка могла масштабуватися без потреби в глибоких знаннях OpenTelemetry від окремих команд сервісів.

Архітектура: Трирівневий конвеєр колектора

Архітектура колектора Adobe слідує трирівневому дизайну: Helm чарти для користувачів, що містять два колектори, централізований керований простір імен з розгортаннями колекторів для кожного типу сигналу, та бекенди спостережуваності.

Рівень 1: Helm чарт користувача

Команда з моніторингу надає Helm чарт, який команди сервісів розгортають у своїх власних просторах імен. Цей чарт створює два колектори:

Sidecar Collector (у поді застосунку): Працює поруч із контейнером застосунку і навмисно обмежений. Команди сервісів не можуть змінювати його конфігурацію. Він збирає всю телеметрію: метрики, логи, трасування, незалежно від того, що команда обрала для експорту далі по ланцюгу. Конфігурація незмінна, щоб запобігти перезапуску застосунку через зміни конфігурації.

Deployment Collector (standalone): Отримує телеметрію від sidecar через OTLP і обробляє маршрутизацію та експорт. На відміну від sidecar, цей колектор може бути налаштований через значення Helm. Команда з моніторингу надає відповідні стандартні значення, але команди сервісів можуть налаштовувати експортери та додавати нові призначення. Коли конфігурація змінюється, перезапускається лише deployment collector. Под застосунку та його sidecar залишаються незмінними.

Рівень 2: Керований простір імен

Колектори deployment пересилають телеметрію до централізованого простору імен, який повністю керується командою з моніторингу. Важливе архітектурне рішення тут — ізоляція на рівні сигналів: керований простір імен запускає окреме розгортання колектора для кожного типу телеметрії: один для метрик, один для логів і один для трасувань.

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

Команди сервісів налаштовують бажаний бекенд через значення Helm, що встановлює HTTP-заголовок на експорт OTLP. Колектори керованого простору імен використовують цей заголовок з routing connector для направлення телеметрії до правильного експортера.

Рівень 3: Бекенди спостережуваності

Колектори керованого простору імен експортують телеметрію до бекендів, якими керує команда з моніторингу. Підтримується кілька бекендів, і команди обирають своє призначення через файл значень Helm.

Автоінструментування: Два рядки і все працює

Adobe використовує OpenTelemetry Operator для автоінструментування мов, підтримуваних OpenTelemetry. Оператор розгортається в кожному кластері, а команди сервісів включають інструментування, додаючи дві анотації до своїх маніфестів розгортання Kubernetes:

instrumentation.opentelemetry.io/inject-java: 'true'
sidecar.opentelemetry.io/inject: 'true'

“Люди додають два рядки у своє розгортання. І все працює,” сказав Богдан.

Команди обирають свою мову у значеннях Helm, а Оператор займається рештою. Хоча команди можуть додавати ручне SDK-інструментування, sidecar приймає всі дані OTLP, підтримуваний шлях команди спостережуваності зосереджений на досвіді автоінструментування. Оператор впорався з масштабом управління sidecars та автоінструментуванням у всьому флоті розгортання без проблем.

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

Власний дистрибутив та компоненти

Adobe створює власний дистрибутив OpenTelemetry Collector, щоб включати лише ті компоненти, які вони використовують, уникаючи непотрібних залежностей від Contrib. Цей власний дистрибутив є стандартним у Helm-чарті, наданому командам сервісів. Однак команди можуть вручну переключитися на дистрибутив Contrib, якщо їм потрібні компоненти, які не включені у власну збірку.

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

Проблема ланцюгових колекторів

Коли колектори зʼєднані в ланцюг, видимість помилок стає проблемою. Транзакція OTLP між колектором розгортання користувача та колектором керованого простору імен завершується з відповіддю 200 до того, як колектор керованого простору імен намагається експортувати дані до бекенду. Якщо бекенд відхиляє дані, помилка видна лише в журналах колектора керованого простору імен.

“Користувач бачив би лише 200. Метрики експортовані, все добре,” пояснив Богдан. “Чого ми не хотіли.”

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

Створення цього розширення було одним з перших проєктів Богдана на Go. Досвід спроби внести внесок у upstream спричинив глибше залучення до спільноти OpenTelemetry. У майбутньому Богдан хотів би бачити більш загальний механізм зворотного тиску в Collector, де відмови експортерів поширюються вгору через ланцюгові колектори.

Розгортання та управління життєвим циклом

Команда спостереження оновлює свій дистрибутив колектора та OpenTelemetry Operator щоквартально. Проблеми з оновленням були рідкісними.

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

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

Навігація по застарілих компонентах

Розгортання Adobe також стикалося з проблемою застарілих компонентів у міру розвитку OpenTelemetry. Команда спочатку використовувала процесор маршрутизації для направлення телеметрії до різних бекендів на основі HTTP-заголовків, але перейшла на конектор маршрутизації, коли процесор був застарілим.

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

“Це ризик, про який ми знали, весь ландшафт OpenTelemetry постійно змінюється, і переваги перевищують ‘проблеми’, якщо можна назвати швидку розробку проблемою,” пояснив Богдан.

Що працює добре

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

Поради для інших

На основі досвіду Adobe у створенні платформи спостережуваності на рівні платформи:

• Розглядайте OpenTelemetry як платформу для розвитку: Не очікуйте, що вона вирішить усі ваші проблеми з коробки. Вона призначена для розширення та налаштування під ваші конкретні потреби.
• Не бійтеся створювати власні компоненти: Архітектура Collector дозволяє легко створювати розширення, адаптовані до ваших потреб.
• Проєктуйте для простоти користувача: Зробіть так, щоб стандартний шлях вимагав мінімальних зусиль. Команди, що використовують вашу платформу, не є експертами в спостережуваності.
• Плануйте видимість помилок у ланцюжкових колекторах: Успішна транзакція OTLP не гарантує доставки від початку до кінця. Розгляньте, як помилки будуть відображатися користувачам.

Висновки

Історія Adobe ілюструє, як центральна команда спостережуваності може запропонувати масштабовану, самостійно обслуговувану конвеєрну систему OpenTelemetry у великій та різноманітній організації. Поєднуючи Operator, Helm-чарти, sidecar-и та розгортання колектора для кожного сигналу, вони створили платформу, де команди сервісів отримують спостережуваність з мінімальними зусиллями, тоді як команда спостережуваності зберігає контроль над централізованою інфраструктурою.