Мы рассмотрели некоторые конфликты между совместимостью OpenTelemetry и Prometheus по ряду причин. Во многом это связано с тем, что Prometheus был — и остается — очень проверенным и надежным решением для измерения метрик с открытым исходным кодом, которое предшествовало тому, что OpenTelemetry предлагала в качестве альтернативного способа стандартизации и других атрибутов, которые определенно хороши для наблюдения.
Во время PromCon, ежегодной конференции пользователей Prometheus, состоявшейся недавно в Мюнхене, Юлиус Фольц, соучредитель Prometheus, во время вступительного выступления предложил конкретные идеи о том, как использование OpenTelemetry с Prometheus по-прежнему создает проблемы и что необходимо сделать для решения этих проблем.
Во-первых, плохо: при использовании OpenTelemetry происходит фундаментальная потеря возможности обнаружения сервисов и активного извлечения, а также сложность SDK OpenTelemetry. Проблем с производительностью также предостаточно. В одном из тестов производительности, который RevCom не проверял, Волц отметил, что разница в скорости в тестах Go составляла до 22 раз при использовании инструментов OpenTelemetry по сравнению с собственными инструментами Prometheus.
Очевидно, что повышение производительности является ключевым моментом, особенно для кода, предназначенного для наблюдения, который выполняется очень часто и предназначен для повышения производительности. Но семантические соглашения также создают проблемы, как мы обсуждали в наших предыдущих статьях. Также существует постоянная потребность в сотрудничестве между командами Prometheus и OpenTelemetry.
«Я хотел указать на недостатки [integrating OpenTelemetry with Prometheus]и, возможно, заставить вас задуматься: «Хорошо, действительно ли мы хотим пойти по этому пути, если вас больше всего интересуют метрики и их использование с Prometheus?» — сказал Волц. — «Кроме того, что касается недостатков обнаружения сервисов и медленности SDK, мне бы очень хотелось, чтобы другие люди больше думали об этом и, возможно, улучшали ситуацию, а не просто выбрасывали ребенка вместе с водой и теряли все эти преимущества, которые мы очень тщательно создавали в Prometheus в течение длительного времени».
С тех пор, как Ричард «RichiH» Хартманн начал официальную работу по улучшению совместимости между двумя проектами в 2020 году, произошло много улучшений (его должность — директор по работе с сообществом в Grafana Labs).
«Хотя отсутствие обнаружения сервисов в OpenTelemetry всегда будет создавать дополнительную работу для операторов, большинство фундаментальных проблем уже решены», — сказал мне Хартманн после конференции. По словам Хартманна, OpenTelemetry изменила (возможно, исправила) свои определения сегментов гистограмм в пользу Prometheus. «Затем Prometheus расширил поддержку меток данных для поддержки OpenTelemetry», — сказал Хартманн. «И оба проекта на раннем этапе совместно работали над собственными гистограммами, основанными на работе Бьёрна «Беорна» Рабенштайна, что привело к полностью совместимым релизам с обеих сторон.
Между тем, OpenTelemetry «существует в полную силу и не собирается исчезать, и организации стремятся использовать ее с Prometheus, инструментируя свои сервисы с помощью OpenTelemetry, а затем отправляя часть метрик в систему Prometheus, — сказал Волц. — Однако существует множество недостатков по сравнению с использованием собственных клиентских библиотек инструментов Prometheus», — сказал Волц. «Важно знать об этом, прежде чем выбирать маршрут OpenTelemetry, если кого-то больше всего волнует метрики и Прометей».
Быстрый контраст между двумя системами показывает, что Prometheus представляет собой целую систему мониторинга, фокусирующуюся только на типе сигнала метрик. Напротив, OpenTelemetry «заботится только о» генерации сигналов, включая журналы, метрики, трассировки и профили, а затем передаче их в какую-то стороннюю серверную систему, сказал Волц. Это соответствует тому, как цель создателей OpenTelemetry состоит в стандартизации аспекта эмиссии, и отражает множество различных поставщиков хранилищ, представленных в OpenTelemetry.
Компоненты передачи представляют собой ключевое отличие: OpenTelemetry использует OTLP для отправки этих метрик посредством push-уведомлений, в то время как Prometheus использует текстовый формат и активно извлекает их, сказал Волц. По словам Волца, отправка метрик через сборщик OpenTelemetry на конечную точку приемника OTLP на сервере Prometheus имеет ряд недостатков.
Потеря активного извлечения и мониторинга состояния
По словам Волца, первым и самым досадным недостатком является отказ от многого из того, что делает Prometheus хорошим и способным: интеграция обнаружения сервисов с активным мониторингом целей на основе извлечения. Prometheus решает эту проблему, взаимодействуя с такими системами, как сервер Kubernetes API, чтобы получать всегда актуальное представление. Затем он активно пытается получить или очистить метрики, записывая повышающиеся метрики со значением 0 или 1, что важно для целевых оповещений о состоянии здоровья, сказал Волц.
Поскольку OpenTelemetry не имеет встроенного средства для этой функции, становится сложнее определить, работает ли цель, но не отправляет метрики, или она не работает, сказал Волц. И наоборот, меры безопасности обходятся при отправке неожиданных метрик. «Многие люди полностью игнорируют это, рассматривая свой сервер Prometheus как случайный приемник метрик, и тогда они не знают, не является ли процесс, который должен быть запущен», — сказал Волц. «Идея синтетической метрики для приема OTLP была услышана, но ее пока не существует».
Вторым недостатком являются измененные названия метрик или несколько «уродливые селекторы PromQL», сказал Волц. OpenTelemetry вводит различия в наборах символов, позволяя использовать такие символы, как точки и косые черты, которые ранее не поддерживались в Prometheus 3. «Это говорит о том, что люди, стандартизирующие OpenTelemetry, не уделяли особого внимания тому, как метрика будет использоваться в языке запросов, таком как PromQL», — сказал Волц.
Соглашения Prometheus добавляют суффиксы как к единицам измерения, так и к типам показателей, чтобы сразу прояснить смысл. OpenTelemetry, однако, говорит: «Не вводите единицу измерения и не вводите имя метрики». В результате уровень приема Prometheus добавляет обратно эти суффиксы во время трансляции. По словам Волца, благодаря расширенному набору символов селекторы PromQL становятся более сложными и их труднее писать и читать, чем собственный селектор.
Действительно, OpenTelemetry и его SDK довольно сложны и могут работать довольно медленно. Бенчмаркинг в Go показал, что собственные клиентские библиотеки Prometheus работают до 22 раз быстрее, чем OpenTelemetry SDK для приращения счетчика, как упоминалось выше. «Даже добавление двух меток делает OpenTelemetry SDK на 90% медленнее», — сказал Волц. «Сложность OpenTelemetry встроена в систему, и от нее трудно избавиться, что делает ее XML или CORBA телеметрии, поскольку она пытается решить все проблемы одновременно».
Засучить рукава
По словам Волца, для проверки работоспособности будущая работа может включать синтетическую метрику для приема OTLP. По словам Волца, эта функция будет использовать обнаружение сервисов и сопоставлять ожидаемые данные с входящими данными, чтобы генерировать метрику работоспособности в случае отсутствия данных.
«Что касается показателей, команда Prometheus активно пытается улучшить ситуацию, включая создание экспериментального процессора Delta to Compulative для поддержки дельта-темпоральности OpenTelemetry», — сказал Волц. «Существует также общепризнанное сожаление по поводу отсутствия семантических соглашений на земле Prometheus с самого начала, что позволяет предположить, что в будущем сотрудничество с людьми OpenTelemetry может иметь смысл ввести аналогичную стандартизированную структуру именования».
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. BC Gain — основатель и главный аналитик ReveCom Media. Его одержимость компьютерами началась, когда в начале 1980-х он взломал консоль Space Invaders, чтобы играть весь день за 25 центов в местном игровом зале. Затем он… Подробнее от Б. Кэмерона Гейна.
