Бенчмарк Prometheus vs VictoriaMetrics на метриках node_exporter

[strangeman]

Используем VM как долговременное хранилище метрик.
В целом выводы от эксплуатации те же — память и диск она использует куда экономнее Prometheus, но есть несколько «но»:

• VM плохо справляется с объемными запросами. Например, мы собираем с помощью postgresql_exporter данные из pg_stat_activity по кверям, и агрегирующие запросы нормально отрабатывают в прометее, но ломаются в VM с cannot find tag filter matching less than 300001 time series; either increase -search.maxUniqueTimeseries or use more specific tag filters;
• У нас (не исключаю, что дело в кривизне рук, но это не точно) VM плохо переживала рестарты (после обновления например) — приходилось сбрасывать кэши и приседать по-всякому, чтобы она начала отдавать нормально метрики;
• Ну и разница в языках запросов иногда стреляет в ногу, несколько раз уже разработчики приходили с вопросами «почему у меня об VM борда в графане нормально работает, а об прометей нет», приходится объяснять.

[valyala]

VM плохо справляется с объемными запросами. Например, мы собираем с помощью postgresql_exporter данные из pg_stat_activity по кверям, и агрегирующие запросы нормально отрабатывают в прометее, но ломаются в VM с cannot find tag filter matching less than 300001 time series; either increase -search.maxUniqueTimeseries or use more specific tag filters

Попробуйте запустить вм с опцией командной строки -search.maxUniqueTimeseries=1000000, как указно в сообщении об ошибке.

У нас (не исключаю, что дело в кривизне рук, но это не точно) VM плохо переживала рестарты (после обновления например) — приходилось сбрасывать кэши и приседать по-всякому, чтобы она начала отдавать нормально метрики;

Странно — за последний год не слышал от пользователей нареканий по поводу проблем с рестартами в вм. Какая версия вм у вас? Рекомендуется периодически обновляться до последней, т.к. там могут быть исправлены всякие баги.

Насчет рестартов — вм может спокойно пережить любые рестарты без порчи данных, в т.ч. kill -9, hardware reset и "на хосте внезапно пропало питание". В худшем случае могут быть потеряны данные, добавленные в вм за последние несколько секунд. Прометеус же обычно теряет до двух часов последних данных либо не может стартануть и падает с OOM после некорректного завершения работы.

Ну и разница в языках запросов иногда стреляет в ногу, несколько раз уже разработчики приходили с вопросами «почему у меня об VM борда в графане нормально работает, а об прометей нет», приходится объяснять.

Различия между MetricsQL и PromQL описаны вот тут.

[strangeman]

Попробуйте запустить вм с опцией командной строки -search.maxUniqueTimeseries=1000000, как указно в сообщении об ошибке.

Да, так и поступили, но это не особо удобное решение:

• Ошибка эта никак не пробрасывается в графану и каждый раз приходится лазать по логам разбираться, почему же графики не строятся;
• Увеличение параметра — это полумера, т.к. никто не гарантирует, что следующий запрос не вылетит за новое значение этого параметра.

Раз уж пошел диалог с разработчиком — расскажите, а чем вообще вызвано такое архитектурное решение? Зачем искусственно ограничивать размер поиска?

Странно — за последний год не слышал от пользователей нареканий по поводу проблем с рестартами в вм.

Страдал у вас в Issues несколько месяцев назад: https://github.com/VictoriaMetrics/VictoriaMetrics/issues/895
После этого пару раз еще проявлялось, но в более лайтовом режиме и после дерганий за /internal/resetRollupResultCache проходило.

Различия между MetricsQL и PromQL описаны вот тут.

Да, но у наших разработчиков это каждый раз вызывает недоумение и путаницу, типа "Зачем для одного и того же делать два немного разных языка, для которых надо каждый раз помнить эти мелкие нюансы". Лично мне с этим ок, я просто всегда запросы на PromQL пишу, чтобы не страдать.

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

[valyala]

Раз уж пошел диалог с разработчиком — расскажите, а чем вообще вызвано такое архитектурное решение? Зачем искусственно ограничивать размер поиска?

Параметр -search.maxUniqueTimeseries нужен для того, чтобы предотвратить повышенное потребление ресурсов либо даже падение с out of memory ошибкой, если кто-то решит отправить аналог select * from table в VictoriaMetrics — {__name__!=""}. Большинство пользователей никогда не узнают про существование этого параметра, т.к. значение по умолчанию покрывает основные области применения VictoriaMetrics. Остальной небольшой части пользователей обычно хватает пары минут, чтобы настроить оптимальное для них значение -search.maxUniqueTimeseries после того, как они обнаружат соответствующее сообщение об ошибке в логах.