Що 10 000 повідомлень Slack розкривають про виклики впровадження OpenTelemetry

Протягом останніх кількох років спільнота OpenTelemetry значно зросла, і разом із цим зростанням зʼявилися цінні інсайти, приховані в наших дискусіях. Ми проаналізували майже 10 000 повідомлень з каналів #otel-collector та #opentelemetry в CNCF Slack за період з травня 2019 року по грудень 2025 року, щоб зрозуміти, з якими проблемами користувачі стикаються найчастіше, які компоненти викликають найбільше обговорень і де спільноті можуть знадобитися додаткові документи або вдосконалення інструментів.

Набір даних

Наш аналіз охопив 9 966 повідомлень у двох найактивніших каналах OpenTelemetry Slack:

• #otel-collector: 5 570 повідомлень (56%)
• #opentelemetry: 4396 повідомлень (44%)

Ці повідомлення поділяються на кілька категорій:

Висока частка питань та повідомлень про помилки (разом понад 72%) свідчить про те, що ці канали є важливими ресурсами підтримки для спільноти, а теми, які зʼявляються найчастіше, відображають реальні проблеми з впровадженням.

Ми застосували моделювання тем за допомогою BERTopic для групування подібних повідомлень, а потім проаналізували показники настрою та розчарування, щоб визначити, які теми викликають найбільші труднощі. Повідомлення, що містять доповіді про помилки, повторювані запити про допомогу або висловлювання про розгубленість, отримали вищі оцінки за нашим показником розчарування.

Найобговорюваніші компоненти Collector

Моделювання тем виявило чіткі закономірності, за якими компоненти Collector генерують найбільше обговорень у спільноті. Ось найпопулярніші компоненти за обсягом повідомлень:

1. Receiver і Exporter Prometheus (498 повідомлень, 5,0%)

Інтеграція Prometheus домінує в обговореннях спільноти. Користувачі часто запитують про:

• Налаштування приймача Prometheus для збору метрик
• Налаштування експортера віддаленого запису Prometheus
• Розуміння типу метрик та збереження метаданих у всьому конвеєрі
• Інтеграція з наявною інфраструктурою Prometheus

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

2. Процесор k8sattributes (258 повідомлень, 2,6%)

Збагачення метаданих Kubernetes є другою за популярністю темою. До типових викликів належать:

• Асоціація Podʼів та вилучення метаданих у розгортаннях DaemonSet
• Дозволи RBAC для доступу до API Kubernetes
• Вплив на продуктивність у великих кластерах
• Взаємодія з приймачем kubeletstats

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

3. Процесор вибірки наприкінці (167 повідомлень, 1,7%)

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

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

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

4. Kafka Receiver та Exporter (131 повідомлення, 1,3%)

Інтеграція Kafka зʼявляється часто, особливо в таких випадках:

• Проблеми з підключенням та автентифікацією в службах Kafka, що надаються провайдерами (AWS MSK)
• Конфігурація тем та управління групами споживачів
• Формат повідомлень та серіалізація
• Моделі розгортання з високою доступністю

5. Процесор обмежувача памʼяті (125 повідомлень, 1,3%)

Управління ресурсами є постійною проблемою:

• Правильна конфігурація обмеження памʼяті відносно обмежень контейнера
• Взаємодія GOMEMLIMIT з обмежувачем памʼяті
• Налагодження піків памʼяті та ситуацій OOM
• Профілювання використання CPU за допомогою pprof

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

10 найпоширеніших проблемних областей та болючих точок

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

1. Помилки підключення та експорту

Найбільше розчарування викликають помилки експорту OTLP, зокрема:

• Помилки DEADLINE_EXCEEDED під час експорту до бекендів
• Проблеми з конфігурацією TLS у балансувальниках навантаження
• Плутанина між протоколами gRPC та HTTP
• Проблеми з підключенням за проксі-серверами або в хмарних середовищах

2. Дистрибутиви власних колекторів

