Комментарии 23
А среди этих миллионов метрик есть метрика под названием КПД или хотябы её логарифм.
Пиксом смотрели ?
Весьма многообещающе.
Если можно, ответьте на несколько вопросов:
Функционал миграций имеющихся баз прометея в хранилище prom++ не планируете?
Downsampling?
Хранение в s3?
Продукт будет монолит или побьете на сервисы как Thanos (и все прочие мимиры/виктории/кортексы)?
Будет ли у продукта будущее отдельно от платформы deckhouse? А отдельно от k8s?
Функционал миграций имеющихся баз прометея в хранилище prom++ не планируете?
Это уже есть. В Prometheus и Prom++ одинаковый формат блоков, есть отличия только в WAL. Для wal уже есть конвертер, в обе стороны. Подробней написано в github
Downsampling
Нет, на данный момент не планируется.
Хранение в s3?
Нет, а зачем? Расскажите свой кейс, возможно сможем что-то посоветовать.
Продукт будет монолит или побьете на сервисы как Thanos (и все прочие мимиры/виктории/кортексы)?
Монолит, так же как и Prometheus. При этом, есть в планах доработать еще и mimir (аналог cortex от grafana).
Будет ли у продукта будущее отдельно от платформы deckhouse? А отдельно от k8s?
Однозначно да. Мы выложили его под лицензией Apache2. Его можно запускать как в виде бинарных файлов, так и с помощью Prometheus Operator или просто в Docker контейнере.
Спасибо!
Нет, а зачем? Расскажите свой кейс, возможно сможем что-то посоветовать.
Хочется перенести хранение большого датасета на более дешевое хранилище.
Еще если не затруднит, скажите:
А не будет ли в prom++ возможен параллельный приема remote write по стандартному старому prometheus wal протоколу? Не всегда есть возможность единомоментно мигрировать все инстансы prometheus на новую систему. Можно ли будет жить в режиме совместимости? Или это принципиально невозможно: старый wal "перекрутить" на приемнике remote write в новый wal?
Чуть дополню и поправлю ответ )) Downsampling планируется, но хитрый. Хранение в S3 в рамках Prom++ не планируется, но, как заметил Вова, планируется сделать доработки mimir, там как раз S3 (хотя возможно, что именно от интерфейса S3 там и откажемся, но распределённое объектное хранилище — да, будет).
Добавлю в копилку вопросов работу вне Кубера. Для 60 таргетов - а это 15 серверов с 4 экспортерами (Node, cAdvisor, Fail2Ban и ещё скрипт-мониторщик для крон-жобов) на каждом - мой Прометей отжирает стабильно под ≈800 Мб оперативки. Учитывая, что сервера у меня ультрабомжатские, полученные по различного рода промокодам, рефералкам и социальной инженерии (развести школьника на бабки - ну, это святое, каждый так делал) - "жирный" контейнер с Prometheus мне прям дышать не даёт, равно как и Ubuntu на хосте.
Так что заинтересован в том, чтобы эта штука работала и без K8s. Желательно, но любом сервере уровня "картошка".
Такая возможность уже есть. Вы можете заменить образ Prometheus на образ Deckhouse Prom++ с docker hub
А на GitHub звёздочку как поставить? :) Или продукт закрытый?
Deckhouse Prom++ можно уже сейчас. Ссылку на GitHub-репозиторий вы найдёте на лендинге.
Ну и чтоб не искать уже: https://github.com/deckhouse/prompp/
Раз все скромничают, спрошу традиционное - ПОЧЕМУ НЕ РАСТ?! (видимо, причина, что был опыт в С++, но не было в Руст?)
Расскажите, пожалуйста, про ваши приключения использования С++ из Go. Вижу, что использовали fastcgo, какие проблемы встретили (как при разработке, так и при эксплуатации в проде)?
мы мощно сидим на фичах ВикторияМетрикс, но ваш функционал вижу очень круто можно использовать в качестве колд стораджей
InfluxDB 3 версии тут вообще не конкурент?)
Грубо говоря, VictoriaMetrics - форк, следующая ветвь развития Prometheus. Почему вы взяли Prometheus, а не VictoriaMetrics за исходную точку развития своего продукта?
Есть несколько причин, по которым мы не выбрали VictoriaMetrics.
Во-первых, при выборе решения для мониторинга мы руководствовались ключевым требованием — унификация стека как для in-cluster мониторинга, так и для централизованного хранения метрик с множества кластеров. Да, у VictoriaMetrics есть кластерный режим, который позволяет это реализовать, но он не поддерживает решардирование данных — а это для нас критически важно.
Во-вторых, степень распространённости решения. VictoriaMetrics используется значительно меньшим числом компаний по сравнению с Prometheus. Это означает меньшую зрелость сообщества, меньшее количество готовых решений и потенциально более высокие риски при масштабировании или развитии системы.
В-третьих, VictoriaMetrics использует собственный формат хранения данных. Переход на него возможен, но обратная совместимость отсутствует. Мы рассматриваем это как существенный недостаток. При проектировании системы мы стремились обеспечить максимальную совместимость с Prometheus, а в тех случаях, где это невозможно, создать инструменты, позволяющие безболезненно переключаться между решениями в обе стороны.
Deckhouse Prom++: мы добавили плюсы к Prometheus и сократили потребление памяти в 7,8 раза