<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 5 февр. 2024 г. в 20:57, 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 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote:<br>
>> какую именно проблему Вы пытаетесь решить с помощью записи логов<br>
>> в unix socket, чтения данных из unix socket`а питоновским скриптом<br>
>> и потом записи данных этим питоновским скриптом в текстовой файл?<br>
<br>
> Если вы предлагаете писать напрямую с nginx-а в файл -- сделайте у себя ротацию файлов с интервалом 30 сек при 200-250 тыс подключений/сек...<br>
> Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать.<br>
<br>
Создание нормального рабочего решения должно начинаться<br>
с внимательного чтения документации и исходников nginx.<br>
<br>
Какую именно существующую проблему Вы пытаетесь решить<br>
с помощью ротации лог-файлов с интервалом в 30 секунд?<br>
<br>
> А на текущем отрезке времени:<br>
> Спасибо, я уже все решил :)<br>
<br>
Нет. Вы просто создали себе еще большую проблему на ровном месте.<br>
<br>
Потому что если программа, которая читает данные из unix socket`а<br>
отвалится - тогда произойдет переполенение буфера и nginx тогда<br>
заблокируется на операции записи в unix socket, и как следствие<br>
этого - перестанет выполнять свою основную функцию - перестанет<br>
отвечать на запросы клиентов по http / https протоколу.<br>
<br>
То есть, то что Вы сделали - это достаточно хрупкое<br>
и ненадежное "решение", особенно в условиях высоких нагрузок.<br>
<br>
Не всегда нужно все подряд писать в лог, например,<br>
можно ограничиться записью в лог только ответов с 4хх и 5хх статусами,<br>
в таком случае - не будет той проблемы, которую Вы пытаетесь<br>
решить таким способом с помощью unix-socket`а и python.<br>
<br>
Так же не понятно, в чем для Вас проблема переименовать<br>
log-файл и отправить сигнал USR1 мастер-процессу nginx,<br>
для того, чтобы он переоткрыл log-файл и продолжил запись.<br>
<br>
Особенно, если учесть, что директива <a href="https://nginx.org/r/access_log" rel="noreferrer" target="_blank">https://nginx.org/r/access_log</a><br>
имеет дополнительные параметры [buffer=size] [flush=time] [if=condition]<br>
<br>
Вместо этого - какие-то жуткие костыли - то syslog, то unix socket и <br>
питоновские скрипты, читающие данные из этого unix-socket`а пишущие<br>
текстовые файлы, то еще что-то.<br>
<br>
Вы так и не ответили на мой вопрос, какую именно проблему<br>
Вы пытаетесь решить таким вот нетривиальным способом?<br></blockquote><div><br></div><div>проблему трудоустройства )) ?</div><div><br></div><div><br></div><div>положа руку на сердце, с ротацией логов есть несколько, честно скажем, решений, с которыми выглядит как компромисс</div><div><br></div><div>1) переменные (позволяющие создавать новый лог, скажем по map-у раз в 30 сек). вроде норм, но буферизации в этом случае не будет. но на nvme возможно норм</div><div>2) copytruncate режим</div><div>3) описанный режим с USR1</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>
<a href="https://habr.com/ru/companies/dododev/articles/467047/" rel="noreferrer" target="_blank">https://habr.com/ru/companies/dododev/articles/467047/</a><br>
Феномен XY: как избежать «неправильных» проблем<br>
<br>
-- <br>
Best regards,<br>
  Gena<br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
</blockquote></div></div>