mysql bad gateway_502 Bad Gateway

一天开发同事说，周末在家用你的运维工具查不出欧美地区的游戏服日志，然后直接截图给我看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异常的根本原因。

不要放弃任何小的故障，在某种情况下会发展成大的故障。