Как лучше всего сделать защиту от denial of service при исчерпании свободного места на диске большими по объему лог-файлами nginx?
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 добавляя в нее все новые и новые поля, до тех пор, пока конфликта
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
вс, 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 > ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
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 ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
А "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.Самое ужасное –
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
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.Спустя много итераций и
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
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-проблема возникает, когда люди зацикливаются на мелких деталях своей проблемы и на том, что они сами считают решением проблемы. В итоге они не могут отступить на шаг назад и
