Спасибо!

Ещё такой вопрос:
Есть ли способ сохранять разные тенанты в разных базах? Или из одной общей базы выгрузить значения только по одному тенанту, чтобы развернуть отдельную VM только с этим тенантом?

Из документации вижу, что vmctl может фильтровать по лейблу, но тенант ведь не лейбл.

Вообще задача такая: есть одна общая VM. Когда один из тенантов становится слишком большим или хочет отделиться от общего проекта, выгружать его данные в отдельную VM.
И в обратную сторону

> Есть ли способ сохранять разные тенанты в разных базах?
Такой возомжности нет.

> Или из одной общей базы выгрузить значения только по одному тенанту, чтобы развернуть отдельную VM только с этим тенантом?
Так можно сделать, т.к. мультитенанси работает на уровне URL - см. https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#multitenancy

> Из документации вижу, что vmctl может фильтровать по лейблу, но тенант ведь не лейбл.
При экспорте из кластерной версии нужно указывать флаг --vm-native-src-addr который будет содержать tenant_id, тогда будут получены только данные этого тенанта.

Ух, спасибо!

Привет. Помогите плз понять суть ошибки.
У меня есть запрос, который строит график с количеством транзакций в секунду. Он пока что прекрасно работает на больших отрезках. Но мне так же нужен запрос, который возвращает общее число транзакций за отрезок. Для этого я беру sum_over_time от increase от счетчика. Этот запрос работает на коротких отрезках, но на длинных появляется ошибка.
Сам запрос: sum(sum_over_time(increase(({__name__=~"^.+_duration_count$"} or on() vector(0)))[15724800s]))
Ошибка: error when executing query=\"...\": too many points for the given step=300000, start=1608294488364 and end=1624019888364: 52419; cannot exceed -search.maxPointsPerTimeseries=30000

Не понимаю почему это происходит в таком запросе и при этом не возникает в таком: sum by (http_status_code) (rate({__name__=~"^.+_duration_count$"} or on() vector(0) ))

я в общем-то заменил уже на sum increase от range вектора, просто интересно было почему такой текст ошибки. То есть он как-то связан с sum_over_time, но ошибка неочевидная в таком случае

Вам нужен запрос sum(increase({__name__=~".+_duration_count"}[15724800s])) . В вашем запросе запускается режим выполнения подзапросов. См. https://valyala.medium.com/prometheus-subqueries-in-victoriametrics-9b1492b720b3 .    Т.е. сначала вычисляется содержимое внутри sum_over_time с заданным шагом (step) на заданном интервале (start .. end], а затем поверх него вычисляется sum_over_time. Параметры start, end и step автоматически передаются клиентом (например, grafana) в хендлер /api/v1/query_range. См. https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries

Здесь как раз самое странное для меня - первый запрос instant и графана в него передает только time (проверял во вкладке network), откуда берётся start и step вообще не понятно.

Второй запрос как раз query_range и в нем step даже меньше.
Но ошибки не возникает.

Как я уже написал, я запросы переделал)
Но вот в таких случаях очень не хватает sql'вского explain. Было бы очень круто в логах Виктории видеть подробный план исполнения запроса при какой-нибудь настройке

В первом запросе таймренж берется из квадратных скобок внешнего запроса, а step берется по умолчанию - 5 минут (300 секунд), если его явно не указать

А, то есть теоретически я могу в квадратных скобках указать шаг (через двоеточие я так понимаю) и тогда кол-во точек будет нормальным и ошибка должна уйти. Огонь, спасибо!

Ага

Я бы тоже топил за downsampling, но глядя на то как хорошо VM жмет данные, придется подождать хотя бы пол года для реальных аргументов.

Скорость выполнения запросов в графане на больших диапазонах это норм аргумент?

Дело на самом деле не в хранении, а больших интервалах в запросах, когда за полгода хочешь проанализировать например

Но мне уже ткнули в vmalert

Здравствуйте. Я собираю данные с сервера, записываю их в VictoriaMetrics посредством экспорта csv. Метрик много и главная проблема --- некоторые из них имеют пробелы, точки, запятые и кириллицу. Сначала я сделал так, что метрика (в термах VM) одна (называется value), но к ним ещё привязан label (имя метрики, которая может содержать кириллицу, пробелы и т.п.). В Grafana всё замечательно (можно выбирать несколько метрик и смотреть) за исключением отображения данных в таблице (в одной строке отображается только одно значение). К тому же по задумке так неправильно делать. Метрика одна, а label-ов много. Как я понимаю, в названии метрики я не могу использовать кириллицу, пробелы и т.п. Получается, надо остановиться на варианте с одной метрикой value и label-ами к нему? Или можно сделать по-другому?

Лучше придерживаться конвенции: https://prometheus.io/docs/practices/naming/

Я пока не знаю, у меня пока все годовые данные в графите, сдаунсампленные

Спасибо. Тогда придётся делать транслитерацию метрик и привязывать к ним оригинальное значение. Однако в таком случае поджидает другая проблема --- нельзя не изменяя запроса (в Grafana) выбирать разные метрики. Т.е. нельзя создать template variable и оттуда выбирать метрики, которые надо отобразить

Системный лейбл
_ _ name _ _ (все пробелы надо убрать, а то Телега форматирует из-за подчеркивания двойного)