具体现象
应用迁移至我们的PaaS平台后会出现偶发性的502问题，错误见图片：
相比于程序的请求量，错误肯定是比较少的，但是错误一直在发生，会影响调用方的代码，需要检查下问题原因。
为啥我们只看到了POST请求
读者肯定会说，你们 ELK 过滤字段里面写的是POST，所以肯定只有POST请求，hah。其实不是这样的，GET请求也会有502，只是Nginx会对GET请求进行重试，产生类似如下的日志:
重试机制是Nginx默认的: proxynextupstream
因为GET方法会被认为是幂等的，所以当一个upstream出现502的时候，nginx会再次尝试. 对于我们的问题，主要想确认为什么有502，只看POST请求就足够了，两者的原因应该是一致的.
网络拓扑结构
网络请求流入集群时，对于我们集群的结构：
不要问为什么有了 Ingress 还有 Nginx。这是历史原因，有些工作暂时需要由 Nginx 承担。
统计排查
基于我们对于Nginx和Ingress的错误请求统计，发现两者中的502错误是想等的，说明问题一定是出现在 Ingress<=>uwsgi 之中。
抓包
这个并不是最先想到的方案，因为我们用了很多统计方法也没总结出来规律，最后只能寄希望于抓包了…
该请求日志如下：
抓包结果如下：
从抓包情况来看，当前的 TCP 连接被复用了，由于Ingress中使用了HTTP1.1协议，会在一次tcp连接中尝试发送第二个HTTP请求，但是uwsgi没有支持http1.1，所以在第二个请求根本不会被处理，直接拒绝了。所以在Ingress看来，这个请求失败了，因此返回了502. 由于GET请求会重试，但POST请求无法重试，所以访问统计中出现了POST请求502的问题。
Ingress配置学习
Ingress中， 默认对upstream使用的http版本为1.1， 但是我们的uwsgi使用的是http-socket， 而非http11-socket， 我们Ingress中使用了与后端不同的协议， 出现了意料之外的502错误。
因为 Nginx 默认是1.0， 但是切换到Ingress中默认变成了1.1， 而我们没有统一， 解决方案是强制指定Ingress中使用的http协议版本。
如果有大佬看到了，可以简单讲讲 Ingress 会在什么时候复用 http1.1 的连接， 以及为什么 Ingress 不复用每一个连接，这样问题会尽快的暴露，这些问题我没有继续深究了。毕竟你换个语言比如 Golang 就没有这个问题了， 这个是 uwsgi 专属错误。
总结
有关这个502问题的排查，我个人觉得，最后抓包一次性解决问题其实没什么特别的，抓了就能发现问题，不抓就发现不了。
我是希望给大家一个启发，对于一整条链路，如何来排查故障：我们这里既使用了Nginx，又使用了 Ingress，在排查时，需要首先检查两者的错误数量， 如果确认错误基本一致，那就说明错误与 Nginx 没有关系，需要检查 Ingress 上的错误，对于多个中转的请求，这样的排查能比较快的确定链路的错误位置。