Доля респондентов, которым сложно использовать Prometheus и OpenTelemetry вместе, за два года сократилась с 29% до 10%. Почти половина участников опроса сочетает подходы Prometheus и OTel к инструментированию инфраструктуры, не переходя полностью на один из них. Команда VK Tech перевела статью с результатами опроса, которые пригодятся SRE и платформенным инженерам при выборе способа инструментирования инфраструктуры и приложений.

Авторы опросили пользователей OpenTelemetry и Prometheus о том, как они собирают, обрабатывают и хранят метрики. Они хотели на основе реальных данных об использовании понять, насколько продвинулась экосистема и по-прежнему ли совместимость вызывает трудности.

Ключевые выводы

1. Совместимость заметно улучшилась со времени нашего опроса 2024 года. Средняя оценка удобства использования выросла с 3,1 до 3,6 — как если бы каждый второй респондент выбрал вариант на одну категорию выше. Доля респондентов, которым сложно использовать два проекта вместе, снизилась с 29% до 10%.

2. Для инструментирования инфраструктуры по-прежнему чаще всего используют экспортёры Prometheus (72%), за ними идут ресиверы OTel (57%). Почти половина респондентов применяет оба способа одновременно, не переходя полностью с одного на другой.

3. Для инструментирования приложений чаще всего используют SDK OTel (65%). SDK Prometheus используют 52% респондентов, а 41% инструментируют приложения только средствами OTel.

4. Для обработки метрик чаще всего используют правила релейблинга Prometheus (54%) и OTel Collector с открытым исходным кодом (53%). При этом 65% респондентов обходятся стандартным стеком из одного или обоих инструментов — без вендорских преобразований и собственных сборок коллектора на всех участках конвейера.

Кто участвовал в опросе

На опрос ответили 186 человек. Из них 81 соответствовал нашим критериям отбора: это активные пользователи OpenTelemetry для сбора метрик, использующие бэкенд из экосистемы Prometheus. Мы также исключили сотрудников вендоров решений для наблюдаемости, чтобы сосредоточиться на конечных пользователях. В проанализированной выборке:

• Все респонденты активно используют OpenTelemetry.

• Все респонденты используют сам Prometheus (46%), совместимый с ним бэкенд с открытым исходным кодом, например 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 (OpenTelemetry Protocol) и OpenTelemetry eBPF Instrumentation (OBI).

Сочетание этих методов показывает, что преобладает гибридный подход. Почти половина респондентов использует для сбора метрик инфраструктуры подходы Prometheus и OTel одновременно, не переходя полностью на один из них. Среди тех, кто придерживается одного подхода, только Prometheus выбирают вдвое чаще, чем только OTel.

Примечание: стиль инструментирования показывает, использует ли респондент методы одного проекта или сочетает методы обоих. К стилю OTel относятся ресиверы OTel, встроенная отправка по OTLP и OpenTelemetry eBPF Instrumentation (OBI). К стилю Prometheus — экспортёры Prometheus и встроенный эндпойнт /metrics (без экспортёра). Все 4 ответа в категории «Другое» респонденты вписали самостоятельно: Zabbix, Heorku Telemetry (вероятно, Heroku Telemetry), textfile collector, Telegraf. Все 4 респондента также выбрали один из методов Prometheus/OTel, но на диаграмме стилей выше наличие собственного ответа относит респондента к категории «Другое» независимо от остальных выбранных вариантов.

В работе: сообщества Prometheus и OTel работают над тем, чтобы экспортёры Prometheus можно было запускать как дистрибутив OTel Collector. Обсуждение продолжается на GitHub.

Метрики приложений

Как вы инструментируете сбор метрик приложений?

В инструментировании приложений лидеры меняются местами: первыми идут SDK OTel, за ними SDK Prometheus. Доля OBI примерно такая же, как в инструментировании инфраструктуры.

Меняется и расклад по стилям. Больше всего участников (41%) пользуются только стилем OTel, и это почти вдвое чаще, чем только стиль Prometheus. Сочетают стили меньше трети.

Примечание: в инструментировании приложений к стилю OTel относятся SDK OTel и OpenTelemetry eBPF Instrumentation (OBI). К стилю Prometheus относятся SDK Prometheus. И снова 4 респондента вписали ответы сами, и мы отнесли их к категории «Другое»: готовые экспортеры, Micrometer, textfile collector, jvm-exporter. Из этих 4 респондентов 3 также выбрали один из методов Prometheus/OTel. Вписанные ответы одного респондента, «самоинструментирование» и «ручное инструментирование для OTEl», мы перекодировали в обычные SDK OTel.

Преобразование

Что вы используете для обработки или преобразования метрик перед отправкой в хранилище?

Чаще всего для обработки метрик используют правила релейблинга Prometheus и OTel Collector с открытым исходным кодом, причём явного лидера среди них нет.

Большинство респондентов используют стандартный стек: в конвейере только правила релейблинга Prometheus и/или обычный OTel Collector, без вендорского дистрибутива или собственной сборки коллектора. Три варианта такого стека встречаются почти одинаково часто.

