Почему я рекомендую использовать нативную инструментализацию Prometheus вместо OpenTelemetry

Биткойн Альткойны

В современном мире IT-инфраструктуры и разработки программного обеспечения мониторинг играет ключевую роль в обеспечении стабильной и эффективной работы приложений и сервисов. На фоне растущей популярности систем наблюдения и инструментализации возникает вопрос: стоит ли использовать OpenTelemetry (OTel) для метрик или же лучше отдавать предпочтение нативным клиентским библиотекам Prometheus? Авторитетный опыт в области мониторинга и наблюдаемости, включая позицию одного из основателей Prometheus, позволяет сделать убедительный аргумент в пользу нативной инструментализации Prometheus для работы с метриками. Рассмотрим основные аспекты, которые влияют на выбор между этими двумя подходами, а также успехи и недостатки каждого из них. OpenTelemetry и Prometheus представляют собой разные инструменты с пересекающейся областью применения, но с принципиально отличающимися архитектурными подходами и целями. OpenTelemetry создавался как универсальное решение для сбора, обработки и передачи данных наблюдаемости — метрик, логов и трассировок — во множестве разнообразных систем и бекендов.

В этом контексте он предлагает мощные SDK и протоколы для передачи телеметрических данных, а также упрощает интеграцию с различными сторонними сервисами. В свою очередь Prometheus — это специализированная система мониторинга, сфокусированная исключительно на метриках. Его архитектура основана на модели опроса (pull), что позволяет Prometheus самому определять, с каких целей и когда собирать метрики, обеспечивая одновременно хранение, обработку и анализ данных. Prometheus включает собственный язык запросов PromQL для гибкой работы с метриками, возможности алертинга и визуализации данных. Одним из важных преимуществ нативной клиентской библиотекой Prometheus является глубоко интегрированная система обнаружения целей.

Prometheus поддерживает множество механизмов сервис-дискавери, включая интеграцию с Kubernetes, Consul, EC2 и другими, что позволяет автоматически получать актуальный список объектов мониторинга. Вместе с моделью pull это обеспечивает надежное определение состояния инфраструктуры и приложений, а также выявление сбоев и недоступных целей путем анализа грязной метрики up. В отличие от этого, OpenTelemetry ориентирован на модель push — приложения или агенты сами отправляют метрики в Collector или напрямую в бекенд. Такой подход лишает систему мониторинга возможности самостоятельно контролировать доступность целей, поскольку отсутствует явное опрос и, следовательно, нет гарантии, что данные всегда отправляются и достигают пункта назначения. Это затрудняет выявление проблем с самим мониторингом и усложняет администрирование большой инфраструктуры.

Еще одним ключевым аспектом является вопрос стабильности и согласованности имен метрик. В Prometheus именование метрик и лейблов строго регламентировано, что обеспечивает удобство и однородность при написании запросов, алертинг-правил и построении дашбордов. OpenTelemetry, напротив, допускает в именах использование более свободы, включая знаки препинания и прочие символы, что приводит к необходимости трансляции метрик перед их экспортом в Prometheus. Такая трансформация сопровождается заменой символов, добавлением суффиксов единиц измерения и типов метрик, что усложняет восприятие и сопряжение с уже существующими метриками. В версии Prometheus 3.

0 был реализован расширенный UTF-8-кодек для именований, что теоретически обеспчивает возможность хранения оригинальных имен из OpenTelemetry. Однако для этого требуется использовать более сложный синтаксис запросов, что уменьшает удобство работы с PromQL. Применение нативных библиотек сразу гарантирует отсутствие таких проблем и благоприятный пользовательский опыт. Промежуточный слой OpenTelemetry при передаче метрик в Prometheus также усложняет управление метаданными. В Prometheus лейблы цели определяются системой мониторинга на основе обнаружения сервисов и служат для идентификации каждой целевой сущности.

В OpenTelemetry так называемые resource attributes выбираются генератором метрик и зачастую включают широкий набор подробных описаний, которые сложно эффективно связывать с целями в Prometheus. Последнее усложняет создание простых и эффективных запросов и увеличивает нагрузку на администрирование. Кроме того, при приеме метрик через OTLP необходимо дополнительное конфигурирование Prometheus, включая включение OTLP-рецептора и настройку обработки данных с возможностью поступления метрик вне последовательного порядка. Это повышает вероятность ошибок безопасности и усложняет архитектуру системы мониторинга. Говоря о производительности, важно отметить, что нативные клиентские библиотеки Prometheus реализованы с акцентом на высокую эффективность и низкие накладные расходы по CPU и памяти.

Исследования и сравнительные тесты, включая ситуации с очень высокими нагрузками, показывают значительное превосходство Prometheus SDK по производительности над OpenTelemetry SDK, особенно в языке Go, который широко используется для серверных приложений. Простота и прозрачность — важное достоинство нативных библиотек Prometheus. Они минималистичны, хорошо документированы и легко интегрируются в кодовую базу, что облегчает сопровождение и отладку. В отличие от этого, OpenTelemetry SDK сложны, содержат множество уровней абстракций и требуют глубокого понимания концепций, что увеличивает время разработки и вероятность ошибок. Не менее важен вопрос открытости и стандартизации.

Несмотря на распространенное мнение, Prometheus является открытым проектом с зрелой моделью управления и широкой поддержкой в сообществе. Его форматы и протоколы, такие как PromQL, Remote Write и формат экспонирования метрик по HTTP, стали де-факто стандартами в индустрии. Примитивную реализацию экспозиции метрик можно создать буквально несколькими строками кода или скрипта, что делает Prometheus очень удобным в различных сценариях, включая специфические или легковесные случаи. OpenTelemetry, с другой стороны, опирается на протоколы, основанные на protobuf, которые требуют наличия полноценной SDK для работы и усложняют разработку собственных клиентов или агентов без глубоких познаний и значительных затрат времени. При этом, если в инфраструктуре появляются сценарии, требующие интеграции с другими сигналами наблюдаемости, такими как трассировки и логи, OpenTelemetry может выступать в роли общей платформы.