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






_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru