Clawdbot Web Chat平台保姆级教程：Qwen3-32B模型服务健康检查自动化脚本-开发者社区

Clawdbot Web Chat平台保姆级教程：Qwen3-32B模型服务健康检查自动化脚本

1. 为什么需要健康检查脚本

你刚部署好Clawdbot Web Chat平台，页面能打开，输入框也能响应，但心里总有点不踏实——模型服务真的稳定吗？API接口会不会在半夜悄悄掉线？Ollama进程有没有被系统自动杀掉？代理转发链路是否始终通畅？

这不是多虑。真实场景中，Qwen3-32B这类大模型服务对资源敏感、启动耗时长、依赖链路长（Ollama → 内部代理 → 8080端口 → 18789网关 → Clawdbot前端），任何一个环节出问题，用户看到的就只是“正在思考…”的无限转圈。

这篇教程不讲怎么安装Ollama，也不重复配置代理规则——这些你已经做完了。我们直奔最实用的一环：用一个不到50行的Python脚本，自动检测整个服务链路的健康状态，并在异常时发通知、记录日志、甚至尝试重启。它不是花架子，而是你上线后真正会每天运行、每周查看、故障时第一个跳出来的“守夜人”。

你不需要是运维专家，只要会复制粘贴、改两处地址、装一个requests库，就能拥有这套能力。接下来，我们就从零开始，把它搭起来。

2. 理解你的服务架构：三步链路不能少

在写脚本前，先确认你环境里的三个关键节点——它们就是脚本要逐一叩门的对象：

2.1 第一关：Ollama本地API是否活着？

这是最底层。Qwen3-32B由Ollama加载，对外提供http://localhost:11434/api/chat接口。脚本第一步就是向这里发一个极轻量的请求：

curl -X POST http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{"model":"qwen3:32b","messages":[{"role":"user","content":"hi"}],"stream":false}'

如果返回HTTP 200且包含"done": true，说明Ollama进程在跑、模型已加载、基础推理通路正常。

2.2 第二关：内部代理是否转发成功？

Clawdbot不直接连Ollama，而是通过你配置的内部代理，把请求从8080端口转发到11434。脚本第二步要验证这个“中间人”：

访问http://localhost:8080/health（或你自定义的代理健康端点）
或者更直接：模拟Clawdbot的请求路径，向http://localhost:8080/v1/chat/completions发一个测试请求（注意：这是代理暴露给前端的路径，不是Ollama原生路径）

如果这一步失败，问题出在Nginx/Apache/Caddy等代理配置，或端口被占用、防火墙拦截。

2.3 第三关：Clawdbot网关是否可达？

最后是面向用户的出口——18789网关端口。Clawdbot前端通过这个端口与后端通信。脚本第三步检查：

http://localhost:18789/api/health（如果网关提供了健康接口）
或者检查网关进程是否监听该端口：lsof -i :18789或netstat -tuln | grep 18789

三者全通，才是真正的“服务健康”。缺一不可。脚本的设计逻辑，就是按这个顺序逐层探测，任一环节失败即标记为异常。

3. 健康检查脚本：可运行、可定制、可告警

下面是一份经过实测的Python脚本，命名为check_qwen3_health.py。它没有复杂依赖，只用标准库和requests，5分钟就能跑起来。

3.1 安装依赖（仅需一次）

pip install requests

注意：如果你的服务器无法访问公网，可提前下载requestswheel包离线安装，不影响脚本功能。

