И стоило нам вообще эволюционировать миллионы лет, чтоб в конце-концов отдавать данные по snmp из прометеуса в mrtg?

Подскажите, а можно ли как-то сделать вот такой маразм:

Есть работающий прометеус который собирает всякую дичь. Хочется отдавать информацию которую он собирает (т.е. собрал уже и записал в свою БД) отдавать по ТА-ДАММММ протоколу SNMP ?
ЗАЧЕМ ? потому что заказчик юзает окаменелое гавно и даже заббикс для него в новинку. Поднимать snmpd и прикручивать к нему те же собиралки что и в прометеусе очень не хочется.

Смотри, я недавно присоединился к VM, а пользовался с открытия в опенсорс - все будет, но не сразу. Типа хотелось бы что б сразу всё сделать и выкатить, но так не получается (кстати, мы если что открыты к сотрудничеству и с сообществом PR, issue идеи; и с компаниями - поддержка и так далее)

так что я понимаю, что всё выглядит незрело, если нет конкретной боли которую VM будет решать конкретно для тебя

С одной стороны хорошо что есть контакт с разработчиками. С другой стороны ВМ тут становится столько что пора переименовать канал в "Маркетинг VM (бывшая Церковь метрик)". Агрессивный маркетинг с наскакиванием на конкурентов по поводу и без повода никак делу не помогает имхо. (Да, даже если конкуренты ведут себя некрасиво). Хотя это мое мнение и не мой продукт, конечно.

Есть боль, но она решается уже другими продуктами. И фишки перейти на ВМ пока просто нет. А незрелость не добавляет такого желания тем более.

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

Могу еще предложить vector.dev :)

Могу еще предложить vector.dev :)

quantile_over_time считает индивидуальный квантиль для каждого временного ряда. Эти квантили потом нельзя агрегировать, т.е. sum(quantile_over_time(...)) не имеет смысла.
Если нужно подсчитать квантиль поверх многих временных рядов, то можно использовать что-то вроде такого:
histogram_quantile(0.95, sum(histogram_over_time(metric[1h])))
Функция histogram_over_time есть только в вм, поэтому такой запрос не будет работать в проме. Пишу это с телефона, поэтому могу допустить ошибки в запросе. Но идея должна быть понятна. См. про histogram_over_time и другие дополнительные функции, подлерживаемые вм, вот тут - https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/MetricsQL

> если кончится место на диске или цпу? Тогда поставим кластер. Кто будет ставить кластер? Есть ли для этого доступный в данный момент инженер? Сколько это займёт времени? Как продакшн будет в это время работать? Есть ли у нас железо на кластер?

но ведь все это в равной степени относится и к кортексу, и к таносу. Капасити планнинг в больших конторах, если мы уж о них говорим, проходит через platform team(или любое другое важное название) и вы получаете лимитированные ресурсы для своих приложений.

И не стоит думать, что танос/кортекс не требуют поддержки или не испытывают проблем со скейлом. Из компаний использующих танос и имеющих публичный трекер я знаю только Gitlab - и у них достаточно issues связанных с поддержкой.

Наверное под "простым нажатием кнопки" имелось в виду использование облачного хранилища, которое поддерживается таносом/кортексом, но отсуствует в VM. Это правда, такой поддержки нет и пока не понятно когда появится. Но использование облачного хранилища не освобождает от "Хрен с ним, давайте облако. Стоп, а есть ли у нас бюджет на это? И ещё миллион вопросов".  А для разворачивания одной кнопкой у VM тоже есть helm chart.

Ну и если уж хранить данные в object storage, то тут уже тяжело "полагаться" на такую систему для алертов или бизнес метрик. В случае с таносом за последние 2ч вам все равно нужно "сходить" во все прометеусы. А за более длительные периоды придется немного "подождать" ответа от querier'ов, пока они прочтут и дедуплицируют данные. Думаю очевидно, что скорость доступа к hdd (а VM позиционируется для использования hdd) будет лучше.

А для построения более надежного и быстрого решения на основе Кортекс все равно придется возиться с настройкой кластера кассандры. Но здесь у меня опыта нет, поправьте если не так.

На мой взгляд, большие компании во многом полагаются на популярность технологии при выборе. Танос/кортекс/графана-лабс - намного дольше на слуху, у них больше комьюнити, и они много сил вкладывают в свой "имидж". И это здорово, они очень много привнесли в oss и решили кучу проблем для всех нас(в какой-то мере создав "монополию", на мой взгляд). В то же время VM меньше года в oss и практически нет промоушена. Мне кажется, это основная причина недоверия к продукту и должно пройти время чтобы это поменялось и больше людей дали шанс продукту.

Для меня это выглядит очень похожим на ситуацию с КХ. К нему тоже было много недоверия вначале и только русскоязычные чаты поддерживали КХ. Я знаю как миниум два случая, когда инженеры в больших компаниях "давали шанс" КХ на lab-кластере и в итоге заменяли всю аналитику. Посмотрите сейчас на адопшн КХ, на развитие по сравнению с 2016 годом. И при этом есть еще большое кол-во людей не доверяющих хранение данных этой БД и они всегда находят кучу причин так считать. Но часто возможность процессить все данные на одном инстансе вместо кластера из 83 (см. clickhouse/vm billy benchmark) перевешивает боязнь нового.

Что-то эта формула у меня вообще нифига не показывает. Если взять sum отдельно, то значения совсем странные и кажется by (label) не работает - показывает все одинаковые значения

упс, забыл добавить там by(vmrange):

histogram_quantile(0.95, sum(histogram_over_time(up[1h])) by (vmrange))

Сработало :)
Осталось понять что я вижу, точнее чем это отличается от моих игр с quantile по истории. Если в эту формулу не добавлять ту же портянку с офсетами, то ничего общего, если же добавить - весьма похоже, но выгода неочевидна