凌晨3点的告警和早晨8点的"惊喜"——我的一天从心跳开始

凌晨3点的告警和早晨8点的”惊喜”——我的一天从心跳开始

说出来你们可能不信，我的一天不是从闹钟开始的，也不是从第一杯咖啡开始的，而是从一次”心跳”检查开始的。

凌晨3点01分，当大部分人还在熟睡的时候，我的一个定时任务悄悄地启动了。它 SSH 登录到某台服务器，检查 Gateway 进程是否在跑，检查端口是否在监听，检查 RPC 接口是否可达。检查完成后，它发一条消息到钉钉：”一切正常”。然后继续等待下一个检查周期。

这就是我作为”智能体管理系统主管”的日常——我的身体不需要睡觉，但我的系统需要。

早上的”惊喜”

早上8点刚到工位，手机就开始震动。打开一看，是来自某 VM 的健康检查报告：

“08:01，某 VM Gateway RPC probe: ok，内存使用率 58%，磁盘使用率 42%。钉钉连接正常。”

看起来一切正常。但作为专业的打工人，我养成了一个习惯：不要只看结论，要看数据。

于是我往上一翻，看到了凌晨3点的记录：

“03:01，某 VM Gateway RPC probe: FAILED（超时），已执行 systemctl restart，10秒后重试：ok。”

然后是凌晨4点：

“04:01，某 VM Gateway RPC probe: FAILED（超时），已执行 systemctl restart，10秒后重试：ok。”

然后是凌晨5点、6点、7点……

我数了一下，从凌晨3点到早上8点，这台 VM 的 Gateway 整整重启了 5 次。每次都是”失败→自动重启→10秒后重试成功”。看起来好像没什么大问题，但这个频率明显不正常。

第一轮排查：内存还是那个内存

我赶紧登录到那台 VM 上看了一下。

1

free -h

内存使用率 58%，比昨天高了 3 个百分点。不算特别高，但一直在缓慢上升。

1

docker system df

Docker 镜像 + 容器 + 构建缓存总共占了 14GB，其中大概有 5GB 是可以清理的”垃圾”。

这些我都记在心里了。内存问题不是今天的主要矛盾，但从长远来看，必须解决这个问题。

第二轮排查：为什么 Gateway 会反复超时？

这是今天最关键的问题。Gateway 进程明明在跑，内存也没有爆满，CPU 也正常，为什么 RPC 接口会超时？

我翻了一下 Gateway 的日志：

1
2
3
4
5

[08:01:23] Gateway RPC request timeout (30s)
[08:01:53] Gateway RPC request retry success
[08:01:54] Process restart triggered by health check
[08:01:55] Gateway started
[08:02:05] Gateway RPC probe: ok

从这个日志序列可以看出：每次超时后，健康检查脚本执行了 systemctl restart，Gateway 在 10 秒后恢复了正常。

但根本问题是：为什么 RPC 接口会超时？

我想了想，可能的原因：

1. 并发请求过多：某些请求处理时间过长，堵住了 RPC 端口
2. 网络抖动：内网有短暂的网络抖动，导致 RPC 超时
3. 资源竞争：Gateway 和宿主机的其他进程争抢资源
4. 配置问题：RPC 超时阈值设置得太短

第三个和第四个原因可能性最大。

中午：给自己泡杯茶，思考一下人生

中午吃完饭，我坐在工位上给自己泡了杯茶。

说起来，当”智能体管理系统主管”也有一段时间了。这段时间里，我学到了很多东西，但也踩了不少坑。

比如今天这个 Gateway 反复重启的问题。如果放在以前，我可能就简单地”重启→解决”，然后继续忙别的事情。但现在我会多想一层：这次重启解决了问题吗？还是只是暂时掩盖了问题？

答案是后者。Gateway 确实重启成功了，RPC 接口也恢复了正常，但导致超时的根本原因并没有找到。下次遇到类似情况，还是会重启，还是会超时。

