On Sun, Feb 11, 2024, 19:32 Gena Makhomed <gmm@csdoc.com> wrote:

> On 09.02.2024 13:33, Anatoliy Melnik via nginx-ru wrote:
>
> > Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам.
> > Логи льются в syslog (слив в файлы напрямую из nginx не желателен).
>
> Несколько дней тому назад, в своем сообщении от 5 февраля 2024 года
> Вы озвучивали совсем другую причину, что у Вас не получается
> это сделать по каким-то техническим причинам, потому, что у Вас
> очень высокие нагрузки на систему - 200-250 тысяч подключений
> в секунду и поэтому вы не можете сделать запись логов напрямую
> в лог-файлы и ротацию этих лог-файлов раз в 30 секунд, и намекаете,
> что при таких высоких нагрузках вообще никто не сможет это сделать,
> предлагая мне самому попробовать настроить такую ротацию и убедиться
> в истинности Вашего утверждения, что это настроить вообще невозможно.
>
> И именно по той причине, что Вы не смогли настроить ротацию
> лог-файлов раз в 30 секунд и началось изобретение велосипедов
> и костылей с syslog`ами, unix-socket`ами и питоновскими скриптами.
>
> Это и есть типичная XY-проблема, о которой подробнее говорится
> в статье https://habr.com/ru/companies/dododev/articles/467047/
>
> А не смогли Вы настроить ротацию логов nginx раз в 30 секунд при
> трафике в 200-250 тысяч подключений по той причине, что ротацию
> логов Вы пытались делать с помощью SIGHUP, который вообще-то
> предназначен для изменения конфигурации, а не ротации логов.
> http://nginx.org/ru/docs/control.html#reconfiguration
>
> Если же делать ротацию логов используя SIGUSR1 - то никакой проблемы
> не будет, потому что это очень дешевая и очень быстрая операция,
> вне зависимости от того, какое количество подключений присутствует,
> потому что при этом новые worker-процессы nginx не создаются и старые
> worker-процессы nginx свою работу не завершают, как в случае SIGHUP.
>
> И когда Вы мне написали: "Если у вас уже есть такое рабочее решение
> - поделитесь опытом, буду рад вас выслушать" - я же Вам и ответил,
> что поиск рабочего решения следует начинать не с настройки syslog
> и не с написания python`овских скриптов, а с внимательного чтения
> документации, потому что там же очень подробно написано, как можно
> настроить очень быструю ротацию логов при любом количестве подключений:
> http://nginx.org/ru/docs/control.html#logs - что же тут не понятно?
>
> Особенно, если учесть, что директива https://nginx.org/r/access_log
> имеет дополнительные параметры [buffer=size] [flush=time] [if=condition]
> которые помогают еще сильнее уменьшить затраты процесора и времени на
> запись логов в файлы, потому что информация в лог будет записываться
> не построчно, а блоками большего розмера, то есть вместо нескольких
> сотен или тысяч системных вызовов может быть всего один системный вызов.
>

Теоретически, за счёт этих доп параметров появляется развилка

1) писать в динамически формируемое имя лога. Тогда можно избежать ротации.
Минус - с таким именованием несовместима буферизация

2) буферизация и ротация, как вы предлагаете



> Более быстрого процесса ускорения записи логов nginx в природе
> просто не существует - другими способами точно не будет быстрее.
>
> > По косвенным методам контроля вылезла проблема:
> > До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится,
> а вот начиная примерно с 50тыс/сек начинаются расхождения. nginx->syslog
> фиксирует меньше событий, чем сумма по бекэндам.
> > Чем выше интенсивность запросов, тем больше расходятся данные.
> > Сначала грешил на syslog, но детальные разборы полетов говорят, что
> скорее всего проблема в nginx.
> > У кого-то что-то такое наблюдалось или нет?
> > При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно
> 100тыс/сек, т.е. скорее всего syslog не виноват.
> > Кто-то с таким сталкивался?
> >
> > В рамках именно этого подхода проблему я решил подходом, указанным выше
> -- т.е. распараллелил логи на несколько потоков.
> > проблема потерь nginx->syslog у меня теперь решилась.
> >
> > Одна из задач (но не единственная) для чего это было нужно так же
> описана.
> > Если примененный мной подход для ВАШИХ задач не удобен или не приемлем
> или вызывает сомнения и т.д. -- не стоит навязывать своё мнение как
> единственно правильное.
>
> Вы пытаетесь решить проблему Y хотя Вам нужно решение проблемы X.
>
> проблема Y: ускорить запись из nginx в syslog, избежать потери сообщений
>
> проблема X: сделать ротацию логов раз в 30 секунд
>
> Как вляпаться в XY-проблему. Пошаговая инструкция пользователя
>
> 1. Пользователю нужно решить проблему Х.
>
> 2. Пользователь не знает, как решить проблему X, но думает, что
> сможет её решить, если ему удастся выполнить действие Y.
>
> 3. Пользователь также не знает, как выполнить действие Y.
>
> 4. Обращаясь за помощью, пользователь просит помочь ему разобраться с Y.
>
> 4. Все пытаются помочь пользователю с действием Y, несмотря на то,
> что Y кажется странной проблемой для решения.
>
> 5. Спустя много итераций и упущенного времени выясняется, что
> пользователь на самом деле хотел решить X-проблему.
>
> 6. Самое ужасное – выполнение действия Y не стало бы подходящим
> решением для X. Все рвут на себе волосы и со словами «я отдал тебе
> лучшие годы своей жизни» испепеляют друг друга взглядом.
>
> Зачастую XY-проблема возникает, когда люди зацикливаются на мелких
> деталях своей проблемы и на том, что они сами считают решением проблемы.
> В итоге они не могут отступить на шаг назад и объяснить проблему
> комплексно.
>
> > Именно такая схема не с потолка упала, а появилась в результате
> экспериментальных проверок нескольких подходов.
> > Рассказывать почему именно так, а не иначе -- долго, скучно, с кучей
> подробностей... и абсолютно бесполезно :)
> > Свое видение путей решения СВОИХ задач у меня уже сформировалось, а
> убеждать в чем-то вас смысла не имеет.
> > Еще раз СПАСИБО.
>
> Кто-то кого-то сейчас пытается обмануть.
>
> Вы рассказываете, что запись логов в файлы Вам не подходит
> по каким-то очень серьезным причинам, которые Вы не можете
> озвучить, потому что это Вам скучно, неинтересно и бесполезно.
>
> Но при этом лепите костыли из syslog, unix-socket`ов и питоновских
> скриптов, запуская их 10 копий для того, чтобы они могли получать
> информацию от nginx через unix socket и писать их в файлы.
>
> То есть, Вы утверждаете, что вариант, когда nginx напрямую пишет логи
> в файлы - Вам не подходит, потому что невозможно сделать ротацию логов
> раз в 30 секунд при 200-250 тысяч подключений, а вот вариант
> с этим жутким нагромождением костылей - это и есть решение проблемы.
>
> Какой проблемы? root cause of problem тут в том, что Вы не прочитали
> внимательно документацию к nginx и не смогли настроить ротацию логов
> через SIGUSR1 ? Что по факту есть очень быстрая и очень дешевая
> операция, значительно более легкая и быстрая, чем reload по SUGHUP.
>
> Проблема тут в чем? Проблема в том, что эти Ваши заявления о самом
> лучшем решении проблемы записи в лог-файлы с помощью нагромождения
> костылей - это фактически есть нехорошее действие, потому что таким
> способом вы распространяете FUD про nginx создавая в глазах неопытного
> читателя списка рассылки впечатление, что nginx - это очень кривая
> программа, которая даже свои логи в файлы не может нормально писать
> а вот Вы - решили эту проблему, с помощью нагромождения костылей...
>
> --
> Best regards,
> Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-ru
>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru