OpenClaw健康检查：Qwen3.5-9B服务监控与自动重启配置

OpenClaw健康检查Qwen3.5-9B服务监控与自动重启配置1. 问题背景与解决思路上周我的OpenClaw网关服务突然挂掉导致凌晨的自动化任务全部失败。排查日志发现是Qwen3.5-9B模型服务响应超时触发了连锁故障。这种问题在长期运行的AI智能体场景中很常见——模型服务可能因为显存泄漏、请求堆积或网络波动变得不稳定。经过多次实践我总结出一套可靠的监控方案通过shell脚本定期检测服务状态结合超时阈值控制和自动恢复机制最终实现7x24小时稳定运行。下面分享具体实现过程包含几个关键设计决策轻量级检测避免复杂监控系统用curl和ps命令实现基础检查分级响应区分临时抖动和持续故障防止频繁重启安全边界设置最大重试次数避免无限循环吃满资源2. 服务健康检查脚本开发2.1 基础检测逻辑创建health_check.sh脚本实现三个核心检查项#!/bin/bash # 配置区域 GATEWAY_URLhttp://127.0.0.1:18789/status MODEL_ENDPOINThttp://localhost:11434/api/generate TIMEOUT_SEC15 # 模型响应超时阈值 # 检查1网关进程是否存在 if ! pgrep -f openclaw gateway /dev/null; then echo [ERROR] Gateway process not found exit 1 fi # 检查2网关HTTP接口可达性 gateway_status$(curl -s -o /dev/null -w %{http_code} $GATEWAY_URL) if [ $gateway_status -ne 200 ]; then echo [ERROR] Gateway returned $gateway_status exit 2 fi # 检查3模型服务响应延迟 start_time$(date %s%3N) curl -s -X POST $MODEL_ENDPOINT \ -H Content-Type: application/json \ -d {prompt:test} /dev/null end_time$(date %s%3N) latency$((end_time - start_time)) if [ $latency -gt $((TIMEOUT_SEC * 1000)) ]; then echo [WARN] Model response latency ${latency}ms exceeds threshold exit 3 fi echo [INFO] All checks passed exit 0关键参数说明TIMEOUT_SEC根据Qwen3.5-9B的实际性能调整我的32G显存GPU设15秒模型测试请求使用最小负载避免检测本身引发压力2.2 超时阈值优化经验初期直接使用默认超时设置导致频繁误报。通过统计历史数据发现冷启动延迟首次请求需要额外2-3秒加载模型长文本波动处理超过2048token的输入时延迟可能翻倍显存影响连续运行6小时后平均延迟增长15%最终采用分级阈值策略# 根据运行时间动态调整阈值 uptime_hours$(ps -o etimes -p $(pgrep -f qwen)) if [ $uptime_hours -gt 6 ]; then TIMEOUT_SEC20 # 运行6小时后放宽阈值 fi3. 自动恢复机制实现3.1 进程守护脚本创建service_watcher.sh处理异常情况#!/bin/bash MAX_RETRIES3 RETRY_DELAY10 function restart_services() { # 先停后启保证干净状态 openclaw gateway stop pkill -f qwen # 启动顺序很重要 nohup python -m qwen.serve qwen.log 21 sleep 5 # 等待模型加载 openclaw gateway start } retry_count0 while [ $retry_count -lt $MAX_RETRIES ]; do ./health_check.sh case $? in 0) retry_count0 sleep 60 # 正常状态检查间隔 ;; 1|2) echo [CRITICAL] Gateway failure detected restart_services ((retry_count)) ;; 3) if [ $retry_count -eq 0 ]; then echo [WARNING] Model latency warning sleep 30 # 首次超时等待自恢复 else restart_services fi ((retry_count)) ;; esac done # 超过重试次数后发送告警 echo [EMERGENCY] Service unavailable after $MAX_RETRIES retries | mail -s OpenClaw Alert adminexample.com3.2 告警集成方案除了邮件告警还可以对接飞书机器人function send_feishu_alert() { local message$1 curl -X POST https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_TOKEN \ -H Content-Type: application/json \ -d { msg_type: text, content: { text: $message } } }建议在告警信息中包含故障类型网关/模型最后已知状态码最近5分钟的平均延迟相关日志片段4. 部署与优化建议4.1 系统层配置日志轮转防止日志文件撑爆磁盘# /etc/logrotate.d/openclaw /var/log/openclaw/*.log { daily rotate 7 compress missingok notifempty }资源隔离限制模型服务内存用量# 启动时添加cgroup限制 systemd-run --slicemodel.slice --propertyMemoryHigh32G python -m qwen.serve4.2 监控看板搭建用netdata实现可视化监控需额外安装# 监控指标示例 echo CHART openclaw.latency 模型响应延迟 ms Qwen 延迟 line echo DIMENSION latency Latency absolute 1 1000 echo BEGIN openclaw.latency echo SET latency $(grep Model latency /var/log/openclaw.log | tail -1 | awk {print $5}) echo END5. 典型问题排查记录5.1 误重启问题现象凌晨总是触发重启但白天正常排查发现crontab里有个备份任务占满IOPS解决添加IO延迟检测逻辑iowait$(top -bn1 | grep Cpu(s) | sed s/.*, *\([0-9.]*\)%id.*/\1/ | awk {print 100 - $1}) if [ $(echo $iowait 70 | bc) -eq 1 ]; then echo [INFO] High IO wait, skipping check exit 0 fi5.2 模型加载失败现象重启后模型服务报CUDA错误原因显存未完全释放修复方案function force_cleanup() { # 确保所有GPU进程终止 nvidia-smi | grep python | awk {print $3} | xargs -r kill -9 # 清理残留锁文件 rm -f /tmp/qwen_lock* }这套方案在我的开发环境稳定运行两个月将非计划停机时间减少了90%。最关键的是把握住三个平衡点检测频率与系统负载的平衡、敏感度与误报的平衡、自动化与人工干预的平衡。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。