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

Anatoliy Melnik anatoliy.melnik на showjet.ru
Ср Фев 14 11:30:57 UTC 2024





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: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20240214/7bcd33e6/attachment-0001.htm>


Подробная информация о списке рассылки nginx-ru