История изменений
Исправление intelfx, (текущая версия) :
Это очень странный подход к мониторингу. Ну точнее это вообще не мониторинг. Обычно в таких случаях не алерты надо делать, а счетчики и метрики.
Это и не мониторинг в узком смысле. Счётчики и метрики у меня уже успешно есть и работают. Число 1000 было взято для примера; если вдруг там реально будет 1000 срабатываний какой-то задачи в секунду — алерт про это мне тоже придёт.
Но если у тебя вообще каждой задаче свой отдельный маршрут и больше ничего, то непонятно зачем это всё, скорее нужен один скрипт-обертка.
Необязательно. Например, там может быть ratelimiting. Например, там может быть метамониторинг (>10 срабатываний рейтлимита == алерт). Например, там может быть условный роутинг (ошибки на телефон, остальное на почту). Наконец, я бы хотел разделить механизм и политику: отдельно ingress (эмиттеры событий), отдельно правила (конфиг), отдельно egress (интеграции).
Вот и вырисовывается объём работы, который в принципе не хочется велосипедить.
В чем у тебя конкретно проблема с mailx?
В том, что это хардкод и негибко.
Исправление intelfx, :
Это очень странный подход к мониторингу. Ну точнее это вообще не мониторинг. Обычно в таких случаях не алерты надо делать, а счетчики и метрики.
Это и не мониторинг в узком смысле. Счётчики и метрики у меня уже успешно есть и работают. Число 1000 было взято для примера; если вдруг там реально будет 1000 срабатываний какой-то задачи в секунду — алерт про это мне тоже придёт.
Но если у тебя вообще каждой задаче свой отдельный маршрут и больше ничего, то непонятно зачем это всё, скорее нужен один скрипт-обертка.
Необязательно. Например, там может быть ratelimiting. Например, там может быть метамониторинг (>10 срабатываний рейтлимита == алерт). Например, там может быть условный роутинг. Наконец, я бы хотел разделить механизм и политику: отдельно ingress (эмиттеры событий), отдельно правила (конфиг), отдельно egress (интеграции).
Вот и вырисовывается объём работы, который в принципе не хочется велосипедить.
В чем у тебя конкретно проблема с mailx?
В том, что это хардкод и негибко.
Исходная версия intelfx, :
Это очень странный подход к мониторингу. Ну точнее это вообще не мониторинг. Обычно в таких случаях не алерты надо делать, а счетчики и метрики.
Это и не мониторинг в узком смысле. Счётчики и метрики у меня уже успешно есть и работают. Число 1000 было взято для примера; если вдруг там реально будет 1000 срабатываний какой-то задачи в секунду — алерт про это мне тоже придёт.
Но если у тебя вообще каждой задаче свой отдельный маршрут и больше ничего, то непонятно зачем это всё, скорее нужен один скрипт-обертка.
Необязательно. Например, там может быть ratelimiting. Например, там может быть метамониторинг (>10 срабатываний рейтлимита == алерт). Например, там может быть условный роутинг. Наконец, я бы хотел разделить механизм и политику: отдельно ingress (эмиттеры событий), отдельно правила (конфиг), отдельно egress (интеграции).
Вот и вырисовывается объём работы, который в принципе не хочется велосипедить.