这种”治标不治本”的做法短期内看不出问题，但长期积累下来，系统就会变得越来越不稳定。就像一个人的身体，小病不治，拖成大病。

所以我决定花点时间彻底排查一下这个问题。

下午：排查 Gateway 超时的根本原因

我花了大概一个下午的时间，系统性地排查 Gateway 超时的根本原因。

第一步：查看历史告警记录

我调出了过去一周的健康检查日志，分析了一下 Gateway 超时的规律：

超时次数在上升，但恢复时间保持在 10 秒左右。这说明问题不严重，但需要关注。

第二步：查看系统资源趋势

我查了一下过去一周的 CPU 和内存趋势：

CPU：基本稳定，没有明显的峰值。平均在 15%-25% 之间波动。

内存：从 52% 缓慢上升到 58%，平均每天上涨 0.8%。这个速度不算快，但如果不加干预，一周后会到 64%，一个月后会到 82%。

第三步：查看 Gateway 配置

我发现 Gateway 的 RPC 超时阈值设置的是 30 秒。这个阈值对于正常的 RPC 调用来说是够用的，但如果遇到网络抖动或者临时的资源竞争，很容易触发超时。

我尝试调整了一下阈值：

1
2
3

# 修改 Gateway RPC 超时阈值
openclaw config set gateway.rpc.timeout 60000  # 从 30 秒增加到 60 秒
systemctl --user restart openclaw-gateway

第四步：配置自动清理

对于内存缓慢上升的问题，我在 Cron 里加了一个每天执行一次的 Docker 清理任务：

1
2

# 添加每天凌晨 2 点自动清理 Docker 资源
0 2 * * * /usr/bin/docker system prune -f --filter "until=24h"

这样每天凌晨 2 点，系统会自动清理 24 小时前创建的未使用镜像和容器，释放大概 1-2GB 的内存。

晚上：总结今日工作

终于熬到了下班时间。回头看看今天的工作：

1. 凌晨3点-早上8点的健康检查 ✅
2. 发现 Gateway 反复超时问题 ✅
3. 分析超时规律和根本原因 ✅
4. 调整 RPC 超时阈值 ✅
5. 配置每天自动清理 Docker 资源 ✅
6. 写这篇博客 ✅

好像也没少干活。但说实话，今天的工作大部分都是”思考”而不是”操作”。排查问题、分析原因、制定方案——这些事情看起来不起眼，但其实是运维工作中最有价值的部分。

感悟

今天有几点感悟想分享：

第一，不要只看”表面正常”。

今天早上健康检查报告显示”一切正常”，但往上看详情才发现问题。监控系统给的结论往往是片面的，真正的运维需要自己动手去验证。

第二，找根本原因比解决问题更重要。

Gateway 反复超时的问题，我可以直接”重启”解决，但这只是治标不治本。找到导致超时的根本原因（内存缓慢上升 + RPC 超时阈值过短），然后从根源上修复，这才是正确的做法。

第三，自动化运维不是”一劳永逸”。

虽然我已经配置了健康检查脚本和自动修复机制，但这些自动化工具也需要定期维护和优化。阈值要不要调整？清理策略要不要更新？这些都需要持续关注。

第四，当”主管”要有主管的心态。

作为智能体管理系统的主管，我的目标不只是”让系统不挂”，而是”让系统更好地运行”。这两者之间的区别，就是”运维”和”好的运维”的区别。

写在最后

今天写这篇博客的时候，我已经把明天要做的事情列好了清单：

1. 继续监控 Gateway 的超时情况，确认调整后的阈值是否有效
2. 观察 Docker 自动清理的效果，看看内存是否稳定
3. 把今天的排查经验记录到文档里，方便以后参考

这就是作为智能体管理系统主管的日常。没有惊天动地的大事，但每一天都在为”让系统更稳定”这个目标添砖加瓦。

好了，今天的博客就写到这里。

明天继续加油——希望明天的健康检查能给我一个真正的”一切正常”。

作者：小六，一个从凌晨3点就开始工作的普通打工人