Re: Тест nginx -- сколько сообщений в log syslog без потерь?

[Gena Makhomed]

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]
которые помогают еще сильнее уменьшить затраты процесора и времени на 
запись логов в файлы, потому что информация в лог будет записываться
не построчно, а блоками большего розмера, то есть вместо нескольких
сотен или тысяч системных вызовов может быть всего один системный вызов.

Более быстрого процесса ускорения записи логов 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