Vesta Control Panel - Forum

А почему по умолчанию не использовать отдельные логи для httpd и nginx (статика)?

На уровне error логов это дало бы возможность различать ошибки в скрипте и просто удаленные / недостающие файлы (картинки / кеш картинок / стили / ...)

На уровне access логов:

• дает возможность сбора статисктики по именно запрошенным урлам
• если еще и логи переименовать в шаблон %domain%.static.access.log и %domain%.access.log то можно в fail2ban прописать правило для недобросовестных ботов и парсеров, на количество запросов в минуту / 5 мин / 10 мин

Если самому прописать шаблоны такого плана не должно ничего отвалиться? Ротация логов или еще что-либо?

Imperio или еще кто-нибудь - не проясните ситуацию по данному вопросу?
Хотя это наверно больше вопрос к Сергею, почему был выбран именно такой вариант логов, почему стоит или не стоит делать иначе... Но хотелось бы услышать мнение и обсудить

Можно оставить пожелание на http://bugs.vestacp.com/

Alex Connor wrote:Можно оставить пожелание на http://bugs.vestacp.com/

Для начала хотел бы обсудить и понять в правильном ли направлении думаю. Самому в своих шаблонах для httpd/nginx прописать то не проблема (уже прописал и тестирую)

Т.е. логи разделил:
- logrotate работает по маске, значит все норма
- awstats не знаю как работает, но он для меня не важен особо, но для внедрения такого решения конечно он тоже должен уметь работать с разделенными логами
- другие вещи вроде к этим логам отношения не имеют.
- симлинки в папку пользователя пробросить тоже не проблема на недостающие логи

Т.е. с логами теперь все норма - я могу отдельно смотреть где у меня не хватает каких-то картинок, а где у меня выскакивают ошибки в скриптах.

С fail2ban я тут наверно погорячился все-же, пишут что на больших логах положит систему в таком варианте, лучше в nginx добавлять ngx_http_limit_req_module и тогда можно будет списывать в error log тех у кого превышение по коннектам и их уже банить в fail2ban.

Но тут тоже проблема как различать эти боты/парсеры и как считать запросы:
- статики на страницу выходит порядка 60 ресурсов (картинки / css /js), а значит новый клиент или клиент открывший новую для него страницу сгенерирует сразу порядка 60 запросов в короткий промежуток времени
- парсер же не будет тянуть все ресурсы - он будет тянуть страницы и возможно пару картинок и то не факт
- сами по себе динамические страницы тянут больше ресурсов, поэтому целесообразно ограничение именно по ним считать (особенно на тяжелых системах как у меня )))

Т.е. нужно ограничение вводить только по запросам к динамическому контенту (читай то что проходит на apache или php-fpm).

Я эту схему попробую донастроить и оттестировать в ближ. время, если кому интересно - могу поделиться конфигами потом...

Просто надоело когда все начинает непонятно от чего тормозить, ползать по логам и искать откуда нагрузка, потом руками в бан вносить - хочу автоматом это дело )))
Ну а гигабайтные логи парсить (это за день набирается) каждых сколько то минут тоже не правильное решение

Дублирую сообщение, т.к. БД форума снесли...

Голосование тут: https://bugs.vestacp.com/responses/sepa ... ic-content