From izorkin на gmail.com Sun Feb 4 07:03:56 2024 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sun, 4 Feb 2024 10:03:56 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?= =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?= In-Reply-To: References: <472646211.20240105204620@gmail.com> <1859693144.20240105221755@gmail.com> <577341570.20240106093303@gmail.com> <1656995827.20240106162514@gmail.com> <1759520254.20240106202059@gmail.com> Message-ID: <645387708.20240204100356@gmail.com> Добрый день, Максим. Сегодня увидел, что разработчики избавились от буферов приёма и создали новый способ разгрузки для протокола HTTP/2: https://github.com/icing/blog/blob/main/curl-h2-perf-evolution.md https://github.com/curl/curl/pull/12828 Реализации аналогичного варианты в Nginx как-то поможет для ускорения работы с протоколом HTTP/2? Вы писали 6 января 2024 г., 21:27:52: > Просадка производительности, которую вы наблюдаете для HTTP/2 при > включённом kTLS - не собственно из-за kTLS, а из-за того, что у > вас включён sendfile, и при включённом kTLS становится возможным > его использование. А в случае HTTP/2 это выливается в большое > количество syscall'ов из-за HTTP/2-фрейминга. -- С уважением, Izorkin mailto:izorkin на gmail.com From mdounin на mdounin.ru Mon Feb 5 08:40:55 2024 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 5 Feb 2024 11:40:55 +0300 Subject: nginxQuic: =?koi8-r?B?08vP0s/T1Ngg2sHH?= =?koi8-r?B?0tXay8kg0NLJIMHL1MnXwcPJyQ==?= kTLS In-Reply-To: <645387708.20240204100356@gmail.com> References: <1859693144.20240105221755@gmail.com> <577341570.20240106093303@gmail.com> <1656995827.20240106162514@gmail.com> <1759520254.20240106202059@gmail.com> <645387708.20240204100356@gmail.com> Message-ID: Hello! On Sun, Feb 04, 2024 at 10:03:56AM +0300, izorkin на gmail.com wrote: > Добрый день, Максим. > > Сегодня увидел, что разработчики избавились от буферов приёма и > создали новый способ разгрузки для протокола HTTP/2: > https://github.com/icing/blog/blob/main/curl-h2-perf-evolution.md > https://github.com/curl/curl/pull/12828 > > Реализации аналогичного варианты в Nginx как-то поможет для ускорения > работы с протоколом HTTP/2? Это какая-то внутренняя история curl'а про борьбу с неэффективным демультиплексингом, к nginx'у не имеет отношения примерно никакого, да и в самом curl'е относится только к случаю получения нескольких файлов одновременно по одному соединению. -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Mon Feb 5 08:57:12 2024 From: izorkin на gmail.com (izorkin на gmail.com) Date: Mon, 5 Feb 2024 11:57:12 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0YHQutC+0YDQvtGB0YLRjCDQt9Cw0LPRgNGD0LfQutC4INC/0YA=?= =?utf-8?B?0Lgg0LDQutGC0LjQstCw0YbQuNC4IGtUTFM=?= In-Reply-To: References: <1859693144.20240105221755@gmail.com> <577341570.20240106093303@gmail.com> <1656995827.20240106162514@gmail.com> <1759520254.20240106202059@gmail.com> <645387708.20240204100356@gmail.com> Message-ID: <897221386.20240205115712@gmail.com> Добрый день, Максим. Ясно, благодарю за пояснение :) Вы писали 5 февраля 2024 г., 11:40:55: > Hello! > Это какая-то внутренняя история curl'а про борьбу с неэффективным > демультиплексингом, к nginx'у не имеет отношения примерно > никакого, да и в самом curl'е относится только к случаю получения > нескольких файлов одновременно по одному соединению. -- С уважением, Izorkin mailto:izorkin на gmail.com From nginx на kinetiksoft.com Mon Feb 5 09:15:44 2024 From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=) Date: Mon, 5 Feb 2024 11:15:44 +0200 Subject: =?UTF-8?B?0JfQtdGA0LrQsNC70L4gaHR0cHM6Ly9oZy5uZ2lueC5vcmcvcGtnLW9z?= =?UTF-8?B?cyDQvdCwIGdpdGh1Yg==?= Message-ID: Здравствуйте! Нельзя ли добавить на github зеркало сабжевого репа? Используем его для сборки nginx и модулей (отсутствующих в официальной поставке), зеркалируем реп во внутренний гитлаб, хотелось бы убрать костыли типа mercurial 2 git. С уважением, Иван. From anatoliy.melnik на showjet.ru Mon Feb 5 11:40:42 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Mon, 5 Feb 2024 14:40:42 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> И снова Здравствуйте :) Итак конечный вариант решения: В конфиге nginx вот такая конструкция map "$remote_port" $log_selector_0 { default 0; ~0$ 1; } map "$remote_port" $log_selector_1 { default 0; ~1$ 1; } map "$remote_port" $log_selector_2 { default 0; ~2$ 1; } map "$remote_port" $log_selector_3 { default 0; ~3$ 1; } map "$remote_port" $log_selector_4 { default 0; ~4$ 1; } map "$remote_port" $log_selector_5 { default 0; ~5$ 1; } map "$remote_port" $log_selector_6 { default 0; ~6$ 1; } map "$remote_port" $log_selector_7 { default 0; ~7$ 1; } map "$remote_port" $log_selector_8 { default 0; ~8$ 1; } map "$remote_port" $log_selector_9 { default 0; ~9$ 1; } ..... access_log syslog:server=unix:/run/socket-00,nohostname,facility=local5,severity=info,tag=nginxStats01 st01 if=$log_selector_0; access_log syslog:server=unix:/run/socket-01,nohostname,facility=local5,severity= info ,tag=nginxStats01 st01 if=$log_selector_1; access_log syslog:server=unix:/run/socket-02,nohostname,facility=local5,severity= info ,tag=nginxStats01 st01 if=$log_selector_2; access_log syslog:server=unix:/run/socket-03,nohostname,facility=local5,severity= info ,tag=nginxStats01 st01 if=$log_selector_3; access_log syslog:server=unix:/run/socket-04,nohostname,facility=local5,severity= info ,tag=nginxStats01 st01 if=$log_selector_4; access_log syslog:server=unix:/run/socket-05,nohostname,facility=local5,severity=info,tag=nginxStats01 st01 if=$log_selector_5; access_log syslog:server=unix:/run/socket-06,nohostname,facility=local5,severity= info ,tag=nginxStats01 st01 if=$log_selector_6; access_log syslog:server=unix:/run/socket-07,nohostname,facility=local5,severity= info ,tag=nginxStats01 st01 if=$log_selector_7; access_log syslog:server=unix:/run/socket-08,nohostname,facility=local5,severity= info ,tag=nginxStats01 st01 if=$log_selector_8; access_log syslog:server=unix:/run/socket-09,nohostname,facility=local5,severity= info ,tag=nginxStats01 st01 if=$log_selector_9; Данные почти равномерно расходятся по 10-ти файлам, которые пишутся на tmpfs в RAM. Отказался и от rsyslog и от syslog-ng В качестве принимающей стороны выступает пока python скрипт В нем стартую 10 процессов, каждый слушает свой сокет и вся его задача -- сложить в файл данные. Отказ от rsyslog-а обусловлен просто огромным количеством переключений контекста, rsyslog-ом генерируемое. Уже на 200-210тыс/сек их количество переваливает за 1.4 млн/сек. ( примерно 0.9млн - работа rsyslog-а) и на этой отметке сильно деградирует производительность системы в целом. syslog-ng при работе с unixSocket показал довольно низкую производительность. (Долго с ним не разбирался. Чисто дефолтная установка и минимальная настройка). python по сравнению с rsyslog ЦПУ потребляет немного больше, но переключений контекста значительно меньше, и это положительно сказывается на работе всей системы. Как итог -- проверен порог в 220-230 тыс/сек (такая нагрузка сохранялась около 3-х часов) на 1 nginx, на моем железе все отработало нормально, все метрики сошлись. Попытка с UDP -- больше потребление CPU, больше прерываний, больше переключений контекста... И если 220-230 тыс/сек на 10 unixSocket -еще не предел для моего железа, то те же 220-230 тыс/сек на udp на loopback интерфейс практически предел судя по мониторингу. Всем еще раз спасибо за внимание и советы. ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Mon Feb 5 12:03:55 2024 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 5 Feb 2024 15:03:55 +0300 Subject: =?utf-8?B?0KLQtdGB0YIgbmdpbnggLS0g0YE=?= =?utf-8?B?0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9n?= =?utf-8?B?INCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> References: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> Message-ID: On Mon, Feb 05, 2024 at 02:40:42PM +0300, Anatoliy Melnik via nginx-ru wrote: > syslog-ng при работе с unixSocket показал довольно низкую > производительность. (Долго с ним не разбирался. Чисто дефолтная установка > и минимальная настройка). Syslog-ng производит огромное количество ненужных (на мой взгляд) сисколов при работе с unix-сокетами, к тому же пытается то, что отдаётся в syslog(3), подменить на более "правильную", по мнению автора, информацию... Например, выправить pid, если писатель нарисовал чужой (наверное, это такая забота о безопасности). Всё очень трогательно, но эта забота выливается в большие накладные расходы. Под большую нагрузку syslog-ng явно не заточен. -- Eugene Berdnikov From gmm на csdoc.com Mon Feb 5 12:16:17 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 5 Feb 2024 14:16:17 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> References: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> Message-ID: <60e4dd66-9e45-4c43-a3e9-225a94ffa54e@csdoc.com> On 05.02.2024 13:40, Anatoliy Melnik via nginx-ru wrote: > Итак конечный вариант решения: > > Данные почти равномерно расходятся по 10-ти файлам, которые пишутся на tmpfs в RAM. > Отказался и от rsyslog и от syslog-ng > В качестве принимающей стороны выступает пока python скрипт > В нем стартую 10 процессов, каждый слушает свой сокет и вся его задача -- сложить в файл данные. какую именно проблему Вы пытаетесь решить с помощью записи логов в unix socket, чтения данных из unix socket`а питоновским скриптом и потом записи данных этим питоновским скриптом в текстовой файл? https://habr.com/ru/companies/dododev/articles/467047/ Феномен XY: как избежать «неправильных» проблем -- Best regards, Gena From anatoliy.melnik на showjet.ru Mon Feb 5 13:21:24 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Mon, 5 Feb 2024 16:21:24 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> References: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> Message-ID: <874654852.122684865.1707139284817.JavaMail.zimbra@showjet.ru> Gena Makhomed >какую именно проблему Вы пытаетесь решить с помощью записи логов >в unix socket, чтения данных из unix socket`а питоновским скриптом >и потом записи данных этим питоновским скриптом в текстовой файл? Если вы предлагаете писать напрямую с nginx-а в файл -- сделайте у себя ротацию файлов с интервалом 30 сек при 200-250 тыс подключений/сек... Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать. А на текущем отрезке времени: Спасибо, я уже все решил :) ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Mon Feb 5 19:56:54 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 5 Feb 2024 21:56:54 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <874654852.122684865.1707139284817.JavaMail.zimbra@showjet.ru> References: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> <874654852.122684865.1707139284817.JavaMail.zimbra@showjet.ru> Message-ID: <6252fb32-1118-478e-88ba-6eec93a799f1@csdoc.com> On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote: >> какую именно проблему Вы пытаетесь решить с помощью записи логов >> в unix socket, чтения данных из unix socket`а питоновским скриптом >> и потом записи данных этим питоновским скриптом в текстовой файл? > Если вы предлагаете писать напрямую с nginx-а в файл -- сделайте у себя ротацию файлов с интервалом 30 сек при 200-250 тыс подключений/сек... > Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать. Создание нормального рабочего решения должно начинаться с внимательного чтения документации и исходников nginx. Какую именно существующую проблему Вы пытаетесь решить с помощью ротации лог-файлов с интервалом в 30 секунд? > А на текущем отрезке времени: > Спасибо, я уже все решил :) Нет. Вы просто создали себе еще большую проблему на ровном месте. Потому что если программа, которая читает данные из unix socket`а отвалится - тогда произойдет переполенение буфера и nginx тогда заблокируется на операции записи в unix socket, и как следствие этого - перестанет выполнять свою основную функцию - перестанет отвечать на запросы клиентов по http / https протоколу. То есть, то что Вы сделали - это достаточно хрупкое и ненадежное "решение", особенно в условиях высоких нагрузок. Не всегда нужно все подряд писать в лог, например, можно ограничиться записью в лог только ответов с 4хх и 5хх статусами, в таком случае - не будет той проблемы, которую Вы пытаетесь решить таким способом с помощью unix-socket`а и python. Так же не понятно, в чем для Вас проблема переименовать log-файл и отправить сигнал USR1 мастер-процессу nginx, для того, чтобы он переоткрыл log-файл и продолжил запись. Особенно, если учесть, что директива https://nginx.org/r/access_log имеет дополнительные параметры [buffer=size] [flush=time] [if=condition] Вместо этого - какие-то жуткие костыли - то syslog, то unix socket и питоновские скрипты, читающие данные из этого unix-socket`а пишущие текстовые файлы, то еще что-то. Вы так и не ответили на мой вопрос, какую именно проблему Вы пытаетесь решить таким вот нетривиальным способом? https://habr.com/ru/companies/dododev/articles/467047/ Феномен XY: как избежать «неправильных» проблем -- Best regards, Gena From chipitsine на gmail.com Mon Feb 5 21:10:02 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 5 Feb 2024 22:10:02 +0100 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC9?= =?UTF-8?B?0LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <6252fb32-1118-478e-88ba-6eec93a799f1@csdoc.com> References: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> <874654852.122684865.1707139284817.JavaMail.zimbra@showjet.ru> <6252fb32-1118-478e-88ba-6eec93a799f1@csdoc.com> Message-ID: пн, 5 февр. 2024 г. в 20:57, Gena Makhomed : > On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote: > >> какую именно проблему Вы пытаетесь решить с помощью записи логов > >> в unix socket, чтения данных из unix socket`а питоновским скриптом > >> и потом записи данных этим питоновским скриптом в текстовой файл? > > > Если вы предлагаете писать напрямую с nginx-а в файл -- сделайте у себя > ротацию файлов с интервалом 30 сек при 200-250 тыс подключений/сек... > > Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад > вас выслушать. > > Создание нормального рабочего решения должно начинаться > с внимательного чтения документации и исходников nginx. > > Какую именно существующую проблему Вы пытаетесь решить > с помощью ротации лог-файлов с интервалом в 30 секунд? > > > А на текущем отрезке времени: > > Спасибо, я уже все решил :) > > Нет. Вы просто создали себе еще большую проблему на ровном месте. > > Потому что если программа, которая читает данные из unix socket`а > отвалится - тогда произойдет переполенение буфера и nginx тогда > заблокируется на операции записи в unix socket, и как следствие > этого - перестанет выполнять свою основную функцию - перестанет > отвечать на запросы клиентов по http / https протоколу. > > То есть, то что Вы сделали - это достаточно хрупкое > и ненадежное "решение", особенно в условиях высоких нагрузок. > > Не всегда нужно все подряд писать в лог, например, > можно ограничиться записью в лог только ответов с 4хх и 5хх статусами, > в таком случае - не будет той проблемы, которую Вы пытаетесь > решить таким способом с помощью unix-socket`а и python. > > Так же не понятно, в чем для Вас проблема переименовать > log-файл и отправить сигнал USR1 мастер-процессу nginx, > для того, чтобы он переоткрыл log-файл и продолжил запись. > > Особенно, если учесть, что директива https://nginx.org/r/access_log > имеет дополнительные параметры [buffer=size] [flush=time] [if=condition] > > Вместо этого - какие-то жуткие костыли - то syslog, то unix socket и > питоновские скрипты, читающие данные из этого unix-socket`а пишущие > текстовые файлы, то еще что-то. > > Вы так и не ответили на мой вопрос, какую именно проблему > Вы пытаетесь решить таким вот нетривиальным способом? > проблему трудоустройства )) ? положа руку на сердце, с ротацией логов есть несколько, честно скажем, решений, с которыми выглядит как компромисс 1) переменные (позволяющие создавать новый лог, скажем по map-у раз в 30 сек). вроде норм, но буферизации в этом случае не будет. но на nvme возможно норм 2) copytruncate режим 3) описанный режим с USR1 > > https://habr.com/ru/companies/dododev/articles/467047/ > Феномен XY: как избежать «неправильных» проблем > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Mon Feb 5 21:21:12 2024 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Tue, 6 Feb 2024 00:21:12 +0300 Subject: =?utf-8?B?0KLQtdGB0YIgbmdpbnggLS0g0YE=?= =?utf-8?B?0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9n?= =?utf-8?B?INCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <6252fb32-1118-478e-88ba-6eec93a799f1@csdoc.com> References: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> <874654852.122684865.1707139284817.JavaMail.zimbra@showjet.ru> <6252fb32-1118-478e-88ba-6eec93a799f1@csdoc.com> Message-ID: On Mon, Feb 05, 2024 at 09:56:54PM +0200, Gena Makhomed wrote: > On 05.02.2024 15:21, Anatoliy Melnik via nginx-ru wrote: > > Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать. > > Создание нормального рабочего решения должно начинаться > с внимательного чтения документации и исходников nginx. Насчёт чтения исходников -- выглядит примерно таким же экстремизмом, как требование знания ассемблера для прикладного программиста... :) > Какую именно существующую проблему Вы пытаетесь решить > с помощью ротации лог-файлов с интервалом в 30 секунд? Товарищ отвечал на этот вопрос: https://mailman.nginx.org/pipermail/nginx-ru/2024-January/MD45SEEP573DPPEQYAFT26MPMUK5646B.html > Потому что если программа, которая читает данные из unix socket`а > отвалится - тогда произойдет переполенение буфера и nginx тогда > заблокируется на операции записи в unix socket, и как следствие > этого - перестанет выполнять свою основную функцию - перестанет > отвечать на запросы клиентов по http / https протоколу. Если так, и без вариантов, то это скорее недостаток nginx-а. Нужно делать запись в сислог через неблокирующийся сокет, и дропать записи если отправлять их не удаётся. Потому что в подавляющем большинстве случаев факт работоспобности сервиса ВАЖНЕЕ правильности его работы и отсутствия разных недостатков, вроде пропуска записей в логах. А ещё лучше дать юзеру ручку, управляющую поведением программы при блокировке записи в лог. По мне так пример разумного подхода -- сквидовский logfile-daemon. -- Eugene Berdnikov From mdounin на mdounin.ru Mon Feb 5 22:24:25 2024 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 6 Feb 2024 01:24:25 +0300 Subject: =?koi8-r?B?9MXT1CBuZ2lueCAtLSDTy8/M?= =?koi8-r?B?2MvPINPPz8Ldxc7JyiDXIGxvZyBzeXNsb2cgwsXaINDP1MXS2D8=?= In-Reply-To: <6252fb32-1118-478e-88ba-6eec93a799f1@csdoc.com> References: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> <874654852.122684865.1707139284817.JavaMail.zimbra@showjet.ru> <6252fb32-1118-478e-88ba-6eec93a799f1@csdoc.com> Message-ID: 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/ From gmm на csdoc.com Mon Feb 5 22:57:50 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 6 Feb 2024 00:57:50 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: References: <695472479.122419773.1707133242787.JavaMail.zimbra@showjet.ru> <874654852.122684865.1707139284817.JavaMail.zimbra@showjet.ru> <6252fb32-1118-478e-88ba-6eec93a799f1@csdoc.com> Message-ID: On 05.02.2024 23:21, Evgeniy Berdnikov wrote: >>> Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать. >> Создание нормального рабочего решения должно начинаться >> с внимательного чтения документации и исходников nginx. > Насчёт чтения исходников -- выглядит примерно таким же экстремизмом, > как требование знания ассемблера для прикладного программиста... :) Слово "должно" здесь означает SHOULD а не MUST, то есть - это рекомендация, а не требование. Исходники - это тоже документация, причем максимально точно и максимально подробно рассказывающая о поведении программы. По крайней мере, это часто экономит время, если ответа нет в документации - то мне обычно проще и быстрее посмотреть в исходниках - документации №2, или провести эксперимент. При чем тут ассемблер - не совсем понятно, nginx ведь на C написан, как и большая часть операционной системы и всего системного софта. >> Какую именно существующую проблему Вы пытаетесь решить >> с помощью ротации лог-файлов с интервалом в 30 секунд? > > Товарищ отвечал на этот вопрос: > https://mailman.nginx.org/pipermail/nginx-ru/2024-January/MD45SEEP573DPPEQYAFT26MPMUK5646B.html почему не подходит вариант делать ротацию логов с помощью USR1 ? >> Потому что если программа, которая читает данные из unix socket`а >> отвалится - тогда произойдет переполенение буфера и nginx тогда >> заблокируется на операции записи в unix socket, и как следствие >> этого - перестанет выполнять свою основную функцию - перестанет >> отвечать на запросы клиентов по http / https протоколу. > Если так, и без вариантов, то это скорее недостаток nginx-а. Нужно делать > запись в сислог через неблокирующийся сокет, и дропать записи если > отправлять их не удаётся. Потому что в подавляющем большинстве случаев > факт работоспобности сервиса ВАЖНЕЕ правильности его работы и отсутствия > разных недостатков, вроде пропуска записей в логах. А ещё лучше дать юзеру > ручку, управляющую поведением программы при блокировке записи в лог. Возможно, я что-то напутали и помню или старое поведение nginx, или путаю сейчас nginx с другой программой, или вообще - путаю unix socket`ы с пайпами. Но текущее поведение nginx можно легко узнать с помощью эксперимента. Мне обычных логов вполне хватает, поэтому записью логов nginx в unix socket никогда не занимался. > По мне так пример разумного подхода -- сквидовский logfile-daemon. Сейчас логи каждый воркер пишет в файл напрямую, а если писать логи через какой-то дополнительный процесс - это увеличит накладные расходы на IPC и сложность, не принося при этом никакой пользы и ценности, IMHO. -- Best regards, Gena From anatoliy.melnik на showjet.ru Fri Feb 9 11:33:40 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Fri, 9 Feb 2024 14:33:40 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> И снова здравствуйте. Прочитал все сообщения, Еще раз спасибо за помощь и участие. Возвращаясь к началу: Здравствуйте. Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам. Логи льются в syslog (слив в файлы напрямую из nginx не желателен). По косвенным методам контроля вылезла проблема: До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а вот начиная примерно с 50тыс/сек начинаются расхождения. nginx->syslog фиксирует меньше событий, чем сумма по бекэндам. Чем выше интенсивность запросов, тем больше расходятся данные. Сначала грешил на syslog, но детальные разборы полетов говорят, что скорее всего проблема в nginx. У кого-то что-то такое наблюдалось или нет? При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно 100тыс/сек, т.е. скорее всего syslog не виноват. Кто-то с таким сталкивался? В рамках именно этого подхода проблему я решил подходом, указанным выше -- т.е. распараллелил логи на несколько потоков. проблема потерь nginx->syslog у меня теперь решилась. Одна из задач (но не единственная) для чего это было нужно так же описана. Если примененный мной подход для ВАШИХ задач не удобен или не приемлем или вызывает сомнения и т.д. -- не стоит навязывать своё мнение как единственно правильное. Именно такая схема не с потолка упала, а появилась в результате экспериментальных проверок нескольких подходов. Рассказывать почему именно так, а не иначе -- долго, скучно, с кучей подробностей... и абсолютно бесполезно :) Свое видение путей решения СВОИХ задач у меня уже сформировалось, а убеждать в чем-то вас смысла не имеет. Еще раз СПАСИБО. ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Feb 9 12:50:37 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 9 Feb 2024 13:50:37 +0100 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC9?= =?UTF-8?B?0LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> Message-ID: On Fri, Feb 9, 2024, 12:34 Anatoliy Melnik via nginx-ru wrote: > И снова здравствуйте. > Прочитал все сообщения, Еще раз спасибо за помощь и участие. > > Возвращаясь к началу: > > Здравствуйте. > Есть nginx-ы, несколько разных версий. Проксируют запросы к бекэндам. > Логи льются в syslog (слив в файлы напрямую из nginx не желателен). > По косвенным методам контроля вылезла проблема: > До примерно 50 тыс/сек сообщений статистика прокси и бекэндов сходится, а > вот начиная примерно с 50тыс/сек начинаются расхождения. nginx->syslog > фиксирует меньше событий, чем сумма по бекэндам. > Чем выше интенсивность запросов, тем больше расходятся данные. > Сначала грешил на syslog, но детальные разборы полетов говорят, что скорее > всего проблема в nginx. > У кого-то что-то такое наблюдалось или нет? > При сливе логов с 2-х nginx-ов в один syslog все хорошо до примерно > 100тыс/сек, т.е. скорее всего syslog не виноват. > Кто-то с таким сталкивался? > > В рамках именно этого подхода проблему я решил подходом, указанным выше -- > т.е. распараллелил логи на несколько потоков. > проблема потерь nginx->syslog у меня теперь решилась. > > Одна из задач (но не единственная) для чего это было нужно так же описана. > Если примененный мной подход для ВАШИХ задач не удобен или не приемлем или > вызывает сомнения и т.д. -- не стоит навязывать своё мнение как единственно > правильное. > > Именно такая схема не с потолка упала, а появилась в результате > экспериментальных проверок нескольких подходов. > Рассказывать почему именно так, а не иначе -- долго, скучно, с кучей > подробностей... и абсолютно бесполезно :) > Свое видение путей решения СВОИХ задач у меня уже сформировалось, а > убеждать в чем-то вас смысла не имеет. > Еще раз СПАСИБО. > Ок, у вас есть видение путей решения. Убеждать вы никого ни в чем не собираетесь Удачи вам в ваших начинаниях! > ------------------------------ > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Sun Feb 11 18:32:07 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 11 Feb 2024 20:32:07 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> Message-ID: <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> 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 From chipitsine на gmail.com Sun Feb 11 19:36:31 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 11 Feb 2024 20:36:31 +0100 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC9?= =?UTF-8?B?0LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> Message-ID: On Sun, Feb 11, 2024, 19:32 Gena Makhomed 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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Sun Feb 11 19:38:10 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 11 Feb 2024 20:38:10 +0100 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC9?= =?UTF-8?B?0LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> Message-ID: А "XY" проблема в левацки ориентированном комьюнити может восприниматься, как хромосома и "токсичная маскулинность", простите(( On Sun, Feb 11, 2024, 19:32 Gena Makhomed 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] > которые помогают еще сильнее уменьшить затраты процесора и времени на > запись логов в файлы, потому что информация в лог будет записываться > не построчно, а блоками большего розмера, то есть вместо нескольких > сотен или тысяч системных вызовов может быть всего один системный вызов. > > Более быстрого процесса ускорения записи логов 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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Sun Feb 11 21:02:59 2024 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 12 Feb 2024 00:02:59 +0300 Subject: =?utf-8?B?0KLQtdGB0YIgbmdpbnggLS0g0YE=?= =?utf-8?B?0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9n?= =?utf-8?B?INCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> Message-ID: On Sun, Feb 11, 2024 at 08:32:07PM +0200, Gena Makhomed wrote: > > Именно такая схема не с потолка упала, а появилась в результате экспериментальных проверок нескольких подходов. > > Рассказывать почему именно так, а не иначе -- долго, скучно, с кучей подробностей... и абсолютно бесполезно :) > > Свое видение путей решения СВОИХ задач у меня уже сформировалось, а убеждать в чем-то вас смысла не имеет. > > Еще раз СПАСИБО. > > Кто-то кого-то сейчас пытается обмануть. > > Вы рассказываете, что запись логов в файлы Вам не подходит > по каким-то очень серьезным причинам, которые Вы не можете > озвучить, потому что это Вам скучно, неинтересно и бесполезно. Вполне возможно, что товарищ никого не обманывает, и ему действительно обсуждать постановку задачи скучно, неинтересно, и даже "бесполезно" в том смысле, что он не готов к обсасыванию этой темы: то ли слишком непривычно и оттого голова напрягается, то ли по ещё какой причине... Товарищу хочется улучшать решение Y, и не хочется обсуждать альтернативы. Ну, это его право. К его сожалению, аудитория тут попалась не очень-то сочувствующая такому подходу, бывает. Но по сути дела изначальный вопрос был "почему пропадают записи в syslog?" Причина, скорее всего, была в том, что syslogd не успевал их принимать. Однако прямого доказательства этому так и не было предъявлено -- в виде статистики возвратов EAGAIN от send() внутри nginx-a, или от мониторинга величины очереди на unix-сокете, или хотя бы от измерения нагрузки на процессор у syslogd. Хотя товарищ измерил чистую пропускную способность syslogd, и получил значение выше проблемного, но это возможно и не даёт ответа для неравномерного трафика. В итоге был переделан велосипед Y, и ответ на изначальный вопрос перестал интересовать. Ну, тоже бывает. :) -- Eugene Berdnikov From chipitsine на gmail.com Sun Feb 11 23:09:35 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 12 Feb 2024 00:09:35 +0100 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC9?= =?UTF-8?B?0LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> Message-ID: вс, 11 февр. 2024 г. в 22:03, Evgeniy Berdnikov : > On Sun, Feb 11, 2024 at 08:32:07PM +0200, Gena Makhomed wrote: > > > Именно такая схема не с потолка упала, а появилась в результате > экспериментальных проверок нескольких подходов. > > > Рассказывать почему именно так, а не иначе -- долго, скучно, с кучей > подробностей... и абсолютно бесполезно :) > > > Свое видение путей решения СВОИХ задач у меня уже сформировалось, а > убеждать в чем-то вас смысла не имеет. > > > Еще раз СПАСИБО. > > > > Кто-то кого-то сейчас пытается обмануть. > > > > Вы рассказываете, что запись логов в файлы Вам не подходит > > по каким-то очень серьезным причинам, которые Вы не можете > > озвучить, потому что это Вам скучно, неинтересно и бесполезно. > > Вполне возможно, что товарищ никого не обманывает, и ему действительно > обсуждать постановку задачи скучно, неинтересно, и даже "бесполезно" > в том смысле, что он не готов к обсасыванию этой темы: то ли слишком > непривычно и оттого голова напрягается, то ли по ещё какой причине... > Товарищу хочется улучшать решение Y, и не хочется обсуждать альтернативы. > ну это весьма обычная история - ты пишешь "проблема" в список рассылки, и на нее как-то начинают реагировать. топик стартер пишет - до syslog не долетает. гарантированно подтверждено. после "гарантированно подтверждено" вопрос - ну ок, ты все подтвердил. какие вопросы могли остаться. на практике - нет, никто ничего не подтверждал. топик стартер ждет кого-то, кто скажет works for me. мне чисто по человечески любопытно, допустим, нашелся такой человек. ну ок, у него работает, у меня нет. и в чем профит того факта, что такой человек нашелся > > Ну, это его право. К его сожалению, аудитория тут попалась не очень-то > сочувствующая такому подходу, бывает. > > Но по сути дела изначальный вопрос был "почему пропадают записи в syslog?" > Причина, скорее всего, была в том, что syslogd не успевал их принимать. > Однако прямого доказательства этому так и не было предъявлено -- в виде > статистики возвратов EAGAIN от send() внутри nginx-a, или от мониторинга > величины очереди на unix-сокете, или хотя бы от измерения нагрузки на > процессор у syslogd. Хотя товарищ измерил чистую пропускную способность > syslogd, и получил значение выше проблемного, но это возможно и не даёт > ответа для неравномерного трафика. В итоге был переделан велосипед Y, и > ответ на изначальный вопрос перестал интересовать. Ну, тоже бывает. :) > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Sun Feb 11 23:15:53 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 12 Feb 2024 01:15:53 +0200 Subject: =?UTF-8?B?0JrQsNC6INC70YPRh9GI0LUg0LLRgdC10LPQviDRgdC00LXQu9Cw0YI=?= =?UTF-8?B?0Ywg0LfQsNGJ0LjRgtGDINC+0YIgZGVuaWFsIG9mIHNlcnZpY2Ug0L/RgNC4INC4?= =?UTF-8?B?0YHRh9C10YDQv9Cw0L3QuNC4INGB0LLQvtCx0L7QtNC90L7Qs9C+INC80LXRgdGC?= =?UTF-8?B?0LAg0L3QsCDQtNC40YHQutC1INCx0L7Qu9GM0YjQuNC80Lgg0L/QviDQvtCx0Yo=?= =?UTF-8?B?0LXQvNGDINC70L7Qsy3RhNCw0LnQu9Cw0LzQuCBuZ2lueD8=?= In-Reply-To: References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> Message-ID: On 11.02.2024 23:02, Evgeniy Berdnikov wrote: > Вполне возможно, что товарищ никого не обманывает, и ему действительно > обсуждать постановку задачи скучно, неинтересно, и даже "бесполезно" > в том смысле, что он не готов к обсасыванию этой темы: то ли слишком > непривычно и оттого голова напрягается, то ли по ещё какой причине... > Товарищу хочется улучшать решение Y, и не хочется обсуждать альтернативы. Из его собщения от 5 февраля однозначно следует, что он уже пытался настроить запись логов напрямую в файл но не смог получить рабочего решения при 200-250 тысячах подключений в секунду и необходимости делать ротацию лога каждые 30 секунд. И даже предлагает мне самому попробовать и убедиться, что это не работает и что таким образом запись и ротацию логов в файл самим nginx при такой большой нагрузке и при таком интервале ротации - настроить невозможно, потому что если делать ротацию через SIGHUP и не использовать директиву worker_shutdown_timeout - то через некоторое время будет очень много старых рабочих процесов, которые еще продолжают обрабатывать подключения - особенно, если используются вебсокеты, стриминг, или идет отдача каких-то больших по объему файлов. И в сервере просто закончится оперативная память и придет OOM killer или если есть своп - сервер начнет делать swapping с плавным переходом в thrashing и - переходом всех сайтов в состояние denial of service. И даже просит поделиться опытом и говорит, что будет рад меня выслушать. Но через несколько дней причины, по котороым он начал создавать костыли из syslog, unix socket`ов и скриптов на Python - уже резко изменились и теперь ему стало долго, скучно и неинтересно рассказывать о том, что но просто не внимательно читал документацию и не нашел там информации о практически мгновенном способе ротации логов, с помощью сигнала SUGUSR1, когда не будет всех тех проблем, что есть при 200-250 тысячах подключений в секунду и ротации лог-файлов раз в 30 секунд с использованием SIGHUP > Но по сути дела изначальный вопрос был "почему пропадают записи в syslog?" > Причина, скорее всего, была в том, что syslogd не успевал их принимать. Да, и Максим же это подтвердил и объяснил, что тогда происходит - тогда те запииси, которые syslog не смог не смог принять - nginx дропает и пишет об этом собщение в error.log - и данной ситуации это есть самое лучшее решение проблемы, потому что оде альтернативы еще хуже - первая альтернатива - это блокироваться на операции записи в syslog и ничего не делать, пока syslog не станет способен принимать сообщения от nginx, вторая альтернатива - это продолжать работу и накапливать сообщения в оперативной памяти, пока не придет Out Of Memory killerи не уничтожит процесс по kill -9. Теоретически - возможен еще вариант, создаватьна диске временный файл и временно хранить записи там, пока syslog не придет в себя и не начнет снова нормально принимать записи от nginx. Но в таком случае - если syslog просто лежит и не работает - этот временный файл может стать очень большим, даже использовав все свободное место на дике - так что это тоже не очень хороший вариант решения, да и добавляет лишней сложности. Лишней, потому что основная задача nginx - это не логи писать, а обрабатывать запросы от клиентов. Ротация логов делается с помощью программы logrotate, которая делает ротацию только по времени и никак не смотрит на количество свободного места на диске и на размер лог-файла. С помощью той программы logrotate, которая идет в составе дистрибутива - неочевидно, как настроить более быструю ротацию логов nginx, если они начинают занимать слишком много места на диске и когда свободного места на диске остается слишком мало. Хотя бы потому, что программа logrotate запускается раз в сутки и в таком случае dateformat будет иметь вид -%Y%m%d - год-месяц-день. И только если указывается параметр ротации hourly - только тогда формат будет -%Y%m%d%H - год-месяц-день-час. Директива dateext присутствует только в файле /etc/logrotate.conf но онаотсутствует в файле /etc/logrotate.d/nginx - в результате - получается такая ситуация, что если хочется сделать принудительную ротацию лог-файла с помощью команды # logrotate --force /etc/logrotate.d/nginx тогда access.log переименовывается в access.log.1 тем более, что access.log-20240211 уже существует на диске. и если в тот же день делать еще принудительную ротацию, прописав внутри файла /etc/logrotate.d/nginx директиву dateext - тогда тоже не будет ничего хорошего, потому что тогда будет ошибка: error: destination /var/log/nginx/access.log-20240211 already exists, skipping rotation error: destination /var/log/nginx/error.log-20240211 already exists, skipping rotation возможно было бы лучшим решением, если бы вместо сообщения про ошибку и отказа отротации логов в этой ситуации - когда файл с таким именем на диске уже есть - программа logrotate сама бы динамически изменяла бы строку dateformat добавляя в нее все новые и новые поля, до тех пор, пока конфликта не будет. Например, значение dateformat по умолчанию равно -%Y%m%d если конфликт имен и такой файл на диске уже существует - тогда добавить %H если и тогда есть конфликт, тогда добавить %M если и сейчас есть конфликт - тогда добавить %S и если и в такой ситуации будет конфликт - тогда подождать 0.5 секунды и снова повторить попытку. В таком случае - никогда не будет проблем с отказом от ротации логов, и принудительную ротацию # logrotate --force /etc/logrotate.d/nginx можно будет запускать как угодно часто, например, раз в час или даже раз в минуту, проверяя предварительно количество свободного места на диске или размер файла или по каким-то другим условиям. Или - встроить, например, lua прямо внутрь бинарника logrotate и расширенную логику принятия решения о том, надо делать ротацию или нет - задавать на lua. но это нереальный вариант. Проще будет наверное, по крону раз 5-10 минут запускать скрипт на Python, вся логика приятия решения о необходимости принудительной ротации будет запрограммирована на Python - это и проверка свободного места на диске и проверка размера лог-файла и все что угодно. И если ротация нужна - тогда этот скрипт просто вызывает logrotate и запрашивает принудительную ротацию. Скрипт может выглядеть примерно так: #!/usr/bin/python3 -u from invoke import run def need_nginx_logs_rotation(): # TODO необходимо ли делать ротацию? return False if need_nginx_logs_rotation(): run("logrotate --force /etc/logrotate.d/nginx") но чтобы это все работало нормально - необходимо, чтобы в https://github.com/logrotate/logrotate была добавлена логика такого динамически изменяемого значения директивы dateformat и после этого - чтобы в /etc/logrotate.d/nginx была добавлена строка dateext - тогда принудительная ротация лог-файлов nginx станет возможной. Для чего может быть нужна принудительная частая ротация лог-файлов? Чтобы система автоматически следила за тем, чтобы лог-файлы nginx не занимали очень много места на диске и автоматически удаляла бы более старые лог-файлы, оставляя в каталоге с логами только самые новые. Это может быть полезно в случае DDoS-атак, чтобы не не было таких неожиданных ситуаций, что место на сервере внезапно закончилось, и база данных MySQL прекратила работать, потому что логи nginx заняли все свободное место на диске, и тогда все пользователи сайта будут получать 5хх статус ошибки на свои запросы вместо содержимого сайта. А это, фактически, будет означать, что DDoS-атака достигла своей цели и для всех новых запросов клиентов действительно происходит отказ в обсуживании, denial-of-service. Но пока в бинарнике logrotate нет такой логики по динамическому изменению значения dateformat и пока нет в файле /etc/logrotate.d/nginx директивы dateext - такая простая и автоматически работающая защита от DDoS-атак с помощью скрипта на python - пока что невозможна. А никакой лучший вариант защиты от такого вида Denial-of-service attack я придумать пока что не могу. Разве что полностью на Python реализовывать всю эту логику и делать автоматическую ротацию логов только скриптом на Python. Более красивое решение - это внести изменения прямо в бинарник logrotate, чтобы dateformat изменялся динамически. Тогда - в 99.999% случаев он будет вида -%Y%m%d, в остальное время расширяясь только при необходимости. Или, как workaround - добавить в файл /etc/logrotate.d/nginx две строчки dateformat -%Y%m%d-%H%M%S dateext и за несколько минут написать в скрипте на Python необходимую логику ротации - по количеству свободного места на диске и т.п. тогда - для себя я смогу таким способом решить проблему защиты от DDoS-атак с помощью исчерпания места на диске логами nginx. или же я зря пытаюсь это автоматизировать и вместо автоматической защиты от исчерпания места на диске необходимо чтобы был настроен мониторинг и алерты, чтобы системный администратор мог бы проснуться среди ночи, зайти на сервер по ssh и вручную удалить старые лог-файлы, чтобы не было ситуации полного исчерпания свободного вместа и прекращения работы сайта вот не знаю, какой из этих трех вариантов будет лучше всего: 1) настроить автоматическую ротацию логов скриптом на Python, внеся необходимые изменения в logrotate, чтобы dateformat динамически изменялся при необходимости от -%Y%m%d до -%Y%m%d-%H%M%S и чтобы никогда не было ошибок при --force ротации логов. 2) добавить в /etc/logrotate.d/nginx две строчки: dateformat -%Y%m%d-%H%M%S dateext и написать за несколько минут скрипт на Python, который будет делать принудительную ротацию, когда остается мало свободного места на диске. для себя я эту проблему смогу решить, получив только визуально некоторое ухудшение ситуации, потому что логи nginx будут выглядеть не так красиво в тех случаях, когда принудительная ротация логов не нужна и суффикс в виде -%H%M%S будет просто избыточным в этих ситуациях. 3) не делать автоматической защиты от DDoS через исчерпание свободного места на диске - потому что идеологически правильно чтобы эту проблему вручную устранял системный администратор, потому что старые логи важны и нужны. Учитывая, что по умолчанию logrotate в системе запускается раз в сутки и по умолчанию dateformat расчитан только на daily и hourly ротацию - и вообще не рассчитан на автоматическую ротацию по причине исчерпания свободного места - это значит третий вариант есть самый правильный? потому что именно он по умочанию и реализован и настроен для nginx в операционной системе и в пакете nginx из официального репозитория? А значит никакой автоматической защиты от DDoS по причине исчерпания свободного места на диске быть не должно, а вместо этого должен быть настроен мониторинг и должно быть только ручное вмешательство системного администратора и ручное устранение им этой проблемы? Или я чего-то не понимаю? -- Best regards, Gena From bgx на protva.ru Mon Feb 12 09:53:52 2024 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Mon, 12 Feb 2024 12:53:52 +0300 Subject: =?utf-8?B?0JrQsNC6INC70YPRh9GI0LUg0LI=?= =?utf-8?B?0YHQtdCz0L4g0YHQtNC10LvQsNGC0Ywg0LfQsNGJ0LjRgtGDINC+0YIgZGVu?= =?utf-8?B?aWFsIG9mIHNlcnZpY2Ug0L/RgNC4INC40YHRh9C10YDQv9Cw0L3QuNC4INGB?= =?utf-8?B?0LLQvtCx0L7QtNC90L7Qs9C+INC80LXRgdGC0LAg0L3QsCDQtNC40YHQutC1?= =?utf-8?B?INCx0L7Qu9GM0YjQuNC80Lgg0L/QviDQvtCx0YrQtdC80YMg0LvQvtCzLdGE?= =?utf-8?B?0LDQudC70LDQvNC4?= nginx? In-Reply-To: References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> Message-ID: On Mon, Feb 12, 2024 at 01:15:53AM +0200, Gena Makhomed wrote: > Ротация логов делается с помощью программы logrotate, которая делает > ротацию только по времени и никак не смотрит на количество свободного места > на диске и на размер лог-файла. Насчёт размера файла утверждение неверное: в конфиге logrotate можно указать директиву "size", которая будет означать предельный размер лог-файла, по достижении которого запускается ротация. Другое дело, что риалтаймовского триггера на достижение предельного размера файла нет. А он мог бы быть в nginx-е, среди опций access_log и error_log. > # logrotate --force /etc/logrotate.d/nginx > > можно будет запускать как угодно часто, например, раз в час или даже раз в > минуту, проверяя предварительно количество свободного места на диске или > размер файла или по каким-то другим условиям. Проверять занятое место на партиции можно хоть раз в секунду и даже чаще. Но нет смысла чаще, чем интервал сброса файловых кэшей ядром. > Это может быть полезно в случае DDoS-атак, чтобы не не было > таких неожиданных ситуаций, что место на сервере внезапно закончилось, Для DoS-атак как раз и полезно разделение обязанностей между рабочим процессом сервиса и процессом-писателем логов. Я уже упоминал здесь сквидовский logfile-daemon, это один из вариантов, как можно обезопасить рабочий процесс от ступора. Но не самый эффективный, поскольку запись через пайп -- это значительное количество сисколов с обеих сторон, с копированием данных в ядро из писателя и обратно читателю. Гораздо эффективней сделать циклический буфер в разделяемой памяти, к которой подключаются два процесса/треда -- рабочий и писатель логов. Запись в такой буфер и чтение из него никаких сисколов не требует. Останется лишь минимизировать расходы на взаимные блокировки, которые, вероятно, также можно сделать без сисколов, если поискать специальные алгоритмы на этот счёт... В итоге получится быстрая запись и быстрое независимое чтение, причём если второе сдохнет или начнёт захлёбываться, писателя это не убьёт. Конечно, программирование всего этого -- немаленькая работа. А костыли в виде логов в оперативной памяти, logrotate и питоновских скриптов можно, конечно, нагородить. Но в современной ситуации, я думаю, проще сделать триггер, который по обнаружении катастрофической нехватки места для логов просто отключит логгирование в nginx-e. > 3) не делать автоматической защиты от DDoS через исчерпание свободного > места на диске - потому что идеологически правильно чтобы эту проблему > вручную устранял системный администратор, потому что старые логи важны > и нужны. Работоспособность web-сервиса, как правило, намного важнее логгирования. -- Eugene Berdnikov From anatoliy.melnik на showjet.ru Mon Feb 12 10:30:58 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Mon, 12 Feb 2024 13:30:58 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <1061322487.6242660.1707733858678.JavaMail.zimbra@showjet.ru> И снова здравствуйте. Тут прям уже прям целое расследование: Что я сказал, что хотел сказать, где и сколько соврал... "Без меня меня женили"... Читается как детективная история :) Коль пошла такая дискуссия: " [ https://forum.nginx.org/read.php?21,298858,299091#msg-299091 | Как лучше всего сделать защиту от denial of service при исчерпании свободного места на диске большими по объему лог-файлами nginx? ] " Насколько понимаю, вы решили, что это одна из решаемых проблем. Итак Цитата: Из его собщения от 5 февраля однозначно следует, что он уже пытался настроить запись логов напрямую в файл но не смог получить рабочего решения при 200-250 тысячах подключений в секунду и необходимости делать ротацию лога каждые 30 секунд. И даже предлагает мне самому попробовать и убедиться, что это не работает и что таким образом запись и ротацию логов в файл самим nginx при такой большой нагрузке и при таком интервале ротации - настроить невозможно, Я предлагал попробовать и поделиться, лично я попробовал, получил результат -- пишет, работает, возможно. И сделал это ДО того, как сюда обратился... НО меня сей результат не удовлетворил. Да, да (понимаю) -- чем он меня "не удовлетворил"?? --- можете фантазировать сколько угодно. Единственное пожелание -- при озвучивании фантазий оставаться в рамках корректного изложения. Возможно и оттуда я почерпну что-то для себя новое и полезное. Цитата: Ротация логов делается с помощью программы logrotate, которая делает ротацию только по времени и никак не смотрит на количество свободного места на диске и на размер лог-файла. С помощью той программы logrotate, которая идет в составе дистрибутива - неочевидно, как настроить более быструю ротацию логов nginx, если они начинают занимать слишком много места на диске и когда свободного места на диске остается слишком мало. Отлично, 1. logrotate - не единственный вариант. 2. logrotate -- УМЕЕТ смотреть на размер. 3. настроить более быструю ротацию вообще штука очевидная, скорее всего, для большинства man logrotate Description Normally, logrotate is run as a daily cron job. т.е. работает через cron... Т.е. все, что умеет крон достижимо в ротации через logrotate .... (или я слишком оптимистичен в разрезе "для большинства"??) Задача по предотвращению исчерпания места на диске так же была решена задолго ДО обращения сюда. Следуем дальше: мне чисто по человечески любопытно, допустим, нашелся такой человек. ну ок, у него работает, у меня нет. и в чем профит того факта, что такой человек нашелся Знание о том, что проблема разрешима, дает довольно много. "Дайте мне точку опоры, и я переверну Землю" (кажется Архимед) Вот эту "точку опоры" я в некотором роде и искал :) Собственно, как и в большинстве случаев, нашел не то, что искал. Но найденное НЕ разочаровало. Со знающими людьми пообщался как минимум. Что у нас еще обнаружилось: Снисходительность, ирония, сарказм... (возможно я самонадеян и не так понял некоторые моменты в комментариях? буду рад, если это действительно так) Возникает впечатление, что кому-то из вас принципиально важно доказать незыблемую правоту своего мнения и ошибочность моих действий. Вопрос - зачем? Это не конкурс или состязание, я сюда обратился за советом. Не за поддержкой или осуждением, сочувствием, порицанием или одобрением и т.д. Помощь я получил. Не в том виде, в котором ожидал. Но поверьте - оценил и благодарен ЗА ПОМОЩЬ. Конкретный ответ на поставленный в самом начале вопрос, как правильно заметили выше, потерял актуальность. Какая разница насколько глубокое ущелье на моем пути, если я уже построил через него мост? Может он не самый красивый, вечный, грузоподъемный и уникальный... Для моих целей его достаточно :) Возможно, по мнению кого-то, я вообще иду "не туда"! И? Вы свои аргументы привели, мое мнение они не изменили... Или для некоторых "есть только два мнения: моё и неправильное"? Всем дочитавшим - благодарность за терпение. Предлагаю на сем финишировать. Или я чего-то не понимаю? ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Feb 13 02:21:20 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 13 Feb 2024 04:21:20 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQu9GD0YfRiNC1INCy0YHQtdCz0L4g0YHQtNC10Ls=?= =?UTF-8?B?0LDRgtGMINC30LDRidC40YLRgyDQvtGCIGRlbmlhbCBvZiBzZXJ2aWNlINC/0YA=?= =?UTF-8?B?0Lgg0LjRgdGH0LXRgNC/0LDQvdC40Lgg0YHQstC+0LHQvtC00L3QvtCz0L4g0Lw=?= =?UTF-8?B?0LXRgdGC0LAg0L3QsCDQtNC40YHQutC1INCx0L7Qu9GM0YjQuNC80Lgg0L/QviA=?= =?UTF-8?B?0L7QsdGK0LXQvNGDINC70L7Qsy3RhNCw0LnQu9Cw0LzQuCBuZ2lueD8=?= In-Reply-To: References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> Message-ID: <113e49fd-5f1e-43f2-b6d8-53d8de76838e@csdoc.com> On 12.02.2024 11:53, Evgeniy Berdnikov wrote: >> Ротация логов делается с помощью программы logrotate, которая делает >> ротацию только по времени и никак не смотрит на количество свободного >> места на диске и на размер лог-файла. > > Насчёт размера файла утверждение неверное: в конфиге logrotate можно > указать директиву "size", которая будет означать предельный размер > лог-файла, по достижении которого запускается ротация. Другое дело, что > риалтаймовского триггера на достижение предельного размера файла нет. > А он мог бы быть в nginx-е, среди опций access_log и error_log. Я немного не точно выразился. Интересует запуск ротации логов не по размеру одного какого-то лог-файла, а по суммарному размеру всего каталога /var/log/nginx/ Потому что даже если выставить лимит size 1G на один лог-файл - не всегда понятно, сколько именно места на диске будет занимать каталог /var/log/nginx/ rotate 52 задает количество ротаций только одного одного файла. А размер каталога /var/log/nginx/ зависит от того, сколько там будет лог-файлов - всего два, access.log и error.log или несколько сотен, или несколько тысяч. Вообще, в идеале - хотелось бы иметь возможность и значение rotate не статически задавать в конфиге, а делать динамически вычисляемым, по определенной формуле, в зависимости от размера каталога /var/log/nginx/ и/или количества свободного места на диске и других параметров. Наверное, самый оптимальный вариант решения всех этих проблем - это сделать демона logrotated, который будет следить за количеством занятого и/или свободного места на разделе /var и в результате - если необходимо делать принудительную ротацию логов, - будет сам генерировать временный файл конфигурации, например, /run/logrotated/nginx-logrotate.conf и потом уже запускать утилиту /usr/sbin/logrotate для выполнения работы по ротации логов, примерно так: /usr/sbin/logrotate --force /run/logrotated/nginx-logrotate.conf то есть, когда DDoS-атак нет - тогда демон logrotated просто висит в фоне, время от времени проверяя состояние и ничего не делает, потому что ни один триггер не срабатывает. И тогда всю работу по ротации логов nginx делает сама программа logrotate, запускаемая по крону раз в сутки. А когда происходит DDoS-атака, тогда logrotated обнаруживает чрезмерное использование места на диске логами nginx и начинает делать принудительную ротацию логов, не допуская исчерпания свободного места на диске DDoS-атакой и наступления ситуации отказа в обслуживании. >> Это может быть полезно в случае DDoS-атак, чтобы не не было >> таких неожиданных ситуаций, что место на сервере внезапно закончилось > Для DoS-атак как раз и полезно разделение обязанностей между рабочим > процессом сервиса и процессом-писателем логов. Та система, которая есть сейчас - она близка к идеальной, когда каждая утилита делает только свою работу, но делает ее очень хорошо - nginx только обрабатывает запосы клиентов, а logrotate - занимается только задачей ротации логов. > Я уже упоминал здесь > сквидовский logfile-daemon, это один из вариантов, как можно обезопасить > рабочий процесс от ступора. У nginx нет ступора рабочих процессов том случае, когда закончилось свободное место на диске. Он даже дополнительно делает паузу в одну секунду, чтобы на FreeBSD все не тормозило, когда нет свободного места на диске. То есть, со стороны nginx - вообще никаких проблем. https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_log_module.c#L288 Проблемы начинаются у остального софта, например, MySQL прекращает нормально работать, потому что ничего не может записать в базу данных, когда на диске 0 байт свободного места и php-fpm начинает возвращать 5xx статус - то есть, в результате и получается denial of service. > А костыли в виде логов в оперативной памяти, logrotate и питоновских > скриптов можно, конечно, нагородить. Но в современной ситуации, я думаю, > проще сделать триггер, который по обнаружении катастрофической нехватки > места для логов просто отключит логгирование в nginx-e. Когда свободного места на диске нет - то nginx туда, естественно, ничего и не пишет, когда свободное место появляется - процесс записи логов автоматически продолжается, тут ничего настраивать не нужно. Единственная проблема которая есть в такой сиутации - перестают работать POST-запросы, если в каталоге client_body_temp_path ноль байт свободного места, но все остальные типы запросов в такой ситуации nginx продолжает нормально обрабатывать. И теряется возможность записи информации в логи. Все остальное - вроде бы работает нормально, когда 0 байт свободного места на диске - но я очень детально это не проверял. >> не делать автоматической защиты от DDoS через исчерпание свободного >> места на диске - потому что идеологически правильно чтобы эту проблему >> вручную устранял системный администратор, потому что старые логи важны >> и нужны. > Работоспособность web-сервиса, как правило, намного важнее логгирования. Тогда почему в операционной системе logrotate запускается по крону только раз в сутки и там нет вообще никакой защиты на этом уровне от исчерпания свободного места на диске? Это просто никому не нужно или же причина в том, что неправильно чтобы система автоматически поддерживала себя в рабочем состоянии и не переходила в состояние denial of service когда на какой-то сайт приходит DDoS-атака? Не могу понять причину, почему не существует демона logrotated, ведь если бы это было нужно не только мне, а и кому-то еще - его бы уже давным-давно кто-то другой придумал бы и написал, и такой демон был бы или в отдельном пакете или даже в составе logrotate в составе каждого дистрибутива Linux. -- Best regards, Gena From gmm на csdoc.com Tue Feb 13 03:31:44 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 13 Feb 2024 05:31:44 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <1061322487.6242660.1707733858678.JavaMail.zimbra@showjet.ru> References: <1061322487.6242660.1707733858678.JavaMail.zimbra@showjet.ru> Message-ID: <9daa99b0-2163-4c64-b4d5-c061d3b1fa8a@csdoc.com> On 12.02.2024 12:30, Anatoliy Melnik via nginx-ru wrote: > Из его собщения от 5 февраля однозначно следует, что он > уже пытался настроить запись логов напрямую в файл но не смог > получить рабочего решения при 200-250 тысячах подключений в секунду > и необходимости делать ротацию лога каждые 30 секунд. И даже предлагает > мне самому попробовать и убедиться, что это не работает и что таким > образом запись и ротацию логов в файл самим nginx при такой большой > нагрузке и при таком интервале ротации - настроить невозможно, > Я предлагал попробовать и поделиться, лично я попробовал, получил результат -- пишет, работает, возможно. И сделал это ДО того, как сюда обратился... > НО меня сей результат не удовлетворил. Так и расскажите, почему не удовлетворил, поделитесь опытом с участниками и читателями этого списка рассылки. Тем более, что здесь присутствуют и разрабочики nginx, так что если проблема в коде nginx действителько существует - эту проблему в коде исправят. Насколько мне известно, переоткрытие лог-файлов по сигналу USR1 происходит практически мгновенно и не требует перезапуска рабочих процессов nginx, поэтому - не может приводить ни к каким проблемам на любом количестве соединений при ротации лог-файлов nginx раз в 30 секунд. Тем более, что директива access_log позволяет настроить процесс записи логов наиболее оптимальным способом, ключив буферизацию, и при необходимости - компрессию логов на лету. access_log path [buffer=size] [gzip[=level] [flush=time] Поэтому - я просто не понимаю, какие у Вас могли там возникнуть проблемы, если делать ротацию логов nginx раз в 30 секунд на любом количестве подключений - от количества подключений это вообще никак не зависит, потому что новые рабочие процессы nginx при этом не создаются и страрые рабочие процессы nginx не завершаются. кстати, и logrotate делает ротацию логов nginx таким же способом: # cat /etc/logrotate.d/nginx if [ -f /var/run/nginx.pid ]; then kill -USR1 `cat /var/run/nginx.pid` fi > Да, да (понимаю) -- чем он меня "не удовлетворил"?? > --- можете фантазировать сколько угодно. Могу, но не хочу. Поэтому и прошу Вас чтобы Вы сами рассказали всем здесь присутствующим о том, какие проблемы Вы обнаружили при ротации логов с помощью сигнала USR1. Я здесь не вижу вообще никаких проблем. > Задача по предотвращению исчерпания места на диске так же была решена задолго ДО обращения сюда. Поделитесь своим опытом решения этой задачи. Потому что я пока что не смог найти решения. > Возникает впечатление, что кому-то из вас принципиально важно доказать незыблемую правоту своего мнения и ошибочность моих действий. > Вопрос - зачем? Я уже отвечал на этот Ваш вопрос. Этот список рассылки - он посвящен nginx, а не процессу самоутверждения. И если кто-то начинает ради самоутверждения распространять ложную информацию про nginx, например, что nginx не способен самостоятельно писать логи в файлы при количестве подключений 200-250 тысяч в секунду и ротации лог-файлов раз в 30 секунду и что решением этой проблемы является набор костылей в виде syslog, unix socket, и десяти одновременно запущеных копий скрипта на Python - то это FUD и это вредит не только конкретно тому человеку, который это делает, но и всему nginx community, то есть всем участниками и читателям списка рассылки, потому что часть неопытных пользователей nginx может в этот FUD поверить и считать эту Вашу информацию истинной. FUD - это https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt https://ru.wikipedia.org/wiki/FUD > Это не конкурс или состязание, я сюда обратился за советом. Так я тоже обратился к Вам за советом - пожалуйста, поделитесь опытом, и расскажите, какие проблемы Вы обнаружили при ротации логов nginx с помощью сигнала USR1 что были вынуждены отказаться от этого варианта работы и логами и были вынуждены в результате соорудить то, что Вы назвали решением этой проблемы - в виде syslog, unix socket и скрипта на Python запускемого в 10 экземплярах и пишущего логи в 10 отдельных файлов. Решением какой именно _проблемы_ является эта конструкция, которую Вы называете в своих сообщениях решением проблемы? > Какая разница насколько глубокое ущелье на моем пути, если я уже построил через него мост? > Может он не самый красивый, вечный, грузоподъемный и уникальный... > Для моих целей его достаточно :) > Возможно, по мнению кого-то, я вообще иду "не туда"! Дело тут не только и не столько в https://xkcd.ru/386/ потому что идя не туда, Вы еще этот способ идти не туда и рекламируете как _решение проблемы_, чем делаете FUD, хотя лично Вам этот веб-сервер ничего плохого не сделал. > И? Вы свои аргументы привели, мое мнение они не изменили... > Или для некоторых "есть только два мнения: моё и неправильное"? Поделитесь своим опытом, расскажите, почему эта конструкция из syslog, unix socket и десяти скриптов на python, пишущих сообщения в десять лог-файлов оказалась для Вас лучше, чем встроенные в nginx возможности для записи и ротации логов? > Или я чего-то не понимаю? «Ничего личного, только бизнес». Источник: https://uchet-jkh.ru/i/nicego-licnogo-tolko-biznes-otkuda-fraza -- Best regards, Gena From gmm на csdoc.com Tue Feb 13 04:43:53 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 13 Feb 2024 06:43:53 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQu9GD0YfRiNC1INCy0YHQtdCz0L4g0YHQtNC10Ls=?= =?UTF-8?B?0LDRgtGMINC30LDRidC40YLRgyDQvtGCIGRlbmlhbCBvZiBzZXJ2aWNlINC/0YA=?= =?UTF-8?B?0Lgg0LjRgdGH0LXRgNC/0LDQvdC40Lgg0YHQstC+0LHQvtC00L3QvtCz0L4g0Lw=?= =?UTF-8?B?0LXRgdGC0LAg0L3QsCDQtNC40YHQutC1INCx0L7Qu9GM0YjQuNC80Lgg0L/QviA=?= =?UTF-8?B?0L7QsdGK0LXQvNGDINC70L7Qsy3RhNCw0LnQu9Cw0LzQuCBuZ2lueD8=?= In-Reply-To: <113e49fd-5f1e-43f2-b6d8-53d8de76838e@csdoc.com> References: <913919824.135873639.1707478420078.JavaMail.zimbra@showjet.ru> <2380af91-02e6-4aa6-910f-8c457a885885@csdoc.com> <113e49fd-5f1e-43f2-b6d8-53d8de76838e@csdoc.com> Message-ID: On 13.02.2024 4:21, Gena Makhomed wrote: > Когда свободного места на диске нет - то nginx туда, естественно, > ничего и не пишет, когда свободное место появляется - процесс записи > логов автоматически продолжается, тут ничего настраивать не нужно. > > Единственная проблема которая есть в такой сиутации - перестают работать > POST-запросы, если в каталоге client_body_temp_path ноль байт свободного > места, но все остальные типы запросов в такой ситуации nginx продолжает > нормально обрабатывать. И теряется возможность записи информации в логи. > > Все остальное - вроде бы работает нормально, когда 0 байт > свободного места на диске - но я очень детально это не проверял. Не знаю, насколько часто встречается такая проблема в дикой природе, но если возникает ошибка записи во время записи client_body в файл в client_body_temp_path - теоретически - можно было бы прочитать, то что успели уже записать в файл, отправить на backend и на какое-то время - переключить режим работы директив fastcgi_request_buffering proxy_request_buffering scgi_request_buffering uwsgi_request_buffering временно из текущего режима работы (on?) в режим работы off, например, на 1 минуту, и если через 1 минуту на разделе куда указывает директива client_body_temp_path появится достаточное количество свободного места, например, N * client_max_body_size при каком-то разумном значении N - тогда вернуть обратное старое значение, какое было для этих директив до момента переключения в такой режим работы. Кстати, что интересно, для модуля grpc в коде установлено r->request_body_no_buffering = 1; поэтому проксирование grpc запросов всегда будет нормально работать, даже в том случае, когда на диске будет 0 байт свободного места. Или - не имеет смысл настолько усложнять код nginx? Потому что в таком случае - если не настроен мониторинг свободного места на сервере - тогда системный администратор узнает об этой проблеме по жалобам, что POST запросы на сайте перестали нормально работать и на backend приходит 0 байт вместо того, что отправлял клиент. А если сделать так, чтобы nginx не терял тело запроса и корректно отправлял бы запросы на backend - то в такой ситуации системный администратор может еще очень долго ничего не знать о проблеме? Вот какое решение в этой ситуации было бы лучшим вариантом для пользователей коммерческой версии nginx-plus и для пользователей бесплатной версии nginx? Ведь если nginx теряет тело запроса - тогда могут сказать, что причина проблемы - это именно nginx, почему сайтом были утеряны ценные данные в POST-запросах клиентов. А если nginx сможет нормально функционировать и POST-запросы смогут нормально функционировать, не смотря на то. что на диске 0 байт свободного места - это может быть расценено как признак высокой надежности nginx и как признак высокого уровня качества кода. Как будет лучше поступить в ситуации нехватки свободного места на диске? -- Best regards, Gena From anatoliy.melnik на showjet.ru Tue Feb 13 09:38:13 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Tue, 13 Feb 2024 12:38:13 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <1592871877.9501809.1707817093382.JavaMail.zimbra@showjet.ru> Gena Makhomed Wrote: ------------------------------------------------------- > On 12.02.2024 12:30, Anatoliy Melnik via nginx-ru wrote: > > > Из его собщения от 5 февраля однозначно следует, что он > > уже пытался настроить запись логов напрямую в файл но не смог > > получить рабочего решения при 200-250 тысячах подключений в секунду > > и необходимости делать ротацию лога каждые 30 секунд. И даже > предлагает > > мне самому попробовать и убедиться, что это не работает и что таким > > образом запись и ротацию логов в файл самим nginx при такой большой > > нагрузке и при таком интервале ротации - настроить невозможно, > > > Я предлагал попробовать и поделиться, лично я попробовал, получил > результат -- пишет, работает, возможно. И сделал это ДО того, как сюда > обратился... > > НО меня сей результат не удовлетворил. > > Так и расскажите, почему не удовлетворил, поделитесь опытом > с участниками и читателями этого списка рассылки. Тем более, > что здесь присутствуют и разрабочики nginx, так что если проблема > в коде nginx действителько существует - эту проблему в коде исправят. > > Насколько мне известно, переоткрытие лог-файлов по сигналу USR1 > происходит практически мгновенно и не требует перезапуска > рабочих процессов nginx, поэтому - не может приводить ни к каким > проблемам на любом количестве соединений при ротации лог-файлов > nginx раз в 30 секунд. > > Тем более, что директива access_log позволяет настроить > процесс записи логов наиболее оптимальным способом, ключив > буферизацию, и при необходимости - компрессию логов на лету. > > access_log path [buffer=size] [gzip[=level] [flush=time] > > Поэтому - я просто не понимаю, какие у Вас могли там возникнуть > проблемы, если делать ротацию логов nginx раз в 30 секунд на любом > количестве подключений - от количества подключений это вообще никак > не зависит, потому что новые рабочие процессы nginx при этом > не создаются и страрые рабочие процессы nginx не завершаются. > > кстати, и logrotate делает ротацию логов nginx таким же способом: > > # cat /etc/logrotate.d/nginx > > if [ -f /var/run/nginx.pid ]; then > kill -USR1 `cat /var/run/nginx.pid` > fi > > Для меня логи не цель, а средство. Источник для необходимых статистических данных. Чем не удовлетворил результат - смотрите чуть дальше. > > Да, да (понимаю) -- чем он меня "не удовлетворил"?? > > --- можете фантазировать сколько угодно. > > Могу, но не хочу. Поэтому и прошу Вас чтобы Вы сами рассказали всем > здесь присутствующим о том, какие проблемы Вы обнаружили при ротации > логов с помощью сигнала USR1. Я здесь не вижу вообще никаких проблем. > > > Задача по предотвращению исчерпания места на диске так же была > решена задолго ДО обращения сюда. > > Поделитесь своим опытом решения этой задачи. > Потому что я пока что не смог найти решения. > Мы с вами решаем задачи при разных исходных условиях и разных конечных целях. Еще и с разными ресурсами. Для меня главный вопрос, на который надо дать ответ: ЗАЧЕМ я пишу логи? ЧТО я дальше с ними буду делать? > > Возникает впечатление, что кому-то из вас принципиально важно > доказать незыблемую правоту своего мнения и ошибочность моих > действий. > > Вопрос - зачем? > > Я уже отвечал на этот Ваш вопрос. > > Этот список рассылки - он посвящен nginx, а не процессу > самоутверждения. > И если кто-то начинает ради самоутверждения распространять ложную > информацию про nginx, например, что nginx не способен самостоятельно > писать логи в файлы при количестве подключений 200-250 тысяч в > секунду > и ротации лог-файлов раз в 30 секунду и что решением этой проблемы > является набор костылей в виде syslog, unix socket, и десяти > одновременно запущеных копий скрипта на Python - то это FUD > и это вредит не только конкретно тому человеку, который это > делает, но и всему nginx community, то есть всем участниками > и читателям списка рассылки, потому что часть неопытных пользователей > nginx может в этот FUD поверить и считать эту Вашу информацию > истинной. > > FUD - это > https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt > https://ru.wikipedia.org/wiki/FUD > > > Это не конкурс или состязание, я сюда обратился за советом. > > Так я тоже обратился к Вам за советом - пожалуйста, поделитесь > опытом, > и расскажите, какие проблемы Вы обнаружили при ротации логов nginx > с помощью сигнала USR1 что были вынуждены отказаться от этого > варианта > работы и логами и были вынуждены в результате соорудить то, > что Вы назвали решением этой проблемы - в виде syslog, unix socket и > скрипта на Python запускемого в 10 экземплярах и пишущего логи в 10 > отдельных файлов. > > Решением какой именно _проблемы_ является эта конструкция, > которую Вы называете в своих сообщениях решением проблемы? > > > Какая разница насколько глубокое ущелье на моем пути, если я уже > построил через него мост? > > Может он не самый красивый, вечный, грузоподъемный и уникальный... > > Для моих целей его достаточно :) > > Возможно, по мнению кого-то, я вообще иду "не туда"! > > Дело тут не только и не столько в https://xkcd.ru/386/ > потому что идя не туда, Вы еще этот способ идти не туда > и рекламируете как _решение проблемы_, чем делаете FUD, > хотя лично Вам этот веб-сервер ничего плохого не сделал. > > > И? Вы свои аргументы привели, мое мнение они не изменили... > > Или для некоторых "есть только два мнения: моё и неправильное"? > > Поделитесь своим опытом, расскажите, почему эта конструкция > из syslog, unix socket и десяти скриптов на python, пишущих > сообщения в десять лог-файлов оказалась для Вас лучше, > чем встроенные в nginx возможности для записи и ротации логов? > Повторюсь: Логи - не цель, а всего лишь средство. Скрипт один, с модулем multiprocessing, так что экземпляров получается 11, но это не важно. Запись в файлы были лишь эпизодом для выяснения ограничений связки nginx->(unixSocket)->syslog Сейчас я вообще не пишу эти файлы, но при необходимости могу это начать делать так же на лету, не дергая ни nginx, ни сам сервис "типа персональный nginx-овый сислог". Все данные извлекаются в скрипте "на лету" и отображаются в соответствующих счетчиках. При необходимости сосчитать что-то другое/новое или по другом алгоритму - я всего лишь изменю несколько строк скрипта. На данном этапе проверенная производительность одной системы 240тыс/сек, прогноз исходя из статистики нагрузки - 400-420. Запись горы сообщений напрямую в файл из nginx-а работает, файлы ротируются, но мне это никак не помогает в решении поставленной задачи. Поэтому и "не удовлетворил". Собственно как следствие -- отсутствие проблемы доступного дискового пространства. Нагрузка на дисковую подсистему близка к нулю. И я с самого начала не говорил, что мне нужны файлы! Меня интересовала связка nginx->(unixSocket)->syslog. Именно эту проблему я и озвучил. Можно сослаться на мои посты: "Сами файлы логов живут максимум 15-20 минут, этого достаточно для извлечения необходимых данных." "Производительности хранилища точно достаточно для 150тыс/сек (один из способов замера -- запуск одновременно 3-х экземпляров rsyslog на одном физическом сервере и заливка в 3 сразу тестового набора в 12млн сообщений на каждый, итог 300-450тыс/сек в совокупности, непрерывно в течении нескольких часов заливка-ротация-удаление)" "Данные почти равномерно расходятся по 10-ти файлам, которые пишутся на tmpfs в RAM. " Это были лишь промежуточные этапы, мне нужно было убедиться, что проблема именно на этапе nginx->(unixSocket)->syslog. И запись в файл на очень быстрый носитель был, наверное, самый прямой путь, дающий адекватные результаты. Свою функцию этот этап выполнил, но повторюсь - это не было целью! И на каждом этапе обсуждения мне казалось очевидным: мне нужна рабочая связка nginx->(unixSocket)->syslog !!! Вот даже не знаю зачем тут все это излагаю... Уже непререкаемая уверенность в собственной непогрешимости в некоторых постах должна была меня насторожить. А уж выводы типа: > И если кто-то начинает ради самоутверждения распространять ложную > информацию про nginx, например, что nginx не способен самостоятельно > писать логи в файлы при количестве подключений 200-250 тысяч в > секунду... Буквально апогей!!!! Выршина дедукции!!! Шерлок Холмс не у вас, случайно, учился?? Чего уж там - давайте и углеродный след приплетем (нынче это модно). > > Или я чего-то не понимаю? > > «Ничего личного, только бизнес». Никогда не понимал восторгов этим правилом. Из личного опыта -- стараюсь не иметь дел с адептами этого подхода, и это сугубо личное. > > Источник: > https://uchet-jkh.ru/i/nicego-licnogo-tolko-biznes-otkuda-fraza > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > [ https://mailman.nginx.org/mailman/listinfo/nginx-ru | https://mailman.nginx.org/mailman/listinfo/nginx-ru ] Best regards..... to be continued ??? ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Feb 13 11:07:24 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 13 Feb 2024 12:07:24 +0100 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC9?= =?UTF-8?B?0LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <1592871877.9501809.1707817093382.JavaMail.zimbra@showjet.ru> References: <1592871877.9501809.1707817093382.JavaMail.zimbra@showjet.ru> Message-ID: вт, 13 февр. 2024 г. в 10:38, Anatoliy Melnik via nginx-ru < nginx-ru на nginx.org>: > Gena Makhomed Wrote: > ------------------------------------------------------- > > On 12.02.2024 12:30, Anatoliy Melnik via nginx-ru wrote: > > > > > Из его собщения от 5 февраля однозначно следует, что он > > > уже пытался настроить запись логов напрямую в файл но не смог > > > получить рабочего решения при 200-250 тысячах подключений в секунду > > > и необходимости делать ротацию лога каждые 30 секунд. И даже > > предлагает > > > мне самому попробовать и убедиться, что это не работает и что таким > > > образом запись и ротацию логов в файл самим nginx при такой большой > > > нагрузке и при таком интервале ротации - настроить невозможно, > > > > > Я предлагал попробовать и поделиться, лично я попробовал, получил > > результат -- пишет, работает, возможно. И сделал это ДО того, как сюда > > обратился... > > > НО меня сей результат не удовлетворил. > > > > Так и расскажите, почему не удовлетворил, поделитесь опытом > > с участниками и читателями этого списка рассылки. Тем более, > > что здесь присутствуют и разрабочики nginx, так что если проблема > > в коде nginx действителько существует - эту проблему в коде исправят. > > > > Насколько мне известно, переоткрытие лог-файлов по сигналу USR1 > > происходит практически мгновенно и не требует перезапуска > > рабочих процессов nginx, поэтому - не может приводить ни к каким > > проблемам на любом количестве соединений при ротации лог-файлов > > nginx раз в 30 секунд. > > > > Тем более, что директива access_log позволяет настроить > > процесс записи логов наиболее оптимальным способом, ключив > > буферизацию, и при необходимости - компрессию логов на лету. > > > > access_log path [buffer=size] [gzip[=level] [flush=time] > > > > Поэтому - я просто не понимаю, какие у Вас могли там возникнуть > > проблемы, если делать ротацию логов nginx раз в 30 секунд на любом > > количестве подключений - от количества подключений это вообще никак > > не зависит, потому что новые рабочие процессы nginx при этом > > не создаются и страрые рабочие процессы nginx не завершаются. > > > > кстати, и logrotate делает ротацию логов nginx таким же способом: > > > > # cat /etc/logrotate.d/nginx > > > > if [ -f /var/run/nginx.pid ]; then > > kill -USR1 `cat /var/run/nginx.pid` > > fi > > > > > > Для меня логи не цель, а средство. > Источник для необходимых статистических данных. > Чем не удовлетворил результат - смотрите чуть дальше. > > > > Да, да (понимаю) -- чем он меня "не удовлетворил"?? > > > --- можете фантазировать сколько угодно. > > > > Могу, но не хочу. Поэтому и прошу Вас чтобы Вы сами рассказали всем > > здесь присутствующим о том, какие проблемы Вы обнаружили при ротации > > логов с помощью сигнала USR1. Я здесь не вижу вообще никаких проблем. > > > > > Задача по предотвращению исчерпания места на диске так же была > > решена задолго ДО обращения сюда. > > > > Поделитесь своим опытом решения этой задачи. > > Потому что я пока что не смог найти решения. > > > > Мы с вами решаем задачи при разных исходных условиях и разных конечных > целях. > Еще и с разными ресурсами. > Для меня главный вопрос, на который надо дать ответ: > ЗАЧЕМ я пишу логи? ЧТО я дальше с ними буду делать? > > > > > Возникает впечатление, что кому-то из вас принципиально важно > > доказать незыблемую правоту своего мнения и ошибочность моих > > действий. > > > Вопрос - зачем? > > > > Я уже отвечал на этот Ваш вопрос. > > > > Этот список рассылки - он посвящен nginx, а не процессу > > самоутверждения. > > И если кто-то начинает ради самоутверждения распространять ложную > > информацию про nginx, например, что nginx не способен самостоятельно > > писать логи в файлы при количестве подключений 200-250 тысяч в > > секунду > > и ротации лог-файлов раз в 30 секунду и что решением этой проблемы > > является набор костылей в виде syslog, unix socket, и десяти > > одновременно запущеных копий скрипта на Python - то это FUD > > и это вредит не только конкретно тому человеку, который это > > делает, но и всему nginx community, то есть всем участниками > > и читателям списка рассылки, потому что часть неопытных пользователей > > nginx может в этот FUD поверить и считать эту Вашу информацию > > истинной. > > > > FUD - это > > https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt > > https://ru.wikipedia.org/wiki/FUD > > > > > Это не конкурс или состязание, я сюда обратился за советом. > > > > Так я тоже обратился к Вам за советом - пожалуйста, поделитесь > > опытом, > > и расскажите, какие проблемы Вы обнаружили при ротации логов nginx > > с помощью сигнала USR1 что были вынуждены отказаться от этого > > варианта > > работы и логами и были вынуждены в результате соорудить то, > > что Вы назвали решением этой проблемы - в виде syslog, unix socket и > > скрипта на Python запускемого в 10 экземплярах и пишущего логи в 10 > > отдельных файлов. > > > > Решением какой именно _проблемы_ является эта конструкция, > > которую Вы называете в своих сообщениях решением проблемы? > > > > > Какая разница насколько глубокое ущелье на моем пути, если я уже > > построил через него мост? > > > Может он не самый красивый, вечный, грузоподъемный и уникальный... > > > Для моих целей его достаточно :) > > > Возможно, по мнению кого-то, я вообще иду "не туда"! > > > > Дело тут не только и не столько в https://xkcd.ru/386/ > > потому что идя не туда, Вы еще этот способ идти не туда > > и рекламируете как _решение проблемы_, чем делаете FUD, > > хотя лично Вам этот веб-сервер ничего плохого не сделал. > > > > > И? Вы свои аргументы привели, мое мнение они не изменили... > > > Или для некоторых "есть только два мнения: моё и неправильное"? > > > > Поделитесь своим опытом, расскажите, почему эта конструкция > > из syslog, unix socket и десяти скриптов на python, пишущих > > сообщения в десять лог-файлов оказалась для Вас лучше, > > чем встроенные в nginx возможности для записи и ротации логов? > > > Повторюсь: > Логи - не цель, а всего лишь средство. > > Скрипт один, с модулем multiprocessing, так что экземпляров получается 11, > но это не важно. > Запись в файлы были лишь эпизодом для выяснения ограничений связки > nginx->(unixSocket)->syslog > Сейчас я вообще не пишу эти файлы, но при необходимости могу это начать > делать так же на лету, не дергая ни nginx, ни сам сервис "типа персональный > nginx-овый сислог". > > Все данные извлекаются в скрипте "на лету" и отображаются в > соответствующих счетчиках. > > При необходимости сосчитать что-то другое/новое или по другом алгоритму - > я всего лишь изменю несколько строк скрипта. > На данном этапе проверенная производительность одной системы 240тыс/сек, > прогноз исходя из статистики нагрузки - 400-420. > > Запись горы сообщений напрямую в файл из nginx-а работает, файлы > ротируются, но мне это никак не помогает в решении поставленной задачи. > Поэтому и "не удовлетворил". > > Собственно как следствие -- отсутствие проблемы доступного дискового > пространства. Нагрузка на дисковую подсистему близка к нулю. > > И я с самого начала не говорил, что мне нужны файлы! Меня интересовала > связка nginx->(unixSocket)->syslog. > Именно эту проблему я и озвучил. > > Можно сослаться на мои посты: > "Сами файлы логов живут максимум 15-20 минут, этого достаточно для > извлечения необходимых данных." > "Производительности хранилища точно достаточно для 150тыс/сек (один из > способов замера -- запуск одновременно 3-х экземпляров rsyslog на одном > физическом сервере и заливка в 3 сразу тестового набора в 12млн сообщений > на каждый, итог 300-450тыс/сек в совокупности, непрерывно в течении > нескольких часов заливка-ротация-удаление)" > "Данные почти равномерно расходятся по 10-ти файлам, которые пишутся на > tmpfs в RAM. " > > Это были лишь промежуточные этапы, мне нужно было убедиться, что проблема > именно на этапе nginx->(unixSocket)->syslog. > И запись в файл на очень быстрый носитель был, наверное, самый прямой > путь, дающий адекватные результаты. > Свою функцию этот этап выполнил, но повторюсь - это не было целью! > И на каждом этапе обсуждения мне казалось очевидным: мне нужна рабочая > связка nginx->(unixSocket)->syslog !!! > я боюсь, сработал стереотип, который выглядит примерно так "связка может быть рабочая или не рабочая в зависимости от, наверное, десятка параметров настройки операционной системы" ..... "поэтому логично для проверки сравнить количество патронов, вылетающих из точки А с прилетающими в точку Б" .... любым доступным автору способом, например, tcpdump (если топикстартеру удобно другое - без проблем) и первая часть была опущена в силу предполагаемой очевидности. потому что никто не знает конкретную комбинацию параметров, и даже, если и знает, навряд ли сможет предложить способ вычисления, как из комбинации параметров получить булево "да, будет работать на рейте 200к" или "нет, не будет". все таки любопытно. вот вас интересовал вопрос "рабочей связки". в каком виде вы ожидаете помощь от комьюнити (с учетом, что никто не понимает, в чем именно у вас узкое место) предположу, что эту ситуацию можно из "не работает" превратить в "работает, если". если найти узкое место и устранить > > > Вот даже не знаю зачем тут все это излагаю... > Уже непререкаемая уверенность в собственной непогрешимости в некоторых > постах должна была меня насторожить. > А уж выводы типа: > > И если кто-то начинает ради самоутверждения распространять ложную > > информацию про nginx, например, что nginx не способен самостоятельно > > писать логи в файлы при количестве подключений 200-250 тысяч в > > секунду... > > Буквально апогей!!!! Выршина дедукции!!! Шерлок Холмс не у вас, случайно, > учился?? > > Чего уж там - давайте и углеродный след приплетем (нынче это модно). > > > > > > Или я чего-то не понимаю? > > > > «Ничего личного, только бизнес». > Никогда не понимал восторгов этим правилом. > Из личного опыта -- стараюсь не иметь дел с адептами этого подхода, и это > сугубо личное. > > > > > Источник: > > https://uchet-jkh.ru/i/nicego-licnogo-tolko-biznes-otkuda-fraza > > > > -- > > Best regards, > > Gena > > > > _______________________________________________ > > nginx-ru mailing list > > nginx-ru на nginx.org > > https://mailman.nginx.org/mailman/listinfo/nginx-ru > > Best regards..... > to be continued ??? > ------------------------------ > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Wed Feb 14 03:15:30 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 14 Feb 2024 05:15:30 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <1592871877.9501809.1707817093382.JavaMail.zimbra@showjet.ru> References: <1592871877.9501809.1707817093382.JavaMail.zimbra@showjet.ru> Message-ID: 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 From anatoliy.melnik на showjet.ru Wed Feb 14 11:30:57 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Wed, 14 Feb 2024 14:30:57 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <2064611552.13185358.1707910257583.JavaMail.zimbra@showjet.ru> Gena Makhomed Wrote: ------------------------------------------------------- > 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) описанное, а кое-где по умолчанию прям в дефолтовых конфигах примененное решение. > > Причина, почему у Вас не получилось настроить ротацию лог-файлов > при записи логов "напрямую с 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? Об этом было в посте от January 22, 2024 04:12AM Цитирую: Зачем мне это нужно: Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются запросы. Обращения жестко делятся на несколько типов, тип определяется значением переменной в запросе, запросы БЕЗ этой переменной игнорируются. Беки ведут статистику сколько и какого типа запросов они получили, эти данные сливаются в БД и хранятся с дискретностью 20минут. Регулярно требуется "нестандартная" статистика, например "средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки" "соотношение обращений по http и https ($schema) по запросам типа "q1wr" за час" "наименьшее/среднее/наибольшее время ($request_time) по запросам типа "sc012" за..." "объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в общем объеме трафика (сумма $body_bytes_sent всех запросов)" и т.д. нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в логах реверс-прокси. Конец цитаты... Чисто техничски можно и без access-логов, будете сами реализовывать нечто подобное -- выберете более близкое вам решение. > > Например, с помощью директив модуля ngx_http_mirror_module > Если Вам достаточно информации, которая присутствует в логах, > значит тело запроса не нужно и можно поставить mirror_request_body > off; > с помощью директивы mirror в internal location и последующим > проксированием запросов на какой-то сервис на Go, который будет > собирать, аккумулировать и отдавать необходимую Вам статистику. > > На Go с использованием goroutines и каналов можно построить очень > эффективный сервис, который будет максимально масштабируемым > и будет выдерживать очень большую нагрузку, так что мощности > хватит с запасом, если проксировать запросы на этот демон > через блок upstream с включенным keepalive. > Идеальных решений не существует. как минимум создам дополнительную нагрузку на сетевой стек ОС-и, ибо tcp как ни крути более затратен по сравнению с unixSocket. Или с высокой вероятностью упрусь в теже ограничения unixSocket если отказаться от tcp со всеми дальше вытекающими. При размещении на другом сервере решить проблему исчерпания портов для соединения прокси-проски. (а их "в моменте" 350-400 тыс), да, без body их будет меньше, но все-таки довольно много.. Заняться изучением Go, потратить на это горку времени. Не, это не проблема, но дальше Go в обозримой перспективе на горизонте не просматривается. При передаче всего этого хозяйства дальше на обслуживание в моем варианте разберется любой начинающий питонист, в предложенной вами схеме квалификация нужна будет повыше мне кажется. Как видите я просто получу иной набор проблем. Мой вариант также страдает набором недостатков, но поставленные задачи решает с устраивающей меня эффективностью. Свой вариант я могу абсолютно спокойно масштабировать до необходимых мне значений, и эти значения почти на порядок выше текущих нагрузок. Реализация укладывается в сотню строк кода... > >>> Возникает впечатление, что кому-то из вас принципиально важно > >>> доказать незыблемую правоту своего мнения и ошибочность моих > >>> действий. Вопрос - зачем? > > Мне интересно понять суть проблемы и найти самое оптимальное решение. Моя проблема "Х": Ограниченность в связке nginx->unixSocket->syslog Мое решение проблемы "Х": распараллелить процесс, чтоб проблема "Х" не возникала в принципе на необходимых мне уровнях. Возможны ли другие решения? безусловно! Отказаться от nginx, отказаться от unixSocket, отказаться от unixSocket->syslog и т.д. и.т.п. Объективно оптимального решения практически любой проблемы не существует в природе. Если у вас в крсе обучения был такой предмет как "методы оптимизации" -- вы должны это понимать. Вспомните задачки из курса: На одну и ту же таблицу данных: Постройте оптимальный маршрут по расстоянию. Постройте оптимальный маршрут по времени. Постройте оптимальный маршрут по загрузке. Постройте оптимальный с учетом состояния дорог. И ответы везде разные, а табличка-то одна :) И это которые простые задачки.... > > >>> Это не конкурс или состязание, я сюда обратился за советом. > > Вы спрашивали совета о том, как решить проблему 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. > Это решение мной рассмативалось на каком-то этапе, решил что менее перспективно, аргументы перечислены выше, хотя на этапе рассмотрения про ограничения unixSocket еще не проявилось. Эффективность реализации весьма эфемерное понятие. Эффективность с точки зрения чего? Мы с вами эффективность считаем по совершенно разным критериям. Это не хорошо и не плохо. Это просто по-разному :) Ваше мнение может отличаться от моего. > > И на каждом этапе обсуждения мне казалось очевидным: мне нужна > рабочая связка nginx->(unixSocket)->syslog !!! > > Получение рабочей связки nginx->(unixSocket)->syslog - это проблема > Y. > > На самом деле - Вам нужно решение проблемы X. > Это вы сами решили? Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно решать что мне надо :) > > Уже непререкаемая уверенность в собственной непогрешимости в > некоторых постах должна была меня насторожить. > > я вполне способен воспринимать технически грамотные ответы > и признавать свои ошибки, - если таковые имели место быть. > Отличное качество. Демонстрируйте его почаще :) > >> «Ничего личного, только бизнес». > > > Никогда не понимал восторгов этим правилом. > > Это я к тому, что меня не интересует обсуждение Вашей личности. > А интересует поиск наиболее оптимальных способов решения интересных > проблем и задач, которые имеют прямое или косвенное отношение к > nginx. > Хорошо. Личности оставим в покое. Про оптимальность я выше упоминал. Оптимизировать можно по разным критериям. Вы исходите из одних критериев оптимальности, я из других. И это абсолютно нормально. Не стоит убеждать меня в "неправильности" моих критериев. Есть большое подозрение, что уже на текущем этапе по данному вопросу осталось лишь 2 собеседника. > > Из личного опыта -- стараюсь не иметь дел с адептами этого подхода, > и это сугубо личное. > > Формула «Ничего личного, только бизнес» имеет как положительную, > как и отрицательную коннотацию. Отрицательная коннотация - потому > что эта формула может быть использована для оправдания каких-то > непопулярных действий и решений в бизнесе. Но есть и положительная, > - в том смысле, что следует отделять личное отношение от "бизнеса", > то есть, что при обсуждении каких-то технических проблем необходимо > руководствоваться рациональностью и логикой, а не эмоциями. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Wed Feb 14 16:59:42 2024 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 14 Feb 2024 20:59:42 +0400 Subject: nginx-1.25.4 Message-ID: <1E7FA49B-8DC0-416E-8C63-46E0E118B1F6@nginx.com> Изменения в nginx 1.25.4 14.02.2024 *) Безопасность: при использовании HTTP/3 в рабочем процессе мог произойти segmentation fault во время обработки специально созданной QUIC-сессии (CVE-2024-24989, CVE-2024-24990). *) Исправление: соединения с незавершенными AIO-операциями могли закрываться преждевременно во время плавного завершения старых рабочих процессов. *) Исправление: теперь nginx не пишет в лог сообщения об утечке сокетов, если во время плавного завершения старых рабочих процессов было запрошено быстрое завершение. *) Исправление: при использовании AIO в подзапросе могла происходить ошибка на сокете, утечка сокетов, либо segmentation fault в рабочем процессе (при SSL-проксировании). *) Исправление: в рабочем процессе мог произойти segmentation fault, если использовалось SSL-проксирование и директива image_filter, а ошибки с кодом 415 перенаправлялись с помощью директивы error_page. *) Исправления и улучшения в HTTP/3. -- Sergey Kandaurov From pluknet на nginx.com Wed Feb 14 17:00:14 2024 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 14 Feb 2024 21:00:14 +0400 Subject: nginx security advisory (CVE-2024-24989, CVE-2024-24990) Message-ID: В реализации HTTP/3 в nginx были обнаружены две проблемы, которые позволяют атакующему с помощью специально созданной QUIC-сессии вызвать падение рабочего процесса (CVE-2024-24989, CVE-2024-24990), а также потенциально другие последствия (CVE-2024-24990). Проблеме подвержен nginx, собранный с модулем ngx_http_v3_module (по умолчанию не собирается), если в конфигурационном файле используется параметр quic директивы listen. Проблеме подвержен nginx 1.25.0 - 1.25.3. Проблема исправлена в nginx 1.25.4. -- Sergey Kandaurov From bgx на protva.ru Wed Feb 14 17:31:53 2024 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 14 Feb 2024 20:31:53 +0300 Subject: =?utf-8?B?0KLQtdGB0YIgbmdpbnggLS0g0YE=?= =?utf-8?B?0LrQvtC70YzQutC+INGB0L7QvtCx0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9n?= =?utf-8?B?INCx0LXQtyDQv9C+0YLQtdGA0Yw/?= In-Reply-To: <2064611552.13185358.1707910257583.JavaMail.zimbra@showjet.ru> References: <2064611552.13185358.1707910257583.JavaMail.zimbra@showjet.ru> Message-ID: On Wed, Feb 14, 2024 at 02:30:57PM +0300, Anatoliy Melnik via nginx-ru wrote: > Все как раз получилось, дальше с этим работать было неудобно. > К тупой записи в файл претензий не было. Вы не сообщили, почему "дальше с этим работать было неудобно". Может, поясните? Если посмотреть на озвученный список задач -- > Зачем мне это нужно: [...] > Регулярно требуется "нестандартная" статистика, например > "средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки" > "соотношение обращений по http и https ($schema) по запросам типа "q1wr" > за час" > "наименьшее/среднее/наибольшее время ($request_time) по запросам типа > "sc012" за..." > "объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в > общем объеме трафика (сумма $body_bytes_sent всех запросов)" > и т.д. то вроде трудно придумать что-то проще и эффективней, чем прост парсинг логов. А лог что из файла, что из пайпа, что из сокета читается абсолютно одинаково, одним и тем же read(), и парсится одинаково. Но из файла якобы неудобно! Чем же неудобно, почему? При чём тут вообще какие-то unix-сокеты, если задача в разборе последовательно идущих строк и каких-то элементарных вычислениях? > Чисто техничски можно и без access-логов, будете сами реализовывать нечто > подобное -- выберете более близкое вам решение. Вы не назвали альтернативные решения. > Мой вариант также страдает набором недостатков, но поставленные задачи > решает с устраивающей меня эффективностью. Вы не конкретизировали, какие недостатки видите у своего варианта и почему его плюсы по сравнению с другими подходами перевешивают. > Свой вариант я могу абсолютно спокойно масштабировать до необходимых мне > значений, и эти значения почти на порядок выше текущих нагрузок. Вы крутейший специалист :)) в своих собственных глазах, конечно. > Концптуальная ошибка в этом опусе -- вы не обслуживание клиентов. > И "непродуктивность пути" определяете в данной конкретной ситуации не вы. > И конечную реализацию делаете не вы. > И за результаты отвечаете не вы. > Как и ответственность за все выполненное в итоге так же не на вас. И что, это лишает собеседника право высказать своё мнение о правильности постановки задачи? Вы также не сообщили, каковы критерии "продуктивности пути", почему выбрана конретная реализация и т.д. Поэтому нет никаких оснований даже подозревать, что Вы что-то делаете правильно... :) > Эффективность реализации весьма эфемерное понятие. > Эффективность с точки зрения чего? > Мы с вами эффективность считаем по совершенно разным критериям. > Это не хорошо и не плохо. Это просто по-разному :) Вы не конкретизировали, по каким критериям оцениваете эффективность. > Оптимизировать можно по разным критериям. > Вы исходите из одних критериев оптимальности, я из других. > И это абсолютно нормально. > Не стоит убеждать меня в "неправильности" моих критериев. Ненормально то, что один собеседник пытается аргументировать свои мысли, а другой всё время отвечает "Не учите меня жить! У меня другая ситуация!" А какая именно -- не говорит. -- Eugene Berdnikov From mdounin на mdounin.ru Wed Feb 14 17:59:51 2024 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Feb 2024 20:59:51 +0300 Subject: announcing freenginx.org Message-ID: Hello! Как вы, вероятно, знаете, компания F5 закрыла офис в Москве в 2022 году, и с тех пор я не работают в F5. Однако после закрытия офиса мы достигли соглашения, что я сохраняю свою роль в разработке nginx'а как волонтёр. И почти два года я занимался тем, что развивал nginx, делая его лучше для всех. К сожалению, кто-то из нетехнического менеджмента F5 недавно решил, что знает лучше, как следует управлять открытыми проектами. В частности, кто-то решил, что не следует руководствоваться security-политикой, используемой nginx'ом в течении многих лет, а равно не следует учитывать мнение разработчиков. Подобный подход можно понять: они владеют проектом, и могут с ним делать всё, что считают нужным, включая подобные маркетинговые акции. Это, однако, противоречит нашемоу соглашению. И, что более важно, я больше не имею возможности как-либо контролировать изменения, которые вносят в nginx в F5, и не могу рассматривать nginx как открытый и свободный проект, разрабатываемый для общего блага. Так что, начиная с сегодняшнего дня, я больше не участвую в разработке nginx'а в рамках F5. Вместо этого я запускаю альтернативный проект, управлять которым будут разработчики, а не корпоративные структуры: http://freenginx.org/ Цель проекта - обеспечить разработку nginx'а, свободную от произвольного корпоративного вмешательства. Помощь и участие приветствуются. Надеюсь, проект будет полезен для всех. -- Maxim Dounin http://freenginx.org/ From izorkin на gmail.com Wed Feb 14 18:32:54 2024 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 14 Feb 2024 21:32:54 +0300 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: <1566332227.20240214213254@gmail.com> Добрый вечер, Максим. Печально всё это слышать... Будет развиваться как очередной форк Nginx или каким-то другим способом будет вестись разработка? Вы писали 14 февраля 2024 г., 20:59:51: > Hello! > Как вы, вероятно, знаете, компания F5 закрыла офис в Москве в 2022 > году, и с тех пор я не работают в F5. Однако после закрытия офиса > мы достигли соглашения, что я сохраняю свою роль в разработке > nginx'а как волонтёр. И почти два года я занимался тем, что > развивал nginx, делая его лучше для всех. > К сожалению, кто-то из нетехнического менеджмента F5 недавно решил, > что знает лучше, как следует управлять открытыми проектами. В > частности, кто-то решил, что не следует руководствоваться > security-политикой, используемой nginx'ом в течении многих лет, а > равно не следует учитывать мнение разработчиков. > Подобный подход можно понять: они владеют проектом, и могут с ним > делать всё, что считают нужным, включая подобные маркетинговые > акции. Это, однако, противоречит нашемоу соглашению. И, что более > важно, я больше не имею возможности как-либо контролировать > изменения, которые вносят в nginx в F5, и не могу рассматривать > nginx как открытый и свободный проект, разрабатываемый для общего > блага. > Так что, начиная с сегодняшнего дня, я больше не участвую в > разработке nginx'а в рамках F5. Вместо этого я запускаю > альтернативный проект, управлять которым будут разработчики, а не > корпоративные структуры: > http://freenginx.org/ Какая помощь приветствуется не из области программирования?) Нет ли желания продвижения в сети Fediverse (микро-блог, аналог Twitter)? Нет ли в планах поднять какой-нибудь небольшой форум? > Цель проекта - обеспечить разработку nginx'а, свободную от > произвольного корпоративного вмешательства. Помощь и участие > приветствуются. Надеюсь, проект будет полезен для всех. -- С уважением, Izorkin mailto:izorkin на gmail.com From mdounin на mdounin.ru Wed Feb 14 19:06:08 2024 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 14 Feb 2024 22:06:08 +0300 Subject: announcing freenginx.org In-Reply-To: <1566332227.20240214213254@gmail.com> References: <1566332227.20240214213254@gmail.com> Message-ID: Hello! On Wed, Feb 14, 2024 at 09:32:54PM +0300, izorkin на gmail.com wrote: > Добрый вечер, Максим. > > Печально всё это слышать... > Будет развиваться как очередной форк Nginx или каким-то другим > способом будет вестись разработка? С учётом деталей - скорее, форк остался у F5. Развиваться будет мной и теми, кто решит присоединиться. [...] > > Так что, начиная с сегодняшнего дня, я больше не участвую в > > разработке nginx'а в рамках F5. Вместо этого я запускаю > > альтернативный проект, управлять которым будут разработчики, а не > > корпоративные структуры: > > > http://freenginx.org/ > > Какая помощь приветствуется не из области программирования?) Не из области программирования - в первую очередь тестировать и репортить проблемы. > Нет ли желания продвижения в сети Fediverse (микро-блог, аналог > Twitter)? > Нет ли в планах поднять какой-нибудь небольшой форум? Нет, и опять же нет. Продвижение особого смысла не имеет, проект строго некоммерческий и не предполагает каких-либо коммерческих перспектив. Что до форумов, то это совершенно не мой формат общения. -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Wed Feb 14 19:23:08 2024 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 14 Feb 2024 22:23:08 +0300 Subject: announcing freenginx.org In-Reply-To: References: <1566332227.20240214213254@gmail.com> Message-ID: <218159027.20240214222308@gmail.com> Добрый вечер, Максим. Удачи, надеюсь всё получится! Вы писали 14 февраля 2024 г., 22:06:08: > С учётом деталей - скорее, форк остался у F5. Развиваться будет > мной и теми, кто решит присоединиться. Ну с этим вроде как уже помогаю :) На данный момент у меня висит вопрос с MIME-типами. Хотелось бы уже решить этот вопрос, актуализировать список и синхронизировать его со списком в NixOS :) > Не из области программирования - в первую очередь тестировать и > репортить проблемы. Тут я имел не коммерческое использование, а анонсирование новых версий, каких-либо новостей, опросов на добавление какой-либо функциональности. В сети Fediverse сидят много технических специалистов :) Некоторым людям удобнее работать с форумом, попробовать можно :) > Нет, и опять же нет. Продвижение особого смысла не имеет, проект > строго некоммерческий и не предполагает каких-либо коммерческих > перспектив. Что до форумов, то это совершенно не мой формат > общения. -- С уважением, Izorkin mailto:izorkin на gmail.com From izorkin на gmail.com Wed Feb 14 19:25:01 2024 From: izorkin на gmail.com (izorkin на gmail.com) Date: Wed, 14 Feb 2024 22:25:01 +0300 Subject: announcing freenginx.org In-Reply-To: References: <1566332227.20240214213254@gmail.com> Message-ID: <1255460295.20240214222501@gmail.com> Добрый вечер, Максим. Удачи, надеюсь всё получится! Вы писали 14 февраля 2024 г., 22:06:08: > С учётом деталей - скорее, форк остался у F5. Развиваться будет > мной и теми, кто решит присоединиться. Ну с этим вроде как уже помогаю :) На данный момент у меня висит вопрос с MIME-типами. Хотелось бы уже решить этот вопрос, актуализировать список и синхронизировать его со списком в NixOS :) > Не из области программирования - в первую очередь тестировать и > репортить проблемы. Тут я имел не коммерческое использование, а анонсирование новых версий, каких-либо новостей, опросов на добавление какой-либо функциональности. В сети Fediverse сидят много технических специалистов :) Некоторым людям удобнее работать с форумом, попробовать можно :) > Нет, и опять же нет. Продвижение особого смысла не имеет, проект > строго некоммерческий и не предполагает каких-либо коммерческих > перспектив. Что до форумов, то это совершенно не мой формат > общения. -- С уважением, Izorkin mailto:izorkin на gmail.com From anatoliy.melnik на showjet.ru Wed Feb 14 21:58:08 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Thu, 15 Feb 2024 00:58:08 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <1695800929.14668824.1707947888526.JavaMail.zimbra@showjet.ru> Evgeniy Berdnikov Wrote: ------------------------------------------------------- > On Wed, Feb 14, 2024 at 02:30:57PM +0300, Anatoliy Melnik via nginx-ru > wrote: > > Все как раз получилось, дальше с этим работать было неудобно. > > К тупой записи в файл претензий не было. > > Вы не сообщили, почему "дальше с этим работать было неудобно". > Может, поясните? Если посмотреть на озвученный список задач -- > > > Зачем мне это нужно: > [...] > > Регулярно требуется "нестандартная" статистика, например > > "средний размер ($body_bytes_sent) по запросам типа "sc012" за > сутки" > > "соотношение обращений по http и https ($schema) по запросам типа > "q1wr" > > за час" > > "наименьшее/среднее/наибольшее время ($request_time) по запросам > типа > > "sc012" за..." > > "объем запросов типа "q1wr" (сумма $body_bytes_sent таких > запросов) в > > общем объеме трафика (сумма $body_bytes_sent всех запросов)" > > и т.д. > > то вроде трудно придумать что-то проще и эффективней, чем прост > парсинг > логов. А лог что из файла, что из пайпа, что из сокета читается > абсолютно одинаково, одним и тем же read(), и парсится одинаково. > > Но из файла якобы неудобно! Чем же неудобно, почему? При чём тут > вообще > какие-то unix-сокеты, если задача в разборе последовательно идущих > строк > и каких-то элементарных вычислениях? 1. первоначально логи сливались по сети и централизованно считались.(без записи в файлы) при высоких нагрузках пошли расхождения. 2. Хорошо -- пусть каждый прокси сам свое считает: исключаются потери по сети, каждый прокси в этом плане становится автономно-независимой единицей. При высоких нагрузках -- расхождения в статистике. 3. Хорошо, запишем в файл прям с nginx-а. файл распарсим-посчитаем. 3а.простыми методами (типа grep и awk) обработка статистики за 30 секунд занимает больше 30 секунд. 3б.пишем в файл->читаем из файла->удаляем файл в объемах 30-60Мбайт/сек... лично мое мнение - файл тут явно лишний. (Ваше мнение может отличатся от моего, я абсолютно не настаиваю). > > > Чисто техничски можно и без access-логов, будете сами > реализовывать нечто > > подобное -- выберете более близкое вам решение. > > Вы не назвали альтернативные решения. Это сделали за меня: Написать свой бекэнд (как вариант на Go) и отзеркалировать туда запросы с фронотов.... Не имею ничего против -- реализовуйте! Я не настаиваю на своем варианте. Не продвигаю как единственно правильный (или у вас иное мнение?) > > > Мой вариант также страдает набором недостатков, но поставленные > задачи > > решает с устраивающей меня эффективностью. > > Вы не конкретизировали, какие недостатки видите у своего варианта и > почему его плюсы по сравнению с другими подходами перевешивают. Ну почему же? Недостатки: Скорее всего более высокая нагрузка на CPU по сравнению с альтернативой (замеров и испытаний никто не проводил, это чисто теоретический вывод) Предположительно масштабируемость моего решения хуже по сравнению с предложенной альтернативой (чисто теоретический вывод) Т.к. я не программист -- само качество решения в плане программного кода далеко от идеала. Жесткое неприятие выбранного мной подхода со стороны некоторых участников обсуждения (почему-- для меня до сих пор загадка). Плюсы: При передаче всего этого хозяйства дальше на обслуживание в моем варианте разберется любой начинающий питонист, в предложенной схеме с зеркалированием квалификация нужна будет повыше мне кажется. Запаса по вычислительной мощности более чем достаточно. На существующих мощностях практически гарантированный порог 720тыс/сек. прогнозируемый, (исходя из показателей работы системы на 240тыс/сек на одном сервере) -- порядка 1.1-1.2 млн./сек. Что в 3 (проверенный) и 5 (прогноз) раз превышает имеющийся на данный момент уровень. Чего хватает на 4-5 лет при росте нагрузки на 22-24% ежегодно. (имеющийся на данный момент прогноз оптимистичный оценивается максимум в 14-16% в год) Затраты времени на реализацию значительно меньше, чем вариант со своим бекэндом. > > > Свой вариант я могу абсолютно спокойно масштабировать до > необходимых мне > > значений, и эти значения почти на порядок выше текущих нагрузок. > > Вы крутейший специалист :)) в своих собственных глазах, конечно. Из лабиринтов собственных заблуждений скорее выберется тот, кто готов признать, что он заблуждается. Лично я этот путь приодолел не единожды. Чего и вам желаю. > > > Концптуальная ошибка в этом опусе -- вы не обслуживание клиентов. > > И "непродуктивность пути" определяете в данной конкретной > ситуации не вы. > > И конечную реализацию делаете не вы. > > И за результаты отвечаете не вы. > > Как и ответственность за все выполненное в итоге так же не на > вас. > > И что, это лишает собеседника право высказать своё мнение о > правильности > постановки задачи? Откуда такие выводы? Собеседник не единожды высказал свое мнение и даже больше. Придумал у меня проблему, которой нет. Привел для нее решение... нет смысла пересказывать -- все есть в ветке. Я его принял к сведению, но разве я обязан после этого изменить свое собственное? Разве я кого-то пытался убедить, что его подход в корне не верен, как в этом пытаются убедить меня? Если я начну вас убеждать в неправильности вашего выбора... ну пусть книг, которые вы читаете -- это ОБЯЗАТЕЛЬНО должно как-то кардинально повлиять на ваши вкусы? Возможно вы полистаете что-то из рекомендованного, может понравится.. А если нет? > Вы также не сообщили, каковы критерии > "продуктивности > пути", почему выбрана конретная реализация и т.д. Поэтому нет никаких > оснований даже подозревать, что Вы что-то делаете правильно... :) > Ну нет оснований - и нет, не подозревайте. Кто судит о правильности или не правильности? Вы для себя сами решаете что правильно, а что нет. Я поступаю аналогичным образом... В чем я не прав? Лишь в том, что выбрал подход, который вы считаете неправильным? И что? Ваше мнение я выслушал, принял к сведению и остался при своем. Критерии продуктивности: У меня все выполняет ту функцию, которую я и хотел, в нужных мне объемах и с устраивающим меня запасом прочности -- для меня вполне критерий. Ваше мнение может отличаться от моего. Может очень сильно отличаться. Может вообще не иметь с моим мнением ничего общего... и что? для вас это повод для... чего? Я же свои задачи решаю, а не ваши. Когда и если я буду решать задачи по вашим ТЗ и постановкам -- буду реализовывать ваши подходы-мнения-рекомендации в полном объеме вне зависимости от своего собственного мнения о правильности или не правильности выбранного вами подхода. > > Эффективность реализации весьма эфемерное понятие. > > Эффективность с точки зрения чего? > > Мы с вами эффективность считаем по совершенно разным критериям. > > Это не хорошо и не плохо. Это просто по-разному :) > > Вы не конкретизировали, по каким критериям оцениваете эффективность. На глазок :) мне кажется, что так-то и так-то будет проще, быстрее и удобнее... А нет, ошибочка вышла, не проще, но удобнее... Не, вариант что-то не очень. Подумаем иначе, если зайти не в лоб, а с боку --- так, эта проблема снимается, эта тоже, но всплывет вот эта! Насколько она портит картинку по сравнению с предидущими? так, не будем ломиться в стену, поищем дверь.. Зачем при достижении пункта Д, при старте из пункта А я обязательно пытаюсь пройти через Л и Т? так ли уж необходимо там побывать?... Ну и так далее. Обычная, по сути, мыслительная деятельность. На финише и складывается представление об некой эфемерной "эффективности" как найденного решения, так и его альтернатив. Но все начинается с определения цели дальнейших действий, оценки доступного ресурса, желаемого результата в 3-х вариантах (удовлетворительно, хорошо, отлично), имеющегося в наличии решения, которое из "хорошо" стало работать "удовлетворительно" (если таковое имеется)... Но вряд ли это для кого-то новость :) Предложение с написанием собственного бекэнда по пунктам "ресурс" и "имеющееся в наличии" проигрывало. в моем случае. Ваше мнение может отличаться от моего :) У вас критерии кардинально отличаются? Вы оную считаете по какой-то отдельной формуле? > > > Оптимизировать можно по разным критериям. > > Вы исходите из одних критериев оптимальности, я из других. > > И это абсолютно нормально. > > Не стоит убеждать меня в "неправильности" моих критериев. > > Ненормально то, что один собеседник пытается аргументировать свои > мысли, > а другой всё время отвечает "Не учите меня жить! У меня другая > ситуация!" > А какая именно -- не говорит. С моей колокольни это выглядело несколько иначе. Лично я там обнаружил, что у меня проблемы которых у меня на самом деле нет. Что я решаю не те проблемы, которые должен. Что я возвожу напраслину на nginx и чуть ли не на все комьюнити... ну и далее по тексту. Хотя я с самого начала сказал, что свои вопросы я решил. Или я опять не прав -- самонадеян -- заблуждаюсь -- ....?? > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Feb 15 01:17:04 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 15 Feb 2024 03:17:04 +0200 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: On 14.02.2024 19:59, Maxim Dounin wrote: > Подобный подход можно понять: они владеют проектом, и могут с ним > делать всё, что считают нужным, включая подобные маркетинговые > акции. Это, однако, противоречит нашемоу соглашению. И, что более > важно, я больше не имею возможности как-либо контролировать > изменения, которые вносят в nginx в F5, и не могу рассматривать > nginx как открытый и свободный проект, разрабатываемый для общего > блага. > > Так что, начиная с сегодняшнего дня, я больше не участвую в > разработке nginx'а в рамках F5. Вместо этого я запускаю > альтернативный проект, управлять которым будут разработчики, а не > корпоративные структуры: > > http://freenginx.org/ > > Цель проекта - обеспечить разработку nginx'а, свободную от > произвольного корпоративного вмешательства. Помощь и участие > приветствуются. Надеюсь, проект будет полезен для всех. Максим, тут есть одна очень большая проблема. Владельцем торговой марки NGINX является компания F5 NETWORKS, INC. https://trademarks.justia.com/853/12/nginx-85312802.html Своего разрешения на использование своей торговой марки NGINX F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст. А вот дальнейшее развитие событий предусмотреть совсем не трудно. Они будут преследовать Вас в судебном порядке за trademark infringement Сначала - будет UDRP - Uniform Domain Name Dispute Resolution https://www.icann.org/resources/pages/trademark-infringement-2017-06-20-en а потом - могут в конечном итоге и вообще отобрать у Вас домен freenginx.org этот домен станет их собственностью. Учитывая их доходы - они смогут найти деньги на очень хороших юристов и адвокатов, так что вопрос утраты контроля над доменом freenginx.org - это не вопрос "если", это вопрос "когда" - они это сделают. А если не сделают сейчас - то смогут сделать в любой момент в будущем, полностью отобрав этот домен и запретив Вам каким-либо образом использовать торговую марку NGINX. Например, они могут заняться этим вопросом не сразу, а через некоторое время, когда Ваш проэкт наберет некоторую популярность и посещаемость сайта станет высокой. Имеет ли смысл так сильно рисковать основной веткой? https://www.wipo.int/amc/en/domains/guide/ https://en.wikipedia.org/wiki/Trademark_infringement - законодательство тут на их стороне и по закону они будут правы. В https://en.wikipedia.org/wiki/WIPO входят практически все страны мира и trademark infringement является нарушением закона практически в любой стране. Даже если они не будут заниматься тем, чтобы отбирать у Вас права на домен freenginx.org - они это смогут сделать в любой момент времени в будущем, когда посчитают это целесообразным. Может быть лучше будет переименовать проект в какое-то другое имя, в котором вообще не будут упоминаться ничьи торговые марки? Когда-то проекту CentOS пришлось не только убирать все упоминания торговой марки Red Hat - они были вынуждены даже убрать все упоминания Red Hat и заменить их на PNAELV. PNAELV - это Prominent North American Enterprise Linux Vendor, это слово не является ничьей торговой маркой и его использование не запрещено. А вот торговую марку Red Hat без их разрешения использовать нельзя. Аналогично будет и с торговой маркой NGINX. Аналогично, например, было и с торговой маркой Apache - из-за чего все дистрибутивы были вынуждены переименовать веб-сервер в httpd. Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то имя, которое не является ничьей торговой маркой и для защиты этого имени - зарегистрировать свою торговую марку, чтобы не было потом ситуации "обратного захвата домена" - это когда вы используете какое-то доменное имя, например, something.ru, при этом - something не ялвяется торговой маркой. И потом, через какое-то время - какой-то совершенно посторонний человек, регистрирует торговую марку something, подает на Вас в суд и по решению суда отбирает у Вас контроль над доменом something.ru не смотря на то, что эта торговая марка не была зарегистрирована в момент регистрации Вами домена something.ru - это ничего не меняет, суд будет на стороне владельца торговой марки. Это и называется "обратный захват домена". Для доменов зарегистрированных в международных TLD - ситуация не такая однозначная, если домен был зарегистрирован до момента регистрации соответствующей торговой марки - то еще могут быть варианты. Но если Вы регистрируете домен freenginx.org в тот момент времени, когда F5 NETWORKS, INC. является владельцем торговой марки NGINX - тогда шансов удержать контроль над этим доменом - практически нет, ведь Вы же здесь без их разрешения используете их торговую марку. Это примерно то же самое, что кто-то зарегистрирует домен freewindows.org и попробует создавать там Open Source конкурента для Microsoft Windows. Не будет это работать. Например, если компания Microsoft отобрала даже домен MikeRoweSoft.com у канадского студента Mike Rowe который занимался веб-дизайном, то и домен freewindows.org она точно так же отберет. https://en.wikipedia.org/wiki/Microsoft_v._MikeRoweSoft Да и торговая марка Linux принадлежит Линусу Торвальдсу только потому что какой-то коммерсант заренистрировал эту торговую марку и потом пытался требовать деньги от производителей дистрибутивов за разрешение использовать принадлежащую ему торговую марку. https://en.wikipedia.org/wiki/Linux_Mark_Institute Поэтому - Gregory Kurtzer чтобы не наступать на эти грабли - с самого начала зарегистрировал торговые марки Rocky Enterprise Software Foundation™ RESF™ Rocky Linux™ на Rocky Enterprise Software Foundation, чтобы никто не мог у него отобрать его домены и никто не мог бы потом запретить ему использовать торговую марку Rocky Linux и чтобы проект мог бы нормально развиваться. Поэтому - для 100% защиты проекта - необходимо иметь свою торговую марку и необходимо иметь домен, который защищен с помощью этой торговой марки. В современном мире таку защиту должы иметь и Open Source проекты. И наверное, даже в первую очередь именно Open Source проекты, поскольку они являют собой наибольшую угрозу и опасность для корпораций. В фильме https://ru.wikipedia.org/wiki/Revolution_OS это очень подробно рассказывается, наиболее качественный перевод этого фильма «Revolution OS» ну русский язык - от Дмитрия Бачило. https://www.youtube.com/watch?v=n1F_MfLRlX0 -- Best regards, Gena From raven_kg на megaline.kg Thu Feb 15 02:41:17 2024 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 15 Feb 2024 08:41:17 +0600 Subject: announcing freenginx.org In-Reply-To: <1255460295.20240214222501@gmail.com> References: <1566332227.20240214213254@gmail.com> <1255460295.20240214222501@gmail.com> Message-ID: <54895bb9-fb4a-4db9-a0ed-61a30292b867@megaline.kg> 15.02.2024 01:25, izorkin на gmail.com пишет: > Некоторым людям удобнее работать с форумом, попробовать можно :) Форумы давно мертвы как формат общения. Исправно рабатают только старые площадки, с давно наруленным сообществом, но и они переживают не лучшие времена. Списки рассылки, кстати, направляются туда же. Всем теперь issues на github-е подавай :smile: ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Feb 15 03:05:11 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 15 Feb 2024 05:05:11 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <2064611552.13185358.1707910257583.JavaMail.zimbra@showjet.ru> References: <2064611552.13185358.1707910257583.JavaMail.zimbra@showjet.ru> Message-ID: On 14.02.2024 13:30, Anatoliy Melnik via nginx-ru wrote: >>> Если вы предлагаете писать напрямую с nginx-а в файл -- >>> сделайте у себя ротацию файлов с интервалом 30 сек >>> при 200-250 тыс подключений/сек... >>> >>> Если у вас уже есть такое рабочее решение - >>> поделитесь опытом, буду рад вас выслушать. >> В этом сообщении Вы говорите о том, что Вы пробовали писать логи >> "напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд, >> при при 200-250 тыс подключений/сек, и у Вас не получилось >> создать "рабочее решение". > Вы привели ПОЛНУЮ ЦИТАТУ! ОТЛИЧНО! > Я сказал ровно то, что и хотел сказать. > Где вы прочитали про "не получилось" ??? > Пожалуйста процитируйте... без своих домыслов и фантазий. А Вы помните, на какой именно мой вопрос Вы отвечали? Напомню: https://mailman.nginx.org/pipermail/nginx-ru/2024-February/L3UKQXO2PKIHBFWHHTQRKDQY53XGE5BN.html Я же практически прямым текстом Вам написал, что Ваша попытка выжать максимум производительности из связки nginx-syslog - это есть проблема Y и задал Вам вопрос, какую именно проблему X Вы таким способом пытаетесь решить. И что я слышу в ответ - что Вы не смогли получить работающую систему при 200-250 тысяч подключений в секунду и при ротации логов раз в 30 секунд - именно это и значают Ваши слова "Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать" - если Вы спрашиваете, как именно построить рабочую систему ротации логов при такой нагрузке, то логично предположить, что Вы попытались это сделать, у Вас это не получилось и Вы тогда пошли другим путем - писать логи через syslog unix socket`ы, потому что там ротации не надо делать. А невозможность получить "такое рабочее решение" при таких параметрах нагрузки может быть вызвана только тем, что ротацию логов Вы делали через SIGHUP а не через SIGUSR1. То есть, я так и понял Ваш ответ на мой вопрос, что проблемой X, которую Вам не удалось решить, является проблема ротации логов nginx раз в 30 секунд при нагрузке в 200-250 тыс подключений/сек. И поэтому - Вы, вместо того, чтобы искать решение проблемы Х, начали решать проблему Y - искать способы, как оптимизировать работу связки nginx-syslog - заведомо более затратный по ресурсам способом, по сравнению с обработкой и ротацией логов по SIGUSR1. И если я Вам задаю вопрос о том, в чем именно состоит Ваша проблема X, которую Вы пытаетесь решить, а в ответ слышу про количество подключений в секунду и интервал ротации раз в 30 секунд и "Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать", то что еще мне оствалалось подумать в этой ситуации, и каким еще образом я мог бы понять Ваши слова? Вот попробуйте поставить себя на мое место и посмотреть на эту ситуацию с моей точки зрения, когда Вы задаете кому-то такой вопрос и слышие такой ответ. И все последующее - это уже следствие того, что Вы начали говорить, что syslog-unix socket-python - это есть решение проблемы X. А сама проблема X у вас появилась из-за использования SIGHUP дял ротации логов, вместо SIGUSR1. Понятно, что при таких парметрах, 200-250 подключений в секунду и интервале ротации раз в 30 секунд ничего работать не будет. Но при использовании SIGUSR1 - нет проблем, вне зависимости от того, какое там количество подключений в секунду, 200 тысяч 250 тысяч или какое-либо еще, потому что рабочие процессы при ротации через SIGUSR1 не перезапускаются, а всего лишь переоткрывается лог-файл, что происходит практически мгновенно и это очень дешевая операция, много ресурсов она не занимает. Или все было совсем не так и это все является моими домыслами и фантазиями и Ваши слова "Если у вас уже есть такое рабочее решение - поделитесь опытом, буду рад вас выслушать" означают что-то совершенно другое? Я и поделился с Вами опытом - используйте SIGUSR1 вместо SIGHUP и тогда Ваша проблема X будет решена и тогда не надо будет заниматься поиском решения для проблемы Y - как сделать, чтобы связка nginx-syslog через unix socket не глючила и не теряла сообщения. Причина проблемы ведь не в nginx, причина проблемы в syslog, потому что он читает данные в один поток, и не успевает их обрабатывать. А когда вы создаете 10 потоков на Python - то вы увеличиваете мощность "читателя" в 10 и более раз, потому что в такой ситуации в каждый из unix socket`ов уходит в 10 раз меньше сообщений и тогда читающая сторона успевает эти сообщения читать и поэтому у nginx нет причин чтобы дропать сообщения из-за того, что syslog не успевает их читать из unix socket`а. >> Причина, почему у Вас не получилось настроить ротацию лог-файлов >> при записи логов "напрямую с nginx-а в файл" может быть в такой >> ситуации только одна - для ротации лог-файлов Вы использовали >> сигнал HUP а не сигнал USR1 - именно поэтому у Вас не получилось. > Вероятно вам не раз приходилось сталкиваться с подобным, и вы автоматически считаете, что так поступают все. > Распространенная модель поведения. > Еще раз -- единственная новость тут для меня была в том, что у меня не получилось. Я именно так и понял Ваш ответ: >>> Если вы предлагаете писать напрямую с nginx-а в файл -- >>> сделайте у себя ротацию файлов с интервалом 30 сек >>> при 200-250 тыс подключений/сек... >>> >>> Если у вас уже есть такое рабочее решение - >>> поделитесь опытом, буду рад вас выслушать. Потому что если бы у Вас получилось - то Вы бы не говорили, что Вам не удалось настроить ротацию логов раз в 30 секунд при 200-250 тысяч подключений в секунду и Вы бы тогда не говорили, что были бы рады выслушать как сделать рабочее решение при таких параметрах нагрузки. Если бы Вы для ротации использовали бы SIGUSR1 а не SIGHUP - тогда бы у Вас все получилось и вообще не надо было бы говорить про количество подключений и интервал ротации, потому что через SIGUSR1 ротацию логов можно делать хоть раз в секунду, при любом количестве подключений, хоть 100 миллионов в секунду. Каким еще способом можно понять Ваш ответ, если Вы мне в ответ приводите информацию про параметры нагрузки и спрашиваете меня есть ли у меня такое рабочее решение этой Вашей проблемы X с ротацией лог-файлов. > Все как раз получилось, дальше с этим работать было неудобно. Читать из unix socket`а удобно, паралельно в 10 потоков, а читать из одного текстового лог-файла - неудобно? А в чем именно неудобство чтения логов из файла? > Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются запросы. > Обращения жестко делятся на несколько типов, тип определяется значением переменной в запросе, запросы БЕЗ этой переменной игнорируются. > Беки ведут статистику сколько и какого типа запросов они получили, эти данные сливаются в БД и хранятся с дискретностью 20минут. > > Регулярно требуется "нестандартная" статистика, например > "средний размер ($body_bytes_sent) по запросам типа "sc012" за сутки" > "соотношение обращений по http и https ($schema) по запросам типа "q1wr" за час" > "наименьшее/среднее/наибольшее время ($request_time) по запросам типа "sc012" за..." > "объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) в общем объеме трафика (сумма $body_bytes_sent всех запросов)" > и т.д. > нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в логах реверс-прокси. Если Вам не достаточно тех метрик, которые Angie умеет отдавать напрямую в Prometheus, рассматривали ли Вы как вариант решения своей задачи улититы https://github.com/google/mtail https://github.com/timberio/vector ? Referer: https://github.com/freeseacher/metrics_ru_faq > как минимум создам дополнительную нагрузку на сетевой стек ОС-и, ибо tcp как ни крути более затратен по сравнению с unixSocket. > Или с высокой вероятностью упрусь в теже ограничения unixSocket если отказаться от tcp со всеми дальше вытекающими. > При размещении на другом сервере решить проблему исчерпания портов для соединения прокси-проски. (а их "в моменте" 350-400 тыс), да, без body их будет меньше, но все-таки довольно много. если использовать keepalive в блоке upstream, то не упретесь, потому что одно и то же соединение к backend`у будет повторно использоваться для отправки на backend большого количества запросов, и не будет такой ситуации, что на каждый запрос открывается новое подлюкчение к backend`у, так что исчерпания портов не произойдет. дефолтовое значение proxy_http_version 1.0 - это плоая идея, потому что в http 1.0 коцен файла - это закрытие соедения, а оно может быть и по причине ошибки, и nginx будет тогда отдавать битые ответы. Если включить proxy_http_version 1.1 - такой проблемы не будет. И заодно - можно будет использовать http keepalive при подключении к backend`у, чтобы по одному tcp соединению передавать большое количество запросов. > Моя проблема "Х": > Ограниченность в связке nginx->unixSocket->syslog > Мое решение проблемы "Х": распараллелить процесс, чтоб проблема "Х" не возникала в принципе на необходимых мне уровнях. Ваша проблема X в том, что Вам нужна нестандартная статистика по запросам. А оптимизировать скорость работы nginx->unixSocket->syslog - это есть проблема Y которая к исходной Вашей проблеме X не имеет вообще никакого отношения. > Объективно оптимального решения практически любой проблемы не существует в природе. Практически всегда можно найти оптимальное ли близкое к оптимальному решение, надо просто осознавать какие критерии важны в первую очередь, а какие являются второстепенными - и исходя из условий задачи - всегда можно найти оптимальное или близкое к оптимальному решение для этих условий. Поэтому, например, иногда будет более оптимальным VPN WireGuard, а иногда - более оптимальным будет VPN OpenVPN. Все зависит от критериев оптимальности и всех условий задачи. > Если у вас в крсе обучения был такой предмет как "методы оптимизации" -- вы должны это понимать. > Вспомните задачки из курса: > На одну и ту же таблицу данных: > Постройте оптимальный маршрут по расстоянию. > Постройте оптимальный маршрут по времени. > Постройте оптимальный маршрут по загрузке. > Постройте оптимальный с учетом состояния дорог. > И ответы везде разные, а табличка-то одна :) > И это которые простые задачки.... И что, Вы разве тогда находили _субъективно_ оптимальные решения? И у каждого из 30 студентов в группе было свое собственное решение, каждой из этих задач, которое он и считал самым оптимальным? Или же для каждой этой задачи оптимальные решения получались одинаковыми или очень сильно похожими друг на друга? > Эффективность с точки зрения чего? > Мы с вами эффективность считаем по совершенно разным критериям. > Это не хорошо и не плохо. Это просто по-разному :) > Ваше мнение может отличаться от моего. при одинаковых критериях эффективности - тоже будут разные решения? > Объективно оптимального решения практически любой проблемы не существует в природе. То есть, у каждого будет свое собственное _субъективное_ понимание того, какое решение является наиболее эффективным при четко заданных критериях эффективности? > Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно решать что мне надо :) Решайте сами, я просто хотел понять Вашу исходную задачу X, поэтому и задавал уточняющие вопросы. > Про оптимальность я выше упоминал. > Оптимизировать можно по разным критериям. > Вы исходите из одних критериев оптимальности, я из других. > И это абсолютно нормально. Ненормально, если при одних и тех же критериях оптимальности и эффективности получаются совершенно различные решения - так не может быть. > Не стоит убеждать меня в "неправильности" моих критериев. Проблема XY - это не про неправильность критериев. Проблема XY - это про то, что Вы ищете решение проблемы Y, хотя на самом деле Вам нужно решение проблемы X. > Есть большое подозрение, что уже на текущем этапе по данному вопросу осталось лишь 2 собеседника. я не настаиваю на продолжении диалога, если Вам этот разговор не интересен, не полезен или доставляет какой-то дискомфорт. On 14.02.2024 23:58, Anatoliy Melnik via nginx-ru wrote: > 2. Хорошо -- пусть каждый прокси сам свое считает: исключаются > потери по сети, каждый прокси в этом плане становится > автономно-независимой единицей. > При высоких нагрузках -- расхождения в статистике. Каким образом можно получить расхождения в статистике, если на диске есть свободное место - в лог пишутся все сообщения, потерь не может быть в этом случае. Получить потери можно в случае использования syslog и unix socket`ов - если читающая сторона не будет успевать читать данные из сокета - у nginx не останется иных варантов, кроме как дропать часть записей. При записи логов в файлы - этот вариант исключен, если на разделе есть достаточное количество свободного места. Хотя бы даже одним только этим свойством запись логов в файлы намного лучше записи логов в unix socket`ы. Потому что, грубо говоря, при использовании unix socket`ов, у Вас есть очень небольшой буфер в памяти и он очень быстро может переполниться, что и приведет к потере части записей. А при использовании лог-файлов на диске и ротации логов по SIGUSR1 - в качестве такого "буфера" у Вас выступает все свободное место на диске - поэтому не требуется та высокая степень синхронности, которая необходима при использовании unix socket`ов. Какой смысл в статистике, если она будет не точкной и ошибочной, если система сбора статистики будет очень хрупкой и будет терять часть сообщений при всплесках пиковой нагрузки на сервис? Если же одним из критериев эффективности и оптимальности системы сбора статистики считать полноту статистики и отсутствие потерь - в таком случае однозначно необходимо предпочесть именно логи, куда будет писать сам nginx напрямую и ротацию логов через SIGUSR1. Если же потери части входных данных Вам не создают проблем, то это у Вас какая-то не совсем понятная статистика получается. Зачем она нужна, если эти система очень легко может терять часть записей? > 3. Хорошо, запишем в файл прям с nginx-а. файл распарсим-посчитаем. > 3а.простыми методами (типа grep и awk) обработка статистики за 30 секунд занимает больше 30 секунд. а если через https://github.com/google/mtail https://github.com/timberio/vector. ? Ведь не Вы же первый сталкиваетесь с задачей обработки логов. И кроме grep и awk придумано и создано большое количество инструментов для этого. > 3б.пишем в файл->читаем из файла->удаляем файл в объемах 30-60Мбайт/сек... лично мое мнение - файл тут явно лишний. (Ваше мнение может отличатся от моего, я абсолютно не настаиваю). Вас не смущает тот факт, что буфер в памяти может очень легко и быстро переполниться и это приведет к потере части данных? Это не важно? Но судя по тому, что именно с этой проблемой Вы сюда и пришли - для Вас это важно и критично, чтобы потерь данных у Вас не было. Если это критично, чтобы не было потерь - тогда логично построить систему которая в принципе не способна терять данные, если только есть достаточное количество свободного места на диске. Разве не так? >>> Чисто техничски можно и без access-логов, будете сами >> реализовывать нечто >>> подобное -- выберете более близкое вам решение. >> >> Вы не назвали альтернативные решения. > Это сделали за меня: > Написать свой бекэнд (как вариант на Go) и отзеркалировать туда запросы с фронотов.... не только, еще можно использовать Angie и экспортировать статистику напрямую в Prometheus, если этого будет достаточно. > Из лабиринтов собственных заблуждений > скорее выберется тот, кто готов признать, что он заблуждается. А он признает? > Лично я этот путь приодолел не единожды. Чего и вам желаю. Спасибо. В чем мои заблуждения? > Разве я кого-то пытался убедить, что его подход в корне не верен, как в этом пытаются убедить меня? Если цель кого-то пытаться убедить в истинности своей точки зрения - это полемика. Если цель найти наиболее оптимальное решение проблемы/задачи - это дискуссия. Отличие только в целях и мотивации, внешнему наблюдателю они могут быть не видны и не понятны, если он воспринимает других через призму своего собственного сознания и своих собственных установок/предубеждений. > Я же свои задачи решаю, а не ваши. Задачи очень схожие часто. И можно поделиться своим опытом с другими. Но чтобы был возможен процесс поиска наиболее оптимального решения задачи - необходимо знать условия задачи и критерии оптимизации / эффективности. Причем, поиска решения настоящей задачи X о сборе статистики, а не придуманной задачи Y про оптимизацию syslog/unix socket. -- Best regards, Gena From andrey на kopeyko.ru Thu Feb 15 07:17:57 2024 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 15 Feb 2024 10:17:57 +0300 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: <2ff6d549235f43e11fe46c1ede1c1bcd@kopeyko.ru> Gena Makhomed писал 2024-02-15 04:17: > On 14.02.2024 19:59, Maxim Dounin wrote: > >> Подобный подход можно понять: они владеют проектом, и могут с ним >> делать всё, что считают нужным, включая подобные маркетинговые >> акции. Это, однако, противоречит нашемоу соглашению. И, что более >> важно, я больше не имею возможности как-либо контролировать >> изменения, которые вносят в nginx в F5, и не могу рассматривать >> nginx как открытый и свободный проект, разрабатываемый для общего >> блага. >> >> Так что, начиная с сегодняшнего дня, я больше не участвую в >> разработке nginx'а в рамках F5. Вместо этого я запускаю >> альтернативный проект, управлять которым будут разработчики, а не >> корпоративные структуры: >> >> http://freenginx.org/ >> >> Цель проекта - обеспечить разработку nginx'а, свободную от >> произвольного корпоративного вмешательства. Помощь и участие >> приветствуются. Надеюсь, проект будет полезен для всех. > > Максим, тут есть одна очень большая проблема. > > Владельцем торговой марки NGINX является компания F5 NETWORKS, INC. > https://trademarks.justia.com/853/12/nginx-85312802.html > > Своего разрешения на использование своей торговой марки NGINX > F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст. Максим, Геннадий беспокоится обоснованно, и соображения написал все очень верные. Если хочешь, могу попробовать организовать тебе консультацию по "доменам, IP, ТМ и судебном опыте вокруг этого всего" у специалистов Ру-Центра. За последние 25 лет они на этом не одну собачью стаю съели, и по буржуйским доменам тоже. > > А вот дальнейшее развитие событий предусмотреть совсем не трудно. > Они будут преследовать Вас в судебном порядке за trademark infringement > > Сначала - будет UDRP - Uniform Domain Name Dispute Resolution > https://www.icann.org/resources/pages/trademark-infringement-2017-06-20-en > а потом - могут в конечном итоге и вообще отобрать > у Вас домен freenginx.org этот домен станет их собственностью. > Учитывая их доходы - они смогут найти деньги на очень хороших > юристов и адвокатов, так что вопрос утраты контроля над доменом > freenginx.org - это не вопрос "если", это вопрос "когда" > - они это сделают. А если не сделают сейчас - то смогут сделать > в любой момент в будущем, полностью отобрав этот домен и запретив > Вам каким-либо образом использовать торговую марку NGINX. Например, > они могут заняться этим вопросом не сразу, а через некоторое время, > когда Ваш проэкт наберет некоторую популярность и посещаемость сайта > станет высокой. Имеет ли смысл так сильно рисковать основной веткой? > https://www.wipo.int/amc/en/domains/guide/ > > > https://en.wikipedia.org/wiki/Trademark_infringement > - законодательство тут на их стороне и по закону они будут правы. > В https://en.wikipedia.org/wiki/WIPO входят практически все страны мира > и trademark infringement является нарушением закона практически в любой > стране. Даже если они не будут заниматься тем, чтобы отбирать у Вас > права на домен freenginx.org - они это смогут сделать в любой момент > времени в будущем, когда посчитают это целесообразным. > Может быть лучше будет переименовать проект в какое-то другое имя, > в котором вообще не будут упоминаться ничьи торговые марки? > > Когда-то проекту CentOS пришлось не только убирать все упоминания > торговой марки Red Hat - они были вынуждены даже убрать все упоминания > Red Hat и заменить их на PNAELV. > > PNAELV - это Prominent North American Enterprise Linux Vendor, > это слово не является ничьей торговой маркой и его использование > не запрещено. А вот торговую марку Red Hat без их разрешения > использовать нельзя. Аналогично будет и с торговой маркой NGINX. > > Аналогично, например, было и с торговой маркой Apache - > из-за чего все дистрибутивы были вынуждены переименовать > веб-сервер в httpd. > > Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то > имя, которое не является ничьей торговой маркой и для защиты этого > имени - зарегистрировать свою торговую марку, чтобы не было потом > ситуации "обратного захвата домена" - это когда вы используете > какое-то доменное имя, например, something.ru, при этом - > something не ялвяется торговой маркой. И потом, через какое-то > время - какой-то совершенно посторонний человек, регистрирует > торговую марку something, подает на Вас в суд и по решению суда > отбирает у Вас контроль над доменом something.ru не смотря на то, > что эта торговая марка не была зарегистрирована в момент регистрации > Вами домена something.ru - это ничего не меняет, суд будет на стороне > владельца торговой марки. Это и называется "обратный захват домена". > Для доменов зарегистрированных в международных TLD - ситуация не такая > однозначная, если домен был зарегистрирован до момента регистрации > соответствующей торговой марки - то еще могут быть варианты. Но если > Вы регистрируете домен freenginx.org в тот момент времени, когда > F5 NETWORKS, INC. является владельцем торговой марки NGINX - тогда > шансов удержать контроль над этим доменом - практически нет, > ведь Вы же здесь без их разрешения используете их торговую марку. > > Это примерно то же самое, что кто-то зарегистрирует домен > freewindows.org и попробует создавать там Open Source > конкурента для Microsoft Windows. Не будет это работать. > > Например, если компания Microsoft отобрала даже домен MikeRoweSoft.com > у канадского студента Mike Rowe который занимался веб-дизайном, > то и домен freewindows.org она точно так же отберет. > https://en.wikipedia.org/wiki/Microsoft_v._MikeRoweSoft > > Да и торговая марка Linux принадлежит Линусу Торвальдсу только > потому что какой-то коммерсант заренистрировал эту торговую марку > и потом пытался требовать деньги от производителей дистрибутивов > за разрешение использовать принадлежащую ему торговую марку. > https://en.wikipedia.org/wiki/Linux_Mark_Institute > > Поэтому - Gregory Kurtzer чтобы не наступать на эти грабли - > с самого начала зарегистрировал торговые марки > > Rocky Enterprise Software Foundation™ > RESF™ > Rocky Linux™ > > на Rocky Enterprise Software Foundation, чтобы никто не мог > у него отобрать его домены и никто не мог бы потом запретить ему > использовать торговую марку Rocky Linux и чтобы проект мог бы > нормально развиваться. > > Поэтому - для 100% защиты проекта - необходимо иметь свою торговую > марку > и необходимо иметь домен, который защищен с помощью этой торговой > марки. > В современном мире таку защиту должы иметь и Open Source проекты. > И наверное, даже в первую очередь именно Open Source проекты, > поскольку они являют собой наибольшую угрозу и опасность > для корпораций. В фильме https://ru.wikipedia.org/wiki/Revolution_OS > это очень подробно рассказывается, наиболее качественный перевод > этого фильма «Revolution OS» ну русский язык - от Дмитрия Бачило. > https://www.youtube.com/watch?v=n1F_MfLRlX0 -- Best regards, Andrey A. Kopeyko From corochoone на gmail.com Thu Feb 15 09:06:40 2024 From: corochoone на gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCS0LjRgdC70L7QsdC+0LrQvtCy?=) Date: Thu, 15 Feb 2024 12:06:40 +0300 Subject: announcing freenginx.org In-Reply-To: <2ff6d549235f43e11fe46c1ede1c1bcd@kopeyko.ru> References: <2ff6d549235f43e11fe46c1ede1c1bcd@kopeyko.ru> Message-ID: С моей колокольни: вечная проблема Open Source проектов - мало активных разработчиков, потому что бесплатно - с одной стороны. Коммерциализация и плохой менеджмент проектов, которые НЕ Open Source. Можно пачку новых freenginx'ов создать, вопрос - хватит ли сил это разрабатывать и поддерживать? Сколько разных форков как появились так и пропали спустя пару лет. чт, 15 февр. 2024 г. в 10:18, Andrey Kopeyko : > Gena Makhomed писал 2024-02-15 04:17: > > On 14.02.2024 19:59, Maxim Dounin wrote: > > > >> Подобный подход можно понять: они владеют проектом, и могут с ним > >> делать всё, что считают нужным, включая подобные маркетинговые > >> акции. Это, однако, противоречит нашемоу соглашению. И, что более > >> важно, я больше не имею возможности как-либо контролировать > >> изменения, которые вносят в nginx в F5, и не могу рассматривать > >> nginx как открытый и свободный проект, разрабатываемый для общего > >> блага. > >> > >> Так что, начиная с сегодняшнего дня, я больше не участвую в > >> разработке nginx'а в рамках F5. Вместо этого я запускаю > >> альтернативный проект, управлять которым будут разработчики, а не > >> корпоративные структуры: > >> > >> http://freenginx.org/ > >> > >> Цель проекта - обеспечить разработку nginx'а, свободную от > >> произвольного корпоративного вмешательства. Помощь и участие > >> приветствуются. Надеюсь, проект будет полезен для всех. > > > > Максим, тут есть одна очень большая проблема. > > > > Владельцем торговой марки NGINX является компания F5 NETWORKS, INC. > > https://trademarks.justia.com/853/12/nginx-85312802.html > > > > Своего разрешения на использование своей торговой марки NGINX > > F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст. > > Максим, > > Геннадий беспокоится обоснованно, и соображения написал все очень > верные. > > Если хочешь, могу попробовать организовать тебе консультацию по > "доменам, IP, ТМ и судебном опыте вокруг этого всего" у специалистов > Ру-Центра. За последние 25 лет они на этом не одну собачью стаю съели, и > по буржуйским доменам тоже. > > > > > > А вот дальнейшее развитие событий предусмотреть совсем не трудно. > > Они будут преследовать Вас в судебном порядке за trademark infringement > > > > Сначала - будет UDRP - Uniform Domain Name Dispute Resolution > > > https://www.icann.org/resources/pages/trademark-infringement-2017-06-20-en > > а потом - могут в конечном итоге и вообще отобрать > > у Вас домен freenginx.org этот домен станет их собственностью. > > Учитывая их доходы - они смогут найти деньги на очень хороших > > юристов и адвокатов, так что вопрос утраты контроля над доменом > > freenginx.org - это не вопрос "если", это вопрос "когда" > > - они это сделают. А если не сделают сейчас - то смогут сделать > > в любой момент в будущем, полностью отобрав этот домен и запретив > > Вам каким-либо образом использовать торговую марку NGINX. Например, > > они могут заняться этим вопросом не сразу, а через некоторое время, > > когда Ваш проэкт наберет некоторую популярность и посещаемость сайта > > станет высокой. Имеет ли смысл так сильно рисковать основной веткой? > > https://www.wipo.int/amc/en/domains/guide/ > > > > > > https://en.wikipedia.org/wiki/Trademark_infringement > > - законодательство тут на их стороне и по закону они будут правы. > > В https://en.wikipedia.org/wiki/WIPO входят практически все страны мира > > и trademark infringement является нарушением закона практически в любой > > стране. Даже если они не будут заниматься тем, чтобы отбирать у Вас > > права на домен freenginx.org - они это смогут сделать в любой момент > > времени в будущем, когда посчитают это целесообразным. > > Может быть лучше будет переименовать проект в какое-то другое имя, > > в котором вообще не будут упоминаться ничьи торговые марки? > > > > Когда-то проекту CentOS пришлось не только убирать все упоминания > > торговой марки Red Hat - они были вынуждены даже убрать все упоминания > > Red Hat и заменить их на PNAELV. > > > > PNAELV - это Prominent North American Enterprise Linux Vendor, > > это слово не является ничьей торговой маркой и его использование > > не запрещено. А вот торговую марку Red Hat без их разрешения > > использовать нельзя. Аналогично будет и с торговой маркой NGINX. > > > > Аналогично, например, было и с торговой маркой Apache - > > из-за чего все дистрибутивы были вынуждены переименовать > > веб-сервер в httpd. > > > > Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то > > имя, которое не является ничьей торговой маркой и для защиты этого > > имени - зарегистрировать свою торговую марку, чтобы не было потом > > ситуации "обратного захвата домена" - это когда вы используете > > какое-то доменное имя, например, something.ru, при этом - > > something не ялвяется торговой маркой. И потом, через какое-то > > время - какой-то совершенно посторонний человек, регистрирует > > торговую марку something, подает на Вас в суд и по решению суда > > отбирает у Вас контроль над доменом something.ru не смотря на то, > > что эта торговая марка не была зарегистрирована в момент регистрации > > Вами домена something.ru - это ничего не меняет, суд будет на стороне > > владельца торговой марки. Это и называется "обратный захват домена". > > Для доменов зарегистрированных в международных TLD - ситуация не такая > > однозначная, если домен был зарегистрирован до момента регистрации > > соответствующей торговой марки - то еще могут быть варианты. Но если > > Вы регистрируете домен freenginx.org в тот момент времени, когда > > F5 NETWORKS, INC. является владельцем торговой марки NGINX - тогда > > шансов удержать контроль над этим доменом - практически нет, > > ведь Вы же здесь без их разрешения используете их торговую марку. > > > > Это примерно то же самое, что кто-то зарегистрирует домен > > freewindows.org и попробует создавать там Open Source > > конкурента для Microsoft Windows. Не будет это работать. > > > > Например, если компания Microsoft отобрала даже домен MikeRoweSoft.com > > у канадского студента Mike Rowe который занимался веб-дизайном, > > то и домен freewindows.org она точно так же отберет. > > https://en.wikipedia.org/wiki/Microsoft_v._MikeRoweSoft > > > > Да и торговая марка Linux принадлежит Линусу Торвальдсу только > > потому что какой-то коммерсант заренистрировал эту торговую марку > > и потом пытался требовать деньги от производителей дистрибутивов > > за разрешение использовать принадлежащую ему торговую марку. > > https://en.wikipedia.org/wiki/Linux_Mark_Institute > > > > Поэтому - Gregory Kurtzer чтобы не наступать на эти грабли - > > с самого начала зарегистрировал торговые марки > > > > Rocky Enterprise Software Foundation™ > > RESF™ > > Rocky Linux™ > > > > на Rocky Enterprise Software Foundation, чтобы никто не мог > > у него отобрать его домены и никто не мог бы потом запретить ему > > использовать торговую марку Rocky Linux и чтобы проект мог бы > > нормально развиваться. > > > > Поэтому - для 100% защиты проекта - необходимо иметь свою торговую > > марку > > и необходимо иметь домен, который защищен с помощью этой торговой > > марки. > > В современном мире таку защиту должы иметь и Open Source проекты. > > И наверное, даже в первую очередь именно Open Source проекты, > > поскольку они являют собой наибольшую угрозу и опасность > > для корпораций. В фильме https://ru.wikipedia.org/wiki/Revolution_OS > > это очень подробно рассказывается, наиболее качественный перевод > > этого фильма «Revolution OS» ну русский язык - от Дмитрия Бачило. > > https://www.youtube.com/watch?v=n1F_MfLRlX0 > > -- > Best regards, > Andrey A. Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Feb 15 10:18:03 2024 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Feb 2024 13:18:03 +0300 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: Hello! On Thu, Feb 15, 2024 at 03:17:04AM +0200, Gena Makhomed wrote: > On 14.02.2024 19:59, Maxim Dounin wrote: > > > Подобный подход можно понять: они владеют проектом, и могут с ним > > делать всё, что считают нужным, включая подобные маркетинговые > > акции. Это, однако, противоречит нашемоу соглашению. И, что более > > важно, я больше не имею возможности как-либо контролировать > > изменения, которые вносят в nginx в F5, и не могу рассматривать > > nginx как открытый и свободный проект, разрабатываемый для общего > > блага. > > > > Так что, начиная с сегодняшнего дня, я больше не участвую в > > разработке nginx'а в рамках F5. Вместо этого я запускаю > > альтернативный проект, управлять которым будут разработчики, а не > > корпоративные структуры: > > > > http://freenginx.org/ > > > > Цель проекта - обеспечить разработку nginx'а, свободную от > > произвольного корпоративного вмешательства. Помощь и участие > > приветствуются. Надеюсь, проект будет полезен для всех. > > Максим, тут есть одна очень большая проблема. > > Владельцем торговой марки NGINX является компания F5 NETWORKS, INC. > https://trademarks.justia.com/853/12/nginx-85312802.html > > Своего разрешения на использование своей торговой марки NGINX > F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст. > > А вот дальнейшее развитие событий предусмотреть совсем не трудно. > Они будут преследовать Вас в судебном порядке за trademark infringement Спасибо за ссылки. Тут есть несколько факторов: Во-первых, название freenginx - хорошо отражает суть проекта. Поэтому оно и было выбрано. Во-вторых, я, конечно, не юрист, но freenginx и NGINX - это два разных названия, и вероятность успешных претензий я оцениваю как небольшую. Кроме того, неявное разрешение на использование торговой марки подразумевается лицензией. Ну и в-третьих, если всё-таки компания F5 решит играть в эти игры, то это хорошо продемонстрирует их отношение к свободному программному обеспечению. Я не думаю, что это случиться, скорее рассчитываю, что компания одумается и будет поддерживать проект, ибо это в первую очередь в их собственных интересах, но поживём - увидим. -- Maxim Dounin http://mdounin.ru/ From izorkin на gmail.com Thu Feb 15 10:20:20 2024 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 15 Feb 2024 13:20:20 +0300 Subject: announcing freenginx.org In-Reply-To: <54895bb9-fb4a-4db9-a0ed-61a30292b867@megaline.kg> References: <1566332227.20240214213254@gmail.com> <1255460295.20240214222501@gmail.com> <54895bb9-fb4a-4db9-a0ed-61a30292b867@megaline.kg> Message-ID: <755075939.20240215132020@gmail.com> Добрый день, Raven. Как вариант есть новый формат форумов на базе flarum и discourse. Ещё можно поднять свой git репозиторий на базе Gitea/Forgejo. К тому же в Forgejo планируется внедрение протокола ForgeFed, который позволит создавать запросы и PR между другими git инстансами: https://forgefed.org      Вы писали 15 февраля 2024 г., 5:41:17: > Форумы давно мертвы как формат общения. Исправно рабатают только старые площадки, с давно наруленным сообществом, но и они переживают не лучшие времена. Списки рассылки, кстати, направляются туда же. Всем теперь issues на github-е подавай   --  С уважением,  Izorkin                          mailto:izorkin на gmail.com ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From raven_kg на megaline.kg Thu Feb 15 10:27:29 2024 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 15 Feb 2024 16:27:29 +0600 Subject: announcing freenginx.org In-Reply-To: <755075939.20240215132020@gmail.com> References: <1566332227.20240214213254@gmail.com> <1255460295.20240214222501@gmail.com> <54895bb9-fb4a-4db9-a0ed-61a30292b867@megaline.kg> <755075939.20240215132020@gmail.com> Message-ID: <774d72b7-a9cd-49b2-9198-131b812dce47@megaline.kg> В каком-то из обсуждений Максим упоминал, что не сторонник git и связанных с ним технологий. Так, что наверное все, что прибито к git гвоздями здесь не поможет. Discourse да, возможно и взлетит, но это наверное больше для пользователей, а не для обсуждения разработки. 15.02.2024 16:20, izorkin на gmail.com пишет: > > Добрый день, Raven. > > > Как вариант есть новый формат форумов на базе flarum и discourse. > > Ещё можно поднять свой git репозиторий на базе Gitea/Forgejo. К тому > > же в Forgejo планируется внедрение протокола ForgeFed, который позволит > > создавать запросы и PR между другими git инстансами: > > https://forgefed.org > > Вы писали 15 февраля 2024 г., 5:41:17: > > Форумы давно мертвы как формат общения. Исправно рабатают только > старые площадки, с давно наруленным сообществом, но и они > переживают не лучшие времена. Списки рассылки, кстати, > направляются туда же. Всем теперь issues на github-е подавай :smile: > > > -- > С уважением, >  Izorkin mailto:izorkin на gmail.com > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Feb 15 10:31:48 2024 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 15 Feb 2024 13:31:48 +0300 Subject: announcing freenginx.org In-Reply-To: <2ff6d549235f43e11fe46c1ede1c1bcd@kopeyko.ru> References: <2ff6d549235f43e11fe46c1ede1c1bcd@kopeyko.ru> Message-ID: Hello! On Thu, Feb 15, 2024 at 10:17:57AM +0300, Andrey Kopeyko wrote: > Gena Makhomed писал 2024-02-15 04:17: > > On 14.02.2024 19:59, Maxim Dounin wrote: > > > > > Подобный подход можно понять: они владеют проектом, и могут с ним > > > делать всё, что считают нужным, включая подобные маркетинговые > > > акции. Это, однако, противоречит нашемоу соглашению. И, что более > > > важно, я больше не имею возможности как-либо контролировать > > > изменения, которые вносят в nginx в F5, и не могу рассматривать > > > nginx как открытый и свободный проект, разрабатываемый для общего > > > блага. > > > > > > Так что, начиная с сегодняшнего дня, я больше не участвую в > > > разработке nginx'а в рамках F5. Вместо этого я запускаю > > > альтернативный проект, управлять которым будут разработчики, а не > > > корпоративные структуры: > > > > > > http://freenginx.org/ > > > > > > Цель проекта - обеспечить разработку nginx'а, свободную от > > > произвольного корпоративного вмешательства. Помощь и участие > > > приветствуются. Надеюсь, проект будет полезен для всех. > > > > Максим, тут есть одна очень большая проблема. > > > > Владельцем торговой марки NGINX является компания F5 NETWORKS, INC. > > https://trademarks.justia.com/853/12/nginx-85312802.html > > > > Своего разрешения на использование своей торговой марки NGINX > > F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст. > > Максим, > > Геннадий беспокоится обоснованно, и соображения написал все очень верные. > > Если хочешь, могу попробовать организовать тебе консультацию по "доменам, > IP, ТМ и судебном опыте вокруг этого всего" у специалистов Ру-Центра. За > последние 25 лет они на этом не одну собачью стаю съели, и по буржуйским > доменам тоже. Спасибо, я пока рассчитываю на отсутствие проблем в этом вопросе, смотри ответ Геннадию. Если возникнут - будем решать их по мере поступления. -- Maxim Dounin http://mdounin.ru/ From anatoliy.melnik на showjet.ru Thu Feb 15 10:49:44 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Thu, 15 Feb 2024 13:49:44 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <739571819.16525971.1707994184471.JavaMail.zimbra@showjet.ru> Gena Makhomed Wrote: ------------------------------------------------------- > On 14.02.2024 13:30, Anatoliy Melnik via nginx-ru wrote: > > >>> Если вы предлагаете писать напрямую с nginx-а в файл -- > >>> сделайте у себя ротацию файлов с интервалом 30 сек > >>> при 200-250 тыс подключений/сек... > >>> > >>> Если у вас уже есть такое рабочее решение - > >>> поделитесь опытом, буду рад вас выслушать. > > >> В этом сообщении Вы говорите о том, что Вы пробовали писать логи > >> "напрямую с nginx-а в файл" с ротацией с интервалом в 30 секунд, > >> при при 200-250 тыс подключений/сек, и у Вас не получилось > >> создать "рабочее решение". > > > Вы привели ПОЛНУЮ ЦИТАТУ! ОТЛИЧНО! > > Я сказал ровно то, что и хотел сказать. > > Где вы прочитали про "не получилось" ??? > > Пожалуйста процитируйте... без своих домыслов и фантазий. > > А Вы помните, на какой именно мой вопрос Вы отвечали? Напомню: > https://mailman.nginx.org/pipermail/nginx-ru/2024-February/L3UKQXO2PKI > HBFWHHTQRKDQY53XGE5BN.html > > Я же практически прямым текстом Вам написал, что Ваша попытка > выжать максимум производительности из связки nginx-syslog - > это есть проблема Y и задал Вам вопрос, какую именно проблему X > Вы таким способом пытаетесь решить. И что я слышу в ответ - > что Вы не смогли получить работающую систему при 200-250 тысяч > подключений в секунду и при ротации логов раз в 30 секунд - именно > это и значают Ваши слова "Если у вас уже есть такое рабочее решение > - поделитесь опытом, буду рад вас выслушать" - если Вы спрашиваете, > как именно построить рабочую систему ротации логов при такой > нагрузке, > то логично предположить, что Вы попытались это сделать, у Вас это > не получилось и Вы тогда пошли другим путем - писать логи > через syslog unix socket`ы, потому что там ротации не надо делать. > Сойдемся на формулировке: "Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее двойное толкование в ту или иную сторону по желанию сторон." Если таковая вас устроит. Дальнейшее перемалывание темы ротации лично для меня интереса не представляет. Т.к. концептуально является переливанием из пустого в порожнее. > > Читать из unix socket`а удобно, паралельно в 10 потоков, > а читать из одного текстового лог-файла - неудобно? > А в чем именно неудобство чтения логов из файла? > > > Есть 3 реверс-прокси, и от 15 до 30 беков, на которые и проксируются > запросы. > > Обращения жестко делятся на несколько типов, тип определяется > значением переменной в запросе, запросы БЕЗ этой переменной > игнорируются. > > Беки ведут статистику сколько и какого типа запросов они получили, > эти данные сливаются в БД и хранятся с дискретностью 20минут. > > > > Регулярно требуется "нестандартная" статистика, например > > "средний размер ($body_bytes_sent) по запросам типа "sc012" за > сутки" > > "соотношение обращений по http и https ($schema) по запросам типа > "q1wr" за час" > > "наименьшее/среднее/наибольшее время ($request_time) по запросам > типа "sc012" за..." > > "объем запросов типа "q1wr" (сумма $body_bytes_sent таких запросов) > в общем объеме трафика (сумма $body_bytes_sent всех запросов)" > > и т.д. > > нет смысла каждый раз перекраивать ПО на беках, ведь все это есть в > логах реверс-прокси. > > Если Вам не достаточно тех метрик, которые Angie > умеет отдавать напрямую в Prometheus, рассматривали > ли Вы как вариант решения своей задачи улититы > > https://github.com/google/mtail > > https://github.com/timberio/vector > > ? Нет, не рассматривал. На данном этапе не интересно и не вижу необходимости ломать имеющееся. > > Referer: https://github.com/freeseacher/metrics_ru_faq > > > > как минимум создам дополнительную нагрузку на сетевой стек ОС-и, ибо > tcp как ни крути более затратен по сравнению с unixSocket. > > Или с высокой вероятностью упрусь в теже ограничения unixSocket если > отказаться от tcp со всеми дальше вытекающими. > > При размещении на другом сервере решить проблему исчерпания портов > для соединения прокси-проски. (а их "в моменте" 350-400 тыс), да, без > body их будет меньше, но все-таки довольно много. > > если использовать keepalive в блоке upstream, то не упретесь, > потому что одно и то же соединение к backend`у будет повторно > использоваться для отправки на backend большого количества запросов, > и не будет такой ситуации, что на каждый запрос открывается новое > подлюкчение к backend`у, так что исчерпания портов не произойдет. > дефолтовое значение proxy_http_version 1.0 - это плоая идея, потому > что в http 1.0 коцен файла - это закрытие соедения, а оно может быть > и по причине ошибки, и nginx будет тогда отдавать битые ответы. > Если включить proxy_http_version 1.1 - такой проблемы не будет. > И заодно - можно будет использовать http keepalive > при подключении к backend`у, чтобы по одному tcp > соединению передавать большое количество запросов. > > > Моя проблема "Х": > > Ограниченность в связке nginx->unixSocket->syslog > > Мое решение проблемы "Х": распараллелить процесс, чтоб проблема "Х" > не возникала в принципе на необходимых мне уровнях. > Все. Точка. При износе какой-то запчасти в механизме чаще меняют запчасть, а не механизм. Я свой случай отношу именно к категории про запчасть. Вы предлагаете замену всего при весьма не очевидных плюсах в результате. Зачем мне менять рабочее, устраивающее меня решение на другое, которое в любом случае придется допиливать и отлаживать, подгонять под свои цели? Чтоб было лучше? Лучше кому? И лучше в чем? Что такого я получу в результате, чего у меня нет сейчас? Полученное решение эффективно расходует мое рабочее время, занимая ровно "0" секунд в день на его обслуживание. оптимально устраивает начальство на предмет отображения полученных данных. Создает равномерную нагрузку на cpu. Без ярко выраженных всплесков, которые будут при обработке файла с накопленными данными. И даже сокращает "углеродный след" не насилуя попусту жесткие диски операциями чтения-записи :) Вам не подходит? Не пользуйтесь подобными конструкциями. > > > Объективно оптимального решения практически любой проблемы не > существует в природе. > > Практически всегда можно найти оптимальное ли близкое к оптимальному > решение, надо просто осознавать какие критерии важны в первую > очередь, > а какие являются второстепенными - и исходя из условий задачи > - всегда можно найти оптимальное или близкое к оптимальному решение > для этих условий. Поэтому, например, иногда будет более оптимальным > VPN WireGuard, а иногда - более оптимальным будет VPN OpenVPN. > Все зависит от критериев оптимальности и всех условий задачи. > > > Если у вас в крсе обучения был такой предмет как "методы > оптимизации" -- вы должны это понимать. > > Вспомните задачки из курса: > > На одну и ту же таблицу данных: > > Постройте оптимальный маршрут по расстоянию. > > Постройте оптимальный маршрут по времени. > > Постройте оптимальный маршрут по загрузке. > > Постройте оптимальный с учетом состояния дорог. > > И ответы везде разные, а табличка-то одна :) > > И это которые простые задачки.... > > И что, Вы разве тогда находили _субъективно_ оптимальные решения? > И у каждого из 30 студентов в группе было свое собственное решение, > каждой из этих задач, которое он и считал самым оптимальным? > Или же для каждой этой задачи оптимальные решения получались > одинаковыми или очень сильно похожими друг на друга? > Решение было свое собственное, (ну не совсем у каждого, а по вариантам) потому что критерий оптимальности был у каждого свой, "данный свыше". В обычной жизни критерии могут быть очень похожи, но это таки субъективные критерии. > > Эффективность с точки зрения чего? > > Мы с вами эффективность считаем по совершенно разным критериям. > > Это не хорошо и не плохо. Это просто по-разному :) > > Ваше мнение может отличаться от моего. > > при одинаковых критериях эффективности - тоже будут разные решения? > > > Объективно оптимального решения практически любой проблемы не > существует в природе. > > То есть, у каждого будет свое собственное _субъективное_ понимание > того, какое решение является наиболее эффективным при четко заданных > критериях эффективности? ДА! ДА! На оба ваших вопроса выше... Оглянитесь вокруг, и вы сами в этом убедитесь. Кровли одинаковой конструкции очень похожих домов покрыты разным материалом. Внешне одинаковые постройки с одинаковой теплоэффективностью в качестве теплоизолятора содержат разные материалы. По дорогам ездят разные автомобили с одинаковыми требованиями к эффективности. Люди носят разную одежду при одинаковых требованиях к эффективности. Список можно продолжать до бесконечности. Можно придраться к каждому пункту по принципу "... а тут они не все критерии!" Так в жизни практически не бывает "чтоб прям все":) По крайней мере в моей. > > > Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно > решать что мне надо :) > > Решайте сами, я просто хотел понять Вашу исходную задачу X, > поэтому и задавал уточняющие вопросы. > Спасибо. Как уже упоминалось ранее -- по озвученной на самом старте теме я уже все решил. > > Про оптимальность я выше упоминал. > > Оптимизировать можно по разным критериям. > > Вы исходите из одних критериев оптимальности, я из других. > > И это абсолютно нормально. > > Ненормально, если при одних и тех же критериях оптимальности > и эффективности получаются совершенно различные решения > - так не может быть. Может. У Пикуля есть произведение "Честь Имею". Там есть эпизод с описанием различия принципов обучения в российской и немецкой академиях генштаба. Так вот - в немецкой идеалом считалось, когда любой выпускник, поставленный в сложную ситуацию, принимал оптимальное эффективное ЕДИНСТВЕННО ВЕРНОЕ решение, одинаковое для всех успешных выпускников в такой ситуации. Коренное отличие русской состояло в том, что каждый выпускник принимал оптимальное эффективное решение для достижения цели, и идеалом считалось когда у подавляющего большинства решения разные, но очень близки по эффективности. Если мне память не изменяет -- давно читал. Может что и напутал или помню не правильно... Кроме того при одинаковых критериях исходные условия могут быть разными. И решения будут КАРДИНАЛЬНО отличаться. Вот при одинаковых условиях, критериях, ресурсах, предпочтениях и конечных требованиях уже можно ожидать низкой вариативности в реализации. И то не факт. > > > Не стоит убеждать меня в "неправильности" моих критериев. > > Проблема XY - это не про неправильность критериев. > > Проблема XY - это про то, что Вы ищете решение проблемы Y, > хотя на самом деле Вам нужно решение проблемы X. Любая проблема является следствием одних проблем, и причиной других. Это нормально. При желании добраться из пунта А в пункт Б именно на машине и проблеме "машина не едет" 2 концептуальных решения: 1.Заменить машину. 2.Устранить причины "не едет" в имеющейся. Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из строя запчасть. Если провести параллели, то с моей точки зрения мне вполне достаточно запчасти. Вы предлагаете замену машины. Да, тут тоже есть куда развить тему, к чему придраться и т.д. Аналогия может не самая удачная. Можете привести свою. > > > Есть большое подозрение, что уже на текущем этапе по данному вопросу > осталось лишь 2 собеседника. > > я не настаиваю на продолжении диалога, если Вам этот разговор > не интересен, не полезен или доставляет какой-то дискомфорт. > > On 14.02.2024 23:58, Anatoliy Melnik via nginx-ru wrote: > > > 2. Хорошо -- пусть каждый прокси сам свое считает: исключаются > > потери по сети, каждый прокси в этом плане становится > > автономно-независимой единицей. > > При высоких нагрузках -- расхождения в статистике. > > Каким образом можно получить расхождения в статистике, > если на диске есть свободное место - в лог пишутся все > сообщения, потерь не может быть в этом случае. > Файлы в следующем пункте. > Получить потери можно в случае использования syslog > и unix socket`ов - если читающая сторона не будет > успевать читать данные из сокета - у nginx не останется > иных варантов, кроме как дропать часть записей. > > При записи логов в файлы - этот вариант исключен, > если на разделе есть достаточное количество свободного места. > О появились доп. условия -- место на разделе... > Хотя бы даже одним только этим свойством запись логов в файлы > намного лучше записи логов в unix socket`ы. > А как же место на разделе? Замена одной проблемы другой. Только и всего. Т.е. Проблему X -- расхождение при использовании сокета, вы меняете на проблему У -- достаточное количество места и производительность системы ввода-вывода, просто с вашей точки зрения это как-бы и не проблема вовсе, с моей точки зрения менять одну проблему на другую смысла нет, если можно решить первую. Тем более решение оказалось сущим пустяком. > Потому что, грубо говоря, при использовании unix socket`ов, > у Вас есть очень небольшой буфер в памяти и он очень быстро > может переполниться, что и приведет к потере части записей. Что и было решено путем распараллеливания. > > А при использовании лог-файлов на диске и ротации логов по > SIGUSR1 - в качестве такого "буфера" у Вас выступает все свободное > место на диске - поэтому не требуется та высокая степень > синхронности, > которая необходима при использовании unix socket`ов. > > Какой смысл в статистике, если она будет не точкной и ошибочной, > если система сбора статистики будет очень хрупкой и будет терять > часть сообщений при всплесках пиковой нагрузки на сервис? На данном этапе эксплуатации не выявлено ни одного из перечисленных вами эффектов. > > Если же одним из критериев эффективности и оптимальности системы > сбора статистики считать полноту статистики и отсутствие потерь > - в таком случае однозначно необходимо предпочесть именно логи, > куда будет писать сам nginx напрямую и ротацию логов через SIGUSR1. > > Если же потери части входных данных Вам не создают проблем, > то это у Вас какая-то не совсем понятная статистика получается. > Зачем она нужна, если эти система очень легко может терять часть > записей? Ну не так уж и легко. Собственно время покажет. > > > 3. Хорошо, запишем в файл прям с nginx-а. файл > распарсим-посчитаем. > > 3а.простыми методами (типа grep и awk) обработка статистики за 30 > секунд занимает больше 30 секунд. > > а если через > > https://github.com/google/mtail > > https://github.com/timberio/vector. > > ? > > Ведь не Вы же первый сталкиваетесь с задачей обработки логов. > И кроме grep и awk придумано и создано большое количество > инструментов для этого. > > > 3б.пишем в файл->читаем из файла->удаляем файл в объемах > 30-60Мбайт/сек... лично мое мнение - файл тут явно лишний. > (Ваше мнение может отличатся от моего, я абсолютно не настаиваю). > > Вас не смущает тот факт, что буфер в памяти может очень легко и > быстро > переполниться и это приведет к потере части данных? Это не важно? > Но судя по тому, что именно с этой проблемой Вы сюда и пришли - > для Вас это важно и критично, чтобы потерь данных у Вас не было. > > Если это критично, чтобы не было потерь - тогда логично построить > систему которая в принципе не способна терять данные, если только > есть достаточное количество свободного места на диске. Разве не так? > > >>> Чисто техничски можно и без access-логов, будете сами > >> реализовывать нечто > >>> подобное -- выберете более близкое вам решение. > >> > >> Вы не назвали альтернативные решения. > > Это сделали за меня: > > Написать свой бекэнд (как вариант на Go) и отзеркалировать туда > запросы с фронотов.... > > не только, еще можно использовать Angie и экспортировать > статистику напрямую в Prometheus, если этого будет достаточно. > > > Из лабиринтов собственных заблуждений > > скорее выберется тот, кто готов признать, что он заблуждается. > > А он признает? А вы у кого спрашиваете? > > > Лично я этот путь приодолел не единожды. Чего и вам желаю. > > Спасибо. В чем мои заблуждения? Ну как вариант: "Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее двойное толкование в ту или иную сторону по желанию сторон." Чуть попозже может всплыть и еще что-то. > > > Разве я кого-то пытался убедить, что его подход в корне не верен, > как > в этом пытаются убедить меня? > > Если цель кого-то пытаться убедить в истинности своей > точки зрения - это полемика. Если цель найти наиболее оптимальное > решение проблемы/задачи - это дискуссия. Отличие только в целях > и мотивации, внешнему наблюдателю они могут быть не видны и не > понятны, > если он воспринимает других через призму своего собственного сознания > и своих собственных установок/предубеждений. Не так много встречал людей, способных к адекватному восприятию не только через призму своего собственного сознания, но также и чужого. > > > Я же свои задачи решаю, а не ваши. > > Задачи очень схожие часто. И можно поделиться своим опытом с другими. > Но чтобы был возможен процесс поиска наиболее оптимального решения > задачи - необходимо знать условия задачи и критерии > оптимизации / эффективности. > > Причем, поиска решения настоящей задачи X о сборе статистики, > а не придуманной задачи Y про оптимизацию syslog/unix socket. Лично для меня уже не актуальны ни Х ни Y, ни их комбинации. Вот вам идея оптимального по большинству критериев решения -- Когда будете решать сходную задачу напишите свой модуль для nginx Чтоб сразу считать все нужное "внутри" без посредников. Я такое решение тоже рассматривал, отказался. Лично мои трудозатраты по реализации такого подхода превосходят все разумные пределы. Что и стало ключевым фактором "против". > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Thu Feb 15 11:04:23 2024 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 15 Feb 2024 14:04:23 +0300 Subject: announcing freenginx.org In-Reply-To: References: <2ff6d549235f43e11fe46c1ede1c1bcd@kopeyko.ru> Message-ID: <0c6652f286bffa3cda11e37864f2bb9c@kopeyko.ru> Maxim Dounin писал 2024-02-15 13:31: > Hello! > > On Thu, Feb 15, 2024 at 10:17:57AM +0300, Andrey Kopeyko wrote: > >> Gena Makhomed писал 2024-02-15 04:17: >> > On 14.02.2024 19:59, Maxim Dounin wrote: >> > >> > > Подобный подход можно понять: они владеют проектом, и могут с ним >> > > делать всё, что считают нужным, включая подобные маркетинговые >> > > акции. Это, однако, противоречит нашемоу соглашению. И, что более >> > > важно, я больше не имею возможности как-либо контролировать >> > > изменения, которые вносят в nginx в F5, и не могу рассматривать >> > > nginx как открытый и свободный проект, разрабатываемый для общего >> > > блага. >> > > >> > > Так что, начиная с сегодняшнего дня, я больше не участвую в >> > > разработке nginx'а в рамках F5. Вместо этого я запускаю >> > > альтернативный проект, управлять которым будут разработчики, а не >> > > корпоративные структуры: >> > > >> > > http://freenginx.org/ >> > > >> > > Цель проекта - обеспечить разработку nginx'а, свободную от >> > > произвольного корпоративного вмешательства. Помощь и участие >> > > приветствуются. Надеюсь, проект будет полезен для всех. >> > >> > Максим, тут есть одна очень большая проблема. >> > >> > Владельцем торговой марки NGINX является компания F5 NETWORKS, INC. >> > https://trademarks.justia.com/853/12/nginx-85312802.html >> > >> > Своего разрешения на использование своей торговой марки NGINX >> > F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст. >> >> Максим, >> >> Геннадий беспокоится обоснованно, и соображения написал все очень >> верные. >> >> Если хочешь, могу попробовать организовать тебе консультацию по >> "доменам, >> IP, ТМ и судебном опыте вокруг этого всего" у специалистов Ру-Центра. >> За >> последние 25 лет они на этом не одну собачью стаю съели, и по >> буржуйским >> доменам тоже. > > Спасибо, я пока рассчитываю на отсутствие проблем в этом вопросе, > смотри ответ Геннадию. Если возникнут - будем решать их по мере > поступления. Макс, дело, конечно, исключительно твоё - но такая твоя беспечность меня начинает беспокоить. Именно тем что ты, не юрист, начинаешь делать вывод о грядущих действиях противников, которые таки юристы. Даже неуспешные их действия - способны выпить немало твоей крови, увы. Рекомендую всё же проконсультироваться с юристами по доменам и IP. На Highload-е обычно бывает 2-3 таких специализированных конторы, если nic.ru тебе не подходит. -- Best regards, Andrey A. Kopeyko From izorkin на gmail.com Thu Feb 15 11:24:17 2024 From: izorkin на gmail.com (izorkin на gmail.com) Date: Thu, 15 Feb 2024 14:24:17 +0300 Subject: announcing freenginx.org In-Reply-To: <774d72b7-a9cd-49b2-9198-131b812dce47@megaline.kg> References: <1566332227.20240214213254@gmail.com> <1255460295.20240214222501@gmail.com> <54895bb9-fb4a-4db9-a0ed-61a30292b867@megaline.kg> <755075939.20240215132020@gmail.com> <774d72b7-a9cd-49b2-9198-131b812dce47@megaline.kg> Message-ID: <186275375.20240215142417@gmail.com> Добрый день, Raven.  Только вот вполне вероятно, что большинству людей проще работать с git. Я как пытался сделать несколько коммитов mercurial, а потом подкорректировать их, но в итоге не справился :( А дальше было лень разбираться. Да и в web-интерфейсе mercurial нет возможности создать вопросы и/или отправить PR. Для этого надо писать письмо с вложенным патчем.     Вы писали 15 февраля 2024 г., 13:27:29: > В каком-то из обсуждений Максим упоминал, что не сторонник git и связанных с ним технологий. Так, что наверное все, что прибито к git гвоздями здесь не поможет. Discourse да, возможно и взлетит, но это наверное больше для пользователей, а не для обсуждения разработки.   --  С уважением,  Izorkin                          mailto:izorkin на gmail.com ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From raven_kg на megaline.kg Thu Feb 15 11:28:48 2024 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Thu, 15 Feb 2024 17:28:48 +0600 Subject: announcing freenginx.org In-Reply-To: <186275375.20240215142417@gmail.com> References: <1566332227.20240214213254@gmail.com> <1255460295.20240214222501@gmail.com> <54895bb9-fb4a-4db9-a0ed-61a30292b867@megaline.kg> <755075939.20240215132020@gmail.com> <774d72b7-a9cd-49b2-9198-131b812dce47@megaline.kg> <186275375.20240215142417@gmail.com> Message-ID: <205f617a-4d46-440c-bc98-6b494128e202@megaline.kg> Боюсь, придется с этим смириться и перебороть свою лень) https://mailman.nginx.org/pipermail/nginx-devel/2024-February/YIFSHIYSKDFBYZ2QRA3WF6SRPGIBDBKI.html 15.02.2024 17:24, izorkin на gmail.com пишет: > > Добрый день, Raven. > > > Только вот вполне вероятно, что большинству людей проще работать с > git. Я как > > пытался сделать несколько коммитов mercurial, а потом > подкорректировать их, > > но в итоге не справился :( А дальше было лень разбираться. > > Да и в web-интерфейсе mercurial нет возможности создать вопросы и/или > отправить > > PR. Для этого надо писать письмо с вложенным патчем. > > Вы писали 15 февраля 2024 г., 13:27:29: > > > В каком-то из обсуждений Максим упоминал, что не сторонник git и > связанных с ним технологий. Так, что наверное все, что прибито к > git гвоздями здесь не поможет. Discourse да, возможно и взлетит, > но это наверное больше для пользователей, а не для обсуждения > разработки. > > > -- > С уважением, >  Izorkin mailto:izorkin на gmail.com > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Thu Feb 15 12:00:05 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 15 Feb 2024 14:00:05 +0200 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: On 15.02.2024 12:18, Maxim Dounin wrote: >>> Так что, начиная с сегодняшнего дня, я больше не участвую в >>> разработке nginx'а в рамках F5. Вместо этого я запускаю >>> альтернативный проект, управлять которым будут разработчики, а не >>> корпоративные структуры: >>> >>> http://freenginx.org/ >>> >>> Цель проекта - обеспечить разработку nginx'а, свободную от >>> произвольного корпоративного вмешательства. Помощь и участие >>> приветствуются. Надеюсь, проект будет полезен для всех. >> >> Максим, тут есть одна очень большая проблема. >> >> Владельцем торговой марки NGINX является компания F5 NETWORKS, INC. >> https://trademarks.justia.com/853/12/nginx-85312802.html >> >> Своего разрешения на использование своей торговой марки NGINX >> F5 NETWORKS, INC. Вам не давала, и скорее всего, что никгда не даст. >> >> А вот дальнейшее развитие событий предусмотреть совсем не трудно. >> Они будут преследовать Вас в судебном порядке за trademark infringement > > Спасибо за ссылки. Тут есть несколько факторов: > > Во-первых, название freenginx - хорошо отражает суть проекта. > Поэтому оно и было выбрано. > > Во-вторых, я, конечно, не юрист, но freenginx и NGINX - это два > разных названия, и вероятность успешных претензий я оцениваю как > небольшую. Да, действительно есть отдельная торговая марка FREEBSD https://trademarks.justia.com/850/90/freebsd-85090213.html и когда-то раньше была отдельная торговая марка BSD https://trademarks.justia.com/741/43/bsd-74143159.html Если у Вас получится зарегистрировать новую торговую марку freenginx - тогда да, все нормально и домен у Вас не отберут. Если Вы сможете заранее зарегистрировать торговую марку freenginx, - после этого вероятность успешных претензий может быть небольшой. А до того момента, пока отдельной торговой марки freenginx нет - вероятность успешности претензий со стороны F5 очень высокая. Кроме того, хотя Вас зовут и не Linus Torvalds, но в данном случае - вполне может произойти аналогичная ситуация, когда кто-то другой зарегистрирует на себя торговую марку freenginx и будет требовать с Вас деньги за право использования этой торговой марки, уже его собственности по аналогии с https://en.wikipedia.org/wiki/Linux_Mark_Institute Так что риски и угрозы тут есть - не только со стороны F5, если проект не будет защищен наличием своей торговой марки. > Кроме того, неявное разрешение на использование > торговой марки подразумевается лицензией. Лицензия https://nginx.org/LICENSE относится только к коду, она же не дает права на использование чужой торговой марки. > Ну и в-третьих, если всё-таки компания F5 решит играть в эти игры, > то это хорошо продемонстрирует их отношение к свободному > программному обеспечению. Я не думаю, что это случиться, скорее > рассчитываю, что компания одумается и будет поддерживать проект, > ибо это в первую очередь в их собственных интересах, но поживём - > увидим. Отто фон Бисмарк когда-то говорил: «Меня не интересуют их намерения, меня интересуют их возможности» - это правильный подход, если Вы заинтересованы в том, чтобы проект freenginx существовал в будущем. Для нормального существования проекта все равно будут нужны деньги, даже на оплату хостинга или на другие расходы. Не планируете создавать некоммерческую организацию, которая будет заниматься курированием этого проекта? По аналогии с FreeBSD Foundation, Linux Foundation ? Когда проект freenginx будет строиться только на личные деньги одного человека - что произойдет с проектом, когда у этого человека закончатся деньги или когда у него наступит момент End of Life? Что произойдет с проектом freenginx после того как lifecycle of Maxim Dounin будет завершен? Ведь даже продлить регистрацию домена freenginx.org тогда как? Если freenginx - это будет основная ветка, то защита очень желательна. On 15.02.2024 12:31, Maxim Dounin wrote: >> Если хочешь, могу попробовать организовать тебе консультацию >> по "доменам, IP, ТМ и судебном опыте вокруг этого всего" >> у специалистов Ру-Центра. За последние 25 лет они на этом >> не одну собачью стаю съели, и по буржуйским доменам тоже. > > Спасибо, я пока рассчитываю на отсутствие проблем в этом вопросе, > смотри ответ Геннадию. Если возникнут - будем решать их по мере > поступления. Если возникнут - тогда их будет решать гораздо труднее, или вообще невозможно. Было бы лучше заранее получить торговую марку freenginx - тогда хотя бы домен отобрать будет гораздо труднее или невозможно. Gregory Kurtzer защитил проект Rocky Linux от подобных угроз и рисков. Три торговые марки Rocky Enterprise Software Foundation™ RESF™ Rocky Linux™ зарегистрированы на Rocky Enterprise Software Foundation, так что тут есть и защита от Bus Factor и защита домена rockylinux.org - сделано все очень грамотно. И есть отдельно CIQ коммерческая компания, CIQ is the official founding support and services partner and sponsor of Rocky Linux. CIQ’s CEO, Gregory Kurtzer, is the also founder of Rocky Linux. - это сложно, но более простыми способами защиту не обеспечить. On 15.02.2024 9:17, Andrey Kopeyko wrote: > Если хочешь, могу попробовать организовать тебе консультацию по > "доменам, IP, ТМ и судебном опыте вокруг этого всего" у специалистов > Ру-Центра. За последние 25 лет они на этом не одну собачью стаю съели, > и по буржуйским доменам тоже. Имеет смысл прислушаться к советам и рекомендациям Андрея, в частности узнаете и о том, дает ли лицензия https://nginx.org/LICENSE Вам право на использование торговой марки NGINX принадлежащей F5, Inc. Чтобы не было потом неожиданных и неприятных сюрпризов. -- Best regards, Gena From andrey на kopeyko.ru Thu Feb 15 12:15:42 2024 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 15 Feb 2024 15:15:42 +0300 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: Gena Makhomed писал 2024-02-15 15:00: > On 15.02.2024 12:18, Maxim Dounin wrote: > >> Ну и в-третьих, если всё-таки компания F5 решит играть в эти игры, >> то это хорошо продемонстрирует их отношение к свободному >> программному обеспечению. Я не думаю, что это случиться, скорее >> рассчитываю, что компания одумается и будет поддерживать проект, >> ибо это в первую очередь в их собственных интересах, но поживём - >> увидим. > > Отто фон Бисмарк когда-то говорил: «Меня не интересуют их намерения, > меня интересуют их возможности» - это правильный подход, если Вы > заинтересованы в том, чтобы проект freenginx существовал в будущем. Золотые слова, очень к месту. > Для нормального существования проекта все равно будут нужны деньги, > даже на оплату хостинга или на другие расходы. Не планируете создавать > некоммерческую организацию, которая будет заниматься курированием > этого проекта? По аналогии с FreeBSD Foundation, Linux Foundation ? Я бы посоветовал \ пожелал воссоединиться коллективу разработчиков nginx - чтобы проект freenginx ушёл под крыло ООО "Вебсервер" https://angie.software/ Это даст и ресурсы, и помощь в защите, и et cetera. Но это лишь мой личный совет. -- Best regards, Andrey A. Kopeyko From alex.hha на gmail.com Thu Feb 15 12:41:31 2024 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 15 Feb 2024 14:41:31 +0200 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: > Во-первых, название freenginx - хорошо отражает суть проекта. Поэтому оно и было выбрано. > Во-вторых, я, конечно, не юрист, но freenginx и NGINX - это два разных названия, и вероятность успешных претензий я оцениваю как небольшую. Кроме того, неявное разрешение на использование торговой марки подразумевается лицензией. JFYI например тот же форк terraform - назвали opentofu, а не open/free/libre terraform. Как раз во избежание претензий со стороны Hashicorp On Thu, Feb 15, 2024 at 2:16 PM Andrey Kopeyko wrote: > Gena Makhomed писал 2024-02-15 15:00: > > On 15.02.2024 12:18, Maxim Dounin wrote: > > > >> Ну и в-третьих, если всё-таки компания F5 решит играть в эти игры, > >> то это хорошо продемонстрирует их отношение к свободному > >> программному обеспечению. Я не думаю, что это случиться, скорее > >> рассчитываю, что компания одумается и будет поддерживать проект, > >> ибо это в первую очередь в их собственных интересах, но поживём - > >> увидим. > > > > Отто фон Бисмарк когда-то говорил: «Меня не интересуют их намерения, > > меня интересуют их возможности» - это правильный подход, если Вы > > заинтересованы в том, чтобы проект freenginx существовал в будущем. > > Золотые слова, очень к месту. > > > > Для нормального существования проекта все равно будут нужны деньги, > > даже на оплату хостинга или на другие расходы. Не планируете создавать > > некоммерческую организацию, которая будет заниматься курированием > > этого проекта? По аналогии с FreeBSD Foundation, Linux Foundation ? > > Я бы посоветовал \ пожелал воссоединиться коллективу разработчиков nginx > - чтобы проект freenginx ушёл под крыло ООО "Вебсервер" > https://angie.software/ > > Это даст и ресурсы, и помощь в защите, и et cetera. > > Но это лишь мой личный совет. > > > -- > Best regards, > Andrey A. Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Thu Feb 15 14:39:36 2024 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 15 Feb 2024 17:39:36 +0300 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: On Thu, Feb 15, 2024 at 03:17:04AM +0200, Gena Makhomed wrote: > Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то > имя, которое не является ничьей торговой маркой и для защиты этого > имени - зарегистрировать свою торговую марку, Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия, плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать Европу и Китай? В РФ мы хотим регистрироваться? Насколько я понимаю, по российскому законодательству регистрация торговой марки (наименования, товарного знака) возможна лишь на юрлицо или ИП, а физлицу придётся заключить договор с какой-либо компанией, чтобы та оформила права на себя в интересах клиента. Какие тут для клиента риски -- отдельный вопрос... Регистрация в Роспатенте это где-то 30-50 тыс.руб, процедурно полгода-год, продление регистрации раз в 10 лет за ~ 25 тыс.руб (на сегодня). -- Eugene Berdnikov From gmm на csdoc.com Thu Feb 15 19:20:14 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 15 Feb 2024 21:20:14 +0200 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> On 15.02.2024 16:39, Evgeniy Berdnikov wrote: >> Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то >> имя, которое не является ничьей торговой маркой и для защиты этого >> имени - зарегистрировать свою торговую марку, > > Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку > хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия, > плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать > Европу и Китай? > > В РФ мы хотим регистрироваться? Насколько я понимаю, по российскому > законодательству регистрация торговой марки (наименования, товарного знака) > возможна лишь на юрлицо или ИП, а физлицу придётся заключить договор > с какой-либо компанией, чтобы та оформила права на себя в интересах > клиента. Какие тут для клиента риски -- отдельный вопрос... > Регистрация в Роспатенте это где-то 30-50 тыс.руб, процедурно полгода-год, > продление регистрации раз в 10 лет за ~ 25 тыс.руб (на сегодня). Я понял ответ Максима, почему он выбрал имя проекта именно freenginx, потому что именно это имя хорошо отражает суть проекта, он планируется полностью свободным и полностью некоммерческим, как например, FreeBSD. Тем более, что https://nginx.org/LICENSE и https://freenginx.org/LICENSE - это есть практически та же самая BSD 2-Clause "Simplified" License, что используется в проекте FreeBSD и является там Preferred License for New Files. Но: FreeBSD is a registered trademark of The FreeBSD Foundation. Почему бы в таком случае не зарегистрировать trademark freenginx? Про риски отсутствия такой защиты с помощью торговой марки я уже говорил раньше, а наличие такой защиты - ничем мешать не будет. Насколько я понимаю, у Максима расчет на то, что F5 не позволит никому постороннему зарегистрировать торговую марку freenginx, и при этом сама F5 не будет выдвигать никаких претензий проекту freenginx, потому что этот проект является полностью свободным и полностью некоммерческим. Вопрос только в том, позволит ли F5 зарегистрировать торговую марку freenginx самому Максиму или freenginx Foundation, стоящей за проектом? Может и не позволить, потому что торговые марки, как правило, используются для ведения бизнеса и продажи товаров и услуг. И поэтому Максим не хочет их дразнить, чтобы не провоцировать на запрет использования проектом freenginx торговой марки NGINX, принадлежащей F5 Inc. ? Возможно я тут зря развожу панику и у F5 выбор есть только между плохим и очень плохим вариантами и поэтому они в текущий момент времени не будут ничем препятствовать работе проекта freenginx. Но если Максим реализует в freenginx под открытой и свободной лицензией BSD 2-Clause "Simplified" License все те возможности, которые сейчас присутствуют в nginx-plus - в F5 такому развитию событий могут быть совсем не рады, потому что они могут быть не готовы переходить на ту модель работы, которую использует компания Percona, когда весь код всех их продуктов доступен под открытой и своободной лицензией и компания зарабатывает только лишь на оказании услуг технической поддержки клиентам. И поскольку цель любой коммерческой компании и корпорации - это заработать как можно больше денег - деятельность проекта freenginx будет проитиворечить этим интересам корпорации F5, и они вполне могут принять решение о защите своей торговой марки и запрете использования торговой марки NGINX проектом freenginx. Разумеется, тогда можно будет просто преименовать проект, и продолжить и дальше делать все то же, что и делали раньше - если в F5 понимают, что тогда они вообще никак не смогут влиять на Максима и на проект freenginx, после переименования проекта, потому что лицензия на код - та же BSD 2-Clause "Simplified" License, которая никаких ограничений на Максима не налагает. То есть, как я понимаю, Максим рассчитывает на наличие здравого смысла у руководства и топ-менеджеров компании F5, что они не будут предпринимать действий, которые будут вредить в первую очередь им же самим, и наносить репутационный ущерб. Не знаю, как тут лучше будет поступить - действительно ли F5 будет по всему миру блокировать регистрацию торговой марки freenginx и действительно ли F5 всегда будет защищать проект freenginx, даже в том случае, когда Максим начнет в Open Source реализовывать ту функциональность, которая сейчас присутствует только в коммерческой версии с закрытыми исходными текстами nginx-plus. А в чем тогда будет мотивация у F5 ничем не мешать деятельности проекта freenginx, если в этой ситуации деятельность проекта freenginx будет непосредственно уменьшать прибыль корпорации F5? Как долго они будут это терпеть и ничего не предпринимать, чтобы защитить свою прибыль? Ведь рано или поздно возникнет ситуация конфликта интересов, когда Максим начнет в freenginx реализовывать уже тот функционал, который есть только в nginx-plus, BIG-IP, BIG-IQ и других продуктах F5 Inc. Томасу Джозефу Даннингу принадлежит широко известное высказывание о сути капитализма, процитированное Карлом Марксом в «Капитале» и потому часто ошибочно ему приписываемое: «Капитал, — говорит „Quarterly Review“, — избегает шума и брани и отличается боязливой натурой». Это правда, но это ещё не вся правда. Капитал боится отсутствия прибыли или слишком маленькой прибыли, как природа боится пустоты. Но раз имеется в наличии достаточная прибыль, капитал становится смелым. Обеспечьте 10 процентов, и капитал согласен на всякое применение, при 20 процентах он становится оживлённым, при 50 процентах положительно готов сломать себе голову, при 100 процентах он попирает все человеческие законы, при 300 процентах нет такого преступления, на которое он не рискнул бы, хотя бы под страхом виселицы. Контрабанда и торговля рабами убедительно доказывают вышесказанное. https://ru.wikipedia.org/wiki/Даннинг,_Томас_Джозеф > В РФ мы хотим регистрироваться? Насколько я понимаю, > по российскому законодательству регистрация торговой марки > (наименования, товарного знака) возможна лишь на юрлицо или ИП, > а физлицу придётся заключить договор с какой-либо компанией, > чтобы та оформила права на себя в интересах клиента. Какие > тут для клиента риски -- отдельный вопрос... > Регистрация в Роспатенте это где-то 30-50 тыс.руб, процедурно > полгода-год, продление регистрации раз в 10 лет за ~ 25 тыс.руб > (на сегодня). Домен freenginx.ru уже зарегистрирован киберсквоттерами, причем, сегодня: https://www.nic.ru/whois/?searchWord=freenginx.ru Если бы у Максима была торговая марка freenginx - в такой ситуации он смог бы защитить свой проект, потому что репутационные потери от действия киберсквоттеров и прочих в РФ могут быть и больше чем 30-50 тыс.руб одноразово и ~ 25 тыс.руб раз в десять лет. Будем ждать, пока кто-то зарегистрирует в России торговую марку freenginx и запретит Максиму использовать эту торговую марку на территории России или же - начнет вымогать с него деньги за право использования этой чужой торговой марки freenginx? См. https://en.wikipedia.org/wiki/Linux_Mark_Institute Неужели история учит только тому, что она ничему не учит? -- Best regards, Gena From bgx на protva.ru Thu Feb 15 20:06:11 2024 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 15 Feb 2024 23:06:11 +0300 Subject: announcing freenginx.org In-Reply-To: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> Message-ID: On Thu, Feb 15, 2024 at 09:20:14PM +0200, Gena Makhomed wrote: > On 15.02.2024 16:39, Evgeniy Berdnikov wrote: > > > > Поэтому - лучше будет для основной ветки веб-сервера выбрать какое-то > > > имя, которое не является ничьей торговой маркой и для защиты этого > > > имени - зарегистрировать свою торговую марку, > > > > Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку > > хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия, > > плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать > > Европу и Китай? [...] > См. https://en.wikipedia.org/wiki/Linux_Mark_Institute > Неужели история учит только тому, что она ничему не учит? Вы много чего написали, но не ответили на вопрос, сколько это будет стоить. Без реального ценника все рассуждения превращаются в схоластику... > Если бы у Максима была торговая марка freenginx - в такой ситуации > он смог бы защитить свой проект, потому что репутационные потери > от действия киберсквоттеров и прочих в РФ могут быть и больше > чем 30-50 тыс.руб одноразово и ~ 25 тыс.руб раз в десять лет. Вы, наверное, имеете методику оценки репутационных потерь, или даже табличку конверсии для свободных проектов по текущему курсу. -- Eugene Berdnikov From gmm на csdoc.com Thu Feb 15 20:20:03 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 15 Feb 2024 22:20:03 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <739571819.16525971.1707994184471.JavaMail.zimbra@showjet.ru> References: <739571819.16525971.1707994184471.JavaMail.zimbra@showjet.ru> Message-ID: On 15.02.2024 12:49, Anatoliy Melnik via nginx-ru wrote: >>>>> Если вы предлагаете писать напрямую с nginx-а в файл -- >>>>> сделайте у себя ротацию файлов с интервалом 30 сек >>>>> при 200-250 тыс подключений/сек... >>>>> >>>>> Если у вас уже есть такое рабочее решение - >>>>> поделитесь опытом, буду рад вас выслушать. > "Я намеренно ввел вас в заблуждение путем публикации сообщения, допускающее двойное толкование в ту или иную сторону по желанию сторон." Почему / зачем? > Дальнейшее перемалывание темы ротации лично для меня интереса не представляет. Тогда прекращаем. >>> Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно >>> решать что мне надо :) Так я и не пытался решать за Вас, как именно будет лучше поступить в Вашей конкретной ситуации - скорее я рассматривал все множество задач сбора статистики и обработки информации из логов - и на всем этом множестве задач старался увидеть наиболее оптимальный способ решения задачи, если абстрагироваться от затрат времени и сил на реализацию решения в виде програмного кода. >> Решайте сами, я просто хотел понять Вашу исходную задачу X, >> поэтому и задавал уточняющие вопросы. > Спасибо. Как уже упоминалось ранее -- по озвученной на самом старте теме я уже все решил. С моей точки зрения более важным является обеспечение более высокой надежности работы системы, чтобы логи не терялись в процессе записи, чем экономия свободного места на диске и экономия ресурсов NVMe SSD. Поэтому с моей точки зрения - я не могу признать решение через syslog и unix socket более оптимальным, чем вариант записи логов напрямую в файлы и ротации логов через SIGUSR1. а ротацию логов можно делать и чаще, чем раз в 30 секунд, например, раз 15, или раз в 10 или даже раз в 5 секунд, если хочется уменьшить отставание статистики по времени. По сути - лог-файл на диске - это можете воспринимать примерно, как то же самое, что и unix socket, только с буфером не в памяти, а в виде файла на диске и без существенных ограничений по размеру такого буфера, что будет лучше сглаживать всплески нагрузки и может позволить большую асинхронность между процессом записи информации в лог и процессом чтения информации из лога. А во всем остальном - никакой существенной разницы нет, учитывая только что запись логов в файлы меньше грузит процесор и использует немного больше свободного места на диске. Но мне например, лучше чтобы процессор был немного свободнее, чем проистаивающее и никак не используемое место на диске. Но самое главное - что запись логов в файлы не приводит к потере данных, а запись логов в unix socket может приводить к потерям даных, если читатель будет не успевать забирать данные из unix socket. Более надежное и более простое решение, и более экономно расходующее процесор сервера - и будет более оптимальным. > При желании добраться из пунта А в пункт Б именно на машине и проблеме "машина не едет" 2 концептуальных решения: > 1.Заменить машину. > 2.Устранить причины "не едет" в имеющейся. > Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из строя запчасть. > Если провести параллели, то с моей точки зрения мне вполне достаточно запчасти. > Вы предлагаете замену машины. Не так, я скорее рассматриваю одновременно все множество путей из точки А в точку Б для различных вариантов А и Б и различных внешних условий и стараюсь понять, какой именно автомобиль, с какими именно параметрами будет наиболее оптимальным решением для такой задачи - перемещения их точки А в точку Б. Вот как я уже говорил, задача построения VPN - если взять все множество таких задач, то в части случаев для построения VPN более оптимальным вариантом будет использование WireGuard, а в части случаев - OpenVPN. Именно потому, что WireGuard обладает некоторыми свойствами и качествами, которые отсутствуют в OpenVPN, и наоборот, потому что OpenVPN обладает некоторыми свойствами и качествами, которые отсутствуют в WireGuard. И поэтому в части случаев оказывается более оптимальным и целесообразным построение VPN с использованием WireGuard, а в некоторых случаях - более оптимальнныи и целесообразным оказывается построение VPN с использованием OpenVPN. >> Получить потери можно в случае использования syslog >> и unix socket`ов - если читающая сторона не будет >> успевать читать данные из сокета - у nginx не останется >> иных варантов, кроме как дропать часть записей. >> >> При записи логов в файлы - этот вариант исключен, >> если на разделе есть достаточное количество свободного места. >> > О появились доп. условия -- место на разделе... Так ведь свободное место на разделе есть, с этим же нет проблем. Если часто делать ротацию логов - его надо будет совсем не много. Тем более, что можно включить компрессию логов на лету, если надо. >> Хотя бы даже одним только этим свойством запись логов в файлы >> намного лучше записи логов в unix socket`ы. > А как же место на разделе? Замена одной проблемы другой. Только и всего. У Вас разве есть проблемы со свободным местом на разделе? тогда включите компрессию логов на лету - свободного места потребуется меньше, ресурсов процессора будет использовано больше. Только и всего. Это не проблема, это лишь tradeoff. > Т.е. Проблему X -- расхождение при использовании сокета, вы меняете на проблему У -- достаточное количество места > и производительность системы ввода-вывода, просто с вашей точки зрения это как-бы и не проблема вовсе Количество свободного места на разделе - это не проблема, потому что Thin provisioning и все разделы виртуальных машин имеют логический размер в 50 TiB, - я бы сделал и больше, но Red Hat не рекомендует. > с моей точки зрения менять одну проблему на другую смысла нет использование места на диске - это не проблема, это необходимая плата за то, что запись в логи будет происходить без потерь информации, и что чтения и обработка информации из логов не обязаны быть такими синхронными и производительными, как в случае с unix socket`ами. > Вот вам идея оптимального по большинству критериев решения -- > Когда будете решать сходную задачу напишите свой модуль для nginx > Чтоб сразу считать все нужное "внутри" без посредников. > Я такое решение тоже рассматривал, отказался. > Лично мои трудозатраты по реализации такого подхода превосходят все разумные пределы. > Что и стало ключевым фактором "против". Такой модуль уже есть, Angie умеет экспортировать данные напрямую в Prometheus. Если бы у njs была возможность разделять данные между worker`ами, то можно был бы пряом через njs это делать. И скорее всего - это можно уже сейчас запрограммировать на lua, используя в качестве веб-сервера OpenResty, там есть доступ к разделяемой памяти. Или - просто парсить логи и все, это будет и быстрее и проще, чем unix socket`ы, IMHO. -- Best regards, Gena From andrey на kopeyko.ru Thu Feb 15 20:20:07 2024 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Thu, 15 Feb 2024 23:20:07 +0300 Subject: announcing freenginx.org In-Reply-To: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> Message-ID: <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Gena Makhomed писал 2024-02-15 22:20: > > Насколько я понимаю, у Максима расчет на то, что F5 не позволит > никому постороннему зарегистрировать торговую марку freenginx, > и при этом сама F5 не будет выдвигать никаких претензий проекту > freenginx, потому что этот проект является полностью свободным > и полностью некоммерческим. Это ровно та же ошибка, которую в 2011 году совершил Игорь Сысоев - увольняясь из Рамблера, он удовлетворился словами рулей что "никаких претензий к нему по поводу nginx у них нет" (в webarchive есть интервью PR-щика Рамблера помершему уже изданию с этими словами, ссылка у меня в ФБ заначена) и не удосужился закрепить это отсутствие претензий на бумаге. Результат такой беспечности налицо - многие (и из этого листа тоже) запомнили 12.12.2019 как день плотного общения со следователями СК. Мне лично очень не понравилось, как я провёл тот день. Да и последующие 4 месяца оказались для меня излишне дорогими. Но как адвокат - Тимофей Мусатов был очень хорош. Макс, на наступай плиз на эти грабли ещё раз. Либо получи от F5 письменный "отказ от претензий" (не берусь даже оценить насколько это реально...) Либо готовься всё время дрожать как осиновый лист. Единственное что в этой ситуации лично меня радует - я не вижу никаких оснований для привлечения своей персоны как свидетеля по возможному "делу freenginx" :-) Тьфу-тьфу-тьфу. Но юристы F5 могут изобретательно докопаться, хотя бы попробовать. Вероятность этого события точно больше нуля. -- Best regards, Andrey A. Kopeyko From gmm на csdoc.com Thu Feb 15 20:55:15 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 15 Feb 2024 22:55:15 +0200 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> Message-ID: <3ad81ce4-5629-4029-bb13-a89e54192158@csdoc.com> On 15.02.2024 22:06, Evgeniy Berdnikov wrote: >>> Вопрос знатокам: сколько стоит нынче зарегистрировать торговую марку >>> хотя бы в крупных англоязычных юрисдикциях -- США, Канада, Англия, >>> плюс Индия и Австралия? Сколько ещё потребуется, чтобы приплюсовать >>> Европу и Китай? > Вы много чего написали, но не ответили на вопрос, сколько это будет стоить. > Без реального ценника все рассуждения превращаются в схоластику... Так Вы же не мне этот вопрос задавали, а знатокам. Не понимаю, почему Вас так сильно интересует ответ на вопрос, сколько это будет стоить ? Вы собираетесь все переводить в деньги и все изменять только деньгами? То есть, если затраты меньше 50 тысяч рублей - тогда регистрируем, а если затраты больше 50 тысяч рублей - тогда не регистрируем, потому что это будет не выгодно? Или с какой целью Вы интересуетесь вопросами цены регистрации торговой марки в различных юрисдикциях ? Изначально разговор был о защите проекта freenginx от возможных наездов со стороны владельца торговой марки NIGNX - корпорации F5 Inc. Не понимаю Вашей логики в этом случае. Вы хотите сказать, что если стоимость регистрации торговой марки небольшая, то ее следует регистрировать, а если стоимость регистрации высокая - то в таком случае не надо регистрировать торговую марку? И не надо защищать проект freenginx от возможных проблем в будущем? Понятно, что если такие проблемы будут - то они будут связаны только с торговой маркой и решением проблем может быть переименование проекта. Но этот процесс переименований может стать бесконечным, если проект не владеет торговой маркой на свое имя, а этой торговой маркой владеет или легко может завладеть в любой момент времени кто-то посторонний. >> Если бы у Максима была торговая марка freenginx - в такой ситуации >> он смог бы защитить свой проект, потому что репутационные потери >> от действия киберсквоттеров и прочих в РФ могут быть и больше >> чем 30-50 тыс.руб одноразово и ~ 25 тыс.руб раз в десять лет. > Вы, наверное, имеете методику оценки репутационных потерь, или даже > табличку конверсии для свободных проектов по текущему курсу. Репутационные риски – это существующие проблемы, которые потенциально могут привести к ухудшению репутации. Ухудшение репутации, в свою очередь, приводит к репутационным издержкам в виде финансовых и иных потерь. Вы этого не знали? Именно потому что репутационные риски приводят к уменьшению прибыли - коммерческие компании озабочены своим имиджем и своей репутацией. Возможно именно поэтому на начальном этапе корпорация F5 и не будет предпринимать никаких враждебных действий по отношению к проекту freenginx - чтобы не портить свою репутацию в глазах пользователей своих товаров и услуг. Но рано или поздно эта ситуация может измениться, если/когла Максим перепишет в freenginx большую часть функциональности, которая есть только в nginx-plus, продукте с закрытым исходным кодом, который принадлежит корпорации F5 Inc. Топ-менеджеры F5 могут быть не готовы к такому развитию событий. И самым простым и очевидным для них вариантом действия и выхода из этой ситуации может показаться полный запрет проекту freenginx на использование торговой марки NGINX, захват домена freenginx.org и установка 301 редиректа на https://www.nginx.com/products/nginx/ -- Best regards, Gena From chipitsine на gmail.com Thu Feb 15 22:00:12 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 15 Feb 2024 23:00:12 +0100 Subject: announcing freenginx.org In-Reply-To: <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: чт, 15 февр. 2024 г. в 21:20, Andrey Kopeyko : > Gena Makhomed писал 2024-02-15 22:20: > > > > Насколько я понимаю, у Максима расчет на то, что F5 не позволит > > никому постороннему зарегистрировать торговую марку freenginx, > > и при этом сама F5 не будет выдвигать никаких претензий проекту > > freenginx, потому что этот проект является полностью свободным > > и полностью некоммерческим. > > Это ровно та же ошибка, которую в 2011 году совершил Игорь Сысоев - > увольняясь из Рамблера, > он удовлетворился словами рулей что "никаких претензий к нему по поводу > nginx у них нет" > (в webarchive есть интервью PR-щика Рамблера помершему уже изданию с > этими словами, ссылка у меня в ФБ заначена) > и не удосужился закрепить это отсутствие претензий на бумаге. > > Результат такой беспечности налицо - многие (и из этого листа тоже) > запомнили 12.12.2019 как день плотного общения со следователями СК. > с интересом бы послушал эту историю, но боюсь, что следователи взяли подписку о неразглашении. по сути той истории, у меня есть непраздный вопрос - допустим у Игоря была бы бумага, что Рамблер не имеет претензий. но насколько я понимаю, претензии предъявил новый собственник Рамблера, Сбербанк же ? ну есть у вас бумага от Рамблера. а следователи вам говорят - а претензия от Сбера. и что с этим счастьем делать ? > > Мне лично очень не понравилось, как я провёл тот день. > Да и последующие 4 месяца оказались для меня излишне дорогими. Но как > адвокат - Тимофей Мусатов был очень хорош. > > > Макс, > > на наступай плиз на эти грабли ещё раз. > > Либо получи от F5 письменный "отказ от претензий" (не берусь даже > оценить насколько это реально...) > > Либо готовься всё время дрожать как осиновый лист. > > > Единственное что в этой ситуации лично меня радует - я не вижу никаких > оснований для привлечения своей персоны как свидетеля по возможному > "делу freenginx" :-) > Тьфу-тьфу-тьфу. > > Но юристы F5 могут изобретательно докопаться, хотя бы попробовать. > Вероятность этого события точно больше нуля. > > > > -- > Best regards, > Andrey A. Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Feb 15 23:24:44 2024 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Feb 2024 02:24:44 +0300 Subject: announcing freenginx.org In-Reply-To: <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: Hello! On Thu, Feb 15, 2024 at 11:20:07PM +0300, Andrey Kopeyko wrote: > Gena Makhomed писал 2024-02-15 22:20: > > > > Насколько я понимаю, у Максима расчет на то, что F5 не позволит > > никому постороннему зарегистрировать торговую марку freenginx, > > и при этом сама F5 не будет выдвигать никаких претензий проекту > > freenginx, потому что этот проект является полностью свободным > > и полностью некоммерческим. > > Это ровно та же ошибка, которую в 2011 году совершил Игорь Сысоев - > увольняясь из Рамблера, > он удовлетворился словами рулей что "никаких претензий к нему по поводу > nginx у них нет" > (в webarchive есть интервью PR-щика Рамблера помершему уже изданию с этими > словами, ссылка у меня в ФБ заначена) > и не удосужился закрепить это отсутствие претензий на бумаге. > > Результат такой беспечности налицо - многие (и из этого листа тоже) > запомнили 12.12.2019 как день плотного общения со следователями СК. > > Мне лично очень не понравилось, как я провёл тот день. > Да и последующие 4 месяца оказались для меня излишне дорогими. Но как > адвокат - Тимофей Мусатов был очень хорош. Андрей, я тебе, как и многим другим, всемерно благодарен за поддержку в 2019 и после (эта история, кстати, всё ещё продолжается). Но, честно говоря, согласен с Геной - какая угодно бумага этих людей бы не остановила. > Макс, > > на наступай плиз на эти грабли ещё раз. > > Либо получи от F5 письменный "отказ от претензий" (не берусь даже оценить > насколько это реально...) > > Либо готовься всё время дрожать как осиновый лист. Если вдруг у компании F5 возникнут претензии к названию - ну, в крайнем случае переименую проект, не велика беда. Других рисков тут не просматривается при всём желании. > Единственное что в этой ситуации лично меня радует - я не вижу никаких > оснований для привлечения своей персоны как свидетеля по возможному "делу > freenginx" :-) > Тьфу-тьфу-тьфу. Да ты, однако, оптимист! :)) -- Maxim Dounin http://mdounin.ru/ From andrey на kopeyko.ru Thu Feb 15 23:25:08 2024 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Fri, 16 Feb 2024 02:25:08 +0300 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: Илья Шипицин писал 2024-02-16 01:00: > чт, 15 февр. 2024 г. в 21:20, Andrey Kopeyko > : > >> Gena Makhomed писал 2024-02-15 22:20: >>> >>> Насколько я понимаю, у Максима >> расчет на то, что F5 не позволит >>> никому постороннему >> зарегистрировать торговую марку >> freenginx, >>> и при этом сама F5 не будет выдвигать >> никаких претензий проекту >>> freenginx, потому что этот проект >> является полностью свободным >>> и полностью некоммерческим. >> >> Это ровно та же ошибка, которую в 2011 >> году совершил Игорь Сысоев - >> увольняясь из Рамблера, >> он удовлетворился словами рулей что >> "никаких претензий к нему по поводу >> nginx у них нет" >> (в webarchive есть интервью PR-щика >> Рамблера помершему уже изданию с >> этими словами, ссылка у меня в ФБ >> заначена) >> и не удосужился закрепить это >> отсутствие претензий на бумаге. >> >> Результат такой беспечности налицо - >> многие (и из этого листа тоже) >> запомнили 12.12.2019 как день плотного >> общения со следователями СК. > > с интересом бы послушал эту историю, > но боюсь, что следователи взяли > подписку о неразглашении. Не бойтесь - не взяли. С удовольствием развиртуализуюсь на DevOpsConf через пару недель. > > по сути той истории, у меня есть > непраздный вопрос - допустим у Игоря > была бы бумага, что Рамблер не имеет > претензий. > но насколько я понимаю, претензии > предъявил новый собственник Рамблера, > Сбербанк же ? ну есть у вас бумага от > Рамблера. > а следователи вам говорят - а > претензия от Сбера. и что с этим > счастьем делать ? А ничего не делать - вместе с покупкой Р. к Сберу переходят не только его права, но и обязанности. В частности, перешла бы обязанность "не привлекать". В этом случае дело затухло бы уже на стадии возбуждения. > >> Мне лично очень не понравилось, как я >> провёл тот день. >> Да и последующие 4 месяца оказались >> для меня излишне дорогими. Но как >> адвокат - Тимофей Мусатов был очень >> хорош. >> >> Макс, >> >> на наступай плиз на эти грабли ещё >> раз. >> >> Либо получи от F5 письменный "отказ от >> претензий" (не берусь даже >> оценить насколько это реально...) >> >> Либо готовься всё время дрожать как >> осиновый лист. >> >> Единственное что в этой ситуации >> лично меня радует - я не вижу никаких >> оснований для привлечения своей >> персоны как свидетеля по возможному >> "делу freenginx" :-) >> Тьфу-тьфу-тьфу. >> >> Но юристы F5 могут изобретательно >> докопаться, хотя бы попробовать. >> Вероятность этого события точно >> больше нуля. >> >> -- >> Best regards, >> Andrey A. Kopeyko >> _______________________________________________ >> 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 -- Best regards, Andrey A. Kopeyko From alex.hha на gmail.com Fri Feb 16 07:45:28 2024 From: alex.hha на gmail.com (Alex Domoradov) Date: Fri, 16 Feb 2024 09:45:28 +0200 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: > Да ты, однако, оптимист! :)) Был бы человек, а дело всегда найдется ( с ) On Fri, Feb 16, 2024 at 1:25 AM Andrey Kopeyko wrote: > Илья Шипицин писал 2024-02-16 01:00: > > чт, 15 февр. 2024 г. в 21:20, Andrey Kopeyko > > : > > > >> Gena Makhomed писал 2024-02-15 22:20: > >>> > >>> Насколько я понимаю, у Максима > >> расчет на то, что F5 не позволит > >>> никому постороннему > >> зарегистрировать торговую марку > >> freenginx, > >>> и при этом сама F5 не будет выдвигать > >> никаких претензий проекту > >>> freenginx, потому что этот проект > >> является полностью свободным > >>> и полностью некоммерческим. > >> > >> Это ровно та же ошибка, которую в 2011 > >> году совершил Игорь Сысоев - > >> увольняясь из Рамблера, > >> он удовлетворился словами рулей что > >> "никаких претензий к нему по поводу > >> nginx у них нет" > >> (в webarchive есть интервью PR-щика > >> Рамблера помершему уже изданию с > >> этими словами, ссылка у меня в ФБ > >> заначена) > >> и не удосужился закрепить это > >> отсутствие претензий на бумаге. > >> > >> Результат такой беспечности налицо - > >> многие (и из этого листа тоже) > >> запомнили 12.12.2019 как день плотного > >> общения со следователями СК. > > > > с интересом бы послушал эту историю, > > но боюсь, что следователи взяли > > подписку о неразглашении. > > Не бойтесь - не взяли. > > С удовольствием развиртуализуюсь на DevOpsConf через пару недель. > > > > > > по сути той истории, у меня есть > > непраздный вопрос - допустим у Игоря > > была бы бумага, что Рамблер не имеет > > претензий. > > но насколько я понимаю, претензии > > предъявил новый собственник Рамблера, > > Сбербанк же ? ну есть у вас бумага от > > Рамблера. > > а следователи вам говорят - а > > претензия от Сбера. и что с этим > > счастьем делать ? > > > А ничего не делать - вместе с покупкой Р. к Сберу переходят не только > его права, но и обязанности. В частности, перешла бы обязанность "не > привлекать". > > В этом случае дело затухло бы уже на стадии возбуждения. > > > > > >> Мне лично очень не понравилось, как я > >> провёл тот день. > >> Да и последующие 4 месяца оказались > >> для меня излишне дорогими. Но как > >> адвокат - Тимофей Мусатов был очень > >> хорош. > >> > >> Макс, > >> > >> на наступай плиз на эти грабли ещё > >> раз. > >> > >> Либо получи от F5 письменный "отказ от > >> претензий" (не берусь даже > >> оценить насколько это реально...) > >> > >> Либо готовься всё время дрожать как > >> осиновый лист. > >> > >> Единственное что в этой ситуации > >> лично меня радует - я не вижу никаких > >> оснований для привлечения своей > >> персоны как свидетеля по возможному > >> "делу freenginx" :-) > >> Тьфу-тьфу-тьфу. > >> > >> Но юристы F5 могут изобретательно > >> докопаться, хотя бы попробовать. > >> Вероятность этого события точно > >> больше нуля. > >> > >> -- > >> Best regards, > >> Andrey A. Kopeyko > >> _______________________________________________ > >> 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 > > -- > Best regards, > Andrey A. Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From vitaliy.okulov на gmail.com Fri Feb 16 08:03:26 2024 From: vitaliy.okulov на gmail.com (Vitaliy Okulov) Date: Fri, 16 Feb 2024 11:03:26 +0300 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: Зачем запугивать? =) По виду вся ситуация с названием проекта, это выбор что реально важно - развивать opensource проект, или что-то доказать F5, возможно даже в суде. Если последнее - freenginx идеальное название, можно будет с ними на дистанции пободаться в суде, показать миру какие F5 козлы. пт, 16 февр. 2024 г. в 10:45, Alex Domoradov : > > Да ты, однако, оптимист! :)) > > Был бы человек, а дело всегда найдется ( с ) > > On Fri, Feb 16, 2024 at 1:25 AM Andrey Kopeyko wrote: > >> Илья Шипицин писал 2024-02-16 01:00: >> > чт, 15 февр. 2024 г. в 21:20, Andrey Kopeyko >> > : >> > >> >> Gena Makhomed писал 2024-02-15 22:20: >> >>> >> >>> Насколько я понимаю, у Максима >> >> расчет на то, что F5 не позволит >> >>> никому постороннему >> >> зарегистрировать торговую марку >> >> freenginx, >> >>> и при этом сама F5 не будет выдвигать >> >> никаких претензий проекту >> >>> freenginx, потому что этот проект >> >> является полностью свободным >> >>> и полностью некоммерческим. >> >> >> >> Это ровно та же ошибка, которую в 2011 >> >> году совершил Игорь Сысоев - >> >> увольняясь из Рамблера, >> >> он удовлетворился словами рулей что >> >> "никаких претензий к нему по поводу >> >> nginx у них нет" >> >> (в webarchive есть интервью PR-щика >> >> Рамблера помершему уже изданию с >> >> этими словами, ссылка у меня в ФБ >> >> заначена) >> >> и не удосужился закрепить это >> >> отсутствие претензий на бумаге. >> >> >> >> Результат такой беспечности налицо - >> >> многие (и из этого листа тоже) >> >> запомнили 12.12.2019 как день плотного >> >> общения со следователями СК. >> > >> > с интересом бы послушал эту историю, >> > но боюсь, что следователи взяли >> > подписку о неразглашении. >> >> Не бойтесь - не взяли. >> >> С удовольствием развиртуализуюсь на DevOpsConf через пару недель. >> >> >> > >> > по сути той истории, у меня есть >> > непраздный вопрос - допустим у Игоря >> > была бы бумага, что Рамблер не имеет >> > претензий. >> > но насколько я понимаю, претензии >> > предъявил новый собственник Рамблера, >> > Сбербанк же ? ну есть у вас бумага от >> > Рамблера. >> > а следователи вам говорят - а >> > претензия от Сбера. и что с этим >> > счастьем делать ? >> >> >> А ничего не делать - вместе с покупкой Р. к Сберу переходят не только >> его права, но и обязанности. В частности, перешла бы обязанность "не >> привлекать". >> >> В этом случае дело затухло бы уже на стадии возбуждения. >> >> >> > >> >> Мне лично очень не понравилось, как я >> >> провёл тот день. >> >> Да и последующие 4 месяца оказались >> >> для меня излишне дорогими. Но как >> >> адвокат - Тимофей Мусатов был очень >> >> хорош. >> >> >> >> Макс, >> >> >> >> на наступай плиз на эти грабли ещё >> >> раз. >> >> >> >> Либо получи от F5 письменный "отказ от >> >> претензий" (не берусь даже >> >> оценить насколько это реально...) >> >> >> >> Либо готовься всё время дрожать как >> >> осиновый лист. >> >> >> >> Единственное что в этой ситуации >> >> лично меня радует - я не вижу никаких >> >> оснований для привлечения своей >> >> персоны как свидетеля по возможному >> >> "делу freenginx" :-) >> >> Тьфу-тьфу-тьфу. >> >> >> >> Но юристы F5 могут изобретательно >> >> докопаться, хотя бы попробовать. >> >> Вероятность этого события точно >> >> больше нуля. >> >> >> >> -- >> >> Best regards, >> >> Andrey A. Kopeyko >> >> _______________________________________________ >> >> 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 >> >> -- >> Best regards, >> Andrey A. Kopeyko >> _______________________________________________ >> 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 > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Feb 16 08:13:48 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 16 Feb 2024 09:13:48 +0100 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: пт, 16 февр. 2024 г. в 00:25, Andrey Kopeyko : > Илья Шипицин писал 2024-02-16 01:00: > > чт, 15 февр. 2024 г. в 21:20, Andrey Kopeyko > > : > > > >> Gena Makhomed писал 2024-02-15 22:20: > >>> > >>> Насколько я понимаю, у Максима > >> расчет на то, что F5 не позволит > >>> никому постороннему > >> зарегистрировать торговую марку > >> freenginx, > >>> и при этом сама F5 не будет выдвигать > >> никаких претензий проекту > >>> freenginx, потому что этот проект > >> является полностью свободным > >>> и полностью некоммерческим. > >> > >> Это ровно та же ошибка, которую в 2011 > >> году совершил Игорь Сысоев - > >> увольняясь из Рамблера, > >> он удовлетворился словами рулей что > >> "никаких претензий к нему по поводу > >> nginx у них нет" > >> (в webarchive есть интервью PR-щика > >> Рамблера помершему уже изданию с > >> этими словами, ссылка у меня в ФБ > >> заначена) > >> и не удосужился закрепить это > >> отсутствие претензий на бумаге. > >> > >> Результат такой беспечности налицо - > >> многие (и из этого листа тоже) > >> запомнили 12.12.2019 как день плотного > >> общения со следователями СК. > > > > с интересом бы послушал эту историю, > > но боюсь, что следователи взяли > > подписку о неразглашении. > > Не бойтесь - не взяли. > > С удовольствием развиртуализуюсь на DevOpsConf через пару недель. > ок, договорились. DevOpsConf в этом году решили провести не в той стране, где я. вероятно, когда-нибудь пересечемся > > > > > > по сути той истории, у меня есть > > непраздный вопрос - допустим у Игоря > > была бы бумага, что Рамблер не имеет > > претензий. > > но насколько я понимаю, претензии > > предъявил новый собственник Рамблера, > > Сбербанк же ? ну есть у вас бумага от > > Рамблера. > > а следователи вам говорят - а > > претензия от Сбера. и что с этим > > счастьем делать ? > > > А ничего не делать - вместе с покупкой Р. к Сберу переходят не только > его права, но и обязанности. В частности, перешла бы обязанность "не > привлекать". > > В этом случае дело затухло бы уже на стадии возбуждения. > > > > > >> Мне лично очень не понравилось, как я > >> провёл тот день. > >> Да и последующие 4 месяца оказались > >> для меня излишне дорогими. Но как > >> адвокат - Тимофей Мусатов был очень > >> хорош. > >> > >> Макс, > >> > >> на наступай плиз на эти грабли ещё > >> раз. > >> > >> Либо получи от F5 письменный "отказ от > >> претензий" (не берусь даже > >> оценить насколько это реально...) > >> > >> Либо готовься всё время дрожать как > >> осиновый лист. > >> > >> Единственное что в этой ситуации > >> лично меня радует - я не вижу никаких > >> оснований для привлечения своей > >> персоны как свидетеля по возможному > >> "делу freenginx" :-) > >> Тьфу-тьфу-тьфу. > >> > >> Но юристы F5 могут изобретательно > >> докопаться, хотя бы попробовать. > >> Вероятность этого события точно > >> больше нуля. > >> > >> -- > >> Best regards, > >> Andrey A. Kopeyko > >> _______________________________________________ > >> 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 > > -- > Best regards, > Andrey A. Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Fri Feb 16 09:19:40 2024 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Fri, 16 Feb 2024 12:19:40 +0300 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: Maxim Dounin писал 2024-02-16 02:24: > Hello! > > Андрей, я тебе, как и многим другим, всемерно благодарен за > поддержку в 2019 и после (эта история, кстати, всё ещё > продолжается). Но, честно говоря, согласен с Геной - какая угодно > бумага этих людей бы не остановила. Подавателей претензий - может, и не остановила бы, но сильно осложнила бы им юридическое оформление претензии. Я хорошо помню как вздрогнул полковник, старший следственной группы, когда уже после завершения допроса, при разъяснении им что же там наговорил, я вспомнил и сказал что в 2011 году читал в прессе что Рамблер высказывался об отсутствии претензий к Игорю по nginx. "Вот вам компьютер с интернет, найдите плиз, это очень важно" - сразу сказал он. Сходу ничего не нашлось; искомое обнаружил Юрий Синодов примерно через неделю; плюс я ещё подтащил, через своего адвоката Тимофея Мусатова, любопытных материалов из числа первоисточников, имевшихся у следствия, - и до следственной группы, похоже, стало доходить что Рамблер их "немножечко попользовал". Ещё в день допроса, разъясняя мне положения УПК, полковник заявил мне что "Дело возбуждено по тяжкой статье, поэтому обязательно кто-то будет посажен. Либо виновный, либо следователь, неправомерно возбудивший уголовное дело". Последний вариант его устраивал слабо, хотя времени для исследования ситуации у них было предостаточно - между подачей заявления Рамблером и решением о возбуждении дела прошло немалое кол-во времени. Мне неведомо как и чем они это время провели, но по некоторым наблюдаемым признакам - подготовка к проведению допросов и обысков прошла весьма халатно. Примерно в середине марта 2020 года началось явное, наблюдаемое извне, отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае вынесением постановления о закрытии дела с феерической формулировкой "... в связи с отсутствием факта преступления". Макс, проверь плиз правильно ли я помню формулировку - у тебя такой документ должен быть; мне, увы, такой бумаги не досталось из-за гибели Тимофея Мусатова в конце апреля... Итого: такая бумага остановила бы СК при попытке Рамблера возбудить дело. > >> Макс, >> >> на наступай плиз на эти грабли ещё раз. >> >> Либо получи от F5 письменный "отказ от претензий" (не берусь даже >> оценить >> насколько это реально...) >> >> Либо готовься всё время дрожать как осиновый лист. > > Если вдруг у компании F5 возникнут претензии к названию - ну, в > крайнем случае переименую проект, не велика беда. Других рисков > тут не просматривается при всём желании. > >> Единственное что в этой ситуации лично меня радует - я не вижу никаких >> оснований для привлечения своей персоны как свидетеля по возможному >> "делу >> freenginx" :-) >> Тьфу-тьфу-тьфу. > > Да ты, однако, оптимист! :)) Я следую принципу "Fac quod debes et quod futurum est". -- Best regards, Andrey A. Kopeyko From bgx на protva.ru Fri Feb 16 09:24:48 2024 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Fri, 16 Feb 2024 12:24:48 +0300 Subject: announcing freenginx.org In-Reply-To: <3ad81ce4-5629-4029-bb13-a89e54192158@csdoc.com> References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <3ad81ce4-5629-4029-bb13-a89e54192158@csdoc.com> Message-ID: On Thu, Feb 15, 2024 at 10:55:15PM +0200, Gena Makhomed wrote: > On 15.02.2024 22:06, Evgeniy Berdnikov wrote: > > > Вы много чего написали, но не ответили на вопрос, сколько это будет стоить. > > Без реального ценника все рассуждения превращаются в схоластику... > > Так Вы же не мне этот вопрос задавали, а знатокам. > > Не понимаю, почему Вас так сильно интересует > ответ на вопрос, сколько это будет стоить ? > > Вы собираетесь все переводить в деньги и все изменять только деньгами? Так я написал: без ценовой конкретики эти дискуссии становятся схоластикой. Нужно соизмерять свои желания со своими возможностями. Регистрация брендов -- занятие, доступное тем, у кого бизнес на миллионы, и есть серьёзная потребность этот бизнес защищать. Для открытого проекта намного проще десять раз поменять название, чем заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим сделать не может, а сборщики дистрибутивов стали раздавать пакет автора, а не сборку Оракла. Причём там была похожая ситуация: пришли манагеры, привыкшие к жёсткой иерархии и принципу "начальник всегда прав", подключили штатных оракловских разрабов и погнали патчи, которые открыто не обсуждались и потому не всегда даже были понятны старым разработчикам. Итог закономерен. -- Eugene Berdnikov From slw на zxy.spb.ru Fri Feb 16 09:43:49 2024 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 16 Feb 2024 12:43:49 +0300 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: <20240216094349.GG76331@zxy.spb.ru> On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote: > Примерно в середине марта 2020 года началось явное, наблюдаемое извне, > отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае > вынесением постановления о закрытии дела с феерической формулировкой > "... в связи с отсутствием факта преступления". а что феерического в данной формулировке? From chipitsine на gmail.com Fri Feb 16 09:51:13 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 16 Feb 2024 10:51:13 +0100 Subject: announcing freenginx.org In-Reply-To: <20240216094349.GG76331@zxy.spb.ru> References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> <20240216094349.GG76331@zxy.spb.ru> Message-ID: пт, 16 февр. 2024 г. в 10:44, Slawa Olhovchenkov : > On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote: > > > Примерно в середине марта 2020 года началось явное, наблюдаемое извне, > > отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае > > вынесением постановления о закрытии дела с феерической формулировкой > > "... в связи с отсутствием факта преступления". > > а что феерического в данной формулировке? > ну, первое столкновение с правовой системой вызывают эмоции. когда в 10-й раз видишь примерно одни и те же патерны, это приедается. возможно, Андрею каждый раз как первый )) или до 2019-го бог его хранил от правоохранителей > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Fri Feb 16 10:29:26 2024 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Fri, 16 Feb 2024 13:29:26 +0300 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> <20240216094349.GG76331@zxy.spb.ru> Message-ID: <97cbd17adcf4aa59a8ebd228901dad41@kopeyko.ru> Илья Шипицин писал 2024-02-16 12:51: > пт, 16 февр. 2024 г. в 10:44, Slawa Olhovchenkov > : > >> On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote: >> >>> Примерно в середине марта 2020 года >> началось явное, наблюдаемое извне, >>> отползание следаков от "дела nginx". >> Что закончилось ЕМНИП в мае >>> вынесением постановления о >> закрытии дела с феерической >> формулировкой >>> "... в связи с отсутствием факта >> преступления". >> >> а что феерического в данной >> формулировке? Обычно прекращение дела формулируется как "отсутствие состава преступления". Т.е. факт действий был подтверждён, но квалифицировать их по УК не получилось. Здесь же следствие постулировало что "самого факта не нашли". Что неудивительно - заявление о возбуждении дела (его мотивировочная часть полностью вошла в постановление об обыске в офисе nginx, утекшее в РБК в середине дня) писали люди плохо знакомые с историей Рамблера, поэтому изложенных там "фактов" не существовало в природе. И я точно указал где в доказательной базе следствия содержится строгое доказательство отсутствия этих "фактов". > ну, первое столкновение с правовой > системой вызывают эмоции. > > когда в 10-й раз видишь примерно одни и > те же патерны, это приедается. > возможно, Андрею каждый раз как первый > )) или до 2019-го бог его хранил от > правоохранителей Нет, это далеко не первое моё столкновение с правоохранителями. Даже не первое моё пребывание в статусе свидетеля по уголовному делу. Но, тьфу-тьфу-тьфу, опыт мой действительно небольшой. И это мне нравится. -- Best regards, Andrey A. Kopeyko From slw на zxy.spb.ru Fri Feb 16 10:51:20 2024 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 16 Feb 2024 13:51:20 +0300 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> <20240216094349.GG76331@zxy.spb.ru> Message-ID: <20240216105120.GH76331@zxy.spb.ru> On Fri, Feb 16, 2024 at 10:51:13AM +0100, Илья Шипицин wrote: > пт, 16 февр. 2024 г. в 10:44, Slawa Olhovchenkov : > > > On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote: > > > > > Примерно в середине марта 2020 года началось явное, наблюдаемое извне, > > > отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае > > > вынесением постановления о закрытии дела с феерической формулировкой > > > "... в связи с отсутствием факта преступления". > > > > а что феерического в данной формулировке? > > > > ну, первое столкновение с правовой системой вызывают эмоции. > > когда в 10-й раз видишь примерно одни и те же патерны, это приедается. > возможно, Андрею каждый раз как первый )) или до 2019-го бог его хранил от > правоохранителей я ничего не понял в том, что ты хотел сказать From slw на zxy.spb.ru Fri Feb 16 10:53:42 2024 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Fri, 16 Feb 2024 13:53:42 +0300 Subject: announcing freenginx.org In-Reply-To: <97cbd17adcf4aa59a8ebd228901dad41@kopeyko.ru> References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> <20240216094349.GG76331@zxy.spb.ru> <97cbd17adcf4aa59a8ebd228901dad41@kopeyko.ru> Message-ID: <20240216105342.GI76331@zxy.spb.ru> On Fri, Feb 16, 2024 at 01:29:26PM +0300, Andrey Kopeyko wrote: > Илья Шипицин писал 2024-02-16 12:51: > > пт, 16 февр. 2024 г. в 10:44, Slawa Olhovchenkov > > : > > > >> On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote: > >> > >>> Примерно в середине марта 2020 года > >> началось явное, наблюдаемое извне, > >>> отползание следаков от "дела nginx". > >> Что закончилось ЕМНИП в мае > >>> вынесением постановления о > >> закрытии дела с феерической > >> формулировкой > >>> "... в связи с отсутствием факта > >> преступления". > >> > >> а что феерического в данной > >> формулировке? > > Обычно прекращение дела формулируется как "отсутствие состава > преступления". > > Т.е. факт действий был подтверждён, но квалифицировать их по УК не > получилось. > > > Здесь же следствие постулировало что "самого факта не нашли". > > Что неудивительно - заявление о возбуждении дела (его мотивировочная > часть полностью вошла в постановление об обыске в офисе nginx, утекшее в > РБК в середине дня) писали люди плохо знакомые с историей Рамблера, > поэтому изложенных там "фактов" не существовало в природе. И я точно > указал где в доказательной базе следствия содержится строгое > доказательство отсутствия этих "фактов". я позанудничаю -- фееричность-то в чем? в том, что прекращений по такой формулировке предельно мало? From ano на bestmx.net Fri Feb 16 12:30:34 2024 From: ano на bestmx.net (Andrey Oktyabrskiy) Date: Fri, 16 Feb 2024 15:30:34 +0300 Subject: announcing freenginx.org In-Reply-To: References: Message-ID: On 2/15/24 15:15, Andrey Kopeyko wrote: > Gena Makhomed писал 2024-02-15 15:00: >> On 15.02.2024 12:18, Maxim Dounin wrote: >> >>> Ну и в-третьих, если всё-таки компания F5 решит играть в эти игры, >>> то это хорошо продемонстрирует их отношение к свободному >>> программному обеспечению.  Я не думаю, что это случиться, скорее >>> рассчитываю, что компания одумается и будет поддерживать проект, >>> ибо это в первую очередь в их собственных интересах, но поживём - >>> увидим. >> >> Отто фон Бисмарк когда-то говорил: «Меня не интересуют их намерения, >> меня интересуют их возможности» - это правильный подход, если Вы >> заинтересованы в том, чтобы проект freenginx существовал в будущем. > > Золотые слова, очень к месту. > > >> Для нормального существования проекта все равно будут нужны деньги, >> даже на оплату хостинга или на другие расходы. Не планируете создавать >> некоммерческую организацию, которая будет заниматься курированием >> этого проекта? По аналогии с FreeBSD Foundation, Linux Foundation ? > > Я бы посоветовал \ пожелал воссоединиться коллективу разработчиков nginx > - чтобы проект freenginx ушёл под крыло ООО "Вебсервер" > https://angie.software/ > > Это даст и ресурсы, и помощь в защите, и et cetera. > > Но это лишь мой личный совет. > > From mdounin на mdounin.ru Fri Feb 16 12:31:50 2024 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 16 Feb 2024 15:31:50 +0300 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <0e6dfe091747e55d88d93f0a0fe78c6f@kopeyko.ru> Message-ID: Hello! On Fri, Feb 16, 2024 at 12:19:40PM +0300, Andrey Kopeyko wrote: > Maxim Dounin писал 2024-02-16 02:24: > > Hello! > > > > Андрей, я тебе, как и многим другим, всемерно благодарен за > > поддержку в 2019 и после (эта история, кстати, всё ещё > > продолжается). Но, честно говоря, согласен с Геной - какая угодно > > бумага этих людей бы не остановила. > > Подавателей претензий - может, и не остановила бы, но сильно осложнила бы им > юридическое оформление претензии. Записали бы подписавшего бумагу в сообщники, не вижу проблем. Ты же читал иск, который они подали в США? Там примерно весь Рамблер состоял из co-conspirator'ов, и компания смогла обнаружить это только в 2019 году. > Я хорошо помню как вздрогнул полковник, старший следственной группы, когда > уже после завершения допроса, при разъяснении им что же там наговорил, я > вспомнил и сказал что в 2011 году читал в прессе что Рамблер высказывался об > отсутствии претензий к Игорю по nginx. "Вот вам компьютер с интернет, > найдите плиз, это очень важно" - сразу сказал он. > > Сходу ничего не нашлось; искомое обнаружил Юрий Синодов примерно через > неделю; плюс я ещё подтащил, через своего адвоката Тимофея Мусатова, > любопытных материалов из числа первоисточников, имевшихся у следствия, - и > до следственной группы, похоже, стало доходить что Рамблер их "немножечко > попользовал". Насколько я понимаю, доходить до них начало, когда они осознали масштаб поднявшегося в прессе шума. Юридическая сторона вопроса им была, скажем так, понятна с самого начала. [...] > Примерно в середине марта 2020 года началось явное, наблюдаемое извне, > отползание следаков от "дела nginx". Что закончилось ЕМНИП в мае вынесением > постановления о закрытии дела с феерической формулировкой "... в связи с > отсутствием факта преступления". > > Макс, проверь плиз правильно ли я помню формулировку - у тебя такой документ > должен быть; мне, увы, такой бумаги не досталось из-за гибели Тимофея > Мусатова в конце апреля... Нет, у меня нет, я в Российском деле не фигурировал (к счастью), и только отдельно потом давал показания со стороны защиты. Игорь писал (на сайте висит, собственно), что дело "прекращено за отсутствием события преступления". Это одна из основных "оправдательных" формулировок, означающая, что факт преступления не подтвердился ("когда не было самого факта, о котором сообщалось в компетентный орган, или событие было ошибочно воспринято как преступное"). -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Fri Feb 16 13:03:00 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 16 Feb 2024 15:03:00 +0200 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <3ad81ce4-5629-4029-bb13-a89e54192158@csdoc.com> Message-ID: <14308b38-59ad-4a42-b4d6-46385da7aa26@csdoc.com> On 15.02.2024 12:18, Maxim Dounin wrote: > Во-первых, название freenginx - хорошо отражает суть проекта. > Поэтому оно и было выбрано. Это действительно наилучший вариант имени для проекта, потому что оно наилучшим образом отражает суть проекта. Я так понимаю, что в будущем - коммерческой версии freenginx с закрытыми исходниками и платными функциями не планируется, поэтому отдельная торговая марка и не нужна для freenginx. Такое имя проекта будет лучше всего и с точки зрения интересов компании F5, потому что они в любой момент могут воспользоваться законодательством о защите торговых марок и заблокировать создание бизнеса и продажу коммерческой версии веб-сервера под именем freenginx-plus или freenginx PRO А поскольку компания F5 является владельцем торговой марки NGINX - то они смогут защищать проект freenginx от любых https://en.wikipedia.org/wiki/Trademark_troll что будет очень полезно и Максиму и самой компании F5. On 16.02.2024 1:24, Maxim Dounin wrote: > Если вдруг у компании F5 возникнут претензии к названию - > ну, в крайнем случае переименую проект, не велика беда. > Других рисков тут не просматривается при всём желании. В случае если они начнут угрожать, что отберут домен freenginx.org или что запретят использование имени freenginx для проекта - тогда Максим просто переименует проект и они потеряют возможность блокировки создания коммерческой версии и еще одного конкурента для nginx-plus. Так что и для Максима и для компании F5 - это есть самый лучший вариант, что проект Максима называется именно словом freenginx а не как-то иначе. F5 - не выгодно терять возможность блокировки создания платной версии, а Максиму не выгодно терять защиту от Trademark trolls. On 16.02.2024 11:24, Evgeniy Berdnikov wrote: > Для открытого проекта намного проще десять раз поменять название, чем > заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL > поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим > сделать не может, а сборщики дистрибутивов стали раздавать пакет автора, > а не сборку Оракла. Причём там была похожая ситуация: пришли манагеры, > привыкшие к жёсткой иерархии и принципу "начальник всегда прав", > подключили штатных оракловских разрабов и погнали патчи, которые открыто > не обсуждались и потому не всегда даже были понятны старым разработчикам. > Итог закономерен. Да, теперь я понял. Как это было с проектом Wireshark, изначально он назывался Ethereal, но был переименован в Wireshark in May 2006 due to trademark issues. -- Best regards, Gena From chipitsine на gmail.com Fri Feb 16 13:21:15 2024 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 16 Feb 2024 14:21:15 +0100 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <3ad81ce4-5629-4029-bb13-a89e54192158@csdoc.com> Message-ID: пт, 16 февр. 2024 г. в 10:25, Evgeniy Berdnikov : > On Thu, Feb 15, 2024 at 10:55:15PM +0200, Gena Makhomed wrote: > > On 15.02.2024 22:06, Evgeniy Berdnikov wrote: > > > > > Вы много чего написали, но не ответили на вопрос, сколько это будет > стоить. > > > Без реального ценника все рассуждения превращаются в схоластику... > > > > Так Вы же не мне этот вопрос задавали, а знатокам. > > > > Не понимаю, почему Вас так сильно интересует > > ответ на вопрос, сколько это будет стоить ? > > > > Вы собираетесь все переводить в деньги и все изменять только деньгами? > > Так я написал: без ценовой конкретики эти дискуссии становятся > схоластикой. > Нужно соизмерять свои желания со своими возможностями. > Регистрация брендов -- занятие, доступное тем, у кого бизнес на миллионы, > и есть серьёзная потребность этот бизнес защищать. > > Для открытого проекта намного проще десять раз поменять название, чем > заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL > поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим > сделать не может, а сборщики дистрибутивов стали раздавать пакет автора, > а не сборку Оракла. Причём там была похожая ситуация: пришли манагеры, > привыкшие к жёсткой иерархии и принципу "начальник всегда прав", > подключили штатных оракловских разрабов и погнали патчи, которые открыто > не обсуждались и потому не всегда даже были понятны старым разработчикам. > Итог закономерен. > отдельно доставляет в подобных историях наличие code conduct и contribution policy. по идее, в каждом проекте есть некие разделяемые всеми правила, как поступать, как комитить и так далее. ну ок, возникает некая ситуация, казалось бы, стороны сели за стол, посмотрели на правила, сказали "давайте уже соблюдать собственную конституцию" и продолжили работать дальше. но каждый божий раз эти code of conduct оказываются филькиной грамотой )) как жить то, одни понятия, никаких законов > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From raven_kg на megaline.kg Fri Feb 16 13:46:29 2024 From: raven_kg на megaline.kg (raven_kg на megaline.kg) Date: Fri, 16 Feb 2024 19:46:29 +0600 Subject: announcing freenginx.org In-Reply-To: References: <94129a70-926a-4f24-95b9-9a7a97788aab@csdoc.com> <3ad81ce4-5629-4029-bb13-a89e54192158@csdoc.com> Message-ID: В данной конкретной истори особо доставляет то, что обсуждение форка (и будущего этого самого форка) происходит в списке рассылки форкнутого продукта 😆 16.02.2024 19:21, Илья Шипицин пишет: > > > пт, 16 февр. 2024 г. в 10:25, Evgeniy Berdnikov : > > On Thu, Feb 15, 2024 at 10:55:15PM +0200, Gena Makhomed wrote: > > On 15.02.2024 22:06, Evgeniy Berdnikov wrote: > > > > > Вы много чего написали, но не ответили на вопрос, сколько это > будет стоить. > > > Без реального ценника все рассуждения превращаются в схоластику... > > > > Так Вы же не мне этот вопрос задавали, а знатокам. > > > > Не понимаю, почему Вас так сильно интересует > > ответ на вопрос, сколько это будет стоить ? > > > > Вы собираетесь все переводить в деньги и все изменять только > деньгами? > >  Так я написал: без ценовой конкретики эти дискуссии становятся > схоластикой. >  Нужно соизмерять свои желания со своими возможностями. >  Регистрация брендов -- занятие, доступное тем, у кого бизнес на > миллионы, >  и есть серьёзная потребность этот бизнес защищать. > >  Для открытого проекта намного проще десять раз поменять название, чем >  заморачиваться с брендированием и сутяжничеством... Вон, автор MySQL >  поменял имя на MariaDB, и всё нормально. Оракл ничегошеньки с этим >  сделать не может, а сборщики дистрибутивов стали раздавать пакет > автора, >  а не сборку Оракла. Причём там была похожая ситуация: пришли > манагеры, >  привыкшие к жёсткой иерархии и принципу "начальник всегда прав", >  подключили штатных оракловских разрабов и погнали патчи, которые > открыто >  не обсуждались и потому не всегда даже были понятны старым > разработчикам. >  Итог закономерен. > > > > отдельно доставляет в подобных историях наличие code conduct и > contribution policy. > по идее, в каждом проекте есть некие разделяемые всеми правила, как > поступать, > как комитить и так далее. > > ну ок, возникает некая ситуация, казалось бы, стороны сели за стол, > посмотрели на правила, > сказали "давайте уже соблюдать собственную конституцию" и продолжили > работать дальше. > > но каждый божий раз эти code of conduct оказываются филькиной грамотой )) > как жить то, одни понятия, никаких законов > > -- >  Eugene Berdnikov > _______________________________________________ > 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 ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From anatoliy.melnik на showjet.ru Mon Feb 19 14:01:23 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Mon, 19 Feb 2024 17:01:23 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <669894399.30032560.1708351283938.JavaMail.zimbra@showjet.ru> Gena Makhomed Wrote: ------------------------------------------------------- > On 15.02.2024 12:49, Anatoliy Melnik via nginx-ru wrote: > > >>>>> Если вы предлагаете писать напрямую с nginx-а в файл -- > >>>>> сделайте у себя ротацию файлов с интервалом 30 сек > >>>>> при 200-250 тыс подключений/сек... > >>>>> > >>>>> Если у вас уже есть такое рабочее решение - > >>>>> поделитесь опытом, буду рад вас выслушать. > > > "Я намеренно ввел вас в заблуждение путем публикации сообщения, > допускающее двойное толкование в ту или иную сторону по желанию > сторон." > > Почему / зачем? Был шанс увидеть в ответ нестандартное решение. > > > Дальнейшее перемалывание темы ротации лично для меня интереса не > представляет. > > Тогда прекращаем. > > >>> Вы почему-то упорно пытаетесь отказать мне в праве самостоятельно > >>> решать что мне надо :) > > Так я и не пытался решать за Вас, как именно будет лучше поступить > в Вашей конкретной ситуации - скорее я рассматривал все множество > задач сбора статистики и обработки информации из логов - и на всем > этом множестве задач старался увидеть наиболее оптимальный способ > решения задачи, если абстрагироваться от затрат времени > и сил на реализацию решения в виде програмного кода. > Т.е. насколько я понимаю некоего идеального коня в сферическом вакууме. Не получиться "универсальный анализ логов". мне нужны средние, кому-то подавай количество больше чем, кому-то нужен разброс будет от min до max. Например 100 коннектов по 1К и 100 по 1М для кого-то то же самое, что и 200 по 0.5005М, а для кого-то это суперважно. соответственно и обработка разной получится. в 1 проход или в 2. > >> Решайте сами, я просто хотел понять Вашу исходную задачу X, > >> поэтому и задавал уточняющие вопросы. > > > Спасибо. Как уже упоминалось ранее -- по озвученной на самом старте > теме я уже все решил. > > С моей точки зрения более важным является обеспечение более высокой > надежности работы системы, чтобы логи не терялись в процессе записи, > чем экономия свободного места на диске и экономия ресурсов NVMe SSD. > > Поэтому с моей точки зрения - я не могу признать решение > через syslog и unix socket более оптимальным, чем вариант > записи логов напрямую в файлы и ротации логов через SIGUSR1. > > а ротацию логов можно делать и чаще, чем раз в 30 секунд, > например, раз 15, или раз в 10 или даже раз в 5 секунд, > если хочется уменьшить отставание статистики по времени. > > По сути - лог-файл на диске - это можете воспринимать примерно, > как то же самое, что и unix socket, только с буфером не в памяти, > а в виде файла на диске и без существенных ограничений по размеру > такого буфера, что будет лучше сглаживать всплески нагрузки > и может позволить большую асинхронность между процессом > записи информации в лог и процессом чтения информации > из лога. А во всем остальном - никакой существенной > разницы нет, учитывая только что запись логов в файлы > меньше грузит процесор и использует немного больше > свободного места на диске. > > Но мне например, лучше чтобы процессор был немного свободнее, > чем проистаивающее и никак не используемое место на диске. > > Но самое главное - что запись логов в файлы не приводит к потере > данных, а запись логов в unix socket может приводить к потерям > даных, если читатель будет не успевать забирать данные из unix > socket. > > Более надежное и более простое решение, и более экономно > расходующее процесор сервера - и будет более оптимальным. > 1. Т.к. мне практически всегда нужны некоторые усредненные данные, то абсолютная полнота статистики не является основным условием. Хорошо, если она присутствует, но и если потеряно даже половина данных -- на средних значениях это слабо скажется :) 2. пока я наблюдал скорее проблему "писатель не успевает записывать", а не "читатель не успевает забирать". Эта же проблема и при файлах присутствует -- NVME не у всех всегда везде. Система дисковая как ни крути - общий ресурс, и если ее интенсивно нагрузить чем-то еще логи тоже могут получить проблему читатель-писатель. Сжатие на лету -- это не только ресурс CPU при сжатии перед записью, это еще и ресурс при распаковке для анализа, у меня это происходит со всеми данными. Т.е. если nginx потратил ресурс на запаковку, то я в ответ должен потратить ресурс на распаковку... И где тут экономия CPU?? Мое мнение: Единственный плюс прямой записи в файл -- это длительное хранение данных, чего лично мне вот вообще не требуется. При необходимости обработки и анализа полученных данных пока опыт эксплуатации показывает преимущества юникс-сокета. Об этом чуть ниже. > > При желании добраться из пунта А в пункт Б именно на машине и > проблеме "машина не едет" 2 концептуальных решения: > > 1.Заменить машину. > > 2.Устранить причины "не едет" в имеющейся. > > Соответственно 2 пути -- ищем другую машину, или меняем вышедшую из > строя запчасть. > > Если провести параллели, то с моей точки зрения мне вполне > достаточно запчасти. > > Вы предлагаете замену машины. > > Не так, я скорее рассматриваю одновременно все множество путей > из точки А в точку Б для различных вариантов А и Б и различных > внешних условий и стараюсь понять, какой именно автомобиль, > с какими именно параметрами будет наиболее оптимальным > решением для такой задачи - перемещения их точки А в точку Б. > Вертолет и телепортацию не забудьте :) Учитывая ваши слова "если абстрагироваться от затрат времени и сил на реализацию решения..." > Вот как я уже говорил, задача построения VPN - если взять все > множество > таких задач, то в части случаев для построения VPN более оптимальным > вариантом будет использование WireGuard, а в части случаев - OpenVPN. > Именно потому, что WireGuard обладает некоторыми свойствами > и качествами, которые отсутствуют в OpenVPN, и наоборот, > потому что OpenVPN обладает некоторыми свойствами и качествами, > которые отсутствуют в WireGuard. И поэтому в части случаев > оказывается более оптимальным и целесообразным построение > VPN с использованием WireGuard, а в некоторых случаях > - более оптимальнныи и целесообразным оказывается > построение VPN с использованием OpenVPN. > И в части случаев оба они окажутся в равной степени не пригодны... Да и там, где пригодны, далеко не всегда оптимальны по каким-то критериям. VPN технологий существуют десятки. Но вы почему-то в этом посте ограничились 2-мя. А как же "все множество путей" ? Эти 2 достаточно удобны для решения большого круга задач -- это да, но это не отменяет достоинств других VPN-ов. > >> Получить потери можно в случае использования syslog > >> и unix socket`ов - если читающая сторона не будет > >> успевать читать данные из сокета - у nginx не останется > >> иных варантов, кроме как дропать часть записей. > >> > >> При записи логов в файлы - этот вариант исключен, > >> если на разделе есть достаточное количество свободного места. > >> > > О появились доп. условия -- место на разделе... > > Так ведь свободное место на разделе есть, с этим же нет проблем. Есть проблема. В исходной постановке (когда сия задача встала передо мной) задачи было пожелание обойтись имеющимся ресурсом. Я задачу решил именно в этих начальных условиях. > > Если часто делать ротацию логов - его надо будет совсем не много. > > Тем более, что можно включить компрессию логов на лету, если надо. > Повторюсь: я уже просто запись в файл счел лишним этапом, а уж сопутствующие этому затраты на компрессию-декомпрессию только в минус. > >> Хотя бы даже одним только этим свойством запись логов в файлы > >> намного лучше записи логов в unix socket`ы. > > > А как же место на разделе? Замена одной проблемы другой. Только и > всего. > > У Вас разве есть проблемы со свободным местом на разделе? > тогда включите компрессию логов на лету - свободного места > потребуется меньше, ресурсов процессора будет использовано > больше. Только и всего. Это не проблема, это лишь tradeoff. > И еще раз повторюсь -- что мешает мне на концептуальном уровне просто изменить подход так, чтоб эта проблема даже на горизонте не маячила? > > Т.е. Проблему X -- расхождение при использовании сокета, вы меняете > на проблему У -- достаточное количество места > > и производительность системы ввода-вывода, просто с вашей точки > зрения это как-бы и не проблема вовсе > > Количество свободного места на разделе - это не проблема, потому что > Thin provisioning и все разделы виртуальных машин имеют логический > размер в 50 TiB, - я бы сделал и больше, но Red Hat не рекомендует. Это тут вообще к чему? > > > с моей точки зрения менять одну проблему на другую смысла нет > > использование места на диске - это не проблема, это необходимая плата > за то, что запись в логи будет происходить без потерь информации, > и что чтения и обработка информации из логов не обязаны быть > такими синхронными и производительными, как в случае с unix > socket`ами. > Обязаны! и синхронными и производительными. Если статистика будет накапливаться быстрее, чем обрабатываться, то данные никогда не будут актуальны. Т.е. я сегодня увижу статистику за вчера, а за сегодня-- только через 2 дня, а к концу года буду видеть уже с отставанием в месяц?? И кому это будет интересно?? > > Вот вам идея оптимального по большинству критериев решения -- > > Когда будете решать сходную задачу напишите свой модуль для nginx > > Чтоб сразу считать все нужное "внутри" без посредников. > > Я такое решение тоже рассматривал, отказался. > > Лично мои трудозатраты по реализации такого подхода превосходят все > разумные пределы. > > Что и стало ключевым фактором "против". > > Такой модуль уже есть, Angie умеет экспортировать данные > напрямую в Prometheus. Если бы у njs была возможность разделять > данные между worker`ами, то можно был бы пряом через njs это делать. > И скорее всего - это можно уже сейчас запрограммировать на lua, > используя в качестве веб-сервера OpenResty, там есть доступ > к разделяемой памяти. Или - просто парсить логи и все, > это будет и быстрее и проще, чем unix socket`ы, IMHO. Нет там нужных мне метрик. И быть не может :) Метрика по параметру в GET/POST запросе, усредненная за 60 секунд... Итоги разных экспериментов: Исходные данные - CPU Xeon E5-26xx v4 CPU 2.2GHz Для наглядности привожу данные по 1 вычислительному ядру. Итак, на 1 вычислительное ядро --- Существующий на данный момент бекэнд, куда nginx у меня проксирует запросы -- максимум около 2000 в секунду на одно ядро (вообще не моя епархия, но там точно НЕ php). --- NGINX для теста, на который отзеркалированы запросы, вся его функция -- выдать ответ "200" и сообщение в лог записать, все, никакого проксирования или отдачи контента, никаких вычислений и т.д. Голый "200" + строка в лог-файле средствами nginx-а, ротация 10 секунд с удалением результата. --- максимум примерно 10 000 в секунду на 1 ядро --- парсинг данных из лога, накопленного за 60 секунд из расчета нагрузки 400тыс/сек, т.е. 24млн строк. -- на одном ядре от 8 минут. в зависимости от нагрузки на дисковую подсистему 8-9 минут. т.е. при среднем 500секунд 48 000 в секунду на одно ядро. --- Обработка через юникс-сокет "на лету" python3.9 скриптом -- 43 000 в секунду на одно ядро 100% соответствие результатов, около 89-92% занятость ядра CPU. Итого технически "самый быстрый" -- парсинг лога, но тянет за собой запись-чтение-удаление при относительном преимуществе 9-12% и зависимости результата от файлового ввода-вывода. а по факту на общей нагрузке системы потенциальный выигрыш составляет 1,5-2% от производительности системы, т.к. это задача вторая, а первая -- проксирование, и она "кушает" гораздо больше парсинга. Возможно оптимизацией парсинга можно добиться и повышя скорости, выигрыш составит еще 1,5%... А из расчета загрузить сокет-питон на 100% и это преимущество теряется. Таким образом единственный сколь-нибудь существенный бонус - потенциальная полнота данных для обработки перестает быть существенным, когда считаем усредненные данные на миллионных выборках. Зеркалирование -- проигрывает по всем параметрам. код принимаюшей стороны должен быть эффективнее nginx-а (отвечающего всем "200") в 5 раз для реального выигрыша над юникс-сокет+питон. Не знаю насколько эффективен будет Go. Но честно говоря даже не вижу смысла проверять. Он должен на поррядок превосходить какой-нибудь php, а по обнаруженным данным там разница в 3-5 раз, а надо минимум в 10 для того, чтоб это имело хоть какой-то смысл в данной конкретной задаче. Могу и ошибаться. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Feb 20 05:48:00 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 20 Feb 2024 07:48:00 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <669894399.30032560.1708351283938.JavaMail.zimbra@showjet.ru> References: <669894399.30032560.1708351283938.JavaMail.zimbra@showjet.ru> Message-ID: On 19.02.2024 16:01, Anatoliy Melnik via nginx-ru wrote: >>>> Если вы предлагаете писать напрямую с nginx-а в файл -- >>>> сделайте у себя ротацию файлов с интервалом 30 сек >>>> при 200-250 тыс подключений/сек... >>>> >>>> Если у вас уже есть такое рабочее решение - >>>> поделитесь опытом, буду рад вас выслушать. >>> >>> Я намеренно ввел вас в заблуждение путем публикации сообщения, >>> допускающее двойное толкование в ту или иную сторону по желанию >>> сторон. >> >> Почему / зачем? > > Был шанс увидеть в ответ нестандартное решение. Из представленной Вами информации - что Вам не удалось настроить ротацию логов nginx раз в 30 секунд при 200-250 тыс. подключений в секунду однозначно следует что Вы использовали для ротации логов сигнал SIGHUP, делающий полный reload nginx а не сигнал SIGUSR1, который только переоткрывает лог-файлы, не перезапуская рабочие процессы. Никакого нестандартного решения в этой ситуации быть не может, кроме как использовать SIGUSR1 вместо SIGHUP для ротации логов nginx. И, как я понимаю, из представленной Вами информации - именно эта изначальная Ваша ошибка и стала причиной того, что не сумев настроить ротацю логов Вы ударились во все тяжкие с syslog, unix socket`ами и 11 процессами на Python, называя этот набор костылей решением вышеназванной Вами проблемы X. Какое именно "нестандартное решение" для вышеобозначенной проблемы с невозможностью нормально настроить ротацию логов Вы сами могли бы предложить, если бы оказались на месте читателя своих же сообщений? Я так понимаю, что и Вы точно так же не видите никаких других вариантов решения этой "проблемы" с невозможностью настроить ротацию логов, кроме как использовать SIGUSR1 вместо SIGHUP для ротации логов nginx. >> С моей точки зрения более важным является обеспечение более высокой >> надежности работы системы, чтобы логи не терялись в процессе записи, >> чем экономия свободного места на диске и экономия ресурсов NVMe SSD. >> >> Поэтому с моей точки зрения - я не могу признать решение >> через syslog и unix socket более оптимальным, чем вариант >> записи логов напрямую в файлы и ротации логов через SIGUSR1. >> >> а ротацию логов можно делать и чаще, чем раз в 30 секунд, >> например, раз 15, или раз в 10 или даже раз в 5 секунд, >> если хочется уменьшить отставание статистики по времени. >> >> По сути - лог-файл на диске - это можете воспринимать примерно, >> как то же самое, что и unix socket, только с буфером не в памяти, >> а в виде файла на диске и без существенных ограничений по размеру >> такого буфера, что будет лучше сглаживать всплески нагрузки >> и может позволить большую асинхронность между процессом >> записи информации в лог и процессом чтения информации >> из лога. А во всем остальном - никакой существенной >> разницы нет, учитывая только что запись логов в файлы >> меньше грузит процесор и использует немного больше >> свободного места на диске. >> >> Но мне например, лучше чтобы процессор был немного свободнее, >> чем проистаивающее и никак не используемое место на диске. >> >> Но самое главное - что запись логов в файлы не приводит к потере >> данных, а запись логов в unix socket может приводить к потерям >> даных, если читатель будет не успевать забирать данные из unix >> socket. >> >> Более надежное и более простое решение, и более экономно >> расходующее процесор сервера - и будет более оптимальным. > пока я наблюдал скорее проблему "писатель не успевает записывать", > а не "читатель не успевает забирать". видимая Вами проблема "писатель не успевает записывать" вызвана именно тем, что "читатель не успевает забирать". Потому что когда у Вас был всего один читатель - он не успевал читать данные из syslog и поэтому у nginx не было никаких других вариантов, кроме как дропать часть сообщений. После того как вместо одного читателя Вы сделали 10 читателей - они начали успевать читать данные из syslog и проблема с потерей сообщений стала быть Вам не видна. > Эта же проблема и при файлах присутствует -- NVME не у всех всегда везде. > Система дисковая как ни крути - общий ресурс, и если ее интенсивно нагрузить > чем-то еще логи тоже могут получить проблему читатель-писатель. На frontend-сервере, сеть может быть загружена на 100% передачей данных, и процессор может быть загружен на 100% шифрованием/расшифровской TLS. Дисковая подсистема может использоваться только для записи логов. нагружать дисковую подсистему чем-либо еще, крмое записи логов - нерационально, имеет смысл даже полностью выключить использование диска при проксировании, чтобы не было блокирования nginx на операциях дискового ввода-вывода и чтобы не было увеличения latency, когда этого можно очень просто ибежать: proxy_http_version 1.1; proxy_request_buffering off; proxy_max_temp_file_size 0; По поводу того, что сейчас NVMe есть не у всех и не всегда - это Вы мне сейчас из какого года свое сообщение пишете ? > Единственный плюс прямой записи в файл -- это длительное хранение данных, чего лично мне вот вообще не требуется. У Вас очень специфически задачи. Потому что как правило логи нужны. Потому что если логи не нужны - их просто выключают для 1хх, 2хх и 3хх статусов и логгируют только 4хх и 5хх ошибки, так что размер лог-файлов получается очень небольшим и никаких проблем создать не может. map $status $loggable { ~^[45] 1; default 0; } access_log /path/to/access.log combined if=$loggable; >> Вот как я уже говорил, задача построения VPN - если взять все множество >> таких задач, то в части случаев для построения VPN более оптимальным >> вариантом будет использование WireGuard, а в части случаев - OpenVPN. >> Именно потому, что WireGuard обладает некоторыми свойствами >> и качествами, которые отсутствуют в OpenVPN, и наоборот, >> потому что OpenVPN обладает некоторыми свойствами и качествами, >> которые отсутствуют в WireGuard. И поэтому в части случаев >> оказывается более оптимальным и целесообразным построение >> VPN с использованием WireGuard, а в некоторых случаях >> - более оптимальнныи и целесообразным оказывается >> построение VPN с использованием OpenVPN. >> > И в части случаев оба они окажутся в равной степени не пригодны... > Да и там, где пригодны, далеко не всегда оптимальны по каким-то критериям. > VPN технологий существуют десятки. Но вы почему-то в этом посте ограничились 2-мя. > А как же "все множество путей" ? > Эти 2 достаточно удобны для решения большого круга задач -- это да, но это не отменяет достоинств других VPN-ов. Я рассматриваю только те реализации VPN, которые доступны в виде open source, и которые доступны для использования, без необходимости покупать лицензию на право использования программы. Все другие варианты Open Source VPN имеет смысл рассматривать только в том случае, если они имеют какие-то преимущества, по сравнению с WireGuard и OpenVPN. Если у них никаких преимуществ нет - тогда их можно и не рассматривать. Еще есть Shadowsocks, если необходимо обходить блокировки WireGuard и OpenVPN через DPI, но это очень специфическая задача. WireGuard и OpenVPN - это две наиболее надежные по качеству кода и наиболее проверенные аудитами реализации VPN. По этому парметру - все остальные реализации и варианты VPN - значительно хуже. Например, в самом протоколе IPsec или в его популярных реализациях могут быть закладки от NSA, поэтому IPsec лучше не использовать. https://en.wikipedia.org/wiki/IPsec#Alleged_NSA_interference >> Так ведь свободное место на разделе есть, с этим же нет проблем. > Есть проблема. > В исходной постановке (когда сия задача встала передо мной) задачи было пожелание обойтись имеющимся ресурсом. > Я задачу решил именно в этих начальных условиях. Как правило, свободное место на диске - это самый дешевый ресурс. И экономить место на диске, увеличивая нагрузку на процессор, или теряя часть сообщений - это не самое лучшее решение. >>> с моей точки зрения менять одну проблему на другую смысла нет >> >> использование места на диске - это не проблема, это необходимая плата >> за то, что запись в логи будет происходить без потерь информации, >> и что чтения и обработка информации из логов не обязаны быть >> такими синхронными и производительными, как в случае с unix >> socket`ами. >> > Обязаны! и синхронными и производительными. > Если статистика будет накапливаться быстрее, чем обрабатываться, то данные никогда не будут актуальны. > Т.е. я сегодня увижу статистику за вчера, а за сегодня-- только через 2 дня, а к концу года буду видеть уже с отставанием в месяц?? > И кому это будет интересно?? Вы меня не поняли. Если использовать unix socket - при переполнении буфера в памяти происходит потеря части сообщений. Если в условиях постановки задачи важно не терять сообщения - тогда читатель сообщений должен быть таким же производительным и как писатель. Иногда, во время DDoS-атак приходит огромное количество запросов, так что процессор может быть занят на 100% и просто не остается на сервере процессорных мощностей для того, чтобы читатель с другой стороны unix socket`а успевал бы считывать данные с такой же скоростью, с какой их будет писать туда nginx. А это означает, что такая ситуация неизбежно приведет к потере части сообщений, которые nginx будет вынужден дропать потому что читатель не успевает их читать с другой стороны unix socket`а. Мне такое нестабильно работающее и ненадежное решение не нужно, которое вроде бы нормально работает под небольшой нагрузкой, но начинает глючить и терять сообщения, когда нагрузка возрастает. Если же nginx пишет логи в файл - тогда такой высокой степени синхронности читателя и писателя логов не нужно, пототому что нет буфера в памяти, который очень быстро может переполниться, а есть просто файлы на диске, и читатель логов может читать их с постоянной скоростью, например, 1 мегабайт в секунду, и даже если будут всплески нагрузки на сервер и в какие-то моменты nginx будет писать логи со скоростью 10 или 100 мегабайт в секунду - это все равно не будет приводить к потере сообщений, потому что в этом случае нет небольшого буфера в оперативной памяти, а роль буфера выполняет фактически все свободное место на диске сервера. И пиковые всплески нагрузки на сервер будут сглаживаться с помощью очень большого "буфера" на диске, и потери сообщений тогда не будет. То есть, при всех прочих условиях, более надежная и более устойчивая к всплескам нагрузки система обработки логов nginx которая не теряет сообщения является более предпочтительной, чем та система, которая теряет часть сообщений в процессе работы при всплесках нагрузки. В большинстве случаев потери сообщений недопустимы или крайне нежелательны, поэтому запись сообщений напрямую в лог-файлы, без дополнительных костылей через syslog и unix socket`ы практически всегда будет более предпочительным вариантом. Тем более, что работающее решение для ротации логов nginx при 200-250 тысячах подключений в секунду и интервале ротации раз в 30 секунд можно очень легко получить, заменив SIGHUP на SIGUSR1. Это есть ответ на тот Ваш вопрос о решении Вашей настоящей проблемы X, который приведен в самом начале этого сообщения. > Итоги разных экспериментов: > Исходные данные - CPU Xeon E5-26xx v4 CPU 2.2GHz > Для наглядности привожу данные по 1 вычислительному ядру. > Итак, на 1 вычислительное ядро > --- Существующий на данный момент бекэнд, куда nginx у меня проксирует запросы -- максимум около 2000 в секунду на одно ядро (вообще не моя епархия, но там точно НЕ php). > --- NGINX для теста, на который отзеркалированы запросы, вся его функция -- выдать ответ "200" и сообщение в лог записать, все, никакого проксирования или отдачи контента, > никаких вычислений и т.д. Голый "200" + строка в лог-файле средствами nginx-а, ротация 10 секунд с удалением результата. --- максимум примерно 10 000 в секунду на 1 ядро > --- парсинг данных из лога, накопленного за 60 секунд из расчета нагрузки 400тыс/сек, т.е. 24млн строк. -- на одном ядре от 8 минут. в зависимости от нагрузки на дисковую подсистему 8-9 минут. т.е. при среднем 500секунд 48 000 в секунду на одно ядро. > --- Обработка через юникс-сокет "на лету" python3.9 скриптом -- 43 000 в секунду на одно ядро 100% соответствие результатов, около 89-92% занятость ядра CPU. > > Итого технически "самый быстрый" -- парсинг лога, но тянет за собой запись-чтение-удаление при относительном преимуществе 9-12% и > зависимости результата от файлового ввода-вывода. парсинг лога не только самый быстрый, он еще и самый надежный, потому что в этом варианте нет потери сообщений. - Собственно, о чем я Вам и говорил, что это есть самый оптимальный вариант. нагрузку на сеть можно уменьшить, включив HTTP/1.1 и keepalive при подключении к backend`у - это если делать обработку логов именно через mirror на специально выделенный для этой задачи сервер. Вы же не рассмотрели вариант, когда nginx сам пишет логи напрямую в файл, например, блоками по 1 мегабайту, делая всего один системный вызов для записи одного такого блока информации. Насколько я понимаю, при N рабочих процессах nginx для этого потребуется дополнительно всего лишь только N мегабайт оперативной памяти. Но в результате - получим значительное уменьшение расходования процессора на запись логов и значительно меньшее количество операций переключения контекста, ведь по умолчанию вызывается операция записи для каждой строчки лога. > Таким образом единственный сколь-нибудь существенный бонус - потенциальная полнота данных для обработки перестает быть существенным, когда считаем > усредненные данные на миллионных выборках. полнота даных для обработки - как правило это важно. если Вам нужны усредненные данные на милионных выборках - тогда с технической точки зрения, самым оптимальным вариантом будет написать модуль для nginx, который будет делать эту работу на лету и практически мгновенно и практически с 0 затратами ресурсов. > Не знаю насколько эффективен будет Go. Go создан достаточно умными людьми, такими как Роб Пайк, один из создателей кодировки UTF-8. Go позволяет сделать concurrency используя goroutines и channels, и этот язык программирования, созданный в Google практически идеально подходит для работы в состоянии высоких нагрузок, позволяя быстро писать быстрый, качественный и надежный код, который легко справляться даже с очень высокими нагрузками. Если производиельности которую дает Go будет не хватать, тогда остается только Rust, C++ и C, но обычно - дешевле и проще будет просто горизонтальное масштабирование, путем увеличения количества серверов для вебсайта. Если нет highload, тогда удобнее и приятнее Python, и скорость написания кода будет выше, но скорость работы кода будет ниже - вот такой тут trade-off. > Он должен на порядок превосходить какой-нибудь php Он превосходит. Поэтому практически весь highload делают сейчас именно на Go а не на PHP, если есть возможность выбора и нет необходимости работать с большим количеством legacy кода. -- Best regards, Gena From anatoliy.melnik на showjet.ru Wed Feb 21 12:54:20 2024 From: anatoliy.melnik на showjet.ru (Anatoliy Melnik) Date: Wed, 21 Feb 2024 15:54:20 +0300 (MSK) Subject: =?utf-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L7QvtCx?= =?utf-8?B?0YnQtdC90LjQuSDQsiBsb2cgc3lzbG9nINCx0LXQtyDQv9C+0YLQtdGA0Yw/?= Message-ID: <127477908.36635932.1708520060516.JavaMail.zimbra@showjet.ru> Gena Makhomed Wrote: ------------------------------------------------------- > On 19.02.2024 16:01, Anatoliy Melnik via nginx-ru wrote: > > >>>> Если вы предлагаете писать напрямую с nginx-а в файл -- > >>>> сделайте у себя ротацию файлов с интервалом 30 сек > >>>> при 200-250 тыс подключений/сек... > >>>> > >>>> Если у вас уже есть такое рабочее решение - > >>>> поделитесь опытом, буду рад вас выслушать. > >>> > >>> Я намеренно ввел вас в заблуждение путем публикации сообщения, > >>> допускающее двойное толкование в ту или иную сторону по желанию > >>> сторон. > >> > >> Почему / зачем? > > > > Был шанс увидеть в ответ нестандартное решение. > (мантры про логи...) > > Какое именно "нестандартное решение" для вышеобозначенной проблемы (мантры....) Если вам его не видно -- это не значит, что его нет. Тот же костыль из юникс-сокета у меня в "альфа" версии на этапе проверки возможностей показал результат в 400тыс/сек с запасом. Кстати от вас я так и не увидел ни одной ссылки на конкретные значения из вашего личного опыта. Лично мой опыт показывает, что при значениях более 500тыс/сек и примерно 1млн "живых" tcp сессий "падает" уже сама ось. Если у вас есть конкретный пример, что на таком-то железе, такой-то оси вы "перевариваете" 1млн/сек -- отлично. Если нет... Ну на нет и суда нет. > > >> С моей точки зрения более важным является обеспечение более > высокой > >> надежности работы системы, чтобы логи не терялись в процессе > записи, > >> чем экономия свободного места на диске и экономия ресурсов NVMe > SSD. > >> > >> Поэтому с моей точки зрения - я не могу признать решение > >> через syslog и unix socket более оптимальным, чем вариант > >> записи логов напрямую в файлы и ротации логов через SIGUSR1. > >> > >> а ротацию логов можно делать и чаще, чем раз в 30 секунд, > >> например, раз 15, или раз в 10 или даже раз в 5 секунд, > >> если хочется уменьшить отставание статистики по времени. > >> > >> По сути - лог-файл на диске - это можете воспринимать примерно, > >> как то же самое, что и unix socket, только с буфером не в памяти, > >> а в виде файла на диске и без существенных ограничений по размеру > >> такого буфера, что будет лучше сглаживать всплески нагрузки > >> и может позволить большую асинхронность между процессом > >> записи информации в лог и процессом чтения информации > >> из лога. А во всем остальном - никакой существенной > >> разницы нет, учитывая только что запись логов в файлы > >> меньше грузит процесор и использует немного больше > >> свободного места на диске. > >> > >> Но мне например, лучше чтобы процессор был немного свободнее, > >> чем проистаивающее и никак не используемое место на диске. > >> > >> Но самое главное - что запись логов в файлы не приводит к потере > >> данных, а запись логов в unix socket может приводить к потерям > >> даных, если читатель будет не успевать забирать данные из unix > >> socket. > >> > >> Более надежное и более простое решение, и более экономно > >> расходующее процесор сервера - и будет более оптимальным. > > > пока я наблюдал скорее проблему "писатель не успевает записывать", > > а не "читатель не успевает забирать". > > видимая Вами проблема "писатель не успевает записывать" > вызвана именно тем, что "читатель не успевает забирать". > > Потому что когда у Вас был всего один читатель - он не успевал > читать данные из syslog и поэтому у nginx не было никаких других > вариантов, кроме как дропать часть сообщений. После того как вместо > одного читателя Вы сделали 10 читателей - они начали успевать читать > данные из syslog и проблема с потерей сообщений стала быть Вам не > видна. > Вы, как и всегда, имеете полное право на свое мнение. > > Эта же проблема и при файлах присутствует -- NVME не у всех всегда > везде. > > Система дисковая как ни крути - общий ресурс, и если ее интенсивно > нагрузить > > чем-то еще логи тоже могут получить проблему читатель-писатель. > > На frontend-сервере, сеть может быть загружена на 100% передачей > данных, > и процессор может быть загружен на 100% шифрованием/расшифровской > TLS. > Дисковая подсистема может использоваться только для записи логов. > > нагружать дисковую подсистему чем-либо еще, крмое записи логов > - нерационально, имеет смысл даже полностью выключить использование > диска при проксировании, чтобы не было блокирования nginx на > операциях > дискового ввода-вывода и чтобы не было увеличения latency, когда > этого > можно очень просто ибежать: > > proxy_http_version 1.1; > proxy_request_buffering off; > proxy_max_temp_file_size 0; > > По поводу того, что сейчас NVMe есть не у всех и не всегда > - это Вы мне сейчас из какого года свое сообщение пишете ? Вы, как и всегда, имеете полное право на свое мнение. Свой набор критериев оптимальности и эффективности. > > > Единственный плюс прямой записи в файл -- это длительное хранение > данных, чего лично мне вот вообще не требуется. > > У Вас очень специфически задачи. Потому что как правило логи нужны. Что и было описано еще в самом начале. > Потому что если логи не нужны - их просто выключают для 1хх, 2хх > и 3хх статусов и логгируют только 4хх и 5хх ошибки, так что размер > лог-файлов получается очень небольшим и никаких проблем создать не > может. > > map $status $loggable { > ~^[45] 1; > default 0; > } > access_log /path/to/access.log combined if=$loggable; > > >> Вот как я уже говорил, задача построения VPN - если взять все > множество > >> таких задач, то в части случаев для построения VPN более > оптимальным > >> вариантом будет использование WireGuard, а в части случаев - > OpenVPN. > >> Именно потому, что WireGuard обладает некоторыми свойствами > >> и качествами, которые отсутствуют в OpenVPN, и наоборот, > >> потому что OpenVPN обладает некоторыми свойствами и качествами, > >> которые отсутствуют в WireGuard. И поэтому в части случаев > >> оказывается более оптимальным и целесообразным построение > >> VPN с использованием WireGuard, а в некоторых случаях > >> - более оптимальнныи и целесообразным оказывается > >> построение VPN с использованием OpenVPN. > >> > > И в части случаев оба они окажутся в равной степени не пригодны... > > Да и там, где пригодны, далеко не всегда оптимальны по каким-то > критериям. > > VPN технологий существуют десятки. Но вы почему-то в этом посте > ограничились 2-мя. > > А как же "все множество путей" ? > > Эти 2 достаточно удобны для решения большого круга задач -- это да, > но это не отменяет достоинств других VPN-ов. > > Я рассматриваю только те реализации VPN, которые доступны > в виде open source, и которые доступны для использования, > без необходимости покупать лицензию на право использования > программы. > > Все другие варианты Open Source VPN имеет смысл рассматривать > только в том случае, если они имеют какие-то преимущества, > по сравнению с WireGuard и OpenVPN. Если у них никаких > преимуществ нет - тогда их можно и не рассматривать. > > Еще есть Shadowsocks, если необходимо обходить > блокировки WireGuard и OpenVPN через DPI, > но это очень специфическая задача. В openssh-е есть "встроенный" socks5. Можно вообще без дополнительного ПО обойтись. Довольно долгое время вообще ppp over ssh пользовался и более чем устраивало. Но опять же. Вы, как и всегда, имеете полное право на свое мнение. Свой набор критериев оптимальности и эффективности. > > WireGuard и OpenVPN - это две наиболее надежные > по качеству кода и наиболее проверенные аудитами > реализации VPN. По этому парметру - все остальные > реализации и варианты VPN - значительно хуже. > > Например, в самом протоколе IPsec или в его популярных реализациях > могут быть закладки от NSA, поэтому IPsec лучше не использовать. > https://en.wikipedia.org/wiki/IPsec#Alleged_NSA_interference > > >> Так ведь свободное место на разделе есть, с этим же нет проблем. > > > Есть проблема. > > В исходной постановке (когда сия задача встала передо мной) задачи > было пожелание обойтись имеющимся ресурсом. > > Я задачу решил именно в этих начальных условиях. > > Как правило, свободное место на диске - это самый дешевый ресурс. > И экономить место на диске, увеличивая нагрузку на процессор, > или теряя часть сообщений - это не самое лучшее решение. Вы, как и всегда, имеете полное право на свое мнение. Свой набор критериев оптимальности и эффективности. > > >>> с моей точки зрения менять одну проблему на другую смысла нет > >> > >> использование места на диске - это не проблема, это необходимая > плата > >> за то, что запись в логи будет происходить без потерь информации, > >> и что чтения и обработка информации из логов не обязаны быть > >> такими синхронными и производительными, как в случае с unix > >> socket`ами. > >> > > Обязаны! и синхронными и производительными. > > Если статистика будет накапливаться быстрее, чем обрабатываться, то > данные никогда не будут актуальны. > > Т.е. я сегодня увижу статистику за вчера, а за сегодня-- только > через 2 дня, а к концу года буду видеть уже с отставанием в месяц?? > > И кому это будет интересно?? > > Вы меня не поняли. > > Если использовать unix socket - при переполнении буфера > в памяти происходит потеря части сообщений. Если в условиях > постановки задачи важно не терять сообщения - тогда читатель > сообщений должен быть таким же производительным и как писатель. > > Иногда, во время DDoS-атак приходит огромное количество запросов, > так что процессор может быть занят на 100% и просто не остается > на сервере процессорных мощностей для того, чтобы читатель > с другой стороны unix socket`а успевал бы считывать данные > с такой же скоростью, с какой их будет писать туда nginx. > А это означает, что такая ситуация неизбежно приведет > к потере части сообщений, которые nginx будет вынужден > дропать потому что читатель не успевает их читать > с другой стороны unix socket`а. > > Мне такое нестабильно работающее и ненадежное решение не нужно, > которое вроде бы нормально работает под небольшой нагрузкой, > но начинает глючить и терять сообщения, когда нагрузка возрастает. > > Если же nginx пишет логи в файл - тогда такой высокой степени > синхронности читателя и писателя логов не нужно, пототому что > нет буфера в памяти, который очень быстро может переполниться, > а есть просто файлы на диске, и читатель логов может читать их > с постоянной скоростью, например, 1 мегабайт в секунду, и даже > если будут всплески нагрузки на сервер и в какие-то моменты > nginx будет писать логи со скоростью 10 или 100 мегабайт в секунду > - это все равно не будет приводить к потере сообщений, потому что > в этом случае нет небольшого буфера в оперативной памяти, а роль > буфера выполняет фактически все свободное место на диске сервера.> > И пиковые всплески нагрузки на сервер будут сглаживаться с помощью > очень большого "буфера" на диске, и потери сообщений тогда не будет. > > То есть, при всех прочих условиях, более надежная и более устойчивая > к всплескам нагрузки система обработки логов nginx которая не теряет > сообщения является более предпочтительной, чем та система, которая > теряет часть сообщений в процессе работы при всплесках нагрузки. > > В большинстве случаев потери сообщений недопустимы > или крайне нежелательны, поэтому запись сообщений > напрямую в лог-файлы, без дополнительных костылей > через syslog и unix socket`ы практически всегда > будет более предпочительным вариантом. > > Тем более, что работающее решение для ротации логов nginx > при 200-250 тысячах подключений в секунду и интервале ротации > раз в 30 секунд можно очень легко получить, заменив SIGHUP на > SIGUSR1. > Это есть ответ на тот Ваш вопрос о решении Вашей настоящей проблемы > X, > который приведен в самом начале этого сообщения. > Вы, как и всегда, имеете полное право на свое мнение. Свой набор критериев оптимальности и эффективности. > > Итоги разных экспериментов: > > Исходные данные - CPU Xeon E5-26xx v4 CPU 2.2GHz > > Для наглядности привожу данные по 1 вычислительному ядру. > > Итак, на 1 вычислительное ядро > > --- Существующий на данный момент бекэнд, куда nginx у меня > проксирует запросы -- максимум около 2000 в секунду на одно ядро > (вообще не моя епархия, но там точно НЕ php). > > --- NGINX для теста, на который отзеркалированы запросы, вся его > функция -- выдать ответ "200" и сообщение в лог записать, все, > никакого проксирования или отдачи контента, > > никаких вычислений и т.д. Голый "200" + строка в лог-файле > средствами nginx-а, ротация 10 секунд с удалением результата. --- > максимум примерно 10 000 в секунду на 1 ядро > > --- парсинг данных из лога, накопленного за 60 секунд из расчета > нагрузки 400тыс/сек, т.е. 24млн строк. -- на одном ядре от 8 минут. в > зависимости от нагрузки на дисковую подсистему 8-9 минут. т.е. при > среднем 500секунд 48 000 в секунду на одно ядро. > > --- Обработка через юникс-сокет "на лету" python3.9 скриптом -- 43 > 000 в секунду на одно ядро 100% соответствие результатов, около 89-92% > занятость ядра CPU. > > > > Итого технически "самый быстрый" -- парсинг лога, но тянет за собой > запись-чтение-удаление при относительном преимуществе 9-12% и > > зависимости результата от файлового ввода-вывода. > > парсинг лога не только самый быстрый, он еще и самый надежный, > потому что в этом варианте нет потери сообщений. - Собственно, > о чем я Вам и говорил, что это есть самый оптимальный вариант. > > нагрузку на сеть можно уменьшить, включив HTTP/1.1 и keepalive > при подключении к backend`у - это если делать обработку логов > именно через mirror на специально выделенный для этой задачи сервер. > > Вы же не рассмотрели вариант, когда nginx сам пишет логи напрямую > в файл, например, блоками по 1 мегабайту, делая всего один системный > вызов для записи одного такого блока информации. Насколько > я понимаю, при N рабочих процессах nginx для этого потребуется > дополнительно всего лишь только N мегабайт оперативной памяти. > Но в результате - получим значительное уменьшение расходования > процессора на запись логов и значительно меньшее количество > операций переключения контекста, ведь по умолчанию вызывается > операция записи для каждой строчки лога. Вы, как и ранее, совершенно спокойно решаете за меня что я делал, а чего не делал. Еще на старте я указал, что "долго, кучно, с кучей подробностей.... и абсолютно бесполезно." Вы с блеском подтвердили этот тезис. Дальнейшее обсуждение не имеет смысла. > > > Таким образом единственный сколь-нибудь существенный бонус - > потенциальная полнота данных для обработки перестает быть > существенным, когда считаем > > усредненные данные на миллионных выборках. > > полнота даных для обработки - как правило это важно. > > если Вам нужны усредненные данные на милионных выборках - > тогда с технической точки зрения, самым оптимальным вариантом > будет написать модуль для nginx, который будет делать эту работу > на лету и практически мгновенно и практически с 0 затратами ресурсов. Ок. Встанет перед вами такая задача -- вы выберете соответствующий путь ее решения. > > > Не знаю насколько эффективен будет Go. > > Go создан достаточно умными людьми, > такими как Роб Пайк, один из создателей кодировки UTF-8. > > Go позволяет сделать concurrency используя goroutines и channels, > и этот язык программирования, созданный в Google практически > идеально подходит для работы в состоянии высоких нагрузок, > позволяя быстро писать быстрый, качественный и надежный код, > который легко справляться даже с очень высокими нагрузками. Без проблем -- пишете, тестируете, выкладываете сюда сравнительные результаты. С числами, процентами, погрешностями и т.д. в конкретной задаче. > > Если производиельности которую дает Go будет не хватать, > тогда остается только Rust, C++ и C, но обычно - дешевле > и проще будет просто горизонтальное масштабирование, > путем увеличения количества серверов для вебсайта. > > Если нет highload, тогда удобнее и приятнее Python, > и скорость написания кода будет выше, но скорость > работы кода будет ниже - вот такой тут trade-off. > > > Он должен на порядок превосходить какой-нибудь php > > Он превосходит. Поэтому практически весь highload делают > сейчас именно на Go а не на PHP, если есть возможность выбора > и нет необходимости работать с большим количеством legacy кода. "Он превосходит" и "он превосходит на порядок" -- несколько разные формулировки. Но у вас есть возможность показать это практически -- пишете 2 реализации одного и тогоже функционала на Go и НЕ_Go, сравниваете, затем сравниваете с "тупо 200 всем прям с nginx-а" и обнародуете результат. На даном этапе лично я свой "костыль" довел до альфа-версии инвалидского кресла с моторчиком :) Проверяю возможность автоматического противодействия ДДоС-у почти в реальном времени. Но это уже совсем другая история. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Wed Feb 21 18:28:46 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 21 Feb 2024 20:28:46 +0200 Subject: =?UTF-8?B?UmU6INCi0LXRgdGCIG5naW54IC0tINGB0LrQvtC70YzQutC+INGB0L4=?= =?UTF-8?B?0L7QsdGJ0LXQvdC40Lkg0LIgbG9nIHN5c2xvZyDQsdC10Lcg0L/QvtGC0LXRgNGM?= =?UTF-8?Q?=3F?= In-Reply-To: <127477908.36635932.1708520060516.JavaMail.zimbra@showjet.ru> References: <127477908.36635932.1708520060516.JavaMail.zimbra@showjet.ru> Message-ID: <1f70b6f6-ea63-4fbc-8218-c512df49b545@csdoc.com> On 21.02.2024 14:54, Anatoliy Melnik via nginx-ru wrote: >>>> Если вы предлагаете писать напрямую с nginx-а в файл -- >>>> сделайте у себя ротацию файлов с интервалом 30 сек >>>> при 200-250 тыс подключений/сек... >>>> >>>> Если у вас уже есть такое рабочее решение - >>>> поделитесь опытом, буду рад вас выслушать. >>> >>> Я намеренно ввел вас в заблуждение путем публикации сообщения, >>> допускающее двойное толкование в ту или иную сторону по желанию >>> сторон. Проблема X которую Вы сформулировали вот таким образом не допускает двойных толкований, потому что не получить "рабочее решение" в таких условиях можно только одним способом - делая ротацию логов через SIGHUP. > Кстати от вас я так и не увидел ни одной ссылки на конкретные значения из вашего личного опыта. > Лично мой опыт показывает, что при значениях более 500тыс/сек и примерно 1млн "живых" tcp сессий "падает" уже сама ось. > Если у вас есть конкретный пример, что на таком-то железе, такой-то оси вы "перевариваете" 1млн/сек -- отлично. > Если нет... Ну на нет и суда нет. Из моего личного опыта - ротация логов через SIGUSR1 возможна при любом количестве подключений, и любом разумном интервале - проблем не будет. Вопрос о том, какую именно нагрузку способен будет выдержать сервер - однозначного ответа не имеет, потому что зависит от очень многих параметров - количества ядер процесора, объема оперативной памяти, пропускной способности подключения к сети, настроек системы и т.п. -- Best regards, Gena From gmm на csdoc.com Thu Feb 29 19:30:21 2024 From: gmm на csdoc.com (Gena Makhomed) Date: Thu, 29 Feb 2024 21:30:21 +0200 Subject: NGINX as a WebSocket Proxy Message-ID: <81245ee0-4b27-4f85-8829-41210eaaada1@csdoc.com> Здравствуйте, All! В статье https://www.nginx.com/blog/websocket-nginx/ рекомендуется такой код: http { map $http_upgrade $connection_upgrade { default upgrade; '' close; } upstream websocket { server 192.168.100.10:8010; } server { listen 8020; location / { proxy_pass http://websocket; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header Host $host; } } } При этом в других статьях - для включения keep-alive рекомендуется такой код: proxy_http_version 1.1; proxy_set_header Connection ""; для того, чтобы режим Keep-alive работал между nginx и backend. Keep-alive connections are enabled by default in HTTP/1.1 while not in HTTP/1.0. HTTP/1.0 was designed to close the connection after every request between client and server. может быть в статье на сайте рекомендуется не самая оптимальная настройка и лучше было бы сделать так: # cat /etc/nginx/nginx.conf http { map $http_upgrade $connection_upgrade { default Upgrade; '' ''; } proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header Host $host; } в таком случае и вебсокеты смогут работать по любому урлу и при этом keep-alive подключения к backend тоже будут работать. upstream node { server 127.0.0.1:3000; keepalive 64; } ведь нет же никаких причин разрешать вебсокеты только по какому-то явно прописанному в конфиге урлу, а по всем остальным урлам - запрещать? -- Best regards, Gena