Re: Как лучше всего сделать защиту от denial of service при исчерпании свободного места на диске большими по объему лог-файлами nginx?
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 ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
И снова здравствуйте. Тут прям уже прям целое расследование: Что я сказал, что хотел сказать, где и сколько соврал... "Без меня меня женили"... Читается как детективная история :) Коль пошла такая дискуссия: " [ 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 (или я слишком оптимистичен в разрезе "для большинства"??) Задача по предотвращению исчерпания места на диске так же была решена задолго ДО обращения сюда. Следуем дальше: мне чисто по человечески любопытно, допустим, нашелся такой человек. ну ок, у него работает, у меня нет. и в чем профит того факта, что такой человек нашелся Знание о том, что проблема разрешима, дает довольно много. "Дайте мне точку опоры, и я переверну Землю" (кажется Архимед) Вот эту "точку опоры" я в некотором роде и искал :) Собственно, как и в большинстве случаев, нашел не то, что искал. Но найденное НЕ разочаровало. Со знающими людьми пообщался как минимум. Что у нас еще обнаружилось: Снисходительность, ирония, сарказм... (возможно я самонадеян и не так понял некоторые моменты в комментариях? буду рад, если это действительно так) Возникает впечатление, что кому-то из вас принципиально важно доказать незыблемую правоту своего мнения и ошибочность моих действий. Вопрос - зачем? Это не конкурс или состязание, я сюда обратился за советом. Не за поддержкой или осуждением, сочувствием, порицанием или одобрением и т.д. Помощь я получил. Не в том виде, в котором ожидал. Но поверьте - оценил и благодарен ЗА ПОМОЩЬ. Конкретный ответ на поставленный в самом начале вопрос, как правильно заметили выше, потерял актуальность. Какая разница насколько глубокое ущелье на моем пути, если я уже построил через него мост? Может он не самый красивый, вечный, грузоподъемный и уникальный... Для моих целей его достаточно :) Возможно, по мнению кого-то, я вообще иду "не туда"! И? Вы свои аргументы привели, мое мнение они не изменили... Или для некоторых "есть только два мнения: моё и неправильное"? Всем дочитавшим - благодарность за терпение. Предлагаю на сем финишировать. Или я чего-то не понимаю? ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как лучше всего сделать защиту от denial of service при исчерпании свободного места на диске большими по объему лог-файлами nginx?
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 запускается по крону только
Re: Тест nginx -- сколько сообщений в log syslog без потерь?
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 возможности для записи и ротации логов? Или я чего-то не понимаю? «Ничего личного, т
Re: Как лучше всего сделать защиту от denial of service при исчерпании свободного места на диске большими по объему лог-файлами nginx?
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 ___ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
