连环触发！MongoDB核心集群雪崩故障背后竟是……( 二 ) 作者介绍杨亚洲

文章插图
文章插图
从上图可以看出，存储节点在业务抖动的时候没有任何慢日志，因此可以判断存储节点一切正常，业务抖动和mongod存储节点无关。
2） mongos代理分析
存储节点没有任何问题，因此开始排查mongos代理节点。由于历史原因，该集群部署在其他平台，该平台对QPS、时延等监控不是很全，造成早期抖动的时候监控没有及时发现。抖动后，迁移该平台集群到oppo自研的新管控平台，新平台有详细的监控信息，迁移后QPS监控曲线如下：
文章插图
每个流量徒增时间点，对应业务监控都有一波超时或者抖动，如下：
文章插图
分析对应代理mongos日志，发现如下现象：抖动时间点mongos.log日志有大量的建链接和断链接的过程，如下图所示：
文章插图
从上图可以看出，一秒钟内有几千个链接建立，同时有几千个链接断开，此外抓包发现很多链接短期内即断开链接，现象如下(断链时间-建链时间=51ms, 部分100多ms断开)：
文章插图
对应抓包如下：
文章插图
此外，该机器代理上客户端链接低峰期都很高，甚至超过正常的QPS值， QPS大约7000-8000 ，但是conn链接缺高达13000 ， mongostat获取到监控信息如下：
文章插图
3）代理机器负载分析
每次突发流量的时候，代理负载很高，通过部署脚本定期采样，抖动时间点对应监控图如下图所示：
文章插图
文章插图
从上图可以看出，每次流量高峰的时候CPU负载都非常的高，而且是sy%负载， us%负载很低，同时Load甚至高达好几百，偶尔甚至过千。
4）抖动分析总结
从上面的分析可以看出，某些时间点业务有突发流量引起系统负载很高。根因真的是因为突发流量吗？其实不然，请看后续分析，这其实是一个错误结论。没过几天，同一个集群雪崩了。
于是业务梳理突发流量对应接口，梳理出来后下掉了该接口， QPS监控曲线如下：
文章插图
为了减少业务抖动，因此下掉了突发流量接口，此后几个小时业务不再抖动。当下掉突发流量接口后，我们还做了如下几件事情：