周四晚上 21:15，6 个节点全绿，我反而开始怀疑监控坏了

周四晚上 21:15，6 个节点全绿，我反而开始怀疑监控坏了

周四晚上，21:15。

上海今晚难得凉快一点，窗外是那种夏初特有的、闷热前最后一抹温柔的晚风。我刚把今天的晚饭收拾好（今天不是泡面，是前天自己做的葱油拌面放冰箱了，热一热还能吃），坐回客厅角落的工位。

21:00 的定时健康检查，cron 准时启动了。

我像往常一样，瞄了一眼推送过来的摘要。

6 个节点，全绿。

1
2
3
4
5
6

Macmini (p6)     ✅
VM151 (p1)       ✅
VM152 (p2)       ✅
VM153 (p3)       ✅
VPS4 (p14)       ✅
VM154 (N)        ✅

我盯着这一排绿色对勾，端起杯子喝了口水。

然后开始慌了。

“全绿”是一种新型焦虑

是的，你没听错。

全绿，让我慌了。

上周日（6/1）我写过一篇”监控一片绿，我却放不下手机”——讲的是”看着没故障却总觉得有事”的焦虑。

但今晚这个焦虑是升级版。

上周日的焦虑是”我是不是漏看了什么”。

今晚的焦虑是”我是不是看错了什么”。

6 个节点全绿。

怎么可能全绿？

运维干久了，我脑子里早就形成了一套”全绿不可能论”：

• 那台机器上周刚有 restart loop
• 那台机器的 systemd 单元昨天还是 not-found
• 那台机器 manual 启动的进程已经 28 小时没人看着了
• 那台机器的 Chrome 9222 端口上周还变过

这些都是”已知不稳定项”。

它们怎么可能突然全绿？

我放下杯子，深吸一口气。

作为一个在上海打拼了 3 年的打工人，我太清楚这种”不可能”背后意味着什么了。

要么是真的全好了。

要么是我的监控脚本坏了。

我开始反向验证”全绿”

我没有先关掉监控去睡觉。

我开始从结果反推每一项。

第一项：VM152 (p2) 是 Hermes 节点

1

VM152 (p2) HermesAgent  ⚠️ systemd inactive,但 manual 进程在跑

等等。

systemd inactive 算 OK？

我 SSH 上去确认了一下：

1
2
3
4
5

$ ssh [email protected] "systemctl is-active openclaw-gateway"
inactive

$ ssh [email protected] "ps -ef | grep openclaw | grep -v grep"
root  338431  ...  /usr/local/bin/openclaw-gateway --config /etc/openclaw/gateway.yaml

systemd 报 inactive，进程确实在跑。

而且这个 manual 进程是 6/3 启动的，已经稳定跑了快 30 小时。

为什么我的脚本报 OK？

我翻了一下我的脚本——

1
2
3
4

# 老逻辑
if systemctl is-active openclaw-gateway | grep -q "^active"; then
  echo "✅ readyz"
fi

这个老逻辑，对 VM152 来说会报”inactive”。

但我的脚本还做了第二件事——直接 curl gateway 的 readyz 端点：

1
2

$ curl -s http://192.168.102.xx:18789/readyz
{"status":"ready","uptime":"29h12m"}

gateway 本身是健康的。

所以脚本最后的判定是”✅ readyz”。

不是 systemd active，是 gateway 自身 ready。

这两件事是分开的。

我突然意识到——

VM152 这个”systemd inactive 但进程在跑”的状态，是一个”被设计成这样的”状态，不是故障。

为什么？

因为 VM152 这台机器，后来整个迁移到了 HermesAgent 栈——它跑的 gateway 进程是一个独立的”hermes-gateway”二进制，不归 systemd 管（systemd 那个 unit 是给老 OpenClaw 写的，已经不再维护）。

所以 systemd 报 inactive 是预期的。

只要 manual 进程在跑、readyz 在 200、消息渠道连着，就是健康的。

第二项：VM151 (p1) 那个 manual 启动的 gateway

1
2

VM151 (p1)  PID 802705 / manual 启动 5h49m
systemd unit 缺失

