Я пытаюсь преобразовать правила перезаписи
из файлов .htaccess
в конфигурацию nginx
. как часть переноса сайта на веб-сервер NGINX
.
вот правила перезаписи из .htaccess
файла
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_URI} !\.php$
RewriteCond %{REQUEST_URI} !\.gif$
RewriteCond %{REQUEST_URI} !\.jp?g$
RewriteCond %{REQUEST_URI} !\.png$
RewriteCond %{REQUEST_URI} !\.css$
RewriteCond %{REQUEST_URI} !\.js$
RewriteCond %{REQUEST_URI} !\.html$
RewriteCond %{REQUEST_URI} !\.xhtml$
RewriteCond %{REQUEST_URI} !\.htm$
RewriteCond %{REQUEST_URI} !\.ico$
RewriteRule (.*) index.php [L]
RewriteRule (.*).html index.php [L]
моей текущей конфигурации nginx
.
server {
listen 80;
server_name example.com;
root /usr/share/nginx/html;
location / {
index index.php index.html index.htm;
}
location ~ \.(php)$ {
try_files $uri =404;
root /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location !~* .(css|js|html|htm|xhtml|php|png|gif|ico|jpg|jpeg)$ {
# Matches requests ending in png, gif, ico, jpg or jpeg.
rewrite ^(.*)$ /index.php break;
rewrite (.*).html /index.php break;
}
}
домашняя страница работает, но внутренние ссылки сайта дают 404.
до сих пор я пробовал много правил перезаписи, подобных этим.
if ( $uri ~ ^/(?!(\.css|\.js|\.html|\.htm|\.xhtml|\.php|\.png|\.gif|\.ico|\.jpg|\.jpeg))) {
rewrite ^/(.*)$ /index.php break;
}
но иногда внутренняя ссылка работает, при перенаправлении всех статических файлов, таких как .css, .js, на домашнюю страницу , время от времени рабочие php-fpm начинают накапливаться, в результате этого также возникает процессор, подключения к sql и, в конечном итоге, процессор sql - к счастью, это никогда не длится слишком долго.
Я уверен, что это что-то удаленное, так как это происходит одновременно со всеми серверами, которые в настоящее время находятся под LB
По результатам моего исследования и тестирования, я думаю, что я отследил это до чего-то на веб-уровне, из-за которого процессы php зависли. ] Я считаю, что могу исключить подключения к моему кластеру ES, а также к RDS по нескольким причинам, - Отдельный мониторинг ES от конкретного хоста, у которого есть проблемы, теперь показывает проблемы - Все подключения к ES / SQL выполняются через уровень API, журналы API не показывают неудачных запросов (499/502), поскольку я получаю в веб-журналах. - Скрипт проверки работоспособности, который работает на php, вызывает данные из ES и SQL с самого веб-сервера, также не показывает проблем, в то время как веб-уровень начинает возвращать 499/502 - Дальнейший общий мониторинг среды SQL и ES не выявил проблем.
Это также не внезапное увеличение количества подключений / атак - анализ показателей балансировщика нагрузки не показывает ничего беспокоящего, кроме увеличения задержки, когда проблемы начинают действовать.
Я подозреваю, что часть php-запроса к веб-уровню требует, чтобы он генерировал ответ, который включает данные из внешних источников, некоторые из которых иногда не отвечают и приводят к зависанию ответа сервера.
Мне нужен способ чтобы доказать (или опровергнуть) это и идентифицировать соединения, я смотрел netstat, возможно, wirehark, но я мог бы помочь с определением команды, которая будет выделять либо сбой исходящего соединения, либо зависание - просто чтобы иметь возможность регистрировать любые исходящие соединения, которые занимают определенное время, были бы очень полезны, если проблемы совпадают с этими журналами, то я буду на правильном пути с некоторыми подсказками.
Я знаю, как я могу запустить это, как только соединения начнут истекать по таймауту, если нецелесообразно запускать его постоянно.
Надеюсь, вы, ребята, дадите мне несколько идей :)
Спасибо
Единственный способ получить необходимые данные - это выполнить захват пакета с полной информацией о пакете. Что-то вроде:
$ tcpdump -s0 -w packet.cap port 80 or port 443
Предупреждение, это займет дисковое пространство, поэтому убедитесь, что у вас достаточно места для хранения пакетов. После прохождения этого периода, когда проблема наблюдается, скопируйте файл локально и изучите его с помощью wirehark. Вы сможете проверить полные потоки TCP и HTTP-вызовы / ответы, как инициированные клиентами, так и инициированные вашим сервером.
Я бы спросил, однако ... вы уверены, что ваш сервер действительно запрашивает эти внешние ресурсы, а затем обслуживает их своим клиентам? В подавляющем большинстве случаев рекламные сети и т.п. обслуживают напрямую браузерам клиентов, а не через ваш веб-сервер.