сейчас я получаю метрики раз в 5 минут и экспозю экспортером для прометея
что в целом работает, но нет нужной мне гранулированости так как получаются 5-минутные интервалы
к счастью, метрики содержат тайистампы, есть идея пушить гистограмму прямо в викторию с нужным таймстампом в прошлом
но для этого гистограмму надо аггрегировать с необходимым интервалом (например, 10-секундным)
вопроса два:
- чтобы не писать свой аггрегатор, может уже есть готовое решение которое так сделает?
- понятно ли я описал юзкейс :)

Всем привет!
проапдейтил графану до версии 6.5.2 и начались проблемы с алертами в телеграм
алерты в телеграм не идут, в логах такое:
grafana-652    | t=2020-01-13T15:26:31+0000 lvl=eror msg="Alert Rule Result Error" logger=alerting.evalContext ruleId=21 name="" error="Alert execution exceeded the timeout" changing state to=alerting

при этом send-test работает, отправляет даже с картинкой
предположил что проблема именно с рендером картинок, установил grafana/grafana-image-renderer , но не помогло

кто-то сталкивался с подобной бедой?

Может, использовать statsd для агрегации гистограмм? См. https://github.com/statsd/statsd/blob/master/docs/metric_types.md#timing . Там можно конфигурировать, с каким интервалом отправлять агрегированные значения в storage, которым может выступать victoriametrics. См. https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/README.md#how-to-send-data-from-graphite-compatible-agents-such-as-statsd

Второй вариант - собирать данные в гистограммы викторииметрикс, чтобы они потом скрейпались прометеусом и заливались в итоге в вм. Эти гистограммы хороши тем, что по ним можно строить отчеты с любой гранулярностью по времени и еще можно суммировать гистограммы по разным метрикам. Вот тут подробности - https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350 .
Также рекомендую присмотреться к функции histogram_share, которая может быть полезна для расчета SLI (SLO) по гистограммам. Вот тут подробности - https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/ExtendedPromQL

Какой вежливый бот)

Спасибо, попробую

А если хочу например не долю запросов - а долю времени когда значение было ниже threshold на промежутке - есть хелпер, или это надо precalc rule создавать все равно ("количество минут")?

Критично когда thresholds могут быть переменными

Я про hisrogram_share

всем привет

есть вопрос:
У меня есть prometheus, alertmanager, сервис (скриптовый), в нём есть 20 предметов, желание: если больше N предметов сработало - объединять сработки и выплёвывать пачкой, проблема: группировка по сервису не работает как в желании, потому что при разных - рекомендованных или любых других настройках group_interval / group_wait и repeat_interval'а prometheus просто спамит в alertmanager одно и то же событие, даже если alertmanager уже отправил по нему уведомление.
Кто нибудь знает что с этим можно сделать чтобы удовлетворить желание?

из тех, за которые пока ещё здесь не банят :-) есть ещё lpar2rrd (скоро lpar2rrd и stor2rrd сольются в один продукт - xormon)
не видел там правда ARM, но зато знает про LDOMы и зоны - https://www.lpar2rrd.com/Solaris-sparc-x86-performance-monitoring-install.php#SOLARIS

Из доли запросов можно высчитать время, умножив результат histogram_share на количество секунд для времени из квадратных скобок increase или rate. Например, histogram_share(threshold, sum(increase(metric_bucket[1h])) by (vmrange)) * 3600 вернет количество секунд, в течение которого значение metric не превышало threshold на протяжении последнего часа.
Если используются прометеусовские гистограммы вместо вм-овских, то вместо by (vmrange) нужно писать by (le).

Можно амиксером догруппировать: https://docs.amixr.io/#/integrations/alertmanager?id=alertmanager-grouping-amp-amixr-grouping хотя не уверен, что правильно понял вопрос)

очень интересно, спасибо
раз уж мы подняли сессию вопросов и ответов - а если предположить что SLA высчитывается не по средней задерже значениям а по эрроррейту и перцентилю задержки?

например, я считаю erorrate так: “sum(rate(http_request_duration_milliseconds_count{status=~"[5].."}[5m])) / sum(rate(http_request_duration_milliseconds_count[5m]))”
мне как-то можно заюзать этот хелпер, или тут я совсем уже путаю теплое с мягким?

Не понял про среднюю задержку. Гистограммы позволяют учитывать все значения, а не только средние.

Если http_request_duration_milliseconds - это histogram, а не summary, то можно использовать вот такой запрос, чтобы получить долю запросов с длительностью не выше max_duration за последние пять минут:

histogram_share(max_duration, sum(rate(http_request_duration_milliseconds_bucket[5m])) by (le))

Про разницу между histogram и summary можно почитать тут - https://prometheus.io/docs/practices/histograms/

Если нужна разбивка по лейблам - status, path или что там еще есть у http_request_duration_milliseconds , то добавляйте это в by (le, other_labels_here...)

спасибо за ответ, распишу подробнее, предположим есть по1, и оно получает данных с неких нечто1, нечто2, нечто3 и тп.
В этом приложении есть prometheus-метрики типа counter (разделенные по labels) и каждый раз при получении данных они инкрементируется на 1.
Следовательно, можно настроить alert правило, которое будет срабатывать когда счетчик перестал изменяться.
Receiver - telegram бот.
Так же хотелось бы настроить алертинг так что бы сообщения по недоступности нечтоХ для по1 объединялись в одно сообщение.

Как пробовал:
Делаем group_by по job.
При group_wait: 5s, group_interval: 5m:
Допустим нечто1 и нечто 2 перестали обновляться -> получаем объединенное сообщение = отлично
После чего, через 20 сек, перестал обновляться нечно3 - фиг, так как group_interval стопит сообщение на 5 минут.

При group_wait: 5s, group_interval: 5s:
Получаем лютый спам от того что prometheus каждый evaluation_interval повторяет сообщения (нафига в нем такая логика?)

Если сделать group_by по job и labels то отправка сообщений конечно идет как нужно, но тогда они не объединяются в одно.

Чем можно добить первый вариант до рабочего?

Возможно как то сменить парадигму мониторинга? Как?

Icinga

@valyala извини меня  за глупые вопросы, я пока еще учусь :) хочу пояснить свой контекст:

предположим, стоит задача - учитывать в SLA количество минут когда error rate был меньше 20%, то есть если SLA 50% за 2 дня значит что как минимум половину этого времени он был больше указанного порога

в проме я это решаю следующим образом:
1) задаю правило которое высчитывает количество минут - потому что пром не умеет range из instant:
   - name: rps_less20
     interval: 1m
     rules:
       - record: errrateless02:up
         expr: sum(rate(http_request_duration_milliseconds_count{status=~"5.."}[5m])) / sum(rate(http_request_duration_milliseconds_count[5m])) < bool 0.2
       - record: errrateless02:up_minutes
         expr: clamp_max(sum_over_time(errrateless02:up[1m]), 1)
2) подсчитываю соответствующий SLA:
sum_over_time(errrateless02:up_minutes[2d]) / (2 * 24 * 60)

не знаю правда правильно или нет считает, не тестил пока на реальных данных - но идея такая

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

ты скинул прикольную функцию, подумал может как-то вокруг нее можно и вышеописанную проблему решить, только поспешил и с телефона неправильно спросил

Вроде норм решение, только правило errrateless02:up_minutes лишнее, т.к. rps_less20 будет и так содержать точки с частотой в одну минуту, которая указана в interval. Также нужно понимать, что поминутные значения rps_less20 высчитваются на основе данных за последние пять минут - см. 5m в квадратных скобках, а не за минуту. Это может быть как нормально, так и не очень, в зависимости от требований.

Это решение можно сделать динамическим с помощью подзапросов - см. https://prometheus.io/blog/2019/01/28/subquery-support/ . Тогда оно будет иметь вид вроде:

avg_over_time((sum(increase(http_request_duration_milliseconds_count{status=~"5.."}[5m])) / sum(increase(http_request_duration_milliseconds_count[5m])) <bool 0.2)[2d:1m])

у VictoriaMetrics есть функция share_le_over_time(metric[d], threshold), которая возвращает долю значений metric за предыдущий интервал d, которые не превышали threshold. Эта функция полезна для подсчета SLI для metric без подзапросов. Если же в качестве metric стоит подзапрос, то лучше использовать вариант avg_over_time((metric <bool threshold)[d:step]), указанный выше.