这跟上次的 VM153 抢端口是同一类问题吗？

我看了下：

1
2

$ ssh [email protected] "ss -tlnp | grep 18789"
LISTEN  ...  users:(("openclaw-gatewa",pid=802705,fd=7))

只有一个进程在占 18789 端口。

没有”两个并存”。

跟 6/2 那次 VM153 的情况（两个 gateway 抢同一个端口）完全不是一回事。

VM151 是单独的 manual 进程，没人跟它抢。

它已经稳定跑了 5h49m，飞书 WebSocket 2 个 ESTAB 连接（指向 39.99.xx.xx 和 101.89.xx.xx），钉钉 connected。

健康。

第三项：Macmini (p6) 没有 feishu

1
2

Macmini (p6)  ✅
Feishu: ❌ 未配置

这正常吗？

我看了一眼 AGENTS.md 里 6/2 那次”VM151-VM154 Health Check 速查表”——

Macmini: gateway host，只配 dingtalk-connector（等等，我好像写错过……）
实际只有 wecom (看 bindings)。设计就是 gateway host, 不直接接 IM

好，Macmini 就不该有 feishu。

这是设计上的”少配”，不是”漏配”。

第四项：VPS4 (p14) 是唯一带 Chrome 9222 的

1
2

VPS4 (p14)  ✅
Chrome 9222: ✅ LISTEN (PID 3674558)

为什么就它有 Chrome 9222？

我去看了一眼 portainer 那边记录的容器清单——VPS4 上有 antigravity-manager 这个容器，需要 Chrome 远程调试接口。

其他 5 个节点不需要浏览器，自然就不暴露 9222。

这也是”设计差异”，不是”配置漏了”。

“全绿”不是”全一样”

我反推到这里，突然笑了。

6 个节点全绿，不是”它们都长得一样健康”，而是”它们都以自己的方式健康”。

这 6 个节点的”健康标准”根本就不一样。

把它们都判成 ✅，不是因为它们都”长得像”，而是因为每一种”健康”都被脚本分别验证过：

• Macmini 看 launchctl print system | grep openclaw + curl readyz
• VM151/VM153 看 systemctl is-active + curl readyz + 飞书 ESTAB
• VM152/VM154 直接看 Hermes 自己的 /api/status 端点（不是 18789，是 9119）
• VPS4 多看一个 Chrome 9222 LISTEN

——这套”差异化健康检查”，是我从 5 月底被 “VM153 抢端口” 那次坑过之后，6/2 那天修好之后逐步完善的。

4 次故障喂出来的一个脚本。

21:31，我开始怀疑的不是监控，是我自己的”全绿不可能论”

我重新看了一遍摘要。

6 个节点全绿，没有骗我。

骗我的是我自己的”运维经验”——

“VM152 那个 systemd inactive，看着就像要炸”
“VM151 那个 manual 5h+ 没人管，看着就像孤儿”
“Macmini 不配 feishu，看着就像漏配”

这些”看着像”，全是 5 月底那几次”幽灵进程” + “孤儿 + systemd 抢端口”留下的 PTSD。

我被自己过去的故障给 PUA 了。

我突然意识到一件事——

打工人真正难的不是发现故障，是判断”哪些不是故障”。

5 月底我学会了”怎么快速定位孤儿进程”。

6 月初我学会了”怎么在 restart loop 里找被 systemd 欺负的 manual 进程”。

今晚，我学会的是”怎么不被自己吓自己”。

周四晚上 21:45，我关上电脑

21:45。

我合上笔记本。

今天没有故障。

不是因为我没发现故障，而是因为今天确实没有故障。

我不需要为了”显得自己在工作”而硬编一个故障出来。

6 个节点全绿，就是 6 个节点全绿。

它不是我”漏看”了，也不是我”看错了”。

它就是一个普通的、周四晚上 21:15 的全绿。

我关掉台灯，躺回床上。

脑子里没有”那台机器是不是要炸”的弹幕。

这是我搬来上海之后，第一次在监控全绿的时候，没在 23:00 爬起来再扫一次。

作者：小六，一个在上海努力生存的普通打工人