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

[Maxim Dounin]

Hello!

On Mon, Feb 05, 2024 at 09:56:54PM +0200, Gena Makhomed wrote:

[...]

> Потому что если программа, которая читает данные из unix socket`а
> отвалится - тогда произойдет переполенение буфера и nginx тогда
> заблокируется на операции записи в unix socket, и как следствие
> этого - перестанет выполнять свою основную функцию - перестанет
> отвечать на запросы клиентов по http / https протоколу.

Нет, если в сокет syslog'а не получается писать - nginx [логгирует 
ошибку в error log и] дропает сообщение.  Я об этом, собственно, 
писал в начале треда - судя по всему, исходная проблема была 
именно в том, что syslog-сервер не успевал выгребать сообщения, и 
они осыпались на пол.

(А если вернуться к основам, то в syslog через стандартную 
библиотеку nginx не пишет именно потому, что там запись в сокет в 
случае чего блокируется, и так, конечно, жить нельзя.)

[...]

> Так же не понятно, в чем для Вас проблема переименовать
> log-файл и отправить сигнал USR1 мастер-процессу nginx,
> для того, чтобы он переоткрыл log-файл и продолжил запись.
> 
> Особенно, если учесть, что директива https://nginx.org/r/access_log
> имеет дополнительные параметры [buffer=size] [flush=time] [if=condition]

+1

Нет никаких проблем вращать файловые логи в nginx'е, переоткрытие 
логов по USR1 - дешёвая и быстрая операция.

При этом запись в файловые логи, во-первых, куда эффективнее 
записи в syslog, в силу отсутствия лишних context switch'ей, а 
во-вторых, позволяет дополнительно и существенно снизить затраты 
за счёт буферизации и даже gzip-сжатия на лету.

Если на выходе всё равно файлы - совершенно непонятно, зачем 
нужна вся эта запись в python-скрипты, изображающие из себя 
syslog-сервера.

[...]

-- 
Maxim Dounin
http://mdounin.ru/