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

[Gena Makhomed]

On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote:

 >> какую именно проблему Вы пытаетесь решить с помощью записи логов
 >> в unix socket, чтения данных из unix socket`а питоновским скриптом
 >> и потом записи данных этим питоновским скриптом в текстовой файл?

 > Если вы предлагаете писать напрямую с nginx-а в файл --
 > сделайте у себя ротацию файлов с интервалом 30 сек
 > при 200-250 тыс подключений/сек...

 > Если у вас уже есть такое рабочее решение -
 > поделитесь опытом, буду рад вас выслушать.

В этом сообщении Вы говорите о том, что Вы пробовали писать логи
"напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд,
при при 200-250 тыс подключений/сек, и у Вас не получилось
создать "рабочее решение".

И Вы просите, чтобы я поделился с Вами опытом, как построить
такое рабочее решение и говорите, что будете рады меня выслушать.

Если настроить ротацию логов через сигнал USR1
- никаких проблем с самой ротацией не должно быть,
при любом количестве подключений.

Тем более, что с помощью дополнительных параметров
[buffer=size] [gzip[=level]] [flush=time] директивы
access_log  можно настроить и буферизацию записи логов
и компрессию на лету - чтобы еще больше оптимизировать
использование ресурсов процессора и занимаемого логами
места на диске сервера.

Расскажите, пожалуйста, какие тут у Вас могли возникнуть проблемы,
что не получилось построить рабочее решение,
если "писать напрямую с nginx-а в файл" ?

Я пока что вижу только всего одну возможную причину,
почему у Вас не получилось создать такое рабочее решение
- для ротации логов Вы использовали сигнал HUP а не сигнал USR1.

Потому что только в случае ротации логом с помощью сигнала HUP
количество подключений в секунду и интервал ротации в 30 секунд
могут влиять на процесс ротации, потому что при этом происходит

"changing configuration, keeping up with a changed time zone
(only for FreeBSD and Linux), starting new worker processes
with a new configuration, graceful shutdown of old worker processes".

Если же делать ротацию логов с помощью сигнала USR1,
тогда не имеет особой разницы, какое количество подключений
в секунду обрабатывают рабочие процессы и и с каким интервалом
происходит ротация лог-файлов, потому что если делать ротацию
с помощью сигнала USR1 - перезапуска рабочих процессов не происходит,
и происходит только лишь "re-opening log files", что является очень
дешевой и очень быстрой операцией, такая ротация происходит
практически мгновенно и не создает дополнительной нагрузки
на систему.

Причина, почему у Вас не получилось настроить ротацию лог-файлов
при записи логов "напрямую с nginx-а в файл" может быть в такой
ситуации только одна - для ротации лог-файлов Вы использовали
сигнал HUP а не сигнал USR1 - именно поэтому у Вас не получилось.

On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote:

 >> какую именно проблему Вы пытаетесь решить с помощью записи логов
 >> в unix socket, чтения данных из unix socket`а питоновским скриптом
 >> и потом записи данных этим питоновским скриптом в текстовой файл?

 > Если вы предлагаете писать напрямую с nginx-а в файл --
 > сделайте у себя ротацию файлов с интервалом 30 сек
 > при 200-250 тыс подключений/сек...

 > Если у вас уже есть такое рабочее решение -
 > поделитесь опытом, буду рад вас выслушать.

Почему Вам не подходит решение
использовать сигнал USR1 для ротации логов?

Ведь Вы же прямо говорите в этом своем сообщении, что проблема
у Вас именно с тем, что не удается настроить сам процесс ротации
логов с интервалом 30 сек при 200-250 тыс подключений/сек.

О другой проблеме - нехватки свободного места на диске сервера
для записи логов, или о проблеме низкой пропускной способности
дисковой подсисетмы в своем ответе - Вы ничего не говорите.

Это же какие у Вас получаются там объемы логов nginx за 30 секунд,
что может не хватать пропускной способности дисковой подсистемы
или свободного места на диске сервера?

Почему у Вас не получается сделать ротацию лог-файлов nginx
с интервалом 30 сек. при 200-250 тыс подключений в секунду?

Низкая пропускная способность дисковой подсистемы сервера?

Или нехватка свободного места для логов на диске сервера?

On 13.02.2024 11:38, Anatoliy Melnik via nginx-ru wrote:

> Для меня главный вопрос, на который надо дать ответ:
> ЗАЧЕМ я пишу логи? ЧТО я дальше с ними буду делать?

То есть, Вы хотите сказать, что Ваша исходная задача
допускает решение, которое может быть реализовано
вообще без исхользования access-логов nginx?

