nginx: как отследить случайный 500 от nginx (не мое приложение). Потенциально как-то связано с нагрузкой?

Недавно у нас было около 500 экземпляров от самого nginx, которые как-то не были зарегистрированы (у нас есть скриншоты, но ничего в журналах). Это странно само по себе, потому что там обычно появляются ошибки. Независимо от того, мне интересно, есть ли что-то вроде размера пула соединений, что в случае максимального значения приведет к 500? Мы связали это потенциально с недавним всплеском трафика, но это не является окончательным.

У кого-нибудь есть идеи, как начать подходить к такому вопросу?

Мы используем комбинацию форматов журналов в nginx и lmon, чтобы поймать подобные вещи. Формат журнала NGINX, такой как:

log_format main '$ status: $ request_time: $ upstream_response_time: $ pipe: $ body_bytes_sent $ connection $ remote_addr $ host $ remote_user [$ time_local] "$ request" "$ http_referer" "$ http_user_agent" "$ http_x_forwarded_for" $ upstream_adache в: $ http_cookie "'

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

Мы используем LMON, чтобы просмотреть эти журналы, а затем предупредить нас (пейджеры / электронная почта), если он обнаружит ошибки, такие как 500, 503, 400, в журналах:

http://www.bsdconsulting.no/tools/lmon-README

Это может помочь вам быть предупрежденным о проблеме, когда она возникает, что является самым простым временем для ее устранения.

Еще одна вещь, которую вы, вероятно, должны учитывать, если вы еще этого не сделали, - это то, что по умолчанию nginx считает 500 фатальным состоянием и не пробует другой апстрим. Если у вас есть несколько восходящих потоков, вы можете настроить его на использование другого, если он получает 500, надеюсь, скрывая сбой от пользователя:

http://wiki.nginx.org/NginxHttpProxyModule#proxy_next_upstream

error_log $filename debug; включит регистрацию уровня отладки в журнале ошибок - это даст вам много-много подробностей о внутреннем статусе nginx во время ошибки, и если скомпилировано с --with-debug (что по умолчанию делают несколько дистрибутивов), дам еще больше.

Имейте в виду, что уровень «отладки» действительно генерирует много выходных данных, вплоть до того, что вы, возможно, захотите посмотреть свое дисковое пространство ...

В моем случае файл conf не был назван правильно (был example.com вместо example.com.conf) и не был включен. Каким-то образом это привело не к «Добро пожаловать в nginx», а к ошибке HTTP 500 без регистрации. Ну, это было зарегистрировано на самом деле, но в файле ошибок с другого виртуального хоста, который не мог работать с этим конкретным URL.