<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 12 июл. 2022 г. в 21:55, Gena Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12.07.2022 17:51, Maxim Dounin wrote:<br>
<br>
> Ограничения и ошибки доступа логгируются на уровне error, так как<br>
> считаются важными (и, вообще говоря, не являются ошибками в<br>
> клиентских запросах, а являются ошибками обработки клиентских<br>
> запросов).  Как в случае access forbidden by rule в allow/deny,<br>
> так и в случае user not found / password mismatch в auth_basic, а<br>
> равно "directory index ... forbidden", "open() ... failed (2:<br>
> No such file or directory)" и limit_conn/limit_req.<br>
> <br>
> Для гибкого изменения уровней логгирования (или вообще<br>
> логгирования) в сложных случаях - есть некоторое количество ручек,<br>
> позволяющих гибко управлять логгированием конкретных событий<br>
> (limit_conn_log_level, limit_req_log_level, log_not_found,<br>
> rewrite_log).  В общем случае - таких ручек нет, и события<br>
> попадают в лог на фиксированном уровне логгирования.<br>
<br>
>> Может быть имеет смысл сделать директиву deny_log_level<br>
<br>
> Добавить возможность настройки уровня логгирования ошибок deny -<br>
> возможно, но пока кажется, что это скорее не нужно.<br>
<br>
Директивы limit_conn_log_level и limit_req_log_level были<br>
добавлены в nginx с какой целью / мотивацией, если не секрет?<br>
<br>
Разве мотивация добавить директиву deny_log_level не такая же,<br>
как и была в случае с директивами limit_{conn,req}_log_level ?<br>
<br>
В чем проблема - логи nginx находятся в каталоге /var/log/nginx/<br>
http-client-body-temp-path в каталоге /var/cache/nginx/client_temp<br>
поэтому когда логи занимают все свободное место на разделе<br>
- перестает работать аплоад файлов и тогда пользователям<br>
возвращается 500 ошибка.<br>
<br>
Чтобы решить проблему - поменял rotate 52 на rotate 7<br>
в файле /etc/logrotate.d/nginx. Отключать access-логи не могу,<br>
менять log level для файла error.log с warn на crit не хочу,<br>
чтобы не пропустить какую-то действительно важную ошибку.<br>
<br>
Поэтому лично для меня - наличие директивы deny_log_level<br>
было бы полезно, потому что примерно 80% содержимого<br>
файла error.log - это "ошибки" access forbidden by rule<br></blockquote><div><br></div><div>я не пробовал, но кажется, можно выкрутиться через error_page, и настроив логи в локейшене в /dev/null</div><div>(неизящно, но может сработать)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
и еще примерно 20% - это "предупреждения" о том, что<br>
a client request body is buffered to a temporary file<br></blockquote><div><br></div><div>это же можно выключить через proxy_request_buffering ?</div><div>из побочных эффектов, если вдруг понадобилось ретраить запрос, то сохраненного тела запроса уже не будет, увы.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Еще - было бы очень хорошо, чтобы nginx умел писать логи на диск<br>
не до тех пор, пока там останется 0 байт свободного места, а хотя<br>
бы оставлял 1 гигабайт для файлов в /var/cache/nginx/client_temp<br></blockquote><div><br></div><div>буферизация на диск имеет кучу побочных эффектов.</div><div>можно через <a href="https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size">Модуль ngx_http_proxy_module (nginx.org)</a> выключить дисковую часть (оставив буферизацию в памяти)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
но наверное это отрицательно скажется на его производительности,<br>
и поэтому такая возможность никогда не будет реализована в nginx?<br>
<br>
Хотя, с другой стороны, nginx master может ведь мониторить свободное<br>
место на диске с интервалом, например, раз в 10 или 20 или 30 секунд,<br>
отключая запись в access.log, когда свободного места меньше 1 гигабайта<br>
и отключая запись в error.log на уровне меньше crit, когда свободного<br>
места на диске меньше, например, 512 мегабайт? (И включая обратно<br>
запись в логи в той же последовательности в случае появления<br>
свободного места на диске)<br>
<br>
Вы наверное скажете, что по нормальному надо было бы где-то установить<br>
и настроить какой-нибудь Zabbix и настроить в нем мониторинг свободного<br>
места на разделе /var/log/nginx/ и /var/cache/nginx/client_temp и потом<br>
вручную чистить логи, когда придет сообщение о том, что low free space?<br></blockquote><div><br></div><div>я бы скорее смотрел в сторону, что диск для реверс прокси не особо нужен. можно транзитом туда-сюда трафик гонять.</div><div>разве что для логов.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Best regards,<br>
  Gena<br>
_______________________________________________<br>
nginx-ru mailing list -- <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
To unsubscribe send an email to <a href="mailto:nginx-ru-leave@nginx.org" target="_blank">nginx-ru-leave@nginx.org</a><br>
</blockquote></div></div>