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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть на-все-руки-мастер Alerta.

Ещё есть относительно новый balerter

А можно упороться и сделать всё на Riemann.

Спасибо! Будем посмотреть.

P. S.: что за рогалик у тебя на аватарке?

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

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

Попадалось конференция с темой «Перестаньте использовать crond». Рекомендуют смотреть в сторону Rundeck

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

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

auditd?