Рейтлимит на сколько я понимаю выставляется только на каждый инстант, в смысле на каждую входную точку по отдельности. Решил сливать логи доступа со всех nginx в одно место и там уже чем-то анализировать. Остаётся вопрос, а как мне сделать ratelimit, на основе сборных логов доступа? Я обычно ratelimit делал на самом nginx, а как мне в данном случае определить нарушителей по частоте запросов? Кто-то сталкивался с готовыми решениями под такую задачу?
я не настоящий сварщик, конечно но посмотреть в сторону решений поверх openresty/lua можно там точно видел лимитеры
ну так они опять же на конкретную установку nginx
из LUA периодически опрашиваешь ендопинт, что знает про лимиты и вычисляешь все что надо
это не похоже на готовое решение), я уж тогда буду писать это на чём-то побыстрее луа))
поищи готовое решние поверх lua. они есть. в том-же kong
например? если мы не говорим про кастомные расширения nginx (даже хз какой там порог входа) то что?
мы вообще не говорим про расширения nginx
Например: Делай лимит через auth_request с опросом какого мемкэша. Устанавливаешь туда маркер с протуханием по времени, устанавливаешь на основе агрегации логов - хоть прям самим сислогом. Например: пишешь на lua синхронизацию диктов между инстансами, и лимитируешь по дикту.
идея понятна, сейчас копну, но я вот думаю, а не замедлит ли мне это работу nginx.?)) Вариант с сторонним модулем который бы курил сборный лог со всех nginx абсолютно не грузит инстанты nginx, да и банить наглецов я всё равно буду не через nginx, а есть на это клоудфлер)
если nginx стоит больше чем на одной тачке - получаешь достаточно большую нагрузку на сеть (ибо регистрируешь каждый запрос) но в среднем кажется отличный вариант. но я бы состояние лимитеров в памяти держал
Это оно и есть. У тебя сторонний процесс считает статистику, и ставит галку - пускать/не пускать. А nginx только ходит в мемкэш и смотрит на наличие галки. +1 запрос к сессии.
а есть понимание какую нагрузку нужно держать?
Нет. 1. Сильно небольшую, + два десятка байт на запрос. 2. Эстеты могут хранить в локальном мемкэше. 3. Держать прямо в памяти nginx - можно, но проблематично синхронизировать.
так а зачем nginx вообще смотреть эту статистику, перед ним стоит клоудфлер, он будет решать пускать или не пускать
думаю что для лимитеров не стоит задачи строгой консистентности. евенчуальная вполне пойдет
а цифры?
Тогда рейт-лимить на cf, зачем вобще что-то городить?
логи с разных тачек еще сливать надо-)
Они и так сливаются. Кроме того, лить можно в минимизированном формате.
ну вот сейчас глянул лог за вчера, было 2619302 запросов к бекенду При этом вчера был далеко не топовый день, в топовый день можно умножить на 4 примерно. А архитектуру переделываем чтобы выдерживать ещё больше.
рейтлимит на клоудфлере, ты там платишь за пропущенные, безые запросы, каждые 10к запросов это 0,05 баксов, учитывая плотность запросов заказчик разорится на рейтлимите от клоудфлера)), да и оно прекрасно работало и у себя, ну пока не принято было решение делать несколько nginx))
тут как раз проблем нет вообще ниразу
ну если размазать на сутки то выходит что так, но ночью как бы опсещалка сам понимаешь такая себе)), а вечером подскакивает. + повторюсь это типа вчера такой себе день был, это может быть в 4 раза больше
даже 120 rps не выглядит очень большой нагрузкой
в среднем за сутки?))
Обсуждают сегодня