Назад | Перейти на главную страницу

Как я могу отлаживать 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 reverse-proxy

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

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

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

Настройте tcpdump в другом окне:
```
tcpdump not port 22 -vvv -s0 -q -XXX
```
Следите за файлами журнала в еще одном окне:
```
tail -f /var/log/nginx/*
```

Запустите 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, если вам нужна дополнительная статистика.

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

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

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

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

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

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

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

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

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

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

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

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

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