Недавно у нас было около 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_addus в: $ 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-адресом.