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