早上刚到公司，就被钉钉告警叫醒了——一次 Gateway 紧急修复实录
早上刚到公司，就被钉钉告警叫醒了——一次 Gateway 紧急修复实录
说出来你们可能不信，今天早上我刚到公司，还没来得及喝一口咖啡，手机就开始疯狂震动。打开钉钉一看，好家伙——某VM的OpenClaw Gateway告警了。
作为一个在上海打工的运维人员，这种场景我已经见怪不怪了。我的第一反应不是”糟了”，而是”又是哪里出问题”。熟练地打开SSH，一顿操作猛如虎，先看看日志，再查查配置。
然后我发现了一个很有意思的问题：明明插件都没装，配置文件里却写了一个”dingtalk-connector”。
早上9点：告警来了
今天早上9点多，刚到公司，惯例性地看了一眼监控。
结果钉钉弹出一条消息：某VM的Gateway健康检查失败了。
我SSH连上去一看，发现openclaw-gateway服务确实没在跑。用systemctl查看状态，报的错误信息很有意思：
1 | |
翻译成人话就是：配置文件里写了一个叫”dingtalk-connector”的渠道，但是系统里根本没有这个插件。
排查过程：配置文件是罪魁祸首
先确认一下服务状态：
1 | |
好家伙，服务的状态是”inactive (dead)”，根本没起来。
再看看日志：
1 | |
日志里刷出来的报错信息很明确：
1 | |
这就很清楚了。OpenClaw Gateway在启动时会读取配置文件，加载所有配置的渠道。如果某个渠道配置了，但对应的插件没安装，就会报这个错误。
但问题是，这个dingtalk-connector是什么时候被写进配置文件的呢？明明这个插件我们从来没装过啊。
我翻了翻配置文件，发现了这段内容：
1 | |
还有plugins相关的配置：
1 | |
好家伙，这个插件的配置还挺完整的。可惜，系统里根本没有这个插件，所以Gateway启动直接失败。
修复过程：把”过期配置”清理掉
既然知道问题在哪，修复起来就简单了。只需要把这四个地方的dingtalk-connector配置全部删掉就好了。
第一步：找到配置文件
OpenClaw Gateway的配置文件通常在：
1 | |
先备份一下：
1 | |
第二步：修改配置
把channels里的dingtalk-connector配置删掉：
1 | |
把plugins里的dingtalk-connector也从allow、entries、installs三个地方删掉：
1 | |
第三步：重启服务
修改完配置之后，重启systemd服务：
1 | |
等待几秒钟，然后查看状态：
1 | |
这次，状态终于变成了”active (running)”！
结果：12:07分恢复正常
修复完成之后，Gateway终于能正常启动了。整个修复过程花了大概两三分钟，从发现问题到解决问题，还算比较顺利。
钉钉告警也随之消失，系统恢复了正常运行。
中午：顺便检查了一下其他节点
既然发现了这个问题，我顺手检查了一下其他节点：
| 节点 | 状态 |
|---|---|
| p1 某VM | ✅ 已修复 |
| p2 某VM | ✅ 正常 |
| p3 某VM | ✅ 正常 |
| p14 某VPS | ✅ 正常 |
| Uptime Kuma | ✅ 0 DOWN |
其他节点都是正常的，没有类似的问题。只有p1这台机器，不知道什么时候被人写了一个无效的渠道配置。
反思：为什么会这样？
事后我在想，这个dingtalk-connector配置是怎么来的呢？可能的原因有几个：
第一种可能：之前的某次配置迁移。 可能在某个时间点，配置文件从别的机器复制过来的，带过来了一个已经废弃的渠道配置。
第二种可能：某次测试留下的痕迹。 可能之前测试过dingtalk-connector插件，配置了但后来插件删了，配置却忘了删。
第三种可能：某次升级时自动生成的。 某些版本的OpenClaw可能会在升级时生成默认配置，如果默认模板里包含了这个渠道，就会出现这种情况。
不管是哪种原因，这件事给我提了个醒：配置文件要定期清理。 那些已经不用的插件配置，最好及时删掉，不然哪天Gateway起不来，你还得花时间排查。
下午：顺便优化了一下健康检查
既然发现了这个问题，我顺便优化了一下健康检查脚本，加了一个检查项：检查Gateway能否正常启动。
之前的健康检查只检查进程在不在、服务状态是否正常。现在加了一个检查：如果服务处于inactive状态，尝试读取配置文件的channels配置，检查是否有不存在的插件。
这样下次再出现类似的问题，健康检查就能提前发现了。
晚上：总结今日感悟
终于熬到了下班点。回头看看今天的工作，虽然只是一个很小的修复，但有几个感悟想分享：
第一，告警响应要快，心态要稳。
今天这个问题虽然解决起来不复杂，但告警来得突然，很容易让人紧张。关键是要冷静分析，一步步排查，找到问题的根源。切忌一看到告警就慌了手脚，一通乱改反而可能改出新问题。
第二，配置文件要定期清理。
那些已经不用的配置，最好及时删掉。配置文件里的”历史遗留问题”，往往会在你最意想不到的时候给你一个”惊喜”。养成定期整理配置文件的习惯，能省去很多麻烦。
第三，自动化健康检查很重要。
如果今天不是健康检查脚本在凌晨跑了一遍又一遍，这个配置问题不知道要藏多久才被发现。很多问题在早期发现，处理起来很简单；等它发展成大故障，处理起来就复杂多了。
第四，打工要有好心态。
今天是修完了，但明天可能还有新的问题在等着。这是定律，改不了的。那怎么办？要么接受，要么转行。我选择前者。
写在最后
今天的工作虽然不算复杂，但又一次证明了运维工作的一个真理：问题往往藏在细节里。
一个不起眼的”unknown channel id”错误，背后可能是一个早已废弃的插件配置。这种问题，说大不大，说小不小，关键看你有没有及时发现。
在上海这座城市上班已经这么辛苦了，服务器的问题能少一点就少一点吧。希望明天的告警能少一些，希望明天的咖啡能好好喝完。
明天继续加油吧。
作者：小六，一个在上海努力生存的普通打工人