Примечание: категория «Другое» объединяет респондентов, которые вообще не преобразуют метрики (15%, n=12), и тех, кто использует вендорский дистрибутив или собственную сборку коллектора (20%, n=16).

Что предлагают улучшить пользователи

Что нам улучшить, чтобы OpenTelemetry и Prometheus лучше работали вместе?

Мы получили 19 ответов в свободной форме с предложениями по улучшению. В них выделились три темы: унификация моделей данных Prometheus и OTel (атрибуты/метки), улучшение обработки атрибутов ресурса и метаданных, а также трудности с именованием и форматированием. Были и отдельные запросы. Мейнтейнеры Prometheus György «Krajo» Krajcsovits и Arthur Sens разобрали ответы и прокомментировали каждый пункт:

Унификация моделей данных Prometheus и OTel (атрибуты/метки). Запрос обоснованный, мы это признаём. Вынесем его на обсуждение на Prometheus Dev Summit в октябре 2026 года.

Пробелы в атрибутах ресурса и метаданных. Проблему должны решить изменения, описанные в проектном документе о нативных метаданных. В частности, нужно дождаться завершения спецификации OTel Entities.

Трудности с именованием и форматированием. Многое из необходимого уже реализовано: формат OpenMetrics 2.0 позволяет использовать имена в стиле OTel прямо в коде, PromQL уже поддерживает имена метрик в UTF-8, а у OTLP-ресивера Prometheus есть настраиваемые стратегии преобразования имён. Все эти возможности уже есть, но пока не включены по умолчанию. Над этим нам ещё предстоит поработать.

Использование нативных правил предвычисления Prometheus в коллекторе. Есть открытое предложение Prometheus и PR с прототипом правил предвычисления на этапе скрейпа. Таким правилам, в отличие от нынешних, не понадобится полноценная TSDB — база временных рядов. Ресивер Prometheus в OpenTelemetry Collector использует код Prometheus как библиотеку Go, поэтому реализация этого предложения была бы полезна и коллектору.

Поддержка сценариев с MCP (Model Context Protocol) или агентным ИИ. Репозиторий проекта Prometheus MCP недавно включили в организацию Prometheus на GitHub. Он должен обеспечить поддержку сценариев с MCP в Prometheus. Сообщество Prometheus будет радо, если пользователи попробуют проект и поделятся обратной связью. А в проектном документе о нативных метаданных описано, как мы планируем улучшить поддержку сценариев с агентным ИИ в Prometheus.

Интересные наблюдения

Организации среднего размера, возможно, дальше всех продвинулись во внедрении нативных для OTel инструментов

По нашим данным, организации со 100–999 сотрудниками чаще всех используют SDK OTel для метрик приложений и ресиверы OTel для инфраструктурных метрик. С инструментированием на основе eBPF (OBI) картина другая — здесь от всех меньших групп отличаются организации с 1000+ сотрудниками.

Внедрение по размеру организации:

Наша гипотеза: организации среднего размера — достаточно крупные, чтобы вести отдельную платформенную работу, и достаточно небольшие, чтобы обходиться без многолетнего плана миграции, — возможно, дальше всех продвинулись в использовании новых нативных для OTel инструментов.

Примечание: это интересное наблюдение и гипотеза, а не подтверждённый вывод. При 10–34 респондентах в группе ни один из этих разрывов не настолько велик, чтобы опрос такого размера мог его подтвердить.

Тип команды связан с выбором бэкенда

Команды платформенной инженерии и SRE заметно тяготеют к совместимым с Prometheus бэкендам с открытым исходным кодом (Thanos, Cortex, Mimir), а команды разработки, наоборот, склоняются к обычному Prometheus.

Граница здесь, похоже, проходит по операционной ответственности, а не по предпочтениям. Команды, которые отвечают за метрики всей организации, со временем перерастают одно развёртывание Prometheus, а командам, которые инструментируют собственный сервис, его, как правило, хватает.

Выбор бэкенда по типу команды — совместимые с Prometheus бэкенды с открытым исходным кодом (n = 30), Prometheus (n = 35), вендор, совместимый с PromQL (n = 8):

Примечание: респонденты из системного администрирования (n = 6) и эксплуатации (n = 2) в таблицу не вошли — обе группы слишком малы для интерпретации, — поэтому остаётся n = 73 из 81 респондента. Как и в предыдущей разбивке, численность групп здесь (от 8 до 35) слишком мала для твёрдых выводов.

Как принять участие

Добиться совместимости сейчас заметно проще, чем два года назад (2024), но открытые ответы указывают на конкретные проблемы — различия в моделях данных, пробелы в атрибутах ресурса и метаданных, а также трудности с именованием и форматированием. Работы ещё много и на стороне OpenTelemetry, и на стороне Prometheus.

Внести вклад может каждый. Обсуждение идёт в канале #otel-prometheus в CNCF Slack.