? у меня каждый час настроен слак хук посылать алерты

Неправильно понял проблему твою.

Я не знаю про алерт манагер, но в том числе встречал что то что тебе нужно зовется гистерезисом, а конкретно разные уровни алертинга и превращения в ок

Так это тебе надо инхеританс алертов сделать, а не тупой сайленс

Т.е. если в алертах совпадают такие-то поля, то считать их зависящими друг от друга и слать только тот что важнее

Там даже в примерах такое было

сейчас поищу

спасибо

кстати, а можно в прометее делать проверки типа if (up == 1) and (service == down) ALERT ...

А group by?

логическое and делается через and on

https://www.robustperception.io/combining-alert-conditions/

вот вам статья про это

круто, спс

and on () hour() > 9 < 17 # From 9am to 5pm UTC.

вот кстати кусок для предыдущего гражданина

А group by не поможет?

#RIPE #link ишь чего бывает https://www.ripe.net/participate/ripe/wg/mat

господа, а вот как правильнее всего задетектить ребут узла если он очень быстро ребутнулся, мне нужен алерт в alertmanager. навскидку мне подумалось что нужно смотреть на метрику node_boot_time. верно ж?

ну и алертить правилом, что если < 30 минут назад, например, произошел ребут.

может есть более красивые/правильные решения?

По-моему, вполне нормальное решение.

если есть аптайм можно просто смотреть что следующее значение меньше предыдущего.

если есть аптайм можно просто смотреть что следующее значение меньше предыдущего.

Тогда сработает один раз только

теперь вот думаю, то ли если node_boot_time changed, то ли если node_boot_time < 30 min ago.

без математики наверное более правильно будет, но как тогда авторезолв сделать.

есть node_boot_time и оно в unix time, в общем. а на хостах сидят prometheus node_exporter'ы.

коллеги по прометею, кто как мониторит SMART?

коллеги по прометею, кто как мониторит SMART?

мне кажется с момента как депрекейтнули megacli, остаётся только скриптами класть text_file метрики.

В линуксе есть boot uuid

Надо мониторить его изменение

Так как это единственный абсолютно достоверный источник информации

/proc/sys/kernel/random/boot_id

Изменение его гарантирует что это был ребут

А ещё к нему можно привязывать данные

Чтобы мерять что то и знать что был ребут

хмммммммммммммм

Я не знаю кто это коллектит правда

так вот в том то и дело, что никто )

Но надо именно так

а чем uptime не надёжен?

только text_file писать туда

а вот если у бубунды live patch накатится, интересно, он сменится или нет. пошел узнаю )

Я не знаю кто это коллектит правда

секуристы такое очень любят

а чем uptime не надёжен?

С ним всё в порядке, для этой задачи он кажется разумнее

господа, а вот как правильнее всего задетектить ребут узла если он очень быстро ребутнулся, мне нужен алерт в alertmanager. навскидку мне подумалось что нужно смотреть на метрику node_boot_time. верно ж?

process_start_time_seconds

Это аптайм процесса, а не ос

http://docs.grafana.org/guides/whats-new-in-v4-3/

Release Highlights: New Heatmap Panel

ого, это та самая панель :)

ERROR: S client not available

Это аптайм процесса, а не ос

да, это аптайм node_exporter # HELP process_start_time_seconds Start time of the process since unix epoch in seconds. # TYPE process_start_time_seconds gauge process_start_time_seconds 1.49558882545e+09

Это аптайм процесса, а не ос

задача же задетектить ребут а не получить аптайм. эту метрику можно использовать.

задача же задетектить ребут а не получить аптайм. эту метрику можно использовать.

ложное срабатывание будет когда я обновлю конфигурацию node_exporter. в этом случае node_boot_time решит проблему и так. пока ищу откуда он берет этот boot_time.

ложное срабатывание будет когда я обновлю конфигурацию node_exporter. в этом случае node_boot_time решит проблему и так. пока ищу откуда он берет этот boot_time.

node_boot_time он берет из /proc/stat

btime

ага, https://github.com/prometheus/node_exporter/blob/61f36ac1ab87c40f7ce42de00908d7101c223217/vendor/github.com/prometheus/procfs/stat.go#L38

что скажете?

В рамках рубрики Как интересно убить время и послушать умных людей, вами от нас этот плейлист докладов с прошедшей UPTIMEDAY. Рассказывали про системы мониторинга в непростых и больших проектах. https://goo.gl/J46Uiz

смотрел кто?

Женя клёвый

именно этот доклад не видел, но он клёвый

Там второй доклад после Жени очень странный

"Как надо хранить данные" — MySQL ?

Судя по чуваку в кепаре писали они его не в тех местах)

"Как надо хранить данные" — MySQL ?

вот я тоже ахуел чот

Женя клёвый

кто по мальчикам тут?

Женя клёвый

Это чуваки с графиками, где тыши алертов? А ещё они кастомят телеграм, но не делятся?

ага

позовите кто нить его сюда ? @eapotapov вроде он :)

Они наверняка ещё и по колено в битрексе давным давно, ничего клёвого

будто бы факт использования ими технологии "а" вместо "б" делает их хорошими или плохими, если это конечно не заббикс.

Тут спор возник. Кто как тестирует правила срабатывания алертов (заббикс, пром, что-то своё - не важно)?

смотрел кто?

и даже лично видел ) отличный Парень

Тут спор возник. Кто как тестирует правила срабатывания алертов (заббикс, пром, что-то своё - не важно)?

В прометее можно просто запрос посылать, язык-то ровно тот же