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

Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск
не до тех пор, пока там останется 0 байт свободного места, а хотя
бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp
но наверное это отрицательно скажется на его производительности,
и поэтому такая возможность никогда не будет реализована в 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