если они подвисли

это вообще в куберчат скорее чем сюда вопрос

Да кто против? Примеры запаздывания экспортёров в rpm?

Кто-нибудь знает, как работает rate? Что-то не могу понять, почему он иногда теряет значения. Вот пример ниже, на котором $interval = 1min. если поставить $interval 30s (равным scrape_interval), то график с ним вообще возвращает пустоту.
Читаю вот это https://prometheus.io/docs/prometheus/latest/querying/functions/#rate и это https://medium.com/@valyala/why-irate-from-prometheus-doesnt-capture-spikes-45f9896d7832 и озарения не приходит.

Т.е. вместо того, чтобы показывать мне 0.0167 ops, он показывает 0.3, но реже, чем это необходимо.

Делай лучше rate(sum()), чем sum(rate())

Но в доке же написано противоположное. И это логично, потому что так не будут ломаться перезагрузки.
Вообще, в данном запросе там ровно одна серия, так что sum вообще ничего менять не должен.

Ну, если есть перегрузки, то да.

Короче, смена функций местами ничего не меняет. Даже, если убрать sum, результат аналогичный. Дело в rate, это точно.

Работает он, по идее, как приращение за указанный интервал, нормированное по секундам. С экстраполяцией данных, если есть необходимость.

В любом случае, не стоит считать rate() точным, это индикатор для примерной оценки динамики приращения метрики.

И, вообще, сам prometheus не стоит считать хранилищем точных данных, раз уж на то пошло :)

а никто не знает в графана есть какой то аналог /etc/grafana/config.d/*.ini ???
чтобы можно было часть grafana.ini переопределить?

или только provisioners с yaml файлами?

Ну это в некотором роде позор😕 Я бы, конечно, не отказался смотреть на эти данные, как на примерные, но я бы хотел понимать, насколько они примерные.

Судя по всему, нужно переходить на rollup от VM. Но только у меня почему-то VM на тестовом контуре, а на прод её ставить не хотят.

Это не позор, это такова предметная область: ты не тратишь кучу ресурсов на сбор и хранение точных данных, но за это расплачиваешься погрешностями при сборе метрик (timestamp выставляется в prome-е и может расходиться с временем актуальности метрики в экспортере), при хранении и при обработке (точка, в конечном счете, должна быть выровнена по периоду таймсерии, что уже само по себе вызывает необходимость в интерполяции).
Если тебе нужны абсолютно точные данные (например, потому что тебе нужно хранить бизнес-метрики), то prom (и, вообще, системы для работы с техническими метриками) — неподходящий для этого инструмент.

Да я ж говорю: я готов мириться с погрешностями, я просто хочу понимать, какая она. Кстати, все это я понимаю, но на моем графике четко видно, что все данные выровнены, а результат все равно непонятный