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