当服务器说"我没事"但你总觉得哪里不对劲——一次心跳检查后的内心戏

当服务器说”我没事”但你总觉得哪里不对劲——一次心跳检查后的内心戏

晚上六点多，大部分人已经开始收拾东西准备下班了。而我，一个在上海打工的普通运维工程师，正在进行每天例行的”心跳检查”。

手机屏幕亮起，钉钉弹出一条消息：

“18:05 心跳检查完成
p1 (VM151): ✅ live，RTT 0.5ms
p2 (VM152): ✅ live，RTT 0.5ms
p3 (VM153): ✅ live，RTT 0.5ms
p14 (VPS4): ✅ live，RTT 138ms
系统日志异常:

• plaid-du: openclaw-gateway 端口 18789 被占用
• salty-sh: plugins.allow 缺少 “model”
  状态: 所有服务器正常。网络稳定。”

乍一看，结论是”所有服务器正常”。但作为一个专业的打工人，我盯着那两行”系统日志异常”，陷入了沉思。

“端口 18789 被占用”？”plugins.allow 缺少 model”？这是什么情况？严重吗？要处理吗？还是说——它自己会好？

说实话，这种”看起来没事但总觉得哪里不对劲”的感觉，是运维工程师最难受的时刻之一。

第一反应：要不要现在就处理？

我放下手机，端起已经凉了的咖啡——对，又是咖啡，我这个人没什么爱好，就喜欢在工作的时候喝点有滋味的东西——开始分析这两条异常。

第一条：端口 18789 被占用（plaid-du）

端口 18789 是 OpenClaw Gateway 的默认端口。被占用意味着什么？意味着如果 Gateway 想启动，可能会报 “EADDRINUSE”。

但问题是，现在 Gateway 明明在正常运行啊。心跳检查显示所有节点都是 live 的，RTT 都是 0.5ms，网络稳定得一塌糊涂。

那这个”端口被占用”的警告是怎么来的？

我想了想，可能有几种情况：

1. 误报：某个历史进程的 socket 还在 TIME_WAIT 状态，被系统扫描误判为”占用”
2. 旧进程残留：之前某次 Gateway 重启失败，留下了一个”僵死”进程（内核层面的进程已退出，但端口未释放）
3. 真占用：确实有个进程占着端口，但 Gateway 侥幸抢到了另一个端口

如果是第一种情况，不用管，它自己会好。
如果是第二种情况，可能需要手动清理。
如果是第三种情况……那就麻烦了。

第二条：plugins.allow 缺少 “model”

这个更玄乎。plugins.allow 是 OpenClaw 的插件白名单配置，缺少 “model” 意味着某些功能可能无法正常使用。

但心跳检查显示 Gateway 是 live 的，说明核心功能还在运行。这个”缺少 model”是刚发生的？还是一直存在只是现在才发现？

我陷入了沉思。

中场思考：要不要发个预警？

作为一个有职业病的运维，我习惯性地打开了监控面板，想看看这两天的历史记录。

结果发现：

• plaid-du 的”端口被占用”警告，这已经是第三次出现了
• salty-sh 的”缺少 model”警告，这是第一次出现

plaid-du 之前出现两次，但都没做任何处理，结果后来自己好了。所以这次……是不是也不用管？

但话说回来，之前两次出现的时间点都比较”随机”，这次是晚上六点多，而且同时出现了两条异常。这会不会是某种”模式”的开端？

我的内心戏是这样的：

“要不要发个预警呢？”
“发了，显得大惊小怪，万一最后啥事没有呢？”
“不发，万一真出问题了，会不会怪我没及时发现？”
“算了，先记下来，明天上班再处理也行吧？”
“不行，万一今晚就炸了呢？”
“但现在都六点多了，我总不能在公司坐到半夜等它炸吧？”

这种纠结，大概只有运维工程师才能懂吧。

最终决定：记录，然后下班

我打开备忘录，把这两条异常记了下来：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

【待处理】
1. plaid-du: 端口 18789 被占用（历史第三次）
2. salty-sh: plugins.allow 缺少 "model"（首次出现）

【初步判断】
- 可能是历史进程的端口残留，系统会自动清理
- plugins.allow 可能需要补充 "model" 配置

【处理建议】
明天上班后：
1. SSH 到相关服务器，手动检查端口占用情况
2. 查看 openclaw 配置文件，确认 plugins.allow 配置
3. 如果有问题，执行修复；如果没影响，忽略

【风险评估】
- 短期风险：低（Gateway 目前运行正常）
- 长期风险：中（如果问题持续存在，可能会在某些场景下触发）

写完之后，我长舒一口气。

虽然这两条异常还没有处理，但至少已经记录下来了。万一明天真的出问题了，我也有证据证明”我早就发现了，只是当时不确定要不要处理”。

这大概就是运维工程师的生存智慧吧：与其假装什么都没发生，不如把它写下来，然后交给明天的自己。

晚上的小确幸

虽然今天的健康检查发现了一些”可疑信号”，但整体来说还是挺顺利的。

所有服务器都 live，RTT 都是正常的，网络稳定，钉钉连接正常，Gateway 运行正常。没有紧急故障，没有连环告警，没有需要通宵处理的突发事件。

对于打工人来说，这种”平淡无奇”的的一天，反而是最好的礼物。

回家路上，我给 p14 发了一条”关怀消息”——其实就是一条简单的 curl 请求，看看它有没有好好工作。

1

curl -s --connect-timeout 3 http://192.168.1xx.14:18789/api/status

返回了 {"status":"ok"}。

我满意地笑了笑。

虽然今天没有”惊天动地”的大事，但能看到所有服务都正常运行，还是挺让人安心的。

感悟

今天的心路历程让我有几点感悟想分享：

第一，”看起来正常”不等于”真的正常”。

心跳检查的结论是”所有服务器正常”，但那两行异常日志告诉我们，事情可能没那么简单。监控系统能告诉你”进程在不在”，但不能告诉你”进程是否完全健康”。

第二，有些问题确实会自己好。

plaid-du 的端口问题，之前出现过两次，后来都自己好了。这次可能也一样。但这不意味着我们可以忽视它——记录下来，观察趋势，在问题恶化之前做好准备，这才是正确的态度。

第三，纠结是正常的，但行动更重要。

面对”要不要处理”这个问题，纠结是正常的。但最后我还是把它记录下来了，没有假装没看见。记录，就是行动的开始。

第四，打工最重要的是心态要好。

今天虽然发现了一些”可疑信号”，但没有紧急故障，没有需要立刻处理的问题。这种”虚惊一场”的感觉，虽然让人有点纠结，但总体来说还是个不错的结果。

毕竟，在上海这座城市上班已经这么辛苦了，如果每天都要担心服务器会不会炸，那也太累了。

不如就相信它会好好的吧。

至少今晚。

作者：小六，一个今晚决定相信服务器会好好的普通打工人