OpenClaw健康检查：千问3.5-9B服务状态监控与告警
OpenClaw健康检查：千问3.5-9B服务状态监控与告警
1. 为什么需要健康检查？
上个月我的OpenClaw网关在凌晨3点突然崩溃，导致第二天早上所有自动化任务全部失效。当我手忙脚乱地排查问题时，发现千问3.5-9B模型服务已经宕机超过6小时——这个教训让我意识到，对于7*24小时运行的AI智能体，被动等待问题出现已经不够了。
健康检查的核心价值在于主动发现问题。通过定期检测网关状态、模型响应和资源占用，我们可以在用户感知到问题前就采取行动。特别是当OpenClaw对接本地部署的千问3.5-9B这类大模型时，服务稳定性直接影响自动化流程的成败。
2. 监控指标体系设计
2.1 基础监控项
经过多次实践调整，我最终确定了这三个关键指标：
- 网关响应延迟：从发送请求到收到网关ACK的时间差，超过500ms需要关注
- 模型接口可用性：千问3.5-9B的/completions端点HTTP状态码
- 资源占用率：重点关注GPU显存占用（警戒线80%）和进程CPU使用率（警戒线70%）
2.2 数据采集方式
我放弃了最初考虑的Prometheus方案——对于个人/小团队使用场景太过重量级。最终采用组合方案：
# 网关延迟检测（使用curl时间测量） curl -w "%{time_total}" -o /dev/null -s http://localhost:18789/ping # 模型可用性检测（注意替换实际API路径） STATUS_CODE=$(curl -s -o /dev/null -w "%{http_code}" \ http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen3.5-9b","prompt":"ping"}') # GPU监控（需要nvidia-smi） nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits3. 告警系统实现
3.1 检测脚本开发
我将所有检测逻辑封装成一个Python脚本health_check.py，核心结构如下：
import subprocess import requests import json def check_gateway(): try: resp = requests.get("http://localhost:18789/ping", timeout=3) return resp.elapsed.total_seconds() * 1000 # 转为毫秒 except Exception as e: return float('inf') # 超时返回无限大 def check_model(): try: resp = requests.post( "http://localhost:8000/v1/completions", json={"model": "qwen3.5-9b", "prompt": "健康检查"}, timeout=5 ) return resp.status_code except: return 503 def get_gpu_usage(): result = subprocess.run( ["nvidia-smi", "--query-gpu=memory.used,memory.total", "--format=csv,noheader,nounits"], capture_output=True, text=True ) used, total = map(int, result.stdout.strip().split(',')) return (used / total) * 1003.2 飞书机器人集成
在飞书开放平台创建自定义机器人后，配置到OpenClaw的openclaw.json：
{ "alerting": { "feishu": { "webhook": "https://open.feishu.cn/open-apis/bot/v2/hook/your_token", "at_mobiles": ["你的手机号"] } } }告警消息模板我选择了Markdown格式，突出关键指标：
def send_alert(metrics): message = { "msg_type": "interactive", "card": { "elements": [{ "tag": "markdown", "content": f"""**OpenClaw健康告警** 🔴 网关延迟：{metrics['latency']:.2f}ms 🟡 模型状态：{metrics['model_status']} 🟢 GPU使用：{metrics['gpu_usage']:.1f}% """ }] } } requests.post(webhook_url, json=message)4. 部署与调度方案
4.1 定时任务配置
在Linux系统使用crontab设置每5分钟检查一次：
*/5 * * * * /usr/bin/python3 /path/to/health_check.py >> /var/log/openclaw_health.log 2>&1对于Windows用户，可以通过任务计划程序实现相同效果。
4.2 异常处理策略
我设计了三级响应机制：
- 初级异常：记录日志并标记状态
- 中级异常：发送飞书通知
- 严重异常：自动尝试重启服务（慎用）
重启逻辑示例（仅建议在测试环境验证后使用）：
if metrics['model_status'] == 503: subprocess.run(["systemctl", "restart", "qwen-service"])5. 实践中的经验教训
5.1 误报问题优化
初期经常收到误报，后发现两个关键改进点：
- 设置连续3次检测失败才触发告警
- 对模型检查使用更复杂的探针prompt（如要求返回特定格式）
改进后的模型检查prompt：
{ "model": "qwen3.5-9b", "prompt": "请返回JSON格式：{'status': 'ok', 'timestamp': '当前时间'}" }5.2 资源监控的陷阱
曾遇到nvidia-smi显示GPU使用率正常，但实际模型推理卡死的情况。现在增加了进程级检查：
# 检查模型服务进程是否存活 pgrep -f "python.*qwen3.5-9b"6. 扩展建议
对于需要更复杂监控的场景，可以考虑：
- 将检测结果存入SQLite数据库用于趋势分析
- 增加对OpenClaw技能模块的单独检测
- 对接Grafana实现可视化看板（适合技术型用户）
这套方案在我本地环境稳定运行两个月后，服务不可用时间下降了92%。最重要的是，现在能在早上喝咖啡时通过飞书消息对系统状态一目了然，再也不用担心突发故障影响自动化流程了。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。