做英文网站怎么赚钱,网页设计跟网站建设的区别,福彩网网站建设方案,电商网站开发用什么语言网上看到几个相关的文章#xff0c;觉得很不错#xff0c;这里整理记录分享一下#xff0c;供大家参考。
upstream配置分
在分析问题原因之前#xff0c;我们先来看下关于上面upstream配置一些相关的参数配置说明#xff0c;参考下面表格
ngx_http_proxy_module
这里重…网上看到几个相关的文章觉得很不错这里整理记录分享一下供大家参考。
upstream配置分
在分析问题原因之前我们先来看下关于上面upstream配置一些相关的参数配置说明参考下面表格
ngx_http_proxy_module
这里重点看框出来的三个参数proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout默认超时时间是60s 官方地址http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout
upstream_server
参考问题排查Nginx-no live upstreams错误_nginx_lucky猿-GitCode 开源社区
还是重点关注我们目前使用的max_fails和fail_timeout可以看到我们使用的是15s内失败2次即认为该服务不可用。再结合proxy_connect_timeout的默认60s以上no live upstreams while connecting to upstream问题就很明朗了。
1、Nginx代码
502伴随出现错误no live upstreams while connecting to upstream的原因:
具体场景接入层的负载均衡的nginx集群转发给业务nginx业务nginx再转发给后端的应用服务器。业务nginx配置文件如下
upstream ads {
server ap1:8888 max_fails1 fail_timeout60s;
server ap2:8888 max_fails1 fail_timeout60s;
}
如果业务nginx出现日志 no live upstreams while connecting to upstream 的日志此外还有大量的“upstream prematurely closed connection while reading response header from upstream”的日志。
看“no live upstreams”的问题。 看字面意思是nginx发现没有存活的backend后端了但是奇怪的是只有部分接口访问异常出现502。
可以从nginx源码的角度来看了。
因为是upstream有关的报错所以在ngx_http_upstream.c中查找“no live upstreams”的关键字可以找到如下代码其实你会发现如果在nginx全局代码中找的话也只有这个文件里面有这个关键字 在这里可以看出当rc等于NGX_BUSY的时候就会记录“no live upstreams”的错误。
往上看1328行可以发现rc的值又是ngx_event_connect_peer这个函数返回的。
ngx_event_connect_peer是在event/ngx_event_connect.c中实现的。这个函数中只有这个地方会返回NGX_BUSY其他地方都是NGX_OK或者NGX_ERROR或者NGX_AGAIN之类的。
rc pc-get(pc, pc-data);
if (rc ! NGX_OK) {
return rc;
} 这里的pc是指向ngx_peer_connection_t结构体的指针 get是个ngx_event_get_peer_pt的函数指针具体指向哪里根据配置和使用的轮询规则来确定。
接着翻看ngx_http_upstream.c
在ngx_http_upstream_init_main_conf中看到了如下代码
uscfp umcf-upstreams.elts;
for (i 0; i umcf-upstreams.nelts; i) {
init uscfp[i]-peer.init_upstream uscfp[i]-peer.init_upstream:
ngx_http_upstream_init_round_robin;
if (init(cf, uscfp[i]) ! NGX_OK) {
return NGX_CONF_ERROR;
}
}
这里可以看到默认的配置为轮询事实上负载均衡的各个模块组成了一个链表每次从链表到头开始往后处理从上面到配置文件可以看出nginx不会在轮询前调用其他的模块并且用ngx_http_upstream_init_round_robin初始化每个upstream。 再看ngx_http_upstream_init_round_robin函数里面有如下行
r-upstream-peer.get ngx_http_upstream_get_round_robin_peer;
这里把get指针指向了ngx_http_upstream_get_round_robin_peer
在ngx_http_upstream_get_round_robin_peer中可以看到
#if (NGX_HTTP_UPSTREAM_ZONE)
if (peers-config rrp-config ! *peers-config) {
goto busy;
}
#endif
if (peers-single) {
peer peers-peer;
if (peer-down) {
goto failed;
}
if (peer-max_conns peer-conns peer-max_conns) {
goto failed;
}
rrp-current peer;
ngx_http_upstream_rr_peer_ref(peers, peer);
} else {
/* there are several peers */
peer ngx_http_upstream_get_peer(rrp);
if (peer NULL) {
goto failed;
}
ngx_log_debug2(NGX_LOG_DEBUG_HTTP, pc-log, 0,
“get rr peer, current: %p %i”,
peer, peer-current_weight);
}
再看看failed的部分
failed:
if (peers-next) {
ngxlog_debug0(NGX_LOG_DEBUG_HTTP, pc-log, 0, “backup servers”);
rrp-peers peers-next;
n (rrp-peers-number (8 * sizeof(uintptr_t) - 1))
/ (8 * sizeof(uintptr_t));
for (i 0; i n; i) {
rrp-tried[i] 0;
}
ngx_http_upstream_rr_peers_unlock(peers);
rc ngx_http_upstream_get_round_robin_peer(pc, rrp);
if (rc ! NGX_BUSY) {
return rc;
}
ngx_http_upstream_rr_peers_wlock(peers);
}
#if (NGX_HTTP_UPSTREAM_ZONE)
busy:
#endif
ngx_http_upstream_rr_peers_unlock(peers);
pc-name peers-name;
return NGX_BUSY;
这里就真相大白了如果连接失败了就去尝试连下一个如果所有的都失败了就会进行quick recovery 把每个peer的失败次数都重置为0然后再返回一个NGX_BUSY然后nginx就会打印一条no live upstreams ,最后又回到原始状态接着进行转发了。
这就解释了no live upstreams之后还能正常访问。
重新看配置文件如果其中一台有一次失败nginx就会认为它已经死掉然后就会把以后的流量全都打到另一台上面当另外一台也有一次失败的时候就认为两个都死掉了然后quick recovery然后打印一条日志。
2、错误的常见原因
有几个问题可能会触发此错误
后端服务器关闭所有后端服务器均已关闭或无法访问。配置错误上游服务器的 NGINX 配置不正确。DNS 问题影响后端服务器地址的 DNS 解析问题。网络问题NGINX 和后端服务器之间的网络连接问题。
3、诊断错误
请按照以下步骤诊断错误
1. 检查 NGINX 日志查找 NGINX 日志中的错误消息。
tail -f /var/log/nginx/error.log2. 验证后端服务器确保后端服务器正在运行且可访问。
curl -I http://backend_server3.检查配置检查您的 NGINX 配置是否有错误。
cat /etc/nginx/nginx.conf解决方案 1重新启动后端服务器
如果后端服务器宕机请重新启动它们。
systemctl restart backend_service解决方案 2修复配置错误
确保 NGINX 中的上游块配置正确。
upstream backend {server backend1.example.com;server backend2.example.com;
}检查服务器地址是否正确。
解决方案 3DNS 配置
如果您使用上游服务器的 DNS 名称请确保 DNS 配置正确。
1.验证 DNS 解析检查 NGINX 是否可以解析 DNS 名称。
nslookup backend1.example.com2. 更新 DNS 记录如果需要请更新 DNS 记录以确保准确性。
解决方案 4网络连接
检查 NGINX 和后端服务器之间的网络连接。
1. Ping 后端服务器测试连通性。
ping backend1.example.com2. Traceroute识别网络路径问题。
traceroute backend1.example.com解决方案 5使用 max_fails0 选项
该max_fails指令设置与服务器通信失败的次数在将服务器视为不可用之前应发生此次数。通过设置max_fails0NGINX 将不会将服务器标记为不可用。
更新上游块以包含此选项
upstream backend {server backend1.example.com max_fails0;server backend2.example.com max_fails0;
}这确保了 NGINX 总是会尝试向上游服务器发送请求即使它们之前已经失败过。
解决方案 6 keepalive连接数不够导致大量TIME_WAIT暂用
参考nginx偶发502 no live upstreams while connecting to upstream-CSDN博客
后台排查nginx后台偶尔大量报错no live upstreams while connecting to upstream
在nginx服务器上nestat查看 发现存在大量的 TIME_WAIT状态的连接
问题分析
问题表现在nginx与下游服务器的连接出现了异常在突发流量以后由于TIME_WAIT状态的连接过多导致无法创建足够的连接。
为什么会有如此之多的TIME_WAIT呢
我的分析是nginx中upstream与下游服务器之间要么是配置的短连接要么是keepalive 的数量太少了。经过排查发现upstream中并无keepalive相关的配置。
如果nginx与下游服务器连接都是短连接的话会频繁的创建和断开连接。每次断开连接都会导致连接处于TIME_WAIT一段时间才能被回收掉。 TIME_WAIT状态的持续时间是2MSL2MSL的是时间还是比较长的大概几十秒到几分钟。 当流量突增的时候会出现大量无法回收的连接最终导致新连接无法创建而报错。
如果nginx与下游服务器配置了长连接但是upstream中keepalive很小的话也会出问题。 举个极端的例子:
假如nginx最多可以建10000个连接keepalive的连接数配置的是1000个即对空闲连接最多可以维持1000个。空闲连接的回收时间为60秒。
在第一秒突然流量高峰瞬间建了10000个连接抗住了压力没出什么大问题。然后在接下来的60秒几乎没有什么流量访问那么在此期间nginx会把9000个空闲连接给断开进行回收。但是回收中的连接会经历2MSL时间的TIME_WAIT。**也就是说在此期间这9000个连接是无法提供服务的。等到第61秒后又来了一波流量高峰需要建10000个连接才能抗住。这时就要出问题了由于9000个连接无法有效回收nginx只能拿出1000个连接应对请求新建连接失败后台报错。**服务器上存在大量TIME_WAIT状态的连接。
配置修改
为了解决上面的问题对nginx做了如下的配置调整后问题解决。 解决方案 7修改timeout值
nginx部分请求都是502但是这些请求某些时间段内是正常的有正常返回结果已确认后端服务存活并且是健康的。经排查发现有个长连接请求是60snginx默认请求时间也是60s超过60snginx默认后端服务器已经挂了然后不再转发请求了所有这段时间所有请求都是502.
解决办法:修改nginx超时时间
proxy_connect_timeout 100s;proxy_send_timeout 100s;proxy_read_timeout 100s;
解决方案 8 其他配置或者使用nginx_upstream_check_module
方案一根据业务合理设置proxy_connect_timeout调整fail_timeout、max_fails阈值
将nginx中的proxy_connect_timeout默认超时时间设置大于下游业务最大执行时间。Nginx默认fail_timeout为10s,max_fails为1次。如果调大Nginx相当于把请求缓冲如果整体的的后端服务处于可用状态对于高并发的场景来说建议适当调大是有效的。
方案二优化下游超时接口
方案三取消fail_timeout、max_fails配置增加主动检测机制Nginx默认被动检测插件包 nginx_upstream_check_module下面将详细介绍该方案。
官方介绍https://github.com/yaoweibin/nginx_upstream_check_module
系统问题
基础环境
版本信息
Centos 7.1nginx version: openresty/1.13.6.2
nginx配置信息
stream {server {listen 53 udp;proxy_pass close_stream_backend;}upstream close_stream_backend {server 10.0.1.2:53;server 10.0.1.3:53;}
}异常问题
20个线程连续压测一分钟后开始交替出现两台目标机器已经宕机单线程访问没什么问题出现日志如下所示
[error] 7184#0: *142585778 no live upstreams while connecting to upstream, udp client: 10.0.1.2, server: 0.0.0.0:53, upstream: dns, bytes from/to client:40/0, bytes from/to upstream:0/0主要有两个疑惑点
首先直接访问目标机器目标机器处于正常访问状态而且没什么压力另外一点如果负载均衡目标服务机器两台改为一台反而不会出现这个异常但是服务所在机器压力非常大所以怀疑是nginx这台机器除了问题。
分析解决 nginx官网查询了下负载均衡策略含义大概意思是这样的首先nginx默认的配置为轮询负载均衡的各个模块组成了一个链表每次从链表到头开始往后处理如果连接失败了就去尝试连下一个如果所有的都失败了就会进行quick recovery 把每个peer的失败次数都重置为0然后再返回一个NGX_BUSY然后nginx就会打印一条no live upstreams ,最后又回到原始状态接着进行下次转发。 查看配置文件如果其中一台有一次失败nginx就会认为它已经死掉然后就会把以后的流量全都打到另一台上面当另外一台也有一次失败的时候就认为两个都死掉了就开始打印错误日志。 第一个想到的办法就是增大重试次数和时间server 10.0.1.2:53 max_fails5 fail_timeout60s把max_fails从1改成5有一定效果no live upstreams出现的概率变少了很多但却没有完全消失。另外压测QPS上不去还不如单台机器。 于是使用tcpdump -i eth2 udp port 53 -s0 -XXnn通过wireshark分析后压力测试工具产生数据已经全部发送到nginx所在机器但是这台机器没有正确处理。 后来想了下Nginx底层采用的IO多路复用模型epoll其epoll又是基于linux内核实现于是看了下/var/log/messages内核日志于是发现大量如下丢包日志 kernel: nf_conntrack: table full, dropping packet.
为了证实问题再次进行压力数据发送发现只有再进行压力测试时才会出现这种内核丢包日志。怀疑是服务器访问量大内核netfilter模块conntrack相关参数配置不合理最终导致新连接被drop掉。 查看netfilter参数配置sudo sysctl -a | grep conntrack发现65536于是我直接提升了4倍 sudo sysctl -w net.netfilter.nf_conntrack_max262144 suod sysctl -w net.nf_conntrack_max262144
执行sudo sysctl -p使其立即生效再次执行压力测试发现内核不在出现丢包nginx也不会出现如上错误日志问题解决。
总体分析
本文主要通过分析nginx网络请求异常然后定位为内核参数设置太小导致丢包最后通过修改内核配置解决但是conntrack又是什么搜索之后发现conntrack是针对状态防火墙的。如果有兴趣请阅读Netfilter的连接跟踪系统。它还包括Netfilter基本的框架。因此conntrack是用来创建记录连接状态以检查流量并避免DDoS安全问题。 另外如上分析问题的过程中我直接把conntrack值设置为原来的四倍这样是否合理碰到这类问题又该如何设置呢下面给出一个公式推荐大小CONNTRACK_MAX RAMSIZE (in bytes) / 16384 / (ARCH / 32)。例如在x86_64 OS中我有8GB内存因此我将它设置为8*1024^3/16384/2262144。
4、预防未来问题
为了避免将来出现此错误请考虑以下最佳做法
冗余使用多个后端服务器来防止单点故障。监控实施监控以尽早发现问题。负载均衡器使用强大的负载均衡器来有效地管理流量分配。
结论
NGINX 中的“连接到上游时没有实时上游”错误可能会中断您的服务。通过诊断根本原因并应用正确的解决方案您可以解决此问题并防止将来再次发生。
参考
[Troubleshooting “No Live Upstreams While Connecting to Upstream” Error in NGINX - Akmatori Blog](https://akmatori.com/blog/nginx-no-live-upstreams “Troubleshooting “No Live Upstreams While Connecting to Upstream” Error in NGINX - Akmatori Blog”)
Nginx Bad Gateway和no live upstreams错误分析 | 墨寒轩
压测nginx出现no live upstreams while connecting to upstream的问题分析-腾讯云开发者社区-腾讯云
压测引起的 nginx报错 502 no live upstreams while connecting to upstream解决 - 雪山上的蒲公英 - 博客园
排查Nginx-no live upstreams错误_nginx_lucky猿-GitCode 开源社区
https://xiezefan.me/2017/09/27/nginx-502-bug-trace/
