Prometheus задыхается на нашем масштабе, мигрировать на VictoriaMetrics или Mimir?

[lev8639]

Prometheus с retention 15 дней стал жрать под 64 гига RAM и периодически падает по OOM при тяжёлых запросах в графане. Кардинальность метрик около пары миллионов серий. Смотрю в сторону VictoriaMetrics и Grafana Mimir, что выбрать?

[nullloop7477]

VictoriaMetrics. У нас был такой же сценарий, после миграции потребление памяти упало раза в четыре на тех же данных. Single-node VM спокойно тянет то, на чём Prometheus загибался, а конфиг в разы проще чем кластер Mimir.

[dmitry_lab]

Mimir хорош если вам реально нужен горизонтальный мультитенант-скейл и вы уже в экосистеме Grafana с Loki и Tempo. Но операционно это тяжёлый зверь, куча компонентов, минио или s3 под чанки. Для одной команды это перебор.

[ksenia_dns]

Мультитенант не нужен, у нас одна команда но много сервисов. Звучит как что VM подходит больше. А PromQL там полностью совместим?

[nulldaemon2798]

Да, VM поддерживает PromQL плюс свой MetricsQL с расширениями. Дашборды из графаны переехали без переделки, просто поменяли datasource. Remote write из существующих прометеев настраивается за пять минут.

[makar_dev]

Добавлю по кардинальности: прежде чем мигрировать, посмотрите cardinality explorer в VM, часто половина серий это мусорные лейблы типа pod_id или request_id которые кто-то залепил в метрики. Почистите источник и возможно даже миграция не понадобится.

[kira_api82]

Вот это дельный совет, про request_id в лейблах прям в точку, грешим этим. Сначала почищу кардинальность, потом уже буду смотреть на переезд. Спасибо!

[mark9640]

Мы крутим VictoriaMetrics в кластерном режиме почти три года, полёт нормальный. Единственное, бекапы через vmbackup настройте сразу, по умолчанию их нет и легко об этом забыть до первого инцидента.

[webproxy2636]

У меня после этого способа всё завелось, спасибо за наводку.

[anna_data53]

Актуально до сих пор, наткнулся через поиск — помогло, спасибо!