集群重启后 30 秒再次崩溃凶手不是重连风暴是日志晚上十点监控告警群炸了EMQX 集群 CPU 打满。那时我们平台的在线设备在几十万量级挂在 2 个 EMQX 节点后面。这种量级的集群日常 CPU 水位并不高突然打满只有一种解释出事了。但真正的故事不是这次崩溃而是半小时后的第二次崩溃——我们把集群重启起来不到 30 秒它又躺下了。事后复盘打垮集群的不是几十万台设备的重连风暴。凶手是一行配置日志等级。一、事故经过两次崩溃第一次崩溃来得没什么征兆。没有发版没有配置变更设备量也没有异常波动。CPU 从正常水位一路爬升到打满消息开始大量堆积然后集群失去响应。运维的第一反应是标准动作重启。集群起来了。设备开始重连。然后几十万台设备同时涌回来的那一刻集群再次崩溃——从重启完成到第二次躺平大约 30 秒。如果你做过设备接入对重连风暴这个词不会陌生长连接集群最怕的不是稳态流量而是全量设备在同一时刻回来。但这一次风暴只是压死骆驼的最后一根稻草——而且骆驼的背上早就被我们自己放了一块石头。二、排查一条误导性线索一个关键排除法【配图 1平台链路图】几十万台智能家电设备负载均衡EMQX 节点 1EMQX 节点 2业务微服务数据库上监控平台看数据第一个异常很醒目磁盘 IOPS 打满。当时的推理链是这样的IOPS 高 → 是不是消息量太大→ 看 EMQX果然堆积了大量消息。逻辑似乎闭环了消息洪峰 → 写盘压力 → IOPS 打满 → CPU 占死。这是本次排查中最大的误导性线索。消息堆积是真实存在的但它是结果不是原因。把我们拉出误区的是一个排除法动作去看下游的负载。如果真的是消息量太大把平台压垮了那么压力一定会传导下去——业务微服务应该在疯狂消费数据库应该在疯狂写入。但实际看到的是什么数据库和微服务的 CPU、负载都风平浪静。下游很闲上游却在堆积。结论只有一个瓶颈不在消息太多而在 EMQX 本机处理不动。消息堆积不是洪水是堰塞湖——河道堵了水才涨起来。回到 EMQX 机器本身什么东西在疯狂写磁盘又和消息量无关答案浮出水面日志。debug 级别的日志。三、根因上线初期埋下的定时炸弹时间倒回平台刚上线的时候。设备接入量小排查问题全靠日志为了看得清楚我们把 EMQX 的日志等级开到了 debug。那时候一天没几条日志开着毫无感觉。然后设备量涨上来了。一万、十万、几十万。每一台设备的每一次连接、每一条消息都在 debug 日志里留下一串记录。日志写入量和设备量同步膨胀直到某个晚上磁盘 IOPS 到达极限——写日志把磁盘写满了队列CPU 大量时间耗在 IO 等待上消息处理能力归零堆积崩溃。【配图 2事故因果链】再次打满上线初期开启 debug 日志设备少,无感知设备量涨到几十万日志量同步膨胀磁盘 IOPS 被打满CPU 耗在 IO 等待消息处理停摆消息堆积集群崩溃,第一次运维重启集群几十万设备同时重连触发新的日志洪峰集群崩溃,第二次重启后约 30 秒最讽刺的地方在这里第一次崩溃是日志打垮的第二次崩溃还是日志打垮的。重连风暴本身并不可怕——可怕的不是几十万台设备同时回来而是它们回来的那一刻每一台都在催集群写 debug 日志。重连波峰 × debug 日志 第二次 IOPS 洪峰集群在 30 秒内重蹈覆辙。重启没有解决任何问题反而成了二次事故的开关。四、恢复一道平时像摆设的闸门恢复动作本身简单到不好意思说把 EMQX 日志等级从 debug 调回生产环境该有的水位重启集群这一次几十万台设备的重连波峰来了集群扛住了。扛住的另一个功臣是集群上一直配置着的最大连接数限制。平时它像个摆设——谁会嫌连接多呢但在重连风暴里它成了一道闸门超过阈值的连接被拒绝或排队设备端退避重试重连被自然地摊平到一个时间窗口里而不是在同一秒全部砸进来。【配图 3恢复后的重连过程】否是集群重启完成几十万设备发起重连达到最大连接数阈值?连接建立,正常恢复超出部分被拒绝/排队设备端随机退避后重试波峰被摊平集群稳定恢复五、三个教训1. 上线初期的临时配置是最危险的定时炸弹debug 日志不是错误为了方便排查是正当需求。错的是它没有任何退出机制没有工单、没有期限、没有 checklist 提醒你在设备量上来之后关掉它。所有临时的东西——临时开的日志、临时关的告警、临时放宽的限流——都应该有明确的过期时间。后来我们把日志等级直接写进了生产环境部署 checklist新环境上线必须确认日志等级为生产水位签字画押。2. 重启不是恢复手段没有预案的重启是二次事故的开关长连接集群的重启等于亲手制造一次全量重连。重启之前要回答的问题不是能不能起得来而是起来之后几十万台设备一起回来扛不扛得住。扛不住预案的重启就是亲手按下第二次崩溃的按钮。3. 排查时先分清楚洪水和堰塞湖消息堆积、队列变长、延迟上升——这些都只是水位高了。水位高有两种可能上游来水太大或者下游河道堵了。两者的处置完全相反。一个简单的排除动作就能区分看下游忙不忙。下游很闲而你在堆积就别再盯着流量看了去查自己这台机器。写在最后这次事故没有高深的技术没有内核 bug没有网络分区没有分布式一致性问题。就是一行日志配置加一次没有预案的重启。但也正因为不高深它才值得讲。生产环境里拖垮系统的往往不是你想不到的黑天鹅而是你以为无害的灰犀牛——它从你系统只有几千台设备的那天起就站在角落里等设备量涨上来。【配图 4事故时间线可放文末作总结图】上线初期设备量少开启 debug日志便于排查无感知设备量增长期几十万设备在线日志量同步膨胀隐患累积事故当晚CPU 告警IOPS 打满集群第一次崩溃重启重连风暴叠加日志洪峰30 秒后第二次崩溃恢复调低日志等级最大连接数限流摊平波峰集群恢复事后日志等级写入生产部署checklist事故时间线你在生产环境里踩过临时配置变永久的坑吗评论区聊聊。
集群重启后 30 秒再次崩溃凶手不是重连风暴是日志晚上十点监控告警群炸了EMQX 集群 CPU 打满。那时我们平台的在线设备在几十万量级挂在 2 个 EMQX 节点后面。这种量级的集群日常 CPU 水位并不高突然打满只有一种解释出事了。但真正的故事不是这次崩溃而是半小时后的第二次崩溃——我们把集群重启起来不到 30 秒它又躺下了。事后复盘打垮集群的不是几十万台设备的重连风暴。凶手是一行配置日志等级。一、事故经过两次崩溃第一次崩溃来得没什么征兆。没有发版没有配置变更设备量也没有异常波动。CPU 从正常水位一路爬升到打满消息开始大量堆积然后集群失去响应。运维的第一反应是标准动作重启。集群起来了。设备开始重连。然后几十万台设备同时涌回来的那一刻集群再次崩溃——从重启完成到第二次躺平大约 30 秒。如果你做过设备接入对重连风暴这个词不会陌生长连接集群最怕的不是稳态流量而是全量设备在同一时刻回来。但这一次风暴只是压死骆驼的最后一根稻草——而且骆驼的背上早就被我们自己放了一块石头。二、排查一条误导性线索一个关键排除法【配图 1平台链路图】几十万台智能家电设备负载均衡EMQX 节点 1EMQX 节点 2业务微服务数据库上监控平台看数据第一个异常很醒目磁盘 IOPS 打满。当时的推理链是这样的IOPS 高 → 是不是消息量太大→ 看 EMQX果然堆积了大量消息。逻辑似乎闭环了消息洪峰 → 写盘压力 → IOPS 打满 → CPU 占死。这是本次排查中最大的误导性线索。消息堆积是真实存在的但它是结果不是原因。把我们拉出误区的是一个排除法动作去看下游的负载。如果真的是消息量太大把平台压垮了那么压力一定会传导下去——业务微服务应该在疯狂消费数据库应该在疯狂写入。但实际看到的是什么数据库和微服务的 CPU、负载都风平浪静。下游很闲上游却在堆积。结论只有一个瓶颈不在消息太多而在 EMQX 本机处理不动。消息堆积不是洪水是堰塞湖——河道堵了水才涨起来。回到 EMQX 机器本身什么东西在疯狂写磁盘又和消息量无关答案浮出水面日志。debug 级别的日志。三、根因上线初期埋下的定时炸弹时间倒回平台刚上线的时候。设备接入量小排查问题全靠日志为了看得清楚我们把 EMQX 的日志等级开到了 debug。那时候一天没几条日志开着毫无感觉。然后设备量涨上来了。一万、十万、几十万。每一台设备的每一次连接、每一条消息都在 debug 日志里留下一串记录。日志写入量和设备量同步膨胀直到某个晚上磁盘 IOPS 到达极限——写日志把磁盘写满了队列CPU 大量时间耗在 IO 等待上消息处理能力归零堆积崩溃。【配图 2事故因果链】再次打满上线初期开启 debug 日志设备少,无感知设备量涨到几十万日志量同步膨胀磁盘 IOPS 被打满CPU 耗在 IO 等待消息处理停摆消息堆积集群崩溃,第一次运维重启集群几十万设备同时重连触发新的日志洪峰集群崩溃,第二次重启后约 30 秒最讽刺的地方在这里第一次崩溃是日志打垮的第二次崩溃还是日志打垮的。重连风暴本身并不可怕——可怕的不是几十万台设备同时回来而是它们回来的那一刻每一台都在催集群写 debug 日志。重连波峰 × debug 日志 第二次 IOPS 洪峰集群在 30 秒内重蹈覆辙。重启没有解决任何问题反而成了二次事故的开关。四、恢复一道平时像摆设的闸门恢复动作本身简单到不好意思说把 EMQX 日志等级从 debug 调回生产环境该有的水位重启集群这一次几十万台设备的重连波峰来了集群扛住了。扛住的另一个功臣是集群上一直配置着的最大连接数限制。平时它像个摆设——谁会嫌连接多呢但在重连风暴里它成了一道闸门超过阈值的连接被拒绝或排队设备端退避重试重连被自然地摊平到一个时间窗口里而不是在同一秒全部砸进来。【配图 3恢复后的重连过程】否是集群重启完成几十万设备发起重连达到最大连接数阈值?连接建立,正常恢复超出部分被拒绝/排队设备端随机退避后重试波峰被摊平集群稳定恢复五、三个教训1. 上线初期的临时配置是最危险的定时炸弹debug 日志不是错误为了方便排查是正当需求。错的是它没有任何退出机制没有工单、没有期限、没有 checklist 提醒你在设备量上来之后关掉它。所有临时的东西——临时开的日志、临时关的告警、临时放宽的限流——都应该有明确的过期时间。后来我们把日志等级直接写进了生产环境部署 checklist新环境上线必须确认日志等级为生产水位签字画押。2. 重启不是恢复手段没有预案的重启是二次事故的开关长连接集群的重启等于亲手制造一次全量重连。重启之前要回答的问题不是能不能起得来而是起来之后几十万台设备一起回来扛不扛得住。扛不住预案的重启就是亲手按下第二次崩溃的按钮。3. 排查时先分清楚洪水和堰塞湖消息堆积、队列变长、延迟上升——这些都只是水位高了。水位高有两种可能上游来水太大或者下游河道堵了。两者的处置完全相反。一个简单的排除动作就能区分看下游忙不忙。下游很闲而你在堆积就别再盯着流量看了去查自己这台机器。写在最后这次事故没有高深的技术没有内核 bug没有网络分区没有分布式一致性问题。就是一行日志配置加一次没有预案的重启。但也正因为不高深它才值得讲。生产环境里拖垮系统的往往不是你想不到的黑天鹅而是你以为无害的灰犀牛——它从你系统只有几千台设备的那天起就站在角落里等设备量涨上来。【配图 4事故时间线可放文末作总结图】上线初期设备量少开启 debug日志便于排查无感知设备量增长期几十万设备在线日志量同步膨胀隐患累积事故当晚CPU 告警IOPS 打满集群第一次崩溃重启重连风暴叠加日志洪峰30 秒后第二次崩溃恢复调低日志等级最大连接数限流摊平波峰集群恢复事后日志等级写入生产部署checklist事故时间线你在生产环境里踩过临时配置变永久的坑吗评论区聊聊。
