A
да уж, нарисовать картинку с графиком нынче целый браузер требуется
Size: a a a
2020 January 14
DZ
Ну, с точки зрения современного фронтенда решение самое правильное
L
спасибо за ответ, распишу подробнее, предположим есть по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 то отправка сообщений конечно идет как нужно, но тогда они не объединяются в одно.
Чем можно добить первый вариант до рабочего?
Возможно как то сменить парадигму мониторинга? Как?
В этом приложении есть 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 то отправка сообщений конечно идет как нужно, но тогда они не объединяются в одно.
Чем можно добить первый вариант до рабочего?
Возможно как то сменить парадигму мониторинга? Как?
напомню про вопрос - может появились люди которые знают ответ, пока тестирую --rules.alert .resend-delay с разными параметрами.
Z
Привет. А расскажите про
params в прометеусе? Мне надо метрики забирать с url, который содержит ?. Гугл подсказывает, что это нужно делает через params, но не объясняет как.GG
да, все так
GG
ты просто в парамс пишешь все то, что после ?
A
Что такое "урл содержит ?"?
GG
blackbox_exporter
GG
Что такое "урл содержит ?"?
ну, это урл с гет запросом
A
ну, это урл с гет запросом
Не подсказывай
TF
а всего то стоит открыть ютуб или правильно спросить гугл..
A
так странно, сегодня говоря с менеджерами разных уровней понял что одни говоря SLA имеют ввиду agreement, а другие availability... еще один плюс в сторону важности создания определений при начале работы )
A
а всего то стоит открыть ютуб или правильно спросить гугл..
Правильно спрашивать гугл это целая наука
A
И даже не гугл, а вообще вопросы задавать
A
так странно, сегодня говоря с менеджерами разных уровней понял что одни говоря SLA имеют ввиду agreement, а другие availability... еще один плюс в сторону важности создания определений при начале работы )
Это отличное наблюдение
A
гугл тоже этим грешит (не книжка в смысле а результаты выдачи)
AS
так странно, сегодня говоря с менеджерами разных уровней понял что одни говоря SLA имеют ввиду agreement, а другие availability... еще один плюс в сторону важности создания определений при начале работы )
Dsl это domain specific language
A
поясните такой момент плиз? гугльбук говорит: "An easy way to understand the difference between SLO and SLA is to ask “what happens of the SLOs aren’t met?“. If there is no explicit consequence - then it’s SLO."
если наш SLA звучит как "если сервис доступен больше чем 99.9% за 10 дней то перестаньте давать нам деньги", значит SLO тоже звучит "сервис доступен больше чем 99.9% за 10 дней", значит availability это SLI метрика?
если наш SLA звучит как "если сервис доступен больше чем 99.9% за 10 дней то перестаньте давать нам деньги", значит SLO тоже звучит "сервис доступен больше чем 99.9% за 10 дней", значит availability это SLI метрика?
AS
поясните такой момент плиз? гугльбук говорит: "An easy way to understand the difference between SLO and SLA is to ask “what happens of the SLOs aren’t met?“. If there is no explicit consequence - then it’s SLO."
если наш SLA звучит как "если сервис доступен больше чем 99.9% за 10 дней то перестаньте давать нам деньги", значит SLO тоже звучит "сервис доступен больше чем 99.9% за 10 дней", значит availability это SLI метрика?
если наш SLA звучит как "если сервис доступен больше чем 99.9% за 10 дней то перестаньте давать нам деньги", значит SLO тоже звучит "сервис доступен больше чем 99.9% за 10 дней", значит availability это SLI метрика?
Важно теперь определить как именно вы ее мереете
AS
Надо определить слово доступен.