Інтероперабельність Prometheus та OpenTelemetry у 2026 році: результати опитування
Ми провели опитування, в якому запитали користувачів OpenTelemetry та Prometheus, як вони збирають, обробляють і зберігають метрики. Мета полягала в тому, щоб на основі реальних даних використання, а не припущень, зрозуміти, наскільки просунулась екосистема та чи досі інтероперабельність створює перешкоди.
Основні висновки
- Інтероперабельність помітно покращилась з часів нашого опитування 2024 року: середня оцінка простоти використання зросла з 3,1 до 3,6, що еквівалентно підвищенню оцінки на цілу категорію кожним другим респондентом, а частка респондентів, які вважають їх складними у спільному використанні, впала з 29% до 10%.
- В інструментуванні інфраструктури експортери Prometheus лишаються найпоширенішим методом (72%), приймачі OTel майже не відстають (57%), а майже половина респондентів використовує обидва підходи одночасно, а не мігрує з одного на інший.
- В інструментуванні застосунків найпоширенішим методом є SDK OpenTelemetry (65%), SDK Prometheus — 52%, а 41% використовують лише інструментування застосунків у стилі OTel.
- Правила relabeling Prometheus (54%) та відкритий колектор OTel (53%) — два найпоширеніші етапи обробки, а 65% респондентів використовують «vanilla стек» з одного або обох компонентів, без жодної вендорної трансформації чи власної збірки Collector у конвеєрі.
Демографія
Зі 186 осіб, які відповіли, 81 пройшов наш відбір активних користувачів OpenTelemetry для метрик на бекенді, суміжному з Prometheus. Ми також відфільтрували співробітників вендорів у сфері спостережуваності, щоб зосередитися на кінцевих користувачах. В аналізованій вибірці:
- Усі респонденти є активними користувачами OpenTelemetry.
- Усі респонденти використовують якусь версію Prometheus — сам Prometheus (46%), відкритий сумісний з Prometheus бекенд, як-от Thanos, Cortex чи Grafana Mimir (42%), або вендорний продукт, сумісний з PromQL (12%).
- Зрілість спостережуваності респондентів висока. 48% описують свою організацію як таку, що має «усталену практику спостережуваності» (експерти), 41% — як таку, що «впроваджує практику спостережуваності» (середній рівень), і лише 11% вважають себе новачками у спостережуваності.
- Організації переважно великі. 42% мають понад 1000 співробітників, 31% — від 100 до 999, 15% — від 50 до 99, а 12% повідомили, що мають менш ніж 50.
Зміна простоти використання з часом
Наскільки легко чи складно використовувати OpenTelemetry та Prometheus разом?
Цього року ми поставили те саме питання, що й у схожому опитуванні 2024 року, щоб зʼясувати, чи побачили кінцеві користувачі прогрес в інтероперабельності.
Середня оцінка зросла на 0,5 бала — з 3,1 до 3,6, ніби кожен другий респондент піднявся на цілу категорію. Найпомітніші зміни — на складному кінці шкали: частка респондентів, які вважають ці два інструменти складними у спільному використанні, впала приблизно до третини рівня 2024 року. Також цього року ніхто не обрав варіант «дуже складно».
Дворічна робота над інтероперабельністю дає результати. Водночас, оскільки найбільша група відповідей припадає на варіант «ні легко, ні складно», у цій сфері ще багато роботи.
Примітка: Опитування 2024 року не запитувало респондентів, чи працюють вони на вендора у сфері спостережуваності, тому це не зовсім точне порівняння «один до одного». Однак повернення співробітників вендорів до вибірки 2026 року (n = 108) майже не змінило б результат оцінки простоти використання (0%, 10%, 40%, 33%, 17% → 0%, 10%, 41%, 33%, 16%). Щоб зберегти узгодженість результатів цього року, ми вирішили й надалі відфільтровувати співробітників вендорів.
Метрики інфраструктури
Як ви інструментуєте збір метрик інфраструктури?
Експортери Prometheus є найпоширенішим окремим методом інструментування для метрик інфраструктури, але приймачі OTel майже не відстають. Далі йдуть вбудована точка доступу /metrics, вбудований OTLP push та інструментування eBPF від OpenTelemetry (OBI).
Якщо подивитися на те, як ці методи поєднуються, картина явно гібридна, а не «або/або». Майже половина респондентів одночасно змішує стилі інструментування Prometheus та OTel для метрик інфраструктури, а не виконує повну міграцію. Серед респондентів, які використовують лише один стиль інструментування, стиль лише Prometheus удвічі популярніший за стиль лише OTel.
Примітка: Стиль інструментування описує, чи використовує респондент методи, властиві лише одному проєкту, чи суміш обох. Стиль OTel охоплює використання приймачів OTel, вбудованого OTLP push або інструментування eBPF від OpenTelemetry (OBI). Стиль Prometheus охоплює експортери Prometheus або вбудовану точку доступу /metrics (без експортера). 4 відповіді «інше» були вписані власноруч: Zabbix, Heorku Telemetry (ймовірно, «Heroku Telemetry»), textfile collector, Telegraf. Усі 4 респонденти також обрали реальний метод Prometheus/OTel разом зі своїм варіантом — але на діаграмі стилів вище власний варіант зараховує респондента до категорії «інше» незалежно від того, що ще він обрав.
У процесі роботи: Спільноти Prometheus та OTel працюють над тим, щоб експортери Prometheus могли працювати як дистрибутив колектора OTel. Розмови ще тривають. Обговорення відкрите в цьому тікеті.
Метрики застосунків
Як ви інструментуєте збір метрик застосунків?
Під час інструментування застосунків уподобання змінюються. SDK OpenTelemetry виходять на перше місце, за ними йдуть SDK Prometheus. OBI зберігає приблизно ту саму частку, що й в інструментуванні інфраструктури.
Стилі інструментування також змінюються. Найбільша частка учасників (41%) використовує лише стиль OTel, що майже вдвічі частіше, ніж лише стиль Prometheus. Менш ніж третина змішує стилі.
Примітка: В інструментуванні застосунків стиль OTel охоплює використання SDK OTel або інструментування eBPF від OpenTelemetry (OBI). Стиль Prometheus охоплює SDK Prometheus. Знову ж таки, є 4 власні варіанти, які ми віднесли до категорії «інше»: вже зібрані експортери, Micrometer, textfile collector, jvm-exporter. 3 з 4 також обрали реальний метод Prometheus/OTel. Власні варіанти одного респондента — «Self instrumentation» та «manual instrumentation for OTEl» — були перекодовані у звичайні SDK OTel.
Трансформація
Що ви використовуєте для обробки або трансформації метрик перед надсиланням до сховища?
Правила relabeling Prometheus та відкритий колектор OTel є двома найпоширенішими етапами обробки, і жоден з них не має явної переваги.
Більшість респондентів використовують «vanilla стек»: лише правила relabeling Prometheus та/або звичайний колектор OTel, без вендорного дистрибутива та без власної збірки Collector у конвеєрі. Три «vanilla»-патерни виходять майже рівними.
Примітка: Категорія «інше» поєднує респондентів, які взагалі не виконують трансформацію (15%, n=12), та тих, хто використовує вендорний дистрибутив або власну збірку Collector (20%, n=16).
Що практики хочуть покращити
Що ви хотіли б, щоб ми покращили, щоб OpenTelemetry та Prometheus працювали краще разом?
Ми отримали 19 відкритих відповідей із пропозиціями щодо покращення. З цих даних виокремилися три теми: уніфікація моделей даних Prometheus та OTel (атрибути/мітки), краща обробка атрибутів ресурсів та метаданих, а також складнощі з найменуванням та форматуванням. Було також кілька індивідуальних запитів. Супровідники Prometheus György «Krajo» Krajcsovits та Arthur Sens опрацювали відповіді та розглянули кожен пункт нижче:
- Уніфікація моделей даних Prometheus та OTel (атрибути/мітки)
- Це слушний запит, і ми його визнаємо. Винесемо його на обговорення на саміті розробників Prometheus у жовтні.
- Прогалини в атрибутах ресурсів та метаданих
- Це має вирішити проєкт нативних метаданих. Одне, на що нам доведеться чекати, — завершення специфікації OTel Entities.
- Складнощі з найменуванням та форматуванням
- Кілька відповідних речей уже існують — формат представлення OpenMetrics 2.0 дозволяє використовувати назви у стилі OTel безпосередньо в коді, PromQL вже підтримує назви метрик у UTF-8, а приймач OTLP у Prometheus має налаштовувані стратегії трансляції. Компоненти існують; просто вони ще стандартно не увімкнені. Над цим нам потрібно попрацювати.
- Використання нативних правил запису Prometheus у Collector
- Є відкриті пропозиція Prometheus та proof-of-concept PR для правил запису на етапі скрейпінгу, яким не потрібен повноцінний TSDB, як правилам запису сьогодні. Оскільки приймач Prometheus у колекторі OpenTelemetry використовує код Prometheus як бібліотеку Go, ця пропозиція також принесе користь Collector.
- Підтримка MCP або агентних AI-процесів
- Prometheus щойно додав репозиторій проєкту Prometheus MCP до своєї організації на GitHub. Це має увімкнути MCP-процеси для Prometheus. Спільнота Prometheus була б рада, якби люди почали ним користуватися та надсилати відгуки. Крім того, проєкт нативних метаданих пояснює, як ми плануємо зробити агентні AI-процеси в Prometheus ще кращими.
Цікаві спостереження
Середні організації можуть бути найбільш просунутими у використанні нативних інструментів OTel
У наших даних організації з 100–999 співробітниками мають найвищий рівень впровадження SDK OTel для метрик застосунків та приймачів OTel для метрик інфраструктури. Інструментування на основі eBPF (OBI) не йде за тим самим патерном — тут вирізняються організації з 1000+ співробітників.
Впровадження за розміром організації:
| Розмір організації | SDK OTel (застосунки) | Приймачі OTel (інфраструктура) | eBPF / OBI (інфраструктура) |
|---|---|---|---|
| 1–49 (n = 10) | 40% | 20% | 20% |
| 50–99 (n = 12) | 58% | 58% | 17% |
| 100–999 (n = 25) | 84% | 76% | 20% |
| 1000+ (n = 34) | 62% | 53% | 3% |
Наша гіпотеза полягає в тому, що середні організації — достатньо великі, щоб мати виділені робочі місця для роботи з платформою, і достатньо малі, щоб рухатися без багаторічного плану міграції, — можливо, найглибше просуваються у використанні новіших нативних інструментів OTel.
Примітка: Це цікаве спостереження та гіпотеза, а не підтверджений висновок: з 10–34 респондентами в кожній групі жоден з цих розривів не є достатньо великим, щоб опитування такого розміру могло їх підтвердити.
Тип команди визначає вибір бекенда
Команди платформної інженерії та SRE значною мірою схиляються до відкритих сумісних з Prometheus бекендів (Thanos, Cortex, Mimir), тоді як команди розробників схиляються в протилежний бік — до звичайного Prometheus.
Тут розділова лінія схожа радше на операційну власність, аніж на вподобання. Команди, які обслуговують метрики для всієї організації, зрештою переростають одне розгортання Prometheus, тоді як команди, що інструментують власний сервіс, зазвичай ні.
Вибір бекенда за типом команди — відкритий сумісний з Prometheus (n = 30), Prometheus (n = 35), сумісний з PromQL вендор (n = 8):
| Тип команди | Відкритий сумісний з Prometheus | Prometheus | Сумісний з PromQL вендор |
|---|---|---|---|
| Розробники | 24% | 71% | 6% |
| DevOps | 23% | 62% | 15% |
| Спостережуваність | 29% | 41% | 29% |
| Платформна інженерія | 69% | 31% | 0% |
| SRE | 69% | 31% | 0% |
Примітка: Респондентів-системних адміністраторів (n = 6) та операційних фахівців (n = 2) виключено з цієї таблиці — обидві групи замалі для інтерпретації, — що дає n = 73 з 81 респондента. Як і в попередньому розбитті, кількості в групах тут (від 8 до 35) замалі для певних висновків.
Долучайтеся
Інтероперабельність стала помітно простішою, ніж два роки тому, але відкриті відповіді вказують на конкретні прогалини — відмінності в моделях даних, прогалини в атрибутах ресурсів та метаданих, а також складнощі з найменуванням та форматуванням. Попереду ще багато роботи як на боці OpenTelemetry, так і на боці Prometheus.
Кожен може долучитися. Обговорення відбувається в каналі #otel-prometheus у CNCF Slack.