Миграция с Prometheus на OpenTelemetry без lock-in
Зачем инженеры хотят держать и Prometheus, и OpenTelemetry
21 сентября 2026 года команда Prometheus опубликовала результаты повторного опроса о совместимости с OpenTelemetry — через два года после первого замера 2024 года. Авторы исследования, Dhruv Ahuja, Andrej Kiripolsky, Ana Muenz и Arthur Silva Sens, спросили инженеров, которые реально эксплуатируют оба стека, как они собирают, обрабатывают и хранят метрики.
Краткий ответ
Судя по опросу, полная миграция с Prometheus на OpenTelemetry — редкость. Большинство команд держат оба метода параллельно: Prometheus-экспортёры и OTel-ресиверы на инфраструктуре, SDK OpenTelemetry в приложениях. Переписывать существующую инструментацию целиком не обязательно — разрыв закрывают через OTel Collector как общий конвертирующий слой между Prometheus scrape и OTLP push.
Что измеряли
Опрос продолжает линию исследования 2024 года: тот же вопрос про ease-of-use, те же темы инструментации инфраструктуры и приложений, но с новым фильтром по выборке. На опрос ответили 186 человек, из них 81 прошёл отбор как активный пользователь OpenTelemetry для метрик на бэкенде, совместимом с Prometheus. Команда отдельно отфильтровала сотрудников observability-вендоров, чтобы смотреть именно на end users.
В итоговой выборке все респонденты используют какую-то разновидность Prometheus: сам Prometheus (46%), open source совместимый бэкенд вроде Thanos, Cortex или Grafana Mimir (42%), либо PromQL-совместимый вендорский продукт (12%). Зрелость observability-практики высокая: 48% называют её «устоявшейся», 41% — «в процессе выстраивания», и только 11% считают себя новичками. Выборка смещена в сторону крупных организаций: 42% компаний — это 1000+ сотрудников, 31% — от 100 до 999.
Как считали
Методология — прямое сравнение с опросом 2024 года по одному и тому же вопросу об ease-of-use, с оговоркой в самом материале: тогда респондентов не спрашивали, работают ли они в observability-вендоре, так что популяции не полностью совпадают. Авторы проверили чувствительность результата: если вернуть вендорских сотрудников в выборку 2026 года (n = 108), распределение ответов почти не меняется. Это разумная проверка, но сама выборка остаётся небольшой и самоотобранной — на опрос откликнулись те, кто уже активно работает с обоими стеками, а не случайная инженерная аудитория.
Что показали цифры
Главный тренд — ease-of-use ощутимо выросла. Средняя оценка совместимости поднялась с 3,1 до 3,6 — авторы сравнивают это с тем, как если бы каждый второй респондент поднял свою оценку на целую категорию. Доля тех, кто считает связку Prometheus и OpenTelemetry сложной, упала с 29% до 10%, и в этом году никто не выбрал вариант «очень сложно».
При этом сама практика сбора метрик остаётся гибридной, а не бинарной. В инструментации инфраструктуры Prometheus-экспортёры — самый частый метод (72%), OTel-ресиверы почти догнали их (57%), и почти половина респондентов использует оба подхода одновременно, а не мигрирует с одного на другой. В инструментации приложений лидирует OTel SDK (65%) против Prometheus SDK (52%), и 41% респондентов используют только OTel-стиль инструментации приложений — здесь сдвиг к OpenTelemetry заметнее.
На уровне обработки данных два самых частых шага — relabeling rules Prometheus (54%) и open source OTel Collector (53%). При этом 65% респондентов работают на «ванильном» стеке — одним или обоими инструментами без вендорских трансформаций и без кастомной сборки Collector где-либо в пайплайне.
Что здесь спорно
Выборка в 81 респондента — не статистически репрезентативный срез рынка, а снимок настроений инженеров, которые уже осознанно выбрали жить на стыке двух экосистем. Это смещает результат в сторону позитивной оценки совместимости: люди, для которых связка Prometheus и OpenTelemetry была слишком болезненной, скорее всего, уже выбрали один стек и не попали в скрининг на «активного пользователя обоих».
Самая большая группа ответов по ease-of-use — «ни легко, ни сложно», и сами авторы отмечают: работы ещё много. Формулировка о 70% организаций, которые хотят dual-export без привязки к вендору — популярная рамка для этой темы в индустрии, но в опубликованном материале Prometheus она напрямую не разбита по этому конкретному вопросу; ближайшее подтверждаемое число — это почти половина респондентов, совмещающих оба метода инструментации инфраструктуры, и 65% на «ванильном» стеке без вендорских трансформаций. Это тот же сигнал, но с другой точностью цифры.
Как приложить к своей команде
Если вопрос звучит как «как мигрировать с Prometheus на OpenTelemetry без переписания инструментации», опрос даёт практичный ответ: не мигрировать резко, а строить dual-export архитектуру. Схема, которую описывают сами цифры исследования: Prometheus scrape и OTel-ресиверы работают параллельно на инфраструктурном слое, приложения постепенно переходят на OTel SDK, а OTel Collector берёт на себя роль шлюза, который конвертирует метрики между форматами и отправляет их туда, куда нужно — хоть в Prometheus-совместимый бэкенд, хоть в OTLP-приёмник.
Для platform team это значит конкретные архитектурные решения: держать Collector как общую точку маршрутизации телеметрии, не привязывать relabeling rules только к одному формату, и проектировать пайплайн так, чтобы смена бэкенда не требовала трогать код приложений. Это прямо снижает риск привязки к вендору — именно то, что ищут команды, которые уже вложились в Prometheus, но не хотят терять гибкость выбора backend.
Для FinOps и cost management observability вывод жёстче: параллельная работа двух методов инструментации почти всегда означает двойной объём телеметрии на каком-то участке пайплайна, пока миграция не завершена. Если 65% респондентов живут на «ванильном» стеке без кастомных трансформаций, значит, контроль кардинальности и объёма remote-write чаще всего остаётся на стороне relabeling rules и настроек Collector — и это тот рычаг, который стоит проверить до того, как включать dual-export на проде.
Заключение
Опрос показывает прогресс, а не финальную точку: разрыв между Prometheus и OpenTelemetry сузился, но не закрылся — слишком много ответов попадает в нейтральную категорию «ни легко, ни сложно». Для платформенных команд это сигнал инвестировать не в полный переход на один стек, а в инфраструктуру конвертации между форматами — она дешевле и безопаснее, чем ставка на единственного вендора.
FAQ
Что такое dual-export в observability?
Это архитектура, при которой одни и те же метрики одновременно отправляются в несколько систем хранения — например, в Prometheus-совместимый бэкенд и в OTLP-приёмник. Чаще всего это реализуют через OTel Collector, который принимает данные в одном формате и рассылает их в несколько направлений.
Нужно ли полностью переписывать инструментацию Prometheus при переходе на OpenTelemetry?
Судя по данным опроса, нет. Почти половина респондентов использует Prometheus-экспортёры и OTel-ресиверы параллельно на инфраструктурном уровне, а не заменяет один метод другим. Полная миграция инструментации — скорее исключение, чем правило.
Чем отличаются Prometheus exporters от OTel receivers?
Prometheus exporters — это компоненты, которые собирают метрики целевой системы и отдают их в формате, который Prometheus забирает через scrape. OTel receivers делают похожую работу, но внутри экосистемы OpenTelemetry, откуда данные уходят дальше через OTLP. По данным опроса, экспортёры всё ещё немного более распространены — 72% против 57%.
Какой процент организаций использует и Prometheus, и OpenTelemetry одновременно?
Опрос Prometheus и CNCF подтверждает, что почти половина респондентов совмещает оба метода инструментации инфраструктуры одновременно, а не мигрирует с одного на другой. Более точная оценка доли именно dual-export без привязки к вендору в опубликованном материале не разбита отдельной цифрой.
Что такое "vanilla stack" в контексте этого опроса?
Авторы называют так конфигурацию, где используется Prometheus, OpenTelemetry или оба инструмента без вендорских трансформаций данных и без кастомной сборки OTel Collector. По данным опроса, на таком стеке работают 65% респондентов.