LINUX.ORG.RU
ФорумAdmin

Мониторинг событий («роутер событий» по типу Alertmanager)

 , , ,


0

1

Приветствую.

Продолжаем цикл тупых вопросов по гетто-мониторингу подкроватного сервера.

С мониторингом как таковым всё в принципе понятно. Вот есть, допустим, стек Prometheus/Alertmanager. Он понятно как работает: Prometheus агрегирует метрики, прогоняет их через правила, генерирует level-triggered алерты и пушит их в Alertmanager. При этом Alertmanager, по существу, делает ровно две вещи: конвертирует level-triggered алерты в edge-triggered события и роутит их.

Мне нужна похожая тулза, только для произвольных событий. У меня есть много периодических (и апериодических) задач, каждую из которых я отдельно заворачиваю в | mailx, но так жить нельзя. Я бы хотел уметь как-то обобщённо рассылать себе уведомления об их окончании, причём необязательно на почту.

Первым делом я попробовал присобачить тот же Alertmanager, потому что у него есть огромное количество интеграций во всё что можно. Но он принципиально не подходит под эту задачу. Он by design ожидает, что ему на вход поступают level-triggered алерты, а он их дедуплицирует и делает edge detection. А в моём случае входы уже edge-triggered, и на каждый вход нужно отправить ровно один выход, не больше и не меньше.

Есть ли в мире какой-нибудь «роутер событий», похожий на Alertmanager, но без этой семантики edge detection?

★★★★★

и на каждый вход нужно отправить ровно один выход, не больше и не меньше

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

А в моём случае входы уже edge-triggered

Так может тебе alertmanager надо не в этом месте прикрутить, а на шаг раньше и перенести в него логику разруливания событий?

alpha ★★★★★
()
Ответ на: комментарий от alpha

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

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

Alertmanager же ожидает, что каждый алерт, поступающий ему на вход, будет поступать в течение условно 30 секунд. И только после того, как ты несколько раз позовёшь его эндпоинт, передавая туда этот алерт, он соизволит его заметить и отправить. А потом нужно ещё один раз позвать эндпоинт и задеассертить алерт. Пока ты этого не сделаешь (или не истечёт таймаут) — этот алерт будет висеть в статусе и периодически рассылаться.

А мне нужно строго обратное. Если алерт пришёл один раз в сутки — нужно один раз в сутки отправить уведомление. И напротив, если пришла тысяча однотипных (или вовсе одинаковых) алертов в секунду — нужно отправить тысячу уведомлений.

Я могу написать демона-прослойку, который будет добавлять к каждому событию уникальный дискриминатор, а потом ассертить каждое событие ровно на протяжении таймаута срабатывания Alertmanager, но «эта сова начинает рваться ещё в самом начале процесса» (ц)

Так может тебе alertmanager надо не в этом месте прикрутить, а на шаг раньше и перенести в него логику разруливания событий?

На какой на шаг раньше? Вместо cron’а? :)

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

И напротив, если пришла тысяча однотипных (или вовсе одинаковых) алертов в секунду — нужно отправить тысячу уведомлений.

Это очень странный подход к мониторингу. Ну точнее это вообще не мониторинг. Обычно в таких случаях не алерты надо делать, а счетчики и метрики.

Судя по описанию твоя задача похожа скорее на шлюз, то есть тебе нужно искать relay, gateway и что-то подобное с учетом сервисов на которых ты хочешь пересылать уведомления. Решений такого типа много, если определиться с набором сервисов с которыми нужна интеграция. Но если у тебя вообще каждой задаче свой отдельный маршрут и больше ничего, то непонятно зачем это всё, скорее нужен один скрипт-обертка.

В чем у тебя конкретно проблема с mailx?

alpha ★★★★★
()
Ответ на: комментарий от alpha

Это очень странный подход к мониторингу. Ну точнее это вообще не мониторинг. Обычно в таких случаях не алерты надо делать, а счетчики и метрики.

Это и не мониторинг в узком смысле. Счётчики и метрики у меня уже успешно есть и работают. Число 1000 было взято для примера; если вдруг там реально будет 1000 срабатываний какой-то задачи в секунду — алерт про это мне тоже придёт.

Но если у тебя вообще каждой задаче свой отдельный маршрут и больше ничего, то непонятно зачем это всё, скорее нужен один скрипт-обертка.

Необязательно. Например, там может быть ratelimiting. Например, там может быть метамониторинг (>10 срабатываний рейтлимита == алерт). Например, там может быть условный роутинг (ошибки на телефон, остальное на почту). Наконец, я бы хотел разделить механизм и политику: отдельно ingress (эмиттеры событий), отдельно правила (конфиг), отдельно egress (интеграции).

