Как я могу отлаживать nginx дальше, чем журнал ошибок?

В настоящее время я получаю довольно большой поток HTTP, и это заставляет мой обратный прокси-сервер nginx производить 502 Bad Gateway.

У меня есть внешний сервер, на котором запущен nginx в качестве прокси-сервера для моего внутреннего сервера, но он просто получает кучу connect() failed (110: Connection timed out) while connecting to upstreamошибок. Тонны из них. Если я обойду прокси-сервер для подключения к бэкэнду, я смогу нормально запустить сайт, поэтому я знаю, что он где-то в обратном прокси. Тем не менее, я понятия не имею, как определить, почему это время ожидания.

Любая помощь?

запуск nginx 1.2.3 на CentOS 6.2

Я предполагаю, что вы уже подняли свой уровень регистрации ошибок Nginx до отладки. Если нет, начните там.

Ваша лучшая ставка, вероятно, будет использоваться straceдля просмотра системных вызовов, выполняемых Nginx. В частности, вы хотите обратить внимание на connect()звонки и следить за их кодами возврата ( man 2 connectможете быть вашим другом здесь).

Получив эту информацию, вы сможете лучше сделать обоснованное предположение о том, связана ли проблема с вашим прокси-сервером внешнего интерфейса или как-то связано с взаимодействиями прокси-сервера и внутреннего сервера приложений.

Он не станет намного более педантичным, чем этот, если вы не захотите использовать датчики dtrace:

1. Установите уровень журнала отладки: /etc/nginx/nginx.conf:

   ...
   http {
           ...
           error_log /var/log/nginx/error.log debug; # todo testing remove me not for production use
           ...
   }
   

2. Настройте tcpdump в другом окне:

   tcpdump not port 22 -vvv -s0 -q -XXX
   

3. Следите за файлами журналов в другом окне:

   tail -f /var/log/nginx/*
   

4. Запуск nginx в интерактивном режиме с помощью strace:

   # top of /etc/nginx/nginx.conf:
   
   daemon off; # todo testing remove me not for production use
   

   А потом

    $ strace nginx 
   

Дальнейшую отладку можно выполнить с помощью скомпилированного nginx --with-debug. Проверьте это, запустив:

    nginx -V 2>&1 | grep -- '--with-debug' # no output if not debug

Еще один хороший модуль, не скомпилированный по умолчанию: HttpStubStatusModule . По всей вероятности, любая приличная установка потребует скомпилированного nginx (настоятельно рекомендуется использовать упаковочные инструменты дистрибутива).

Большинство из них не подходят для производственного использования, посмотрите на компиляцию nginx с помощью gperf, если вам нужно больше статистики.

Похоже, вы отлаживаете сайт с высоким трафиком.

Используйте debugс debug_connectionдирективой, чтобы журнал ошибок nginx отображал журналы отладки только с вашего IP.

Как только вы начнете видеть некоторые полезные журналы ошибок, а не активировать опцию отладки для всего конфига nginx, добавьте отдельную error_log /path/to/some/file/ debug;директиву в location {..}блок, отвечающий за соединение reverse_proxy.

Таким образом, вы сможете изолировать журнал ошибок отладки только от вашего IP.

Попробуйте связать это с запросом, который вы делаете (из вашего браузера).

Например, проверьте: https://easyengine.io/tutorials/nginx/debugging/

На шаг впереди вы можете использовать HttpEchoModule от Nginx

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

1. Проблема с настройкой Nginx
   1. Значение тайм-аута в восходящем направлении неверно
   2. Неправильный URL-адрес зонда в восходящем направлении
   3. Слишком мало работников
   4. И т.п.
2. Узкое место в TCP / IP операционной системы
   1. Возможно, сам прокси вызывает дублирование открытых портов и состояний. Будь то файловые дескрипторы, порты, TCP-соединения

Не видя ваших конфигов Nginx, никто не может прокомментировать первое. А без подходящих выходов из ОС никто не сможет прокомментировать последнее.