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异常的根本原因。
不要放弃任何小的故障，在某种情况下会发展成大的故障。