<div dir="auto">А "XY" проблема в левацки ориентированном комьюнити может восприниматься, как хромосома и "токсичная маскулинность", простите((</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 11, 2024, 19:32 Gena Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09.02.2024 13:33, Anatoliy Melnik via nginx-ru wrote:<br>
<br>
> Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам.<br>
> Логи льются в syslog (слив в файлы напрямую из nginx не желателен).<br>
<br>
Несколько дней тому назад, в своем сообщении от 5 февраля 2024 года<br>
Вы озвучивали совсем другую причину, что у Вас не получается<br>
это сделать по каким-то техническим причинам, потому, что у Вас<br>
очень высокие нагрузки на систему - 200-250 тысяч подключений<br>
в секунду и поэтому вы не можете сделать запись логов напрямую<br>
в лог-файлы и ротацию этих лог-файлов раз в 30 секунд, и намекаете,<br>
что при таких высоких нагрузках вообще никто не сможет это сделать,<br>
предлагая мне самому попробовать настроить такую ротацию и убедиться<br>
в истинности Вашего утверждения, что это настроить вообще невозможно.<br>
<br>
И именно по той причине, что Вы не смогли настроить ротацию<br>
лог-файлов раз в 30 секунд и началось изобретение велосипедов<br>
и костылей с syslog`ами, unix-socket`ами и питоновскими скриптами.<br>
<br>
Это и есть типичная XY-проблема, о которой подробнее говорится<br>
в статье <a href="https://habr.com/ru/companies/dododev/articles/467047/" rel="noreferrer noreferrer" target="_blank">https://habr.com/ru/companies/dododev/articles/467047/</a><br>
<br>
А не смогли Вы настроить ротацию логов nginx раз в 30 секунд при<br>
трафике в 200-250 тысяч подключений по той причине, что ротацию<br>
логов Вы пытались делать с помощью SIGHUP, который вообще-то<br>
предназначен для изменения конфигурации, а не ротации логов.<br>
<a href="http://nginx.org/ru/docs/control.html#reconfiguration" rel="noreferrer noreferrer" target="_blank">http://nginx.org/ru/docs/control.html#reconfiguration</a><br>
<br>
Если же делать ротацию логов используя SIGUSR1 - то никакой проблемы<br>
не будет, потому что это очень дешевая и очень быстрая операция,<br>
вне зависимости от того, какое количество подключений присутствует,<br>
потому что при этом новые worker-процессы nginx не создаются и старые<br>
worker-процессы nginx свою работу не завершают, как в случае SIGHUP.<br>
<br>
И когда Вы мне написали: "Если у вас уже есть такое рабочее решение<br>
- поделитесь опытом, буду рад вас выслушать" - я же Вам и ответил,<br>
что поиск рабочего решения следует начинать не с настройки syslog<br>
и не с написания python`овских скриптов, а с внимательного чтения<br>
документации, потому что там же очень подробно написано, как можно<br>
настроить очень быструю ротацию логов при любом количестве подключений:<br>
<a href="http://nginx.org/ru/docs/control.html#logs" rel="noreferrer noreferrer" target="_blank">http://nginx.org/ru/docs/control.html#logs</a> - что же тут не понятно?<br>
<br>
Особенно, если учесть, что директива <a href="https://nginx.org/r/access_log" rel="noreferrer noreferrer" target="_blank">https://nginx.org/r/access_log</a><br>
имеет дополнительные параметры [buffer=size] [flush=time] [if=condition]<br>
которые помогают еще сильнее уменьшить затраты процесора и времени на <br>
запись логов в файлы, потому что информация в лог будет записываться<br>
не построчно, а блоками большего розмера, то есть вместо нескольких<br>
сотен или тысяч системных вызовов может быть всего один системный вызов.<br>
<br>
Более быстрого процесса ускорения записи логов nginx в природе<br>
просто не существует - другими способами точно не будет быстрее.<br>
<br>
> По косвенным методам контроля вылезла проблема:<br>
> До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения. nginx->syslog фиксирует меньше событий, чем сумма по бекэндам.<br>
> Чем выше интенсивность запросов, тем больше расходятся данные.<br>
> Сначала грешил на syslog, но детальные разборы полетов говорят, что скорее всего проблема в nginx.<br>
> У кого-то что-то такое наблюдалось или нет?<br>
> При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно 100тыс/сек, т.е. скорее всего syslog не виноват.<br>
> Кто-то с таким сталкивался?<br>
> <br>
> В рамках именно этого подхода проблему я решил подходом, указанным выше -- т.е. распараллелил логи на несколько потоков.<br>
> проблема потерь nginx->syslog у меня теперь решилась.<br>
> <br>
> Одна из задач (но не единственная) для чего это было нужно так же описана.<br>
> Если примененный мной подход для ВАШИХ задач не удобен или не приемлем или вызывает сомнения и т.д. -- не стоит навязывать своё мнение как единственно правильное.<br>
<br>
Вы пытаетесь решить проблему Y хотя Вам нужно решение проблемы X.<br>
<br>
проблема Y: ускорить запись из nginx в syslog, избежать потери сообщений<br>
<br>
проблема X: сделать ротацию логов раз в 30 секунд<br>
<br>
Как вляпаться в XY-проблему. Пошаговая инструкция пользователя<br>
<br>
1.    Пользователю нужно решить проблему Х.<br>
<br>
2.    Пользователь не знает, как решить проблему X, но думает, что <br>
сможет её решить, если ему удастся выполнить действие Y.<br>
<br>
3.    Пользователь также не знает, как выполнить действие Y.<br>
<br>
4.    Обращаясь за помощью, пользователь просит помочь ему разобраться с Y.<br>
<br>
4.    Все пытаются помочь пользователю с действием Y, несмотря на то, <br>
что Y кажется странной проблемой для решения.<br>
<br>
5.    Спустя много итераций и упущенного времени выясняется, что <br>
пользователь на самом деле хотел решить X-проблему.<br>
<br>
6.    Самое ужасное – выполнение действия Y не стало бы подходящим <br>
решением для X. Все рвут на себе волосы и со словами «я отдал тебе <br>
лучшие годы своей жизни» испепеляют друг друга взглядом.<br>
<br>
Зачастую XY-проблема возникает, когда люди зацикливаются на мелких <br>
деталях своей проблемы и на том, что они сами считают решением проблемы. <br>
В итоге они не могут отступить на шаг назад и объяснить проблему комплексно.<br>
<br>
> Именно такая схема не с потолка упала, а появилась в результате экспериментальных проверок нескольких подходов.<br>
> Рассказывать почему именно так, а не иначе -- долго, скучно, с кучей подробностей... и абсолютно бесполезно :)<br>
> Свое видение путей решения СВОИХ задач у меня уже сформировалось, а убеждать в чем-то вас смысла не имеет.<br>
> Еще раз СПАСИБО.<br>
<br>
Кто-то кого-то сейчас пытается обмануть.<br>
<br>
Вы рассказываете, что запись логов в файлы Вам не подходит<br>
по каким-то очень серьезным причинам, которые Вы не можете<br>
озвучить, потому что это Вам скучно, неинтересно и бесполезно.<br>
<br>
Но при этом лепите костыли из syslog, unix-socket`ов и питоновских <br>
скриптов, запуская их 10 копий для того, чтобы они могли получать<br>
информацию от nginx через unix socket и писать их в файлы.<br>
<br>
То есть, Вы утверждаете, что вариант, когда nginx напрямую пишет логи<br>
в файлы - Вам не подходит, потому что невозможно сделать ротацию логов<br>
раз в 30 секунд при 200-250 тысяч подключений, а вот вариант<br>
с этим жутким нагромождением костылей - это и есть решение проблемы.<br>
<br>
Какой проблемы? root cause of problem тут в том, что Вы не прочитали<br>
внимательно документацию к nginx и не смогли настроить ротацию логов<br>
через SIGUSR1 ? Что по факту есть очень быстрая и очень дешевая<br>
операция, значительно более легкая и быстрая, чем reload по SUGHUP.<br>
<br>
Проблема тут в чем? Проблема в том, что эти Ваши заявления о самом<br>
лучшем решении проблемы записи в лог-файлы с помощью нагромождения<br>
костылей - это фактически есть нехорошее действие, потому что таким<br>
способом вы распространяете FUD про nginx создавая в глазах неопытного<br>
читателя списка рассылки впечатление, что nginx - это очень кривая<br>
программа, которая даже свои логи в файлы не может нормально писать<br>
а вот Вы - решили эту проблему, с помощью нагромождения костылей...<br>
<br>
-- <br>
Best regards,<br>
  Gena<br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank" rel="noreferrer">nginx-ru@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
</blockquote></div>