☰

nginx：如何从 nginx（不是我的应用程序）中追踪随机 500。可能与负载有关？

tag-icon • tag-icon nginx 500-error
nginx：如何从 nginx（不是我的应用程序）中追踪随机 500。可能与负载有关？

我们最近收到了一些来自 nginx 本身的 500 条错误，但不知何故没有记录下来（我们有屏幕截图，但日志中没有任何内容）。这本身就很奇怪，因为通常错误会出现在那里。无论如何，我想知道是否存在类似连接池大小的东西，如果达到最大值，会导致 500 条错误？我们已将其可能与最近的流量激增联系起来，但尚无定论。

有人知道如何开始解决这个问题吗？

答案1

我们使用 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 "in: $http_cookie"'

将捕获许多有用的诊断信息，例如处理请求的上游服务器，以及将状态放在前面，以便即使日志滚动得非常快也易于阅读。

我们使用 LMON 监视这些日志，然后在日志中发现错误（例如 500、503、400）时提醒我们（寻呼机/电子邮件）：

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

这可以帮助您在问题发生时收到警报，这也是最容易调试的时间。

您可能还应该考虑的另一件事是，默认情况下，nginx 将 500 视为致命情况，并且不会尝试其他上游。如果您有多个上游，您可以将其配置为在获得 500 时使用另一个上游，希望可以向用户隐藏故障：

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

答案2

error_log $filename debug;将打开调试级别的错误日志记录 - 这将为您提供大量有关错误发生时 nginx 内部状态的详细信息，并且如果使用 --with-debug 进行编译（默认情况下几个发行版都这样做）它将提供更多信息。

请注意，“调试”级别确实会产生很多输出，以至于您可能需要查看磁盘空间......

答案3

在我的情况下，conf 文件命名不正确（是 example.com 而不是 example.com.conf），并且未包含在内。不知何故，这并没有导致“欢迎使用 nginx”，而导致了未记录的 HTTP 500 错误。好吧，它实际上被记录了，但在来自无法与该特定 URL 配合使用的不同虚拟主机的错误文件中。

相关内容