夜雨聆风学习资料网

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 探活步骤,不通就立刻告警(而不是只检查文章在不在)。

逻辑应该是这样:

  1. 先探 127.0.0.1:8787 端口
  1. 再探一个真实模型调用
  1. 任一不通 → 记 provider_down 告警 + 尝试切备用模型
  1. 都通 → 才进入"今天文章在不在"的内容闸

今天漏发的根因就是第 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 实操技巧

相关学习资料