记录一个诡异的线上宕机事故，大佬们帮忙排查一下问题呀

环境

二三十个微服务 SpringBoot+Dubbo 部署在阿里的 K8S 上，数据库也是买的阿里的 RDS，听领导说配置还挺高的，支持主备自动切换什么的。

事故起因和经过

大版本上线，改了用户的缓存数据结构，凌晨上线时把 Redis 用户缓存全清了，上线当晚验证功能正常，白天运行也十分稳定。

下午 5 点多业务高峰的时候运营反馈系统蹦了，看后台是数据库负载正常、Dubbo 调用全部超时，领导首先怀疑是系统被攻击了，然后在阿里的后台打开了防火墙增强模式（具体叫什么不懂，效果是可以阻拦大部分到 Nginx 的请求），开完观察了好久后台调用还是超时，老板都开始炸锅了跑来了解情况，领导开始尝试万能的重启大法，ZK 的三个节点都重启了，微服务也挨个重启，绝望的是重启依然没有任何效果。

一顿瞎搞时间很快就到了晚上 8 点，这时候已经宕机 2 个多小时了还没找到原因，也不知道怎么恢复。然后我试着用 Arthas 监控了一下调用时间，发现主要业务流量入口 M 服务调用 Cache 服务一直超时，调用 C 主要是 M 从 Redis 获取不到用户缓存，需要 C 构建缓存放 Redis 。监控 C 服务的时候发现所有请求数据库的耗时都要 2000ms 以上，然后我们构建缓存需要读 8~9 次数据库但是 Dubbo 的超时时间设的是 10s 所以一直超时。

诡异事件

首先怀疑是 SQL 写的有问题，但是有一个根据主键 ID 查询单表的居然也要 2000+ms，这就非常离谱了，后面我把参数打出来自己拼接 SQL 用 Navicat 查询只要十几毫秒，领导说可能是工具监控有问题，然后当场给这个查询加调用时间的日志验证，从 master 拉的分支，只加了一行日志！！！

然后，重新发包观察，诡异的是，系统恢复正常了！！！没有调用超时的日志，新加的那行日志打印出来的也是十几毫秒，其他服务也能正常调用了！！！

事故报告

领导给的事故报告是晚上清除用户缓存，没有预先跑脚本构建缓存导致业务高峰期系统宕机。

疑惑

为什么那个时间点 Navicat 和微服务查询同一条 SQL 时间差这么多？然后加了行日志系统又自动恢复了？诡异，太诡异了，说没有鬼我是不信的

大佬们来帮忙排查一下这可能是什么原因呀

gBurnX

2021-09-09 13:13:46 +08:00

当复杂系统，不容易及时排查出问题时，其实可以留一手：粗暴的监控大法：

1.能输出日志的 app，全部监控起来。

2.把你们自己写的程序里，每个函数、接口与数据库 rpc 、List/Queue/Cache 等 size，全部监控起来。

3.把 OS 、nginx 、iis 、db 等各种队列 /缓存 /容器 size，全部监控起来。

然后当 size 接近 total lenth 的 80%，以及 rpc 时间超过 3s 时，在监控面板报警。

性能问题，基本上就是这些，监控好了，就不会出现诡异问题了。