ХабрПостыНовостиМегапосты?

Для хранения метрик Deckhouse-кластеров теперь нужно до 10 раз меньше памяти

За сбор и хранение метрик во всех кластерах Deckhouse Kubernetes Platform теперь по умолчанию отвечает Deckhouse Prom++. Начиная с версии 1.71, он заменит прожорливый Prometheus в Enterprise-редакциях платформы и в Open Source-продукте. Это поможет заметно сократить затраты на работу кластеров — Prom++ требует в разы меньше RAM. Сертифицированную ФСТЭК России редакцию DKP CSE обновим чуть-чуть позже. 

Что такое Deckhouse Prom++

Deckhouse Prom++ — это Open Source-система мониторинга, включённая в Единый реестр российского ПО под номером 28605. Мы переписали наиболее ресурсоёмкую часть ванильного Prometheus на С++ так, чтобы он потреблял до 10 раз меньше памяти. Подробнее о реализации и оптимизации хранения данных в Write-Ahead Log можно прочитать в отдельной статье. 

Как применить изменения в своём Deckhouse-кластере

Всё, что вам нужно сделать — это дождаться выхода Deckhouse Kubernetes Platform 1.71 и обновиться на неё. В среднем после перехода расходы на систему мониторинга кластера снижаются на 37 %.

Если у вас есть весомые причины остаться на обычном Prometheus, перед обновлением платформы нужно создать следующий ModuleConfig:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: prompp
spec:
  enabled: false

Кстати, Deckhouse Prom++ — это не только про DKP. Его можно использовать в любых Kubernetes-кластерах, а также в классической инфраструктуре без Kubernetes. И у нас уже есть яркие примеры: одна из компаний, пожелавшая остаться анонимной, поделилась результатами перехода на Prom++ в своей инфраструктуре.

Продукт разворачивается так же, как стандартный Prometheus:

  1. В Kubernetes — с помощью Prometheus Operator или через Helm-чарт, в зависимости от того, как был установлен ванильный Prometheus.

  2. В классической инфраструктуре — с помощью Docker-образа или запуска бинарника. 

Переход с Prometheus займёт у вас 5–10 минут. Привычные API и настройки останутся без изменений. Дашборды и алерты продолжат работать как прежде. Никаких новых зависимостей не появится, плюс в любой момент можно вернуться на обычный Prometheus, если новый вариант вам не понравится. 

Полезные ссылки:

  1. Telegram-сообщество Prom++, где можно задать вопросы разработчикам.

  2. Документация по установке. 

@anna_lesnykh
07.08.2025 13:12 UTC
Первоисточник

Комментарии

@IgorOhrimenko
09.08.2025 17:22 UTC
0

К потреблению прометея уже все привыкли, а вот к медленной скрости нет, Prom++ скорости прибавляет?

12.08.2025 11:01 UTC
0

А что не так со скоростью Prometheus?

24.08.2025 08:03 UTC
0

Так как дела обстоят со скоростью Prom++? Есть сравнителным анализ с конкурентами?

25.08.2025 08:52 UTC
0

Собственно нас периодически спрашивают — почему мы переписали именно на плюсах, ведь те же алгоритмы можно было написать на Go или на Rust. Ответ — скорость. В C++ мы использовали SIMD-инструкции и другие оптимизации, чтобы алгоритмы компрессии получились не хуже по производительности. Мы не напрямую замеряем скорость, а смотрим изменение утилизации процессора. Она по итогу незначительно снизилась. Но в целом Prom++ на сегодня близок по показателям к ванильному прому. Собственно первая задача была — оптимизация по памяти, потому что это самый дорогой ресурс в кластерах. Вот в этой статье есть сравнительные графики и таблицы с числами.

25.08.2025 09:00 UTC
0

Последние полгода мы активно работаем в том числе и над производительностью, снижая количество блокировок и добавляя конкурентные операции чтения и записи. При этом до сих пор мы работали только с оперативным хранилищем данных, то, что называется головой. Работа с историческими данными не менялась. Но в планах есть более масштабные изменения:

  1. Переработка формата исторических блоков, которая в том числе позволит ускорить их подгрузку и выполнение запросов по ним.

  2. Предобработка данных в процессе их декодинга, что позволит делать меньше аллокаций и перенести часть математики в C++, где эти операции можно будет лучше оптимизировать.

  3. Построение распределённого хранилища, позволяющего распараллелить вычисление запросов между всеми нодами кластера, а не внутри одного контейнера с Prom++.

Это лишь направления, которые обсуждались как возможные. Команда у нас небольшая, так что итоговое направление приходится выбирать одно. И выбираем мы его сейчас в основном ориентируясь на «количество боли», которую слышим от наших пациентов клиентов.

07.09.2025 09:43 UTC
0

А с Victoria Metrics сравнение делали?

07.09.2025 21:00 UTC
0

Да