ну, в графане пока твое выражение будет возвращать хоть что-то, алерта NO DATA ты не получишь

пример у тебя есть график и ты хочешь чтоб алертилось его у него  есть пик > 100 (например) это значит что графана выберет точки по query_range api и потом сама проверит значения (и  если точек нет вот тебе но дата), в проме же есть просто выражение которое содержит уже больше меньше или что то другое и это неотъемлемая часть запроса и  если метрики вернулись то алерт а если метрики есть но не подпадают под условие  или их нет то соотвественно не вернулись

А можно делать групповые условия. Типа:

Количество_запросов < 100 && max (деплой)[5m] == 0

Ори пожалуйста сюда.

я тут не знаю (мой опыт с другой стороны с человека который ишет почему сработал алерт по вине имплементции апи query_range)

Идея такая: хочу алерт только если не было деплоя в ближайшие 5 минут.
Если был деплой, алерт не нужен.
При этом, если данные все еще ниже 100, а 5 минут уже прошло - то алерт давай

в vm это можно сделать благодаря функции lag

в проме absent может помочь и использования [5m] в выражении

хм, я что то не совсем понимаю как может помочь lag:

lag(m[d]) - returns lag between the current timestamp and the timestamp from the previous data point in m over d.

cluster

Ищет за указанные интервал точку берет последнюю и считает разницу между текущим временем и точкой пример lag(last_deploy[10m]) найдет метрику с именем last_deploy за последние 10 минут вычтет время последнего датапоинта от текущего и покажет это

это делается не так. это на время проведения работ делается сайленс

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

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

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

Т.е для тестов у нас есть описание в cucumber, вот что то похожее бы для прома

делаешь обычный conf.d и клеишь результаты приемлимым для тебя инструментом. мне подошел yq

Md, это некие ридмишки в которых описывается сервис, хочется часть этой ридмишки посвятить метрикам

в кубере там и джобы и рулы описываются отдельными апи объектами. по верх этого дела написана кастомная магия которая собирает кофиг прома по кускам.

jq?

а не, нашел