在Nginx日志中,它会说服务器不可用,因为它在x
秒内失败了y
次?
我在nginx的上游块中有一组服务器,每个服务器都设置了fail_timeout
和max_fails
值,如下所示:
upstream loadbalancer {
server ip1:80 max_fails=3 fail_timeout=60s;
server ip2:80 max_fails=3 fail_timeout=60s;
}
如果我故意关闭其中一台服务器(让我们说ip:80),NGINX会返回503
,我已将其标记为无效标头。所以我确保NGINX在六十秒内击中该服务器三次。
我希望日志中有一些内容可以将服务器标记为不可用,即fail_timeout
已启动。但我无法找到任何内容。
这是我的日志配置:
access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log warn;
答案 0 :(得分:1)
我不确定您是否可以获取不可用服务器的日志。但是,您可以执行 lsof 命令,以通过其PID获取 httpd root 的其他列表日志文件。
1)首先执行此命令以获取HTTPD根的PID:
> ps axu |grep httpd
2)然后复制 root 的PID。假设PID 1234 。
3)接下来我们使用PID 1234 并执行最终命令以获取httpd root 的日志文件:
> lsof -p 1234 |grep log
这确实帮助了我找到了丢失的日志。现在,您可以检查日志文件是否包含有关不可用服务器的任何内容。最好的运气
答案 1 :(得分:1)
服务器超过max_fails时,现在会显示一条日志消息。 它已在1.9.1中添加。 日志级别为警告,消息显示“上游服务器暂时禁用”。
答案 2 :(得分:0)
You should see logging in the error log with useful information on the reason. Here are some examples from Nginx 1.8
[error] 9369#0: *837 connect() failed (111: Connection refused) while connecting to upstream
[error] 9369#0: *851 connect() failed (113: No route to host) while connecting to upstream
[error] 9369#0: *844 no live upstreams while connecting to upstream
As you can see, the log level is error
so that is not an issue in your config.
You mention setting a 503 header to mark hosts as unavailable. This will not be detected in the default Nginx settings. To use specific response codes to determine upstream host status look into the proxy_next_upstream option.
Setting it to the following would include 503 response codes in the list of results that counts as an upstream failure:
proxy_next_upstream error timeout http_503;
From the documentation:
The directive also defines what is considered an unsuccessful attempt of communication with a server. The cases of error, timeout and invalid_header are always considered unsuccessful attempts, even if they are not specified in the directive. The cases of http_500, http_502, http_503 and http_504 are considered unsuccessful attempts only if they are specified in the directive. The cases of http_403 and http_404 are never considered unsuccessful attempts