OpenTelemetry и Prometheus стали заметно лучше работать вместе: доля пользователей, которым трудно совмещать эти инструменты, упала с 29% до 10% за два года. Для команд, которые строят мониторинг Kubernetes, микросервисов и AI-сервисов, это не косметика, а шанс меньше тратить время на перевод метрик из одного диалекта в другой.
По данным The New Stack, свежий опрос 2026 года о совместимости Prometheus и OpenTelemetry показывает редкий для observability сюжет: два больших open source-мира не просто сосуществуют, а понемногу перестают мешать друг другу. Средняя оценка удобства совместного использования выросла с 3,1 до 3,6 по пятибалльной шкале. Никто из респондентов в этом году не выбрал вариант «очень трудно», хотя в 2024 году таких было 7%.
Опрос провели участники экосистемы OpenTelemetry: Dhruv Ahuja из SigNoz, Andrej Kiripolsky и Arthur Sens из Grafana Labs, а также независимая участница Ana Muenz. Из 186 ответивших в финальную выборку попал 81 активный пользователь OpenTelemetry для метрик на Prometheus-совместимом бэкенде. Сотрудников observability-вендоров отфильтровали, чтобы не смешивать опыт конечных пользователей с профессиональной любовью к собственным графикам.
Картина получилась не про «Prometheus умер, да здравствует OTel». В инфраструктурных метриках Prometheus exporters всё ещё лидируют: их используют 72% респондентов. OpenTelemetry receivers идут рядом с 57%. Почти половина участников, 49,4%, уже смешивает Prometheus- и OTel-подходы для инфраструктуры. То есть миграция чаще выглядит не как большой хлопок рубильником, а как долгий период двуязычия: старые экспортеры продолжают отдавать /metrics, новые компоненты приходят через OTLP и Collector.
В приложениях расклад другой. Там OpenTelemetry SDK используют 65% респондентов, Prometheus SDK — 52%. Только OTel-стиль выбрали 41,3%, смешанный подход — 30,7%, только Prometheus-стиль — 22,7%. Это логично: новый код проще сразу инструментировать через OpenTelemetry, а инфраструктурный слой тащит за собой годы накопленных экспортеров, дашбордов и алертов. Любой SRE, который хотя бы раз трогал чужой PromQL пятилетней давности, сейчас понимающе кивнул.
На этапе обработки метрик тоже нет победителя с большим отрывом. Prometheus relabeling и recording rules используют 54%, open source OpenTelemetry Collector — 53%. При этом 65% респондентов обходятся «ванильным» стеком: без вендорских дистрибутивов Collector и без кастомной сборки в пайплайне. Это важная деталь для IT-директоров и платформенных команд: совместимость развивается не только в дорогих коммерческих платформах, а в базовой open source-инфраструктуре, которую можно держать под собственным контролем.
Но болевые точки никуда не делись. Пользователи хотят лучшего согласования моделей данных Prometheus и OpenTelemetry: в одном мире привычнее labels, в другом — attributes и resource attributes. Ещё один раздражитель — метаданные. Командам нужно, чтобы сведения о сервисе, кластере, регионе или владельце не терялись по дороге от SDK до хранилища и запроса. Третья зона трения — имена и форматирование метрик. Поддержка UTF-8 в PromQL, OpenMetrics 2.0 и настраиваемые стратегии трансляции в OTLP receiver уже есть, но это пока набор деталей, а не полностью гладкий путь для пользователя.
Практический пример даёт Atlassian. Компания описала миграцию метрик с gostatsd, своей Go-реализации StatsD-подхода, на OpenTelemetry. Старый пайплайн обрабатывал данные примерно со 100 тысяч хостов в 14 регионах, но всё хуже совпадал с тем, куда двигалась остальная индустрия. Atlassian не стала заставлять владельцев сервисов срочно переписывать интерфейсы отправки метрик. Вместо этого платформенная команда заменила механику сбора и пайплайна под капотом. По итогам агрегация стала потреблять примерно вдвое меньше CPU на том же трафике, нагрузка по ingest-шардам распределилась ровнее, а затраты на sidecar на масштабе флота снизились примерно на 30%.
Для бизнеса вывод довольно трезвый: OpenTelemetry и Prometheus сейчас выгоднее рассматривать не как конкурирующие религии, а как совместный слой наблюдаемости. Prometheus остаётся сильным в метриках, PromQL и экосистеме экспортеров. OpenTelemetry становится универсальным способом собирать и переносить телеметрию между трассировками, метриками, логами и новыми AI-нагрузками. New Relic в своём Observability Forecast 2026 отдельно зафиксировала, что 73% организаций уже стандартизируются на OTel, мигрируют на него или тестируют его; 83% считают observability критичной для AI-сгенерированного кода. Когда код всё чаще пишет не человек, смотреть на поведение продакшена приходится внимательнее, а не реже.
Главный вопрос теперь не в том, «победит» ли OpenTelemetry и Prometheus, а в том, насколько быстро их сообщества уберут оставшиеся шероховатости: модели данных, resource attributes, метаданные и имена метрик. Если эти проблемы станут настройками по умолчанию, а не темой для отдельного внутреннего гайда на 40 страниц, observability наконец приблизится к скучному состоянию. В инфраструктуре это комплимент.