[error] access forbidden by rule

[Илья Шипицин]

вт, 12 июл. 2022 г. в 21:55, Gena Makhomed <gmm на csdoc.com>:

> On 12.07.2022 17:51, Maxim Dounin wrote:
>
> > Ограничения и ошибки доступа логгируются на уровне error, так как
> > считаются важными (и, вообще говоря, не являются ошибками в
> > клиентских запросах, а являются ошибками обработки клиентских
> > запросов).  Как в случае access forbidden by rule в allow/deny,
> > так и в случае user not found / password mismatch в auth_basic, а
> > равно "directory index ... forbidden", "open() ... failed (2:
> > No such file or directory)" и limit_conn/limit_req.
> >
> > Для гибкого изменения уровней логгирования (или вообще
> > логгирования) в сложных случаях - есть некоторое количество ручек,
> > позволяющих гибко управлять логгированием конкретных событий
> > (limit_conn_log_level, limit_req_log_level, log_not_found,
> > rewrite_log).  В общем случае - таких ручек нет, и события
> > попадают в лог на фиксированном уровне логгирования.
>
> >> Может быть имеет смысл сделать директиву deny_log_level
>
> > Добавить возможность настройки уровня логгирования ошибок deny -
> > возможно, но пока кажется, что это скорее не нужно.
>
> Директивы limit_conn_log_level и limit_req_log_level были
> добавлены в nginx с какой целью / мотивацией, если не секрет?
>
> Разве мотивация добавить директиву deny_log_level не такая же,
> как и была в случае с директивами limit_{conn,req}_log_level ?
>
> В чем проблема - логи nginx находятся в каталоге /var/log/nginx/
> http-client-body-temp-path в каталоге /var/cache/nginx/client_temp
> поэтому когда логи занимают все свободное место на разделе
> - перестает работать аплоад файлов и тогда пользователям
> возвращается 500 ошибка.
>
> Чтобы решить проблему - поменял rotate 52 на rotate 7
> в файле /etc/logrotate.d/nginx. Отключать access-логи не могу,
> менять log level для файла error.log с warn на crit не хочу,
> чтобы не пропустить какую-то действительно важную ошибку.
>
> Поэтому лично для меня - наличие директивы deny_log_level
> было бы полезно, потому что примерно 80% содержимого
> файла error.log - это "ошибки" access forbidden by rule
>

я не пробовал, но кажется, можно выкрутиться через error_page, и настроив
логи в локейшене в /dev/null
(неизящно, но может сработать)


> и еще примерно 20% - это "предупреждения" о том, что
> a client request body is buffered to a temporary file
>

это же можно выключить через proxy_request_buffering ?
из побочных эффектов, если вдруг понадобилось ретраить запрос, то
сохраненного тела запроса уже не будет, увы.


>
> Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск
> не до тех пор, пока там останется 0 байт свободного места, а хотя
> бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp
>

буферизация на диск имеет кучу побочных эффектов.
можно через Модуль ngx_http_proxy_module (nginx.org)
<https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size>
выключить
дисковую часть (оставив буферизацию в памяти)


> но наверное это отрицательно скажется на его производительности,
> и поэтому такая возможность никогда не будет реализована в nginx?
>
> Хотя, с другой стороны, nginx master может ведь мониторить свободное
> место на диске с интервалом, например, раз в 10 или 20 или 30 секунд,
> отключая запись в access.log, когда свободного места меньше 1 гигабайта
> и отключая запись в error.log на уровне меньше crit, когда свободного
> места на диске меньше, например, 512 мегабайт? (И включая обратно
> запись в логи в той же последовательности в случае появления
> свободного места на диске)
>
> Вы наверное скажете, что по нормальному надо было бы где-то установить
> и настроить какой-нибудь Zabbix и настроить в нем мониторинг свободного
> места на разделе /var/log/nginx/ и /var/cache/nginx/client_temp и потом
> вручную чистить логи, когда придет сообщение о том, что low free space?
>

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


>
> --
> Best regards,
>   Gena
> _______________________________________________
> nginx-ru mailing list -- nginx-ru на nginx.org
> To unsubscribe send an email to nginx-ru-leave на nginx.org
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20220712/df7e6ed3/attachment.htm>