问题描述
问题是这样的,线上一个推送服务以http接口方式支持内部其他服务的推送需求。众所周知,对于大多数APP来说push都是保证DAU的重要途径。所以,推送服务的稳定性至关重要。
昨天开始,我负责的推送接口接连报了很多次502状态码,对应的推送请求也失败了。所以我用了半天的时间都在分析接口失败的原因。
分析日志
查看线上问题的最好方式就是分析日志,线上服务都会打很多trace日志。我的推送服务通过全局trace_id把请求串联起来,所以可以快速跟踪请求是否正常执行。
分析日志我发现几个现象:
-
返回502状态码的请求的nginx日志upstream_time是0,request_time也是0。并且没有对应的服务日志。
-
由于上游服务是golang程序,基于GIN框架的web服务。每次启动会有启动日志,我发现问题阶段有大量的启动日志。
-
上游服务在问题阶段有大量的redis连接超时报错。
-
替换了有问题的redis proxy机器后,服务报错都没有了。
经过分析可以推断出,由于Redis代理机器故障,导致推送服务连接Redis超时,