Например, с помощью директив модуля ngx_http_mirror_module
Если Вам достаточно информации, которая присутствует в логах,
значит тело запроса не нужно и можно поставить mirror_request_body off;
с помощью директивы mirror в internal location и последующим 
проксированием запросов на какой-то сервис на Go, который будет
собирать, аккумулировать и отдавать необходимую Вам статистику.

На Go с использованием goroutines и каналов можно построить очень
эффективный сервис, который будет максимально масштабируемым
и будет выдерживать очень большую нагрузку, так что мощности
хватит с запасом, если проксировать запросы на этот демон
через блок upstream с включенным keepalive.

>>> Возникает впечатление, что кому-то из вас принципиально важно
>>> доказать незыблемую правоту своего мнения и ошибочность моих
>>> действий. Вопрос - зачем?

Мне интересно понять суть проблемы и найти самое оптимальное решение.

>>> Это не конкурс или состязание, я сюда обратился за советом.

Вы спрашивали совета о том, как решить проблему Y,
хотя на самом деле - Вы хотите решить проблему X.

https://ru.wikipedia.org/wiki/Проблема_XY_(Ошибка_молотка)

Проблема XY — это проблема, возникающая при обращении в службу поддержки
и в других похожих ситуациях, когда обратившийся за помощью человек
ставит не проблему X напрямую, а спрашивает решение проблемы Y, которая
по его мнению позволит решить проблему X. Тем не менее, решение проблемы
Y часто не решает проблему X, или является не самым удачным для неё
решением. При этом человек, пытающийся помочь, может испытывать
проблемы коммуникации и/или предлагать не самые оптимальные решения.

Проблема XY обычно встречается в среде технической поддержки или
обслуживания клиентов, где конечный пользователь пытается решить
проблему самостоятельно и неправильно понимает реальную природу
проблемы, полагая, что их реальная проблема X уже решена, за исключением
некоторых мелких деталей Y в их решении. Неспособность обслуживающего
персонала решить реальную проблему или понять природу запроса может
привести к разочарованию конечного пользователя. Ситуация может
проясниться, если конечный пользователь спросит о какой-то
«бессмысленной» детали, которая не связана с полезной конечной целью.
Решение для обслуживающего персонала состоит в том, чтобы задавать
наводящие вопросы: зачем нужна эта информация, чтобы выявить корень
проблемы и перенаправить конечного пользователя с непродуктивного
пути исследования.

> Все данные извлекаются в скрипте "на лету" и отображаются в соответствующих счетчиках.
> При необходимости сосчитать что-то другое/новое или по другом алгоритму - я всего лишь изменю несколько строк скрипта.
> На данном этапе проверенная производительность одной системы 240тыс/сек, прогноз исходя из статистики нагрузки - 400-420.

Вместо syslog, unix socket и скриптов на Python - Вы пробовали вариант
решения этой проблемы с помощью зеркалирования исходных запросов через
директиву mirror с mirror_request_body off ? Получателем этих запросов
может быть или какой-то веб-сервер на Python, например, gunicorn.org,
или FastWSGI или сразу backend на Go, потому что там все компилируется
сразу в машинный код и с помощью goroutines и каналов можно сделать
достаточно эффективный backend для сбора статистики - это проблема X.

> И на каждом этапе обсуждения мне казалось очевидным: мне нужна рабочая связка nginx->(unixSocket)->syslog !!!

Получение рабочей связки nginx->(unixSocket)->syslog - это проблема Y.

На самом деле - Вам нужно решение проблемы X.

> Уже непререкаемая уверенность в собственной непогрешимости в некоторых постах должна была меня насторожить.

я вполне способен воспринимать технически грамотные ответы
и признавать свои ошибки, - если таковые имели место быть.

>> «Ничего личного, только бизнес».

> Никогда не понимал восторгов этим правилом.

Это я к тому, что меня не интересует обсуждение Вашей личности.
А интересует поиск наиболее оптимальных способов решения интересных
проблем и задач, которые имеют прямое или косвенное отношение к nginx.

> Из личного опыта -- стараюсь не иметь дел с адептами этого подхода, и это сугубо личное.

Формула «Ничего личного, только бизнес» имеет как положительную,
как и отрицательную коннотацию. Отрицательная коннотация - потому
что эта формула может быть использована для оправдания каких-то
непопулярных действий и решений в бизнесе. Но есть и положительная,
- в том смысле, что следует отделять личное отношение от "бизнеса",
то есть, что при обсуждении каких-то технических проблем необходимо
руководствоваться рациональностью и логикой, а не эмоциями.

-- 
Best regards,
  Gena