Вот и вырисовывается объём работы, который в принципе не хочется велосипедить.

В чем у тебя конкретно проблема с mailx?

В том, что это хардкод и негибко.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Например, там может быть ratelimiting. Например, там может быть метамониторинг (>10 срабатываний рейтлимита == алерт).

Ну, это метрика, метрику ест prometheus, alert по ней роутит alertmanager.

Всё как обычно.

Ты зачем-то смешал всё в одну кучу. запихал кучу логики на стороне сбора данных вместо того чтобы переложить её на инструменты анализа.

Твой cron - это exporter для prometheus. У тебя есть сервис, у сервиса есть метрика и есть алерты по ней. Плюс есть отдельные прямые алерты через API alertmanager.

Но проблема в том что ты вместо того чтобы отрефакторить свою структуру и вписать её в нормальный workflow, ищешь инструмент который будет соответствовать твой кастомной структуре.

Я понимаю - это рефлекс разработчика, типа не тобой рулят а ты рулишь. Ты придумал дизайн, и хочешь его реализовать. Но в инфровых задач немножко поскромнее надо себя вести и подстраиваться под инструменты, в соответствии с их логикой, а не вопреки. Это сильно упрощает жизнь. :)

alpha ★★★★★
()
Ответ на: комментарий от alpha

Ну, это метрика, метрику ест prometheus, alert по ней роутит alertmanager.

Естественно. Это метрика. Которую нужно экспортировать из роутера событий. Это увеличивает его сложность и уменьшает моё желание его велосипедить.

Ты зачем-то смешал всё в одну кучу. запихал кучу логики на стороне сбора данных вместо того чтобы переложить её на инструменты анализа.

Нет, это ты не разобралась в вопросе, прежде чем говорить, что вопрошающий принципиально неправ.

Какая ещё логика на стороне сбора данных?

Твой cron - это exporter для prometheus. У тебя есть сервис, у сервиса есть метрика и есть алерты по ней. Плюс есть отдельные прямые алерты через API alertmanager.

Нет, я уже устал повторять: меня абсолютно не интересуют агрегатные метрики из этого cron’а. Меня интересует каждое срабатывание в отдельности. Эта задача ближе к logging, чем к monitoring.

Но проблема в том что ты вместо того чтобы отрефакторить свою структуру и вписать её в нормальный workflow, ищешь инструмент который будет соответствовать твой кастомной структуре.

Я понимаю - это рефлекс разработчика, типа не тобой рулят а ты рулишь. Ты придумал дизайн, и хочешь его реализовать. Но в инфровых задач немножко поскромнее надо себя вести и подстраиваться под инструменты, в соответствии с их логикой, а не вопреки. Это сильно упрощает жизнь. :)

Нет, это всё не так (вытекает из твоих некорректных предположений о моей задаче).

intelfx ★★★★★
() автор топика
Ответ на: комментарий от alpha

Давай я опишу задачу ещё раз и заменю абстракции конкретными примерами, чтобы попытаться устранить недопонимание.

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

Статистика по всем срабатываниям одной задачи (или вообще статистика по всем срабатываниям всех задач) меня не интересует от слова совсем: разных задач слишком много и там нечего обобщать. Ну то есть меня не интересует алерт вида «больше 10% дисков в датацентре выходят из строя», потому что у меня нет датацентра. Меня интересует лог и код возврата последнего запуска smartctl, в котором написано, что конкретный диск вот прямо сейчас выходит из строя.

Помимо cron’а есть и другие источники апериодических событий. В частности, у меня есть небольшой демон на питоне, который подключается к systemd и journald и читает события о старте/завершении юнитов. Опять же, меня не интересует статистика по этим событиям и алерты типа «за последний час более 10% экземпляров такого-то пода упали больше 10 раз» (реальный алерт из kube-prometheus). Если упало что-то одно и хотя бы один раз — это уже проблема, и я хочу увидеть подробности, код возврата и последние 100 строчек лога конкретно того, что упало.

У меня есть (точнее, ещё нет, но скоро будет) самопальный CI, который запускает задачи опять же как systemd-юниты. Я бы хотел получать логи выполнения CI-задач себе на почту, и мне совсем не улыбается костылить под это дело совершенно отдельный механизм доставки уведомлений.

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

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от intelfx

ADoM, скриншот примерно из 2003 года.

Добро пожаловать в церковь метрик в телеге с такими вопросами.

AnDoR ★★★★★
()
Последнее исправление: AnDoR (всего исправлений: 1)
Ответ на: комментарий от anonymous

Разумеется, это условный crond. Я использую systemd.timer, и вообще многие из этих задач запускаются не по таймерам, а по иным триггерам.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Эта задача ближе к logging, чем к monitoring.

auditd?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.