привет. Данные из прошлого можно инжектить, но нужно помнить про кэш ответов, который по умолчанию считает, что все ответы с конечным временем старше пяти минут больше никогда не меняются. Если во время заливки старых данных делать запросы по этим данным, то они закэшируются при первом запросе, поэтому последюущие запросы не будут возвращать данные, добавленные после первого запроса. Это можно решить несколькими путями:
1) отключить кэш запросов на время заливки данных с помощью флага -search.disableCache
2) увеличить интервал времени от текущего момента, на котором данные не кэшируются, с помощью флага -search.cacheTimestampOffset. По умолчанию он равен 5 минутам
3) сбросить кэш после заливки данных с помощью обращения к /internal/resetRollupResultCache
См. подробности https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/README.md#backfilling .

VictoriaMetrics/VictoriaMetrics tagged: v1.34.2
Link: https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v1.34.2
Release notes:

### Changes since v1.34.1

*   ENHANCEMENT: vmagent: add `-remoteWrite.urlRelabelConfig` for applying individual relabeling for each `-remoteWrite.url`. See [#308](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/308) and [#320](https://gith...

More

Поясните пожалуйста кто prometheus в проде юзает, у вас насколько большая страница по /metrics выходит?

Смотря где

ну меня интересует вообще, т.е. я сейчас должен добавить метрики которые дадут метров 10-15 прироста размера ответа, вроде и не особо страшно должно быть, локальная сеть, быстрые ответы, но чет сомнения гложут, на такие объемы я пока не рассчитывал. Для меня метрики это что-то более обобщенное, а тут файл будет только расти в размерах, что.. не есть хорошо, но и вариантов особо других не вижу

т.е. выходит что-то вроде labelNames: ['id1', 'id2', 'os', 'type'] , дико не есть хорошо, но в базу такое писать будет еще веселее

Лейблы id и id2... Вам точно нужен пром?  Расскажите про задачу?

мониторинг пуш уведомлений, в какой группе какое сообщение. там на каждое сообщение может быть дофига действий, вот их количество и мониторим. но проблема в том что хотят считать для каждой группы и сообщения все отдельно. писать в БД - не выход, там десятки тысяч которые отрабатываются отдельно, если писать туда то будет тупо лишняя нагрузка на базу которая вообще не нужна, да и не факт что база такое извращение вообще выдержит. в пром - будет расти /metrics т.к. группы и сообщения будут только увеличиваться. щас думаю про influx на самом деле, но все равно смущает

Это события. Для событий пром не нужен

Вам нужна база данных. Кликхаус сейчас в маинтстриме

Возможно эластик

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

distributed sqlite

Это начальный трафик для кх

На четверть ядра

Спасибо, попробую его 🙏

Посмотрите, на решения типа как clickhouse+sql_exporter+prometheus. Такие решения например для сбора статистики nginx используют, есть куча примеров реализации

Товарищи, а кто-то занимался переносом дашбордов графаны?
Что-то все инструменты, которые нагуглились и работают через api генерят json, который не влетает в импорт потом.
Может, нюанс какой-то есть?
Что вообще в этом деле принято за best practice ?

сгенери json, и добавь как код, а не через апи

copy - paste