一天开发同事说,周末在家用你的运维工具查不出欧美地区的游戏服日志,然后直接截图给我看502 Bad Gateway。正好上午不是很忙,就来探个究竟。
日志提取架构
处理过程:
(1)、首先是开发重现上面操作,依然报错502。
(2)、开始查Nginx日志,看到如下
意思是说从上游接受头部信息时,上游提前关闭连接。通过抓包分析后端8888端口在59s后开始关闭TCP连接。
从而定位到是后端uwsgi、game server、MySQL有问题,提交结束并没有返回http头部信息,导致Nginx直接返回502。
(3)、现在还是不能确定是哪里问题,先假设,
① 、是否game server提取日志代码逻辑出错导致呢?通过查询uwsgi进程日志,没有发现异常,另外通过查询国内其他游戏服日志可以正常提取,因此这个直接排除。
② 、是否game server提取日志过长导致从uwsgi——>game server提取日志提前中断?通过查看,发现后端进程在出现502后进程还在提取日志,因此判断从uwsgi——>game server是正常的调用。
③ 、是否和MySQL有关呢?直接排除,该处理逻辑不涉及到MySQL。
④ 、是否uwsgi进程自身关闭tcp连接呢?怀疑uwsgi配置超时时间配置问题。
(4)、现在基本定位到是超时时间配置问题,通过查找帮助文档+google找到三个可以影响的配置, http-timeout,socket-timeout,HARAKIRI,但是官方和google并没有很详细的说明他们设置上的区别和默认时间。通过自己调试,总结如下,
socket-timeout:如果你的uwsgi启动是socket模式,则socket-timeout起作用,我将uwsgi调整到这个模式,发现没有配置超时时间能出结果。
http-timeout:如果你的uwsgi启动是http模式,则http-timeout起作用,通过测试在没有配置http-timeout时,会在60s时中断并提示502,配置300s后,能正常提取到日志。
HARAKIRI:如果你的请求任务超过配置的时间,它会自动杀掉并重新启动一个。
总结:
通过上面的测试,解决问题是配置http-timeout=300s,因为我的uwsgi是用的http模式,提取日志需要144s时间。
uwsgi默认的http模式超时时间为60s,就是这个默认时间导致提取日志时报502异常的根本原因。
不要放弃任何小的故障,在某种情况下会发展成大的故障。