记一次神奇的nginx-502问题
第一次写博客，之前都是写在云盘，本次主要描述下前几天频繁出现Nginx的502问题，话不多说，先说问题。
目前的系统架构师这样的，前端Nginx，+后端8台Tomcat，系统发现，每天不定期会出现nginx请求后端502，突然8台全部502，持续时间不固定，有时候几秒钟，有时候2-3分钟，然后突然好了。集群策略为ipHash，通过日志发现，ng发现其中一个节点挂掉后，会upstream另外的节点，结果Ng发现每个都是502，事实上，通过监控，发现后端Tomcat都没问题，jvm也没问题。
Nginx 负载报错信息如下：
1、Nginx的配置如下：
upstream baidu_movie_h5 {
ip_hash;
server 192.168.26.94:8280 ;# max_fails=3 fail_timeout=30s;
server 192.168.26.92:8280;# max_fails=3 fail_timeout=30s;
server 192.168.26.125:8280;# max_fails=3 fail_timeout=30s;
server 192.168.26.126:8280 ;#max_fails=3 fail_timeout=30s;
server 192.168.26.127:8280;# max_fails=3 fail_timeout=30s;
server 192.168.26.128:8280;# max_fails=3 fail_timeout=30s;
server 192.168.26.129:8280;# max_fails=3 fail_timeout=30s;
server 192.168.26.130:8280 ;#max_fails=3 fail_timeout=30s;
keepalive 256;
}
server {
listen 80;
server_name bmh.loyaltychina.com;
access_log /usr/local/nginx/logs/baidu_moive.access.log;
access_log /usr/local/nginx/logs/baidu_moive.upstream.access.log upstreamlog;
error_log /usr/local/nginx/logs/baidu_moive.error.log;
if ($request_method !~ ^(GET|POST)$ ) {
return 405;
}
large_client_header_buffers 4 16k;
client_max_body_size 30m;
client_body_buffer_size 128k;
proxy_connect_timeout 500;
proxy_read_timeout 500;
proxy_send_timeout 500;
proxy_buffer_size 64k;
proxy_buffers 16 64k;
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 16m;
#return 404;
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|css|js|ico)?$ {
expires 3h;
proxy_cache cache;
add_header Nginx-Cache "$upstream_cache_status";
proxy_pass http://baidu_movie_h5;
}
location / {
proxy_next_upstream http_502 http_504 error invalid_header;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Connection "Keep-Alive";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://baidu_movie_h5;
proxy_intercept_errors on;
}
}
首先排查是不是ng配置问题，修改了各种参数，其中还将proxy_set_header Connection 设置为"Keep-Alive" ，同时keepalive 256; 一开始，感觉挺好，没啥问题，突然觉得这神奇的问题是不是解决了，但是通过监控发现，还是不停的的报警，瞬间天就塌了。
继续找，tcpdump抓包发现,如图所示：
有客户端重新发送ACK，通过ping出问题的节点发现网络非常不稳定，有netstat -antp 的连接状态统计截图
送达最后继续找，找到WAF节点，发现请求进入的时候，再次转发，有延迟并且，不稳定，把ng和app之间的WAF防火墙关了，暂时没发现502问题。
总结：502出问题的地方会比较多，ng比较傻，什么责任都揽在自己身上，后端服务也比较傻，说它连不上也不会反驳。所以出现该问题，先别慌，一点点找问题，先看后端服务情况，在看Ng配置是不是出问题，如果都没问题，在网上看，看请求从哪个终端过来，是不是那出了问题，通过ping和tcpdump分析网络和数据包，逐步定位到为题的出现点。如果发现NG找不到节点 先判断网络，如果上述延迟原因 那就看交换机的负载，建议通cacti等 运维工具把交换机全部监控起来。补充一点：这个只是个WAF防火墙，出口还有一个硬件防火墙，是放在DMZ和OUTSIDE之间的设备，现在已经开启了waf的bypass，流量已经不走waf了，继续监测，看下是否已经正常。