我们最近有nginx本身的500多个，不知何故没有logging（我们有截图，但没有在日志中）。 这本身很奇怪，因为通常会出现错误。 无论如何，我想知道是否有像连接池的大小，如果最多会导致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_addr $ upstream_cache_status“在：$ http_cookie“'
将捕获许多有用的诊断信息，如处理请求的上游服务器，以及将状态置于前端，这样即使日志滚动速度非常快，也很容易阅读。
我们使用LMON来查看这些日志，然后在日志中发现错误（例如500s，503s，400s）时通知我们（寻呼机/电子邮件）：
http://www.bsdconsulting.no/tools/lmon-README
这可以帮助您在发生问题时发出警报，这是debugging它的最简单时间。
另一件你可能应该考虑的事情是，如果你还没有，默认情况下，nginx认为500是一个致命的条件，不会尝试另一个上游。 如果你有多个上游，你可以configuration它使用另一个，如果它得到一个500，希望模糊了用户的失败：
http://wiki.nginx.org/NginxHttpProxyModule#proxy_next_upstream
error_log $filename debug; 会打开debugging级别的日志logging到错误日志 – 这会给你很多很多nginx的错误发生时的内部状态的详细信息，如果使用–with-debug编译（默认情况下有几个发行版本）会给予更多。
被警告说，“debugging”级别确实会产生大量的输出，以至于您可能想要观察磁盘空间。
在我的情况下，conf文件没有正确命名（是example.com而不是example.com），并没有包括在内。 不知何故，这并没有导致“欢迎使用nginx”，而是出现了未logging的HTTP 500错误。 那么，它实际上被logging，但在从不同的虚拟主机的错误文件，不能使用该特定的url。