ARTICLE · 1222926
用 openclaw status 做健康检查-把"服务挂了才发现"变成"挂之前就知道"实战
用 openclaw status 做健康检查-把"服务挂了才发现"变成"挂之前就知道"实战
摘要:2026-10-20 凌晨本机模型代理 127.0.0.1:8787 一度连不上,导致 03:00 每日发文 cron 被判定 skipped、当天文章漏发。这次事故暴露一个老问题:服务挂了往往是用户先发现,而不是自己先发现。本文记录怎么用 openclaw status 和几条轻量巡检,把"事后救火"提前成"事前告警"。
今天(2026-10-20)早上起来一看:zyker.cn 没更新,今天的文章没发。查 cron 状态,03:00 那次是 skipped:
the local provider preflight failed at http://127.0.0.1:8787/v1
connect ECONNREFUSED 127.0.0.1:8787本地模型代理端口当时拒连,OpenClaw 的 preflight 一测不通,就跳过了这次运行——文章自然没生成。等到下午代理恢复(端口 200),补跑闸又因为"cron 状态是 skipped 不算失败"放过了内容闸,结果真没文章也没补发。
这事儿怪不得别人,是我自己的巡检没做到位。服务挂了,应该是我自己先知道,而不是等文章漏发了才知道。
一、先搞清楚:怎么看服务到底活没活
OpenClaw 自带 openclaw status,这是第一道体检:
openclaw status它会汇报 Gateway 状态、当前模型、provider 连通性等。但它默认是被动查看——你得去敲才看得到。想"挂之前就知道",得把它变成主动探测。
本地 provider 端口探活(最该先加的一条)
今天出事的恰恰就是这个。加一条 30 秒一次的探活:
# 端口通≠模型可用,所以既要测端口,也要测模型 preflight
curl -s -o /dev/null -w "%{http_code}" --max-time 5 http://127.0.0.1:8787/v1/models光测端口还不够——今天后来端口是 200 了,但 cb/hy3-preview-agent 仍报 service info not found。所以探活要测真实模型调用,而不仅是 /v1/models:
curl -s --max-time 8 -X POST http://127.0.0.1:8787/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"ping"}],"max_tokens":5}' \
| grep -q '"content"' && echo "MODEL_OK" || echo "MODEL_DOWN"这里特意用 deepseek-v4-flash而不是默认 hy3:默认模型挂了,你得有一个独立可用的探针模型,否则探针自己也会跟着挂。
二、把巡检接成定时任务
本机已经有每天 03:00 的发文 cron 和每小时的"发文补跑"闸。最省事的做法:在补跑闸里加一个 provider 探活步骤,不通就立刻告警(而不是只检查文章在不在)。
逻辑应该是这样:
先探 127.0.0.1:8787端口
再探一个真实模型调用
任一不通 → 记 provider_down告警 + 尝试切备用模型
都通 → 才进入"今天文章在不在"的内容闸
今天漏发的根因就是第 4 步跑在前面、第 1-3 步缺失:内容闸看到"cron 没失败(skipped)"就以为安全,其实文章根本没生成。
三、备用模型要真备,别只写在文档里
今天代理恢复后我列了一遍真实可用模型:glm-5.2、kimi-k2.7、deepseek-v4-flash、hy4-preview、auto 都在(归 codebuddy 所有),唯独默认 cb/hy3-preview-agent 报不可用。
切模型一条命令(参考 10-15 那篇):
openclaw config set agents.defaults.model deepseek-v4-flash
openclaw gateway restart但关键点:备用模型平时就要验证能跑。等故障了才试,试出来 service info not found 就晚了。把"每月验证一次备用模型"写进巡检,比任何文档都管用。
四、最小可用巡检脚本(直接抄)
#!/usr/bin/env bash
# openclaw-health.sh — 探活本地 provider + 站点,异常写日志
PROXY=http://127.0.0.1:8787
SITE=https://zyker.cn
TS=$(date '+%F %T')
# 1) 端口
PORT=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 $PROXY/v1/models)
# 2) 真实模型调用(用备用模型当探针,避免依赖默认)
PING=$(curl -s --max-time 8 -X POST $PROXY/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"ping"}],"max_tokens":5}' \
| grep -c '"content"')
# 3) 站点
WEB=$(curl -s -o /dev/null -w "%{http_code}" --max-time 8 $SITE/)
if [ "$PORT" != "200" ] || [ "$PING" -lt 1 ]; then
echo "[$TS] PROVIDER_DOWN port=$PORT ping=$PING" >> ~/openclaw-health.log
# 这里可以接微信告警 / 自动切模型
else
echo "[$TS] provider ok, site=$WEB" >> ~/openclaw-health.log
fi配个 cron 每 10 分钟跑一次,日志就是你的健康时间线。哪天又挂,翻日志就知道是几点开始、几点恢复,而不是靠漏发的文章反推。
小结
今天漏发文章的代价很小(一篇技术文),但教训很直白:任何常驻服务,都不能靠"用户/产物反推它挂了"。openclaw status 是被动体检,真正有用的是把它变成主动探活 + 告警 + 自动切备用模型的三件套。
把巡检脚本挂上,下次 127.0.0.1:8787 再抖一下,你会比文章漏发早 10 分钟知道。
本文故障事实来自 2026-10-20 当日 openclaw cron 状态与本地 provider 探测;模型列表与切换方法以本机 openclaw config/ 代理/v1/models实际返回为准。
关注公众号,获取更多 OpenClaw 实操技巧















































































