Дослідження щодо використання OpenTelemetry Collector

У 2024 році End User SIG провела Collector Survey, щоб зібрати відгуки про те, як колектор OpenTelemetry використовується на практиці, та про досвід користувачів. Результати цього опитування вплинули на кілька рішень щодо розвитку та пріоритетності в рамках спільноти.

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

Основні висновки

• Розгортання колекторів продовжує масштабуватися (65% використовують понад 10 колекторів), при цьому Kubernetes залишається панівним (81%), а використання віртуальних машин (VM) значно зросло з 33% до 51%.
• Чверть користувачів з відносно невеликим розміром розгортання і приблизно половина користувачів з великим розміром розгортання використовують як Kubernetes, так і ВМ.
• Ще 13% респондентів зараз створюють власні колектори, а 61% користувачів OTel не можуть сказати, що OpenTelemetry Collector Builder є простим у використанні.
• Великі організації (>100 колекторів) збирають більше метрик і логів. З іншого боку, менші організації (<100 колекторів) збирають більше трасувань.
• Використання Otlphttpexporter, datadogexporter, filelogreceiver, k8sclusterreceiver, k8sclusterreceiver, filereceiver, Attributesprocessor, transformprocessor, Routingconnector, datadogconnector, Storage, zpages та filestorage збільшилося, тоді як використання Memorylimiterprocessor зменшилося.
• Управління конфігурацією та її вирішення, стабільність і спостережуваність колектора є найпопулярнішими запитами на вдосконалення.

Детальна інформація

Масштаб розгортання та середовище

Минулого року питання про кількість колекторів, які наші користувачі мають в експлуатації, було класифіковано інакше, ніж цього року. Це повʼязано з тим, що багато учасників опитування 2024 року повідомили, що мають більше 10 колекторів в експлуатації, що змусило нас розділити категорії на більше рівнів в опитуванні 2025 року. Для порівняння ми зменшили категорію 2025 року і виявили, що 65% (+10%) мають більше 10 колекторів, 15% (-7%) мають від 2 до 5 колекторів, а кількість користувачів з 1 колектором і 6-10 колекторами не змінилася.

Що стосується місця розгортання, користувачі OTel як і раніше віддають перевагу Kubernetes (81%, як і в попередньому році), 51% (+18%) повідомили, що використовують віртуальні машини, а 18% (+7%) використовують звичайне обладнання. В опитуванні 2025 року жоден з респондентів не вибрав HashiCorp Nomad як бажане місце розгортання.

Збільшення використання віртуальних машин на 18% викликало питання, який відсоток користувачів віртуальних машин також використовує Kubernetes і які розміри їх розгортання? Ми виявили, що чверть користувачів з відносно невеликим розміром розгортання (<100 колекторів) і приблизно половина користувачів з великим розміром розгортання (>100 колекторів) використовують як Kubernetes, так і віртуальні машини.

Місце розгортання з позначкою * означає значущість на рівні достовірності 90%.

Сценарії використання та розгортання

Сценарії використання Kubernetes демонструють тенденцію, схожу на результати торішнього опитування: 58% (-7%) gateway, 50% (-2%) daemonset, 23% (-1%) sidecar та 14% (+1%) statefulset. Ці відсоткові відмінності є незначними.

Налаштування та конфігурація

Кількість користувачів OTel, які створюють власні колектори, зросла до 46% (+13%). З цих 55 розробників власних колекторів 47 (86%) використовують OpenTelemetry Collector Builder (для порівняння: торік таких було 80%), а 21 (~25%) користувачів повідомили, що Collector Builder важко використовувати, тоді як торік таких було лише 2.

Важливо також зазначити, що лише 39% респондентів впевнено погодилися з тим, що Collector Builder простий у використанні, а 61% відповіли, що він нейтральний або складний у використанні (що свідчить про значний потенціал для вдосконалення).

Моніторинг та спостережуваність

Щодо моніторингу колекторів, близько 23% (-6% порівняно з минулим роком) повідомили, що не здійснюють моніторинг колекторів. Однак у опитуванні 2024 року 82% повідомили, що збирають внутрішні метрики та журнали, а опитування 2025 року показує, що 83% збирають метрики, 61% збирають журнали, а 25% збирають трасування. Це свідчить про те, що метрики є найбільш поширеними внутрішніми телеметричними даними, що збираються. Крім того, ми перевірили, чи впливає кількість колекторів на тип телеметричних даних, що моніторяться. Ми виявили, що люди, які використовують понад 100 колекторів, безумовно збирають метрики, але рідко збирають трейси.

Використання компонентів OTel

У нашій спробі порівняти, як змінилося використання компонентів між 2025 роком і попереднім роком, ми розрахували різницю у відсотках для 10 найпопулярніших компонентів (використовуючи опитування 2025 року), і використання наступних компонентів значно змінилося з рівнем достовірності 90%:

• Приймачі: Filelogreceiver, k8sclusterreceiver та filereceiver збільшилися
• Процесори: Attributesprocessor та transformprocessor збільшилися, тоді як Memorylimiterprocessor зменшився.
• Експортери: Otlphttpexporter та Datadogexporter збільшилися, а lokiexporter зменшився.
• Конектори: Routingconnector та datadogconnector збільшилися.
• Розширення: Storage, zpages та filestorage збільшилися.

Сфери, що потребують вдосконалення

Користувачі OTel у своїх відповідях вказали на сфери, які, на їхню думку, потребують вдосконалення: близько 63% зазначили управління конфігурацією та вирішення проблем, 52% — стабільність, 43% — покращення спостережуваності колекторів, а 29% — підтримку більшої кількості приймачів або експортерів.

Більш детально користувачі висловили свої пропозиції щодо того, що слід вдосконалити, словами:

Конфігурація, реконфігурація та оперативна гнучкість

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

«Реконфігурація та перезапуск окремого конвеєра без необхідності розривати інші зʼєднання та конвеєри — не потрібно перезапускати весь колектор, якщо потрібно змінити лише один конвеєр».

Продуктивність, масштабованість та ефективність використання ресурсів

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

«Конектор spanmetrics вимагає багато ресурсів, і швидший час запуску значно поліпшив би роботу Collector у великих масштабах».

Якість документації, доступність та узгодженість сигналів

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

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

Розробка та розширюваність

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

«Вивчення найкращих та найсвіжіших шаблонів для написання власних експортерів було вкрай болісним — нам довелося в основному покладатися на проблеми GitHub, щоб зрозуміти, у якому напрямку рухається спільнота».

Прогалини в екосистемі та покриття компонентів

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

«Ми використовуємо окремий експортер CloudWatch, оскільки awscloudwatchmetricsreceiver не має супровідників».

Надійність, справність та зворотна сумісність

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

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

Висновок

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

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