Comments 5
вопросики
1) как понимаю у вас идет запрос к ~api/addnewnotif, они записываются в базу, потом сервис раз в Nt сканирует базу, берет новые и отправляет?
1.1) если это так как вы решается горизонтальное масштабирования этого сервиса?
2) есть ли группировка? какую логику используете?
По первому пункту. Не совсем так. Под Notifier, на самом деле, находится redis stream (изначально был Consul KV, что не подходит под такие задачи). Факт нотификации записывается в него. Сам же Notifier просто отслеживает стрим, раз в Nsec `XRANGE stream prevID +` полученные обновления сопоставляет с подписками, которые пришли на ws и совпадения выкидывает в нужное соединение. Что касается горизонтального масштабирования, могу сказать, что в рамках одного продукта не так много событий, поэтому один redis + notifier прекрасно справляются. Но простор для маневров есть. Redis можно кластеризовать, а Notifier, как его клиент, можно размножить в любом количестве. Останется только решить вопрос распределения клиентов между копиями Notifier.
По второму вопросу не совсем понял, о чем идет речь.
По второму вопросу не совсем понял, о чем идет речь.
второй вопрос про "антиспам", если есть 100 нотификаций в минуту, вы пошлете 100 писем на email?
В общем случае этот вопрос решили на уровне сервиса конфигурации параметром «частота сообщений». Устанавливается для каждой конкретной настройки уведомлений и есть дефолтное значение для всех.
Если говорить о конкретной реализации в VMmanager (уведомлять о пороговых значениях виртуальных машин и нод) в настройках есть следующие поля:
— значение ресурса (о превышении которого нужно сообщать)
— интервал (время в течении которого держится превышение)
— частота сообщений
Т.е. при CPU 80% peak 120s frequency 300s При условии что CPU зашкаливает постоянно первое письмо мы получим через 2мин и затем каждые 5мин.
Соблюдение этой логики сейчас целиком возложено на конечный алерт. И если администратор при настройке уведомлений выставит все ограничения на минимум уведомления будут сыпаться с максимальной скоростью, при условии что они постоянно генерируются. Все упрется в очередь сервиса отправки сообщений. Возможно стоит предусмотреть дополнительный фильтр и группировку, например во враппере, группировать, отправлять пачками. Спасибо за мысль.
Если говорить о конкретной реализации в VMmanager (уведомлять о пороговых значениях виртуальных машин и нод) в настройках есть следующие поля:
— значение ресурса (о превышении которого нужно сообщать)
— интервал (время в течении которого держится превышение)
— частота сообщений
Т.е. при CPU 80% peak 120s frequency 300s При условии что CPU зашкаливает постоянно первое письмо мы получим через 2мин и затем каждые 5мин.
Соблюдение этой логики сейчас целиком возложено на конечный алерт. И если администратор при настройке уведомлений выставит все ограничения на минимум уведомления будут сыпаться с максимальной скоростью, при условии что они постоянно генерируются. Все упрется в очередь сервиса отправки сообщений. Возможно стоит предусмотреть дополнительный фильтр и группировку, например во враппере, группировать, отправлять пачками. Спасибо за мысль.
UFO just landed and posted this here
Sign up to leave a comment.
Как мы написали сервис уведомлений