k
может повесить на каждый кластер лэйбл и уже по нему выборку делать?
Size: a a a
2019 November 27
A
то есть тебе надо сагрегировать по хосту?
k
получается, что так
A
тогда тебе надо поджойнить по мета-метрике которая сматчит имя хоста на имя пода
A
может у них есть какой-нибудь идентификатор "кластера"?
A
в метриках или где-то ещё
k
может у них есть какой-нибудь идентификатор "кластера"?
нет, к сожалению. иначе бы повесил в запросе уже
k
хотя. когда мышкой навожу на лэйбл, появляется список before relabeling. и там есть вот такое:
с этим можно что-то сделать? как-то заиспользовать?
__meta_kubernetes_pod_label_cluster="m1c5"с этим можно что-то сделать? как-то заиспользовать?
A
можно релейбелингом положить в лейбл
cluster напримерk
я как раз про это говорил
k
может повесить на каждый кластер лэйбл и уже по нему выборку делать?
A
да, делай
k
да, делай
ееее))) получилось))
спасибо всем!
sum(max(minio_total_disks) by (cluster))спасибо всем!
A
zbs
AS
Evgeny Lazin
мне просто интересно, почему они так сделали странно
На эту тему был доклад на последнем промконе.
AS
Тлдр там Легаси, нет сырых данных ибо для них нужны таймстампы, проблема с изоляцией между транзакциями
ЕО
Evgeny Lazin
зачем? гистограмму можно посчитать по любому набору данных
В проме фиксированный счётчик времени, нет никакого любого набора данных
ЕО
Ты не можешь как с КХ добавлять строчку c http response на каждый запрос. Приходится делать несколько увеличивающихся счётчиков на каждый тип ресонса
AV
Evgeny Lazin
а зачем вообще эти странные гистограммы в проме? неужели так дорого посчитать гистограмму просто по сырым данным?
Тебе нужно построить гистрограмму по времени обработки запросов на adserver, который обрабатывает 3 миллиона запросов в секунду. Ты будешь записывать сырые данные по всем 3 миллионам значениям в секунду в TSDB и потом строить по ним гистограммы? Или лучше предагрегировать эти данные на стороне приложения и записывать агегированные счетчики в TSDB раз в 30 секунд?
AV
если что, это реальный пример со старой работы