negasus 17 сен 2020 в 17:29

Легкая работа со сложными алертами. Или история создания Balerter

4 мин

11K

Информационная безопасность*Open source*Go*DevOps*

+19

Комментарии 21

rzerda 17 сен 2020 в 17:57

Если у вас уже есть Prometheus, отчего не привести всю эту информацию в него и не написать правила для уведомления там? Бонусом получаются HA (на alertmanager), группировка для уведомлений, возможность потом спросить у Prometheus «что видел мониторинг в момент срабатывания правила». Для PostgreSQL точно есть экспортер, позволяющий произвольные запросы, для остальных баз он либо есть, либо тривиально пишется. И в эти экспортеры у вас уезжает только определение метрик, а смысл уведомления видно не в коде, который надо глазами разбирать сквозь boilerplate-код соединения с источниками данных, а в одном выражении с человекопонятными именами метрик (которые всё равно придумывать). Приёмники уведомлений ваяются так же через webhook какие угодно.

negasus 17 сен 2020 в 18:01

И когда вам надо написать алерт на какую-то бизнес-логику, причем на основе данных из более чем одного сервиса — тут и наступает описанный случай.

rzerda 17 сен 2020 в 18:12

Я Вашу статью прочитал, а Вы мой комментарий — нет, это досадно. Бизнес-логика может быть хоть какой, и данные из этого множества баз это всё равно метрики, имеющие по отдельности свой смысл, который можно назвать прямо в имени метрики. Исключение составляют только вопросы типа «возьмём оттуда топ100 строк и отсюда топ100 строк и сравним как списки», но мне хотелось бы видеть пример осмысленного алерта с такой механикой. Подсчёт rps за период на сложность, по моему мнению, не тянет.

negasus 17 сен 2020 в 18:23

Прошу прощения, если ответил не на тот вопрос. Постараюсь привести пример: идем в кликхаус, берем данные за текущую минуту, берем данные за последний час, сравниваем дельту. Идем в постгрес, смотрим — какая дельта для какого клиента максимальная. Если превысили — алертим. Примерно так.

Sleuthhound 17 сен 2020 в 21:25

И что же тут сложного запихать эту дельту с помощью zabbix_sender в zabbix, а далее настроить там 50 оттенков любых алертов? На вскидку скрипт на bash в 10-15 строк + Несколько кликов мышкой в zabbix и все готово.

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

negasus 18 сен 2020 в 09:49

bash скрипт, котором мы сходили куда надо, взяли любые данные и как-то их сверили — справится с любой задачей, как мне кажется. Тут трудно спорить. И, конечно, я не гуру в, например, zabbix. Инструмент писался из наших потребностей — уметь в одном скрипте за один раз анализировать данные из разных источников, типа логов из Loki, метрик из Prometheus и данных из Postgres. И если zabbix это умеет и довольно легко сделать — чтож, это значит, что я этого не знал. Мне кажется, ничего страшного в этом нет. Ну или мы «не осилили», можно и так сказать, почему бы и нет)

strangeman 18 сен 2020 в 10:37

Для этого пишется простой экспортер на %language_name%. Выше справедливо заметили, что смешивать сбор данных и алертинг на основе этих данных не очень удобно в сопровождении.

negasus 18 сен 2020 в 11:17

А что имеется ввиду под смешиванием сбора данных и алертинга? Я не очень уловил. Особенно если мы говорим в рамках задачи, где решение об алерте принимается на основе данных из более чем одного источника. Как вы видите такую систему? Мне правда интересно

strangeman 18 сен 2020 в 11:32

Так, как это сделано в прометеусе — данные преобразуются в метрики (с помощью экспортеров), которые хранятся отдельно, и потом на основе них строятся алерты.

А как вы при сборе «на лету» будете смотреть исторические данные, особенно если источники данных эволюционировали со временем? Допустим, вы мониторите конверсию на основе данных из постгри, которые хранятся в табличке conversion_rate. Собирали эти данные 6 месяцев, а потом разработка решила переделать все на кликхаус и новые данные теперь хранятся в клике.
И теперь, чтобы построить какой-то сложный алерт (например, «сравни текущую конверсию с конверсией годом ранее и скажи если все плохо») вам придется городить какую-то адовую логику с кучей условий «если дата меньше такой-то — смотри в постгрю, иначе смотри в кликхаус» вместо того, чтобы работать с одной метрикой.

negasus 18 сен 2020 в 12:03

А, теперь я понял о чем речь. Да, конечно это все имеет смысл.

negasus 18 сен 2020 в 12:04

Мне все равно кажется, что не всегда так просто это сделать. Например, метрика (текущий RPS относительно исторического в N часов) — кто и где ее считать должен? А если для алерта мне еще надо взять данных из другого источника — допустимые лимиты какие-то?

dnbstd 17 сен 2020 в 19:18

Господи, ну почему на Lua? Я ничего не имею против Lua. Но как по мне порог вхождения в bash ниже, чем в Lua.

negasus 17 сен 2020 в 19:25

Легко встроить. Язык привычен для использования в качестве встраиваемого (ну, например, Tarantool). И, убежден, он в среднем сильно легче для изучения, чем баш) Хотя, разумеется, это индивидуально. Хотя, он, конечно, не без странных и, порой, раздражающих моментов

dnbstd 17 сен 2020 в 19:30

Просто в обиходе общения с ОС Linux чаще работаешь с Bash, нежели со специфичным Lua. Я вот к чему. Ну в этом и есть Open Source, а не заказная разработка. Каждый пишет как удобно ему и отдает на рассмотрение сообщества.

Neikist 17 сен 2020 в 21:51

Справедливости ради — я баш скрипты не писал ни разу в жизни, так вот сложилось, только отдельные команды использовал, а вот на lua бывало пробовал себе awesome wm настроить (да и на днях очередную попытку сделал). Но я и не бекенд разработчик и не девопс, потому не релевантен в данном случае))

subvillion 18 сен 2020 в 07:30

Если метрику сложно собрать имеющимися инструментами, а также дополнительно нужно обработать какой-то логикой — пишется свой Prometheus exporter который отдаст заветное 42. В подавляющем большинстве он примитивен. Аналогично решается задача кастомной метрикой в zabbix. IMHO прекрасный образовательный проект получился, практические применение выглядит не убедительно

negasus 18 сен 2020 в 09:45

Практически всегда какую-то задачу можно решить несколькими вариантами. Вариант, что вы описали, вполне возможно рабочий для примера, что я привел выше. Я, к сожалению (к счастью?) не очень близко знаком со всеми возможностями zabbix. И он, возможно, сумеет вытащить мне нужные данные из баз данных и других источников.
Мне сейчас кажется, что проще выглядит путь — написать один скрипт (затем другой скрипт, затем править) для сконфигурированного Balerter, чем писать и вносить правки в prometheus exporter, затем надо обязательно иметь zabbix и править там. Я допускаю, что ошибаюсь, но пока мне кажется так.

subvillion 18 сен 2020 в 15:45

Часто даже писать не нужно, "изучи инструмент с которым работаешь", есть убер комбайн telegraf, который превращает что угодно в метрики, позволяя дополнительно манипулировать данными. Корреляции, гистерезис, аномалии — все мимо без хранилища. Это не вопрос религии, это вопрос проектирования, архитектуры и ресурсов

estet 18 сен 2020 в 15:19

очень похоже на errbot

Tertium 21 фев в 12:46

Умер видимо проект - последняя активность 2г назад на гите

negasus 27 мар в 15:55

На самом деле, лично меня он сейчас устраивает и выполняет свою работу.
Были планы добавить поддержку JS в дополнение к Lua, но не очень понятно, нужно ли это.
Добавление поддержки других источников данных большого труда не составит, но нет запроса.
Вот как-то так)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

Легкая работа со сложными алертами. Или история создания Balerter

Комментарии 21

Публикации

Истории