3.2 脚本完整代码（含详细注释）

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ Clawdbot + Qwen3-32B 服务健康检查脚本 功能：依次检测 Ollama API → 代理服务 → Clawdbot网关 三层状态 作者：一线运维实践整理 """ import requests import time import logging import subprocess import sys from datetime import datetime # ==================== 配置区（你只需改这里） ==================== OLLAMA_URL = "http://localhost:11434/api/chat" PROXY_URL = "http://localhost:8080/v1/chat/completions" # 代理暴露给前端的路径 GATEWAY_URL = "http://localhost:18789/api/health" # Clawdbot网关健康端点 TIMEOUT = 10 # 所有请求超时设为10秒 LOG_FILE = "/var/log/qwen3_health.log" # 日志配置 logging.basicConfig( level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s", handlers=[ logging.FileHandler(LOG_FILE, encoding="utf-8"), logging.StreamHandler(sys.stdout) ] ) logger = logging.getLogger(__name__) def check_ollama(): """检查Ollama服务：发送最小化chat请求""" try: payload = { "model": "qwen3:32b", "messages": [{"role": "user", "content": "health check"}], "stream": False } resp = requests.post(OLLAMA_URL, json=payload, timeout=TIMEOUT) if resp.status_code == 200: data = resp.json() if data.get("done", False): logger.info(" Ollama服务正常：模型加载完成，可响应请求") return True logger.error(f"❌ Ollama返回非预期状态：{resp.status_code} | {resp.text[:100]}") except Exception as e: logger.error(f"❌ Ollama连接失败：{str(e)}") return False def check_proxy(): """检查代理服务：模拟前端请求""" try: # 构造一个极简的OpenAI兼容格式请求（Clawdbot前端实际发送的格式） payload = { "model": "qwen3-32b", "messages": [{"role": "user", "content": "ping"}], "temperature": 0.1 } resp = requests.post(PROXY_URL, json=payload, timeout=TIMEOUT) if resp.status_code in [200, 201]: logger.info(" 代理服务正常：请求可成功转发至Ollama") return True logger.error(f"❌ 代理返回错误码：{resp.status_code}") except Exception as e: logger.error(f"❌ 代理连接失败：{str(e)}") return False def check_gateway(): """检查Clawdbot网关端口是否监听""" try: # 直接检查端口是否被监听（比发HTTP请求更底层、更可靠） result = subprocess.run( ["lsof", "-i", ":18789"], capture_output=True, text=True, timeout=5 ) if result.returncode == 0 and "LISTEN" in result.stdout: logger.info(" Clawdbot网关正常：18789端口正在监听") return True else: logger.error("❌ Clawdbot网关异常：18789端口未监听") except subprocess.TimeoutExpired: logger.error("❌ 检查网关端口超时") except Exception as e: logger.error(f"❌ 检查网关端口失败：{str(e)}") return False def main(): logger.info(" 开始执行Qwen3-32B服务健康检查...") checks = [ ("Ollama API", check_ollama), ("代理服务", check_proxy), ("Clawdbot网关", check_gateway) ] failed = [] for name, func in checks: if not func(): failed.append(name) if failed: logger.error(f"🚨 健康检查失败：{'、'.join(failed)} 不可用") # 这里可以扩展：发邮件、写数据库、触发重启... # 示例：记录到告警文件 with open("/tmp/qwen3_alert.flag", "w") as f: f.write(f"{datetime.now()} - Failed: {', '.join(failed)}\n") else: logger.info(" 全部检查通过！Qwen3-32B服务链路健康") if __name__ == "__main__": main()

3.3 如何运行与验证

保存脚本后，赋予执行权限并首次运行：

chmod +x check_qwen3_health.py python3 check_qwen3_health.py

你会看到类似输出：

2024-06-15 10:22:33,456 [INFO] 开始执行Qwen3-32B服务健康检查... 2024-06-15 10:22:34,122 [INFO] Ollama服务正常：模型加载完成，可响应请求 2024-06-15 10:22:34,891 [INFO] 代理服务正常：请求可成功转发至Ollama 2024-06-15 10:22:35,003 [INFO] Clawdbot网关正常：18789端口正在监听 2024-06-15 10:22:35,004 [INFO] 全部检查通过！Qwen3-32B服务链路健康

日志同时写入/var/log/qwen3_health.log，方便后续排查。

4. 进阶用法：让脚本真正“活”起来

脚本本身只是工具，让它发挥价值，关键在如何集成进你的日常运维流程。

4.1 每5分钟自动检查（Linux cron）

编辑crontab：

crontab -e

添加一行：

*/5 * * * * /usr/bin/python3 /opt/clawdbot/scripts/check_qwen3_health.py >> /dev/null 2>&1

这样，每5分钟系统自动运行一次，异常时日志里会有明确记录。

4.2 异常时自动重启Ollama（谨慎使用）

如果你确认Ollama是唯一不稳定环节，可在check_ollama()失败后加入重启逻辑（放在脚本末尾main()函数内）：

# 在 check_ollama() 返回 False 后添加： logger.warning(" 尝试重启Ollama服务...") try: subprocess.run(["ollama", "serve"], timeout=30, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL) time.sleep(5) # 等待启动 # 再次调用 check_ollama() 验证 except Exception as e: logger.error(f" 重启Ollama失败：{e}")

提示：重启操作请先在测试环境验证，避免影响线上推理任务。

4.3 对接企业微信/钉钉告警（一行代码）

将告警消息推送到团队群，只需在failed分支中加入：

if failed: # 企业微信机器人Webhook（替换为你自己的URL） webhook = "https://qyapi.weixin.qq.com/xxx" requests.post(webhook, json={ "msgtype": "text", "text": {"content": f"【Clawdbot告警】Qwen3-32B服务异常：{', '.join(failed)}"} })

无需额外SDK，标准requests即可完成。

5. 常见问题与排查指南

即使脚本跑起来了，你也可能遇到一些典型问题。以下是高频场景及速查方案：

5.1 脚本报“Connection refused”，但网页能访问？

原因：脚本用localhost，而你的代理或网关可能只监听127.0.0.1或特定IP。
解决：检查代理配置中listen地址，确保包含0.0.0.0:8080；或把脚本中的localhost改为实际监听IP（如192.168.1.100）。

5.2 Ollama检查通过，但代理失败？

说明Ollama本身OK，但代理没正确转发到它。
快速验证：手动用curl走一遍代理链路

curl -X POST http://localhost:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen3-32b","messages":[{"role":"user","content":"test"}]}'

如果返回502 Bad Gateway，就是代理配置问题；返回404，说明代理没把路径映射对。

5.3 网关检查总失败，但Clawdbot页面能用？

因为18789端口是Clawdbot后端服务端口，它不一定提供/api/health接口。
替代方案：改用端口监听检查（脚本中已默认采用），或确认Clawdbot文档是否开放了健康检查路径。

5.4 日志里全是“Timeout”，但服务明明很快？

可能是TIMEOUT = 10设得太小。Qwen3-32B首次响应可能达8秒（尤其冷启动）。
建议：将TIMEOUT提高到15或20，再观察。

6. 总结：健康检查不是锦上添花，而是上线必选项

这篇教程带你完成的，不是一个“玩具脚本”，而是一套可立即投入生产的轻量级监控方案。它不依赖Prometheus、不配置Grafana、不学习新语法——用最朴素的HTTP请求和系统命令，守住Qwen3-32B服务的生命线。

你收获的不仅是代码，更是思路：

分层检测：不假设“全通”或“全断”，每一层独立验证；
最小侵入：不修改Ollama、不改动Clawdbot源码，纯外部观测；
结果可读：日志带时间戳、emoji状态标识、失败定位到具体环节；
扩展自由：告警渠道、重启策略、检查频率，全部由你掌控。

下一步，你可以把它加入CI/CD流水线，在每次模型更新后自动校验；也可以封装成Docker镜像，随服务一起部署。但最紧要的，是今天就把脚本跑起来，看一眼你的服务链路，是否真的坚如磐石。

获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

Clawdbot Web Chat平台保姆级教程：Qwen3-32B模型服务健康检查自动化脚本