Gena Makhomed Wrote:
-------------------------------------------------------
> On 13.02.2024 4:21, Gena Makhomed wrote:
>
> > Когда свободного места на диске нет - то nginx туда, естественно,
> > ничего и не пишет, когда свободное место появляется - процесс
> записи
> > логов автоматически продолжается, тут ничего настраивать не нужно.
> >
> > Единственная проблема которая есть в такой сиутации - перестают
> работать
> > POST-запросы, если в каталоге client_body_temp_path ноль байт
> свободного
> > места, но все остальные типы запросов в такой ситуации nginx
> продолжает
> > нормально обрабатывать. И теряется возможность записи информации в
> логи.
> >
> > Все остальное - вроде бы работает нормально, когда 0 байт
> > свободного места на диске - но я очень детально это не проверял.
>
> Не знаю, насколько часто встречается такая проблема в дикой природе,
> но если возникает ошибка записи во время записи client_body в файл
> в client_body_temp_path - теоретически - можно было бы прочитать,
> то что успели уже записать в файл, отправить на backend
> и на какое-то время - переключить режим работы директив
>
> fastcgi_request_buffering
> proxy_request_buffering
> scgi_request_buffering
> uwsgi_request_buffering
>
> временно из текущего режима работы (on?) в режим работы off,
> например,
> на 1 минуту, и если через 1 минуту на разделе куда указывает
> директива
> client_body_temp_path появится достаточное количество свободного
> места,
> например, N * client_max_body_size при каком-то разумном значении N
> -
> тогда вернуть обратное старое значение, какое было для этих директив
> до момента переключения в такой режим работы.
>
> Кстати, что интересно, для модуля grpc в коде установлено
>
> r->request_body_no_buffering = 1;
>
> поэтому проксирование grpc запросов всегда будет нормально работать,
> даже в том случае, когда на диске будет 0 байт свободного места.
>
> Или - не имеет смысл настолько усложнять код nginx? Потому что
> в таком случае - если не настроен мониторинг свободного места
> на сервере - тогда системный администратор узнает об этой проблеме
> по жалобам, что POST запросы на сайте перестали нормально работать
> и на backend приходит 0 байт вместо того, что отправлял клиент.
>
> А если сделать так, чтобы nginx не терял тело запроса и корректно
> отправлял бы запросы на backend - то в такой ситуации системный
> администратор может еще очень долго ничего не знать о проблеме?
>
> Вот какое решение в этой ситуации было бы лучшим вариантом
> для пользователей коммерческой версии nginx-plus и для пользователей
> бесплатной версии nginx? Ведь если nginx теряет тело запроса - тогда
> могут сказать, что причина проблемы - это именно nginx, почему
> сайтом были утеряны ценные данные в POST-запросах клиентов.
>
> А если nginx сможет нормально функционировать и POST-запросы смогут
> нормально функционировать, не смотря на то. что на диске 0 байт
> свободного места - это может быть расценено как признак высокой
> надежности nginx и как признак высокого уровня качества кода.
>
> Как будет лучше поступить в ситуации нехватки свободного места на
> диске?
>

1. Можно всю буферизацию держать в RAM на tmpfs -- таких данных не должно быть много, и отзывчивость системы вырастет, и бесполезной нагрузки на диски будет меньше, да и фообще отдача не будет зависеть от нагрузки на дисковую подсистему.
2. Можно персонально под логи отдельный раздел..
Не хотите раздел выделять или переразбивать диск - создать файл-образ диска ограниченного размера, подмонтировать и писать в этот виртуальный диск.
Не хотите виртуальный диск в файле -- посмотрите в сторону квот файловой системы.

Можно вообще поставить что-то вроде rabbitMQ, там очередь на 100тыс (1млн?) сообщений с вытеснением.
При нештатных ситуациях начинаем по сети выгребать очередь и имеем историю "вглубь" до начала выгребания в (сколько поставили) сообщений+текущую ситуацию "что там у нас нынче?"
При штатных из последних сколько-то там всегда доступна...

Четко сформулируйте ЧТО вы хотите видеть в итоге, оцените имеющиеся ресурсы. Ищите пути решения/обхода/развития....


> --
> Best regards,
> Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru