故障现象

先收到报警通知,然后运营反馈问题,

websocket服务掉线用户大于2k

排查过程

集群整体负载正常

https://arms.console.aliyun.com/apm?pid=fl0zuy81v2%40f9d1ca21c1bad6a&regionId=cn-shanghai#/callChain/ea1ae6018c16637637393566236d0001/1663763439356/1663764039356/fl0zuy81v2@f9d1ca21c1bad6a?&page=apps

9-21 21:09:39

mongodb?

9-21 21:10:20

因为健康检查超时是3秒,但是这个请求3.6秒了,我看是检查mongodb的时候慢了,我再看看mongo怎么了

9-21 21:14:29

当时mongo CPU100%了

我分析了精确的监控,mongo从20:35:30到20:35:40 短短10秒钟时间 CPU从40%到100%,不知道发生了什么

比较异常的是这几个指标

从日志的先后来看,不是健康检查通不过才掉线的,是先掉线,后健康检查不通过的

20:35:35 battle-websocket开始出现大量掉线日志

20:35:35-20:35:40 mongo读写队列从平常的0飙升到117

20:35:40 mongodb cpu100%

20:35:42 健康检查超时,是20:35:38左右开始发出检查,42时超时,因为mongodb cpu100%,检查mongo用时3.6秒

websocket实例在这期间没有发生full gc

沈文俊 9-21 21:53:14

mongocpu上去还是因为大量重练的ws连接吧

9-21 21:55:10

对 从表现上来是这样

所以问题来到了为什么这个websocket实例会突然大量用户掉线,我看过没有异常gc,且掉线用户都来自同一个实例

9-21 21:58:27

没有什么错误日志

  • and topic: battle-websocket and tag:client_ip: “106.14.32.124” and error

那台容器的节点服务器 网络上会不会有什么问题?

https://cs.console.aliyun.com/?spm=5176.12818093.ProductAndResource--ali--widget-product-recent.dre0.3be916d09xleyZ#/next/clusters/c5ee2ef6132674f438dfca921ee9345b5/eventcenter?ns=kube-system

从k8s事件来看,发生了reload,但是时间对不上

跟运维确认,昨晚没有进行运维操作,但是集群确认有nginx reload操作,现在知道的是如果认为执行nginx reload操作,针对http服务没有什么大的影响,但是tcp长连接服务是会掉线的

继续查k8s日志

这个时间就对应的上了，这个时间点 edas有组件更新

9-22 10:37:23

我们这个老集群好像也不是edas

9-22 10:37:43

之前导入过

9-22 10:37:50

哦

9-22 10:39:35

里面还有个sbp的项目是edas的 迁移掉然后取消接入edas吧

由此，本次故障的原因定位到了

由于k8s集群的组件自动更新, 为了使nginx配置生效, 进行了重启操作, 短时间内大量用户断开, 发起重连请求, 进而短时间内拖垮mongodb

结果

故障持续时间 20:35:30-20:36:40 1分10秒

故障影响范围,当时大约3500人对战平台出现掉线重连,未影响游戏中用户,出故障之前在线人数约13000人.

决定websocket集群取消接入eads，因为没有用到，且还存在这种自动更新的事

在11：15分操作了，立马复现昨晚的问题

观察mongo性能，出现了短暂的CPU100%，这还是业务低峰期

后续Action

  1. 如果集群中有长连接服务，进行配置更新的时候要注意在业务低峰期操作，组件升级也需要与业务部门确认操作，集群中无用组件尽早去除
  2. 检查代码是否能够优化；检查是否能够优化mongo连接配置，防止出现这种类似情况，不要直接影响到数据库

责任认定

主要责任人: 阿里云

次要责任人: