Различия между MetricsQL и PromQL описаны вот тут.
Да, но у наших разработчиков это каждый раз вызывает недоумение и путаницу, типа "Зачем для одного и того же делать два немного разных языка, для которых надо каждый раз помнить эти мелкие нюансы". Лично мне с этим ок, я просто всегда запросы на PromQL пишу, чтобы не страдать.
В любом случае, вы делаете прекрасный продукт, который действительно избавлен от многих родовых травм Прометея и за это вам огромное спасибо. Но увы, идеальных серебряных пуль не существует. :)
Используем 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 борда в графане нормально работает, а об прометей нет», приходится объяснять.
Мы тоже пришли к тому, что Bareos не очень подходит для бэкапов БД: надо писать и сопровождать свои скрипты, неудобно делать Point-in-Time Recovery. В итоге ушли на специфичные для БД бэкапилки (pgbackrest например).
Так, как это сделано в прометеусе — данные преобразуются в метрики (с помощью экспортеров), которые хранятся отдельно, и потом на основе них строятся алерты.
А как вы при сборе «на лету» будете смотреть исторические данные, особенно если источники данных эволюционировали со временем? Допустим, вы мониторите конверсию на основе данных из постгри, которые хранятся в табличке conversion_rate. Собирали эти данные 6 месяцев, а потом разработка решила переделать все на кликхаус и новые данные теперь хранятся в клике.
И теперь, чтобы построить какой-то сложный алерт (например, «сравни текущую конверсию с конверсией годом ранее и скажи если все плохо») вам придется городить какую-то адовую логику с кучей условий «если дата меньше такой-то — смотри в постгрю, иначе смотри в кликхаус» вместо того, чтобы работать с одной метрикой.
Для этого пишется простой экспортер на %language_name%. Выше справедливо заметили, что смешивать сбор данных и алертинг на основе этих данных не очень удобно в сопровождении.
Хорошая штука, тоже пользуемся. Странно, что вопрос конфигурирования практически не раскрыт в статье, по умолчанию он загружает весь лог в память, что может очень лихо съесть всю память на сервере. Для отключения такого поведения есть параметр `seek_from_end`.
Также, nginx-clickhouse с недавнего времени выставляет эндпойнт с метриками для Prometheus, в которых рассказывает, сколько логов он записал в CH, а сколько отбросил, не сумев распарсить.
Ну и Dockerfile там в репо тоже есть, чтобы с rpm не возиться.
Telepresence удобная штука, когда, например, надо подцепиться дебаггером к микросервису. Тормозит все в этом случае жестко, конечно, но иногда это единственный выход.
До уровня Димы мне еще далеко, конечно, плюс мы сознательно решили вынести весь стейт «в сторонку» от K8S/Openshift. Но да, там у него очень много ценного про хранение стейта в кубере. :)
Невозможность контроля? Они же говорят, что у них есть четкий план — соответственно они будут очень авторитарны. Это приведет к форку игры и распылению сообщества.
Да, так и поступили, но это не особо удобное решение:
Раз уж пошел диалог с разработчиком — расскажите, а чем вообще вызвано такое архитектурное решение? Зачем искусственно ограничивать размер поиска?
Страдал у вас в Issues несколько месяцев назад: https://github.com/VictoriaMetrics/VictoriaMetrics/issues/895
После этого пару раз еще проявлялось, но в более лайтовом режиме и после дерганий за
/internal/resetRollupResultCacheпроходило.Да, но у наших разработчиков это каждый раз вызывает недоумение и путаницу, типа "Зачем для одного и того же делать два немного разных языка, для которых надо каждый раз помнить эти мелкие нюансы". Лично мне с этим ок, я просто всегда запросы на PromQL пишу, чтобы не страдать.
В любом случае, вы делаете прекрасный продукт, который действительно избавлен от многих родовых травм Прометея и за это вам огромное спасибо. Но увы, идеальных серебряных пуль не существует. :)
В целом выводы от эксплуатации те же — память и диск она использует куда экономнее Prometheus, но есть несколько «но»:
cannot find tag filter matching less than 300001 time series; either increase -search.maxUniqueTimeseries or use more specific tag filters;А как вы при сборе «на лету» будете смотреть исторические данные, особенно если источники данных эволюционировали со временем? Допустим, вы мониторите конверсию на основе данных из постгри, которые хранятся в табличке conversion_rate. Собирали эти данные 6 месяцев, а потом разработка решила переделать все на кликхаус и новые данные теперь хранятся в клике.
И теперь, чтобы построить какой-то сложный алерт (например, «сравни текущую конверсию с конверсией годом ранее и скажи если все плохо») вам придется городить какую-то адовую логику с кучей условий «если дата меньше такой-то — смотри в постгрю, иначе смотри в кликхаус» вместо того, чтобы работать с одной метрикой.
github.com/kubernetes/kubernetes/issues/78421
github.com/kubernetes/kubernetes/issues/89947
Также, nginx-clickhouse с недавнего времени выставляет эндпойнт с метриками для Prometheus, в которых рассказывает, сколько логов он записал в CH, а сколько отбросил, не сумев распарсить.
Ну и Dockerfile там в репо тоже есть, чтобы с rpm не возиться.
Положил дашборд из примера в репо с ролью. Но мне кажется, это такая штука, которую под свои нужды надо сильно тюнить.
Prometheus + Grafana
Запросы подтер, ибо палево. :)