icon
Update time
Oct 31, 2022 07:34 AM
Internal status
password
故障现象
先收到报警通知,然后运营反馈问题,
websocket服务掉线用户大于2k
排查过程
集群整体负载正常
https://arms.console.aliyun.com/apm?pid=fl0zuy81v2%40f9d1ca21c1bad6a®ionId=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连接配置，防止出现这种类似情况，不要直接影响到数据库
责任认定
主要责任人: 阿里云
次要责任人: