k
а, у тебя там два пода?
сейчас 8 подов, 2 ноды
Size: a a a
2019 November 27
EL
Этот способ никто не отменяет, просто в этом случае "full-scan" по всему массиву нужен каждый раз. А если ты не хочешь, например, хранить весь исходный массив - как тогда считать будешь? Вот и остаются пред-посчитанные агрегаты в виде гистограмм. Разве не так?
даже в этом случае можно хранить HdrHistogram или t-digest какой-нибудь, а не тупо каунтеры для статических бакетов
k
и каждый из подов считает, что у него 4 диска. вот и получаю 4(пода)*4(диска)*2(ноды)
A
сейчас 8 подов, 2 ноды
у тебя каждый под должен видеть только 1 диск, верно?
A
если они видят все, то проблема не в прометее же
BG
Evgeny Lazin
а в чем проблема? ну тебе в запросе нужно указать какие бакеты тебе нужны, в остальном данные все есть
Ну, для такого нужно будет условно усреднять данные, что в итоге должно привести к тому, что это будет дикая апроксимация, разве нет? И чем больше scrape_interval относительно времени отдельного события, тем кошмарней будет результат. разве нет?
k
у тебя каждый под должен видеть только 1 диск, верно?
немного не так. минио запущен в кластерном режиме. там аргументом переданы все ендпоинты других подов. вот и получается, что каждый под запущен с 4 дисками (но только один из них локальный, а другие на других подах)
k
если они видят все, то проблема не в прометее же
да, и я уже отписал об этом разрабам. сейчас же нужен просто костыль из запроса, который отобразит реальное число устройст
A
немного не так. минио запущен в кластерном режиме. там аргументом переданы все ендпоинты других подов. вот и получается, что каждый под запущен с 4 дисками (но только один из них локальный, а другие на других подах)
и чо? они же все вместе в кластере у тебя, и должны (вроде как) отдавать либо 1 каждый либо 8 каждый
A
а отдают почему-то 4
EL
Ну, для такого нужно будет условно усреднять данные, что в итоге должно привести к тому, что это будет дикая апроксимация, разве нет? И чем больше scrape_interval относительно времени отдельного события, тем кошмарней будет результат. разве нет?
зачем устреднять? у меня есть бакет 1-10, мне нужно посчитать что туда попадает 2 значения в твоем массиве и все
BG
Evgeny Lazin
зачем устреднять? у меня есть бакет 1-10, мне нужно посчитать что туда попадает 2 значения в твоем массиве и все
В массиве только количество событий в промежутке времени. Из-за этого можно только предположить время одного события в интервале, поделив интервал на количество событий.
yL
Evgeny Lazin
даже в этом случае можно хранить HdrHistogram или t-digest какой-нибудь, а не тупо каунтеры для статических бакетов
С этим не поспоришь, можно, но это уже про выбор конкретной имплементации представления гистограммы и накладных расходов на неё. Вариант прома совсем кривой, конечно. Предложенное в VM уже рациональнее и притом не сильно ломает совместимость.
EL
В массиве только количество событий в промежутке времени. Из-за этого можно только предположить время одного события в интервале, поделив интервал на количество событий.
ах вот в чем дело, ок
то бишь в проме ты по другому никак не можешь хранить данные, которые обновляются чаще чем scrape interval, поэтому вот такие костыли?
то бишь в проме ты по другому никак не можешь хранить данные, которые обновляются чаще чем scrape interval, поэтому вот такие костыли?
k
а отдают почему-то 4
BG
Evgeny Lazin
ах вот в чем дело, ок
то бишь в проме ты по другому никак не можешь хранить данные, которые обновляются чаще чем scrape interval, поэтому вот такие костыли?
то бишь в проме ты по другому никак не можешь хранить данные, которые обновляются чаще чем scrape interval, поэтому вот такие костыли?
Да
EL
мне просто интересно, почему они так сделали странно
k
а отдают почему-то 4
правильно. с каждого пода метрика отдает значение 4. потому что минио запущен с 4 аргументами.
A
то есть у тебя типа два "кластер" минио и в каждом по 4 хоста?
k
два кластера, в каждом по одному хосту, на каждом хосте 4 устройства.