А чем так плохи приблизительные цифры? Сейчас IT по всему миру уходит от ультранадежных(и дорогостоящих) серверов-питомцев в пользу стада сущностей с пониженной ответственностью за сохранность данных. Зато с пачкой механизмов балансировки и отказоустойчивости чтобы сохранность данных таки обеспечить. И в этих условиях нормально терять метрики. Нормально предоставлять некий приблизительный результат вычислений. Чтобы "на глаз" можно было сказать сильно стадо поредело или же одна овца ногу подвернула. Сильно страдают пользователи от этого или один процент увидел 500ки. В современном ИТ допускается некоторое кратковременное пострадывание юзера. И приблизительные метрики тоже допускаются. Если хочется точности - метрики то сами ведь никак не искажены. Можно выдрать metric[range] из API и посчитать как надо, а не как авторы хайпожорного инструмента придумали

Чтобы триггер сделать, когда средний размер транзакции упадет, например

Там же речь о rate/increase. А средние размеры - это про average. И с avg все в порядке

Ну пусть будет 'при росте транзакции'

И что же надо иметь в голове, чтобы смотреть на размер транзакции при помощи инкрементного счётчика?))

А kubelet как запущен и где?

С помощью kind

Внутри я nfs-common тож поставил

монтирование выполняет он, выглядит как будто либ/бинарника нет

а попробуй руками с этого nfs сервера примонтировать что-то

там где kubelet

Уже убил :)

Решил, что оно мне с таким геморроем не надо

А, ну в общем выглядит как проблема nfs на самой машине клиенте

Не заточено оно на железках крутиться нормально

Машина одна и та же :)

там емнип nfs сделано по-тупому, он монтирует через бинарник nfs каталог и юзает типа как local volume, но знает что там nfs и инфу о маунтах в etcd сохраняет

Так серверные и клиентский софт-то разный

Это да

смотри,
для rate и т.п. приблизительные цифры ОК

а вот для Increase НЕТ

самый простой use case
тебе надо узнать сколько именно было ошибок в конкретную минуту, не сколько "ошибок в секунду"
а именно пик словить, что например хотя бы одна ошибка была

у тебя есть монотонный  счетчик - кол-во ошибок
ты делаешь в prometheus
increase()
у тебя счетчик скакнул на +1

а ты получаешь цифру типа 1.1
и офигеваешь, потому что вроде как может быть либо 0 либо 1
другого по поведению метрики не дано... она целочисленная

и тебе надо бегать и целый день выискивать в документации почему так...

а оказывается просто аффтар / точнее ЛИДЕР проекта в свое время упоролся с экстраполяцией и increase знаете ли ли синтаксический сахар к rate()