Створення власних дистрибутивів за допомогою ocb (OpenTelemetry Collector Builder) викликає значне розчарування:

• Конфлікти версій між компонентами
• Помилки під час побудови на певних платформах (особливо болісно на Windows MSI)
• Проблеми з вирішенням залежностей
• Розуміння, які компоненти слід включити

3. Синтаксис конфігурації та валідація

Багато користувачів стикаються з проблемами базової конфігурації:

• Помилки синтаксису YAML, які створюють заплутані повідомлення про помилки
• Розуміння відносин між отримувачами, процесорами та експортерами
• Конфігурація конвеєра та потік даних
• Синтаксис підстановки змінних середовища

4. Поширення контексту

Основи розподіленого трасування викликають непорозуміння:

• Формати контексту трасування B3 чи W3C
• Поширення «багажу» через межі сервісів
• Операції видобування та впорскування в SDK
• Проблеми міжмовного поширення

5. Управління атрибутами та ресурсами

Розуміння моделі даних виявляється складним:

• Коли використовувати атрибути ресурсу чи атрибутів відрізків/метрики/логів
• Переміщення атрибутів між рівнями ресурсу та сигналу
• Відповідність семантичним домовленостями
• Кардинальність атрибутів та її вплив

6. OTTL (OpenTelemetry Transformation Language)

Хоча OTTL є потужною, вона викликає непорозуміння:

• Синтаксис функцій та доступні операції
• Шляхи та доступи, специфічні до контексту
• Відлагодження збоїв трансформацій
• Наслідки для продуктивності складних трансформацій

7. Kubernetes Operator та Автоінструментування

Оператор спрощує розгортання, але вводить свої власні виклики:

• Впровадження інструментації не працює, як очікувалося
• Різні режими розгортання колекторів (DaemonSet, Sidecar, Deployment)
• Варіанти конфігурації CRD
• Виправлення помилок впроваджених агентів

8. Інтеграція з бекендом

Підключення до бекендів спостережуваності вимагає зусиль:

• Конфігурація Jaeger та міграція з застарілих налаштувань
• Конфігурація експортерів, специфічних для постачальника
• Атестація та авторизація з керованими сервісами
• Мультибекендна маршрутизація

9. Розгортання Docker та контейнерів

Проблеми, повʼязані з контейнерами, виникають регулярно:

• Вибір образу (contrib чи core)
• Доступність версій на Docker Hub
• Створення власного образу
• Обмеження ресурсів та налаштування продуктивності

10. Поведінка черги та повторних спроб

Розуміння поведінки допоміжного експортера:

• Конфігурація та зберігання постійної черги
• Політики повторних спроб та поведінка затримки
• Сценарії втрати даних та їх запобігання
• Розмір черги для розгортань з високим обсягом

Що це нам говорить

З цього аналізу виникає кілька тем:

Екосистема Prometheus залишається центральною. Організації не відмовляються від Prometheus; вони інтегрують його з OpenTelemetry. Документація та інструменти, що зʼєднують ці екосистеми, залишаються цінними.

Складність Kubernetes ускладнює складність OTel. Обговорення процесора k8sattributes та Оператора показують, що середовища Kubernetes вносять додаткові рівні конфігурації та усунення несправностей. Спрощені шаблони розгортання та кращі стандартні значення могли б допомогти.

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

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

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

Далі вперед

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

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

Подяки

Дякуємо всім, хто бере участь у спільноті OpenTelemetry в Slack. Ваші запитання, повідомлення про помилки та обговорення не тільки допомагають один одному, але й надають цінний сигнал про те, де проєкт може покращитися. Особлива подяка учасникам спільноти, які знаходять час, щоб відповідати на запитання та ділитися своїм досвідом — 1% відповідей на запити у наших даних представляють безліч годин волонтерської роботи, яка робить цю спільноту гостинною для новачків.

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

• ←Попередня
• Наступна→