Clawdbot直连Qwen3-32B教程：Prometheus指标暴露与Grafana监控看板搭建
1. 为什么需要监控大模型服务
你刚把Clawdbot和Qwen3-32B跑起来了，界面能打开、对话也通了——但接下来呢？
当用户开始频繁提问，模型响应变慢、GPU显存悄悄飙到98%、某次请求卡住30秒没返回……这些情况不会自动告诉你。没有监控，就像开着一辆没仪表盘的车，油量、水温、转速全靠猜。
这正是本教程要解决的问题：不只教你“怎么让模型跑起来”，更关键的是“怎么知道它跑得稳不稳、快不快、健不健康”。
我们会在Clawdbot直连Qwen3-32B的完整链路上，埋入可观测性能力——通过Prometheus自动采集API调用次数、响应延迟、错误率、GPU显存占用等真实指标，并用Grafana搭出一目了然的监控看板。所有操作基于标准开源组件，无需修改模型代码，也不依赖云厂商黑盒服务。
整个过程你只需要一台能跑Docker的机器，30分钟内就能拥有属于自己的大模型服务健康仪表盘。
2. 架构概览：从请求入口到监控大盘
2.1 当前服务链路还原
根据你提供的部署说明，当前Clawdbot与Qwen3-32B的通信路径是这样的：
用户浏览器 → Clawdbot Web前端（HTTP） ↓ Clawdbot后端服务（Python/Node.js） ↓ 内部代理（端口转发）→ 8080 → 18789网关 ↓ Ollama服务（托管Qwen3-32B） ↓ GPU推理层（CUDA + llama.cpp或vLLM）关键点在于：Clawdbot本身不直接暴露指标，Ollama默认也不提供Prometheus格式的metrics端点。所以我们要在“代理层”和“Ollama层”两个位置做轻量级增强，让指标自然流出。
2.2 监控架构设计原则
我们不引入复杂中间件，而是采用“最小侵入+最大复用”策略：
- 代理层加装指标中间件：在8080→18789的转发代理中嵌入Prometheus exporter，自动记录每次转发的耗时、状态码、请求大小
- Ollama侧启用原生指标：新版Ollama（v0.4.0+）已支持
/metrics端点，只需开启OLLAMA_PROMETHEUS=1环境变量 - Clawdbot日志结构化：将关键业务日志（如会话ID、模型名、token数）输出为JSON格式，供Logstash或Promtail采集
- ❌ 不修改Qwen3-32B模型权重或推理逻辑
- ❌ 不替换现有Web网关（Nginx/Apache），仅在其上游或下游插入指标探针
最终数据流向清晰简洁：代理指标 + Ollama原生指标 + 结构化日志→Prometheus Server拉取→Grafana可视化展示
3. 实操步骤：四步完成监控体系搭建
3.1 步骤一：为代理层注入Prometheus指标能力
你当前使用的是端口转发代理（8080→18789）。无论它是Nginx、Caddy还是自研Go代理，我们统一推荐一个零配置、开箱即用的方案：promhttp-proxy
它是一个轻量级HTTP代理，内置Prometheus指标收集器，支持记录：
http_request_duration_seconds（按路径、状态码、方法分组）http_requests_total（成功/失败请求数）http_response_size_bytes（响应体大小分布）
部署方式（Docker Compose）
# docker-compose.monitor.yml version: '3.8' services: promhttp-proxy: image: ghcr.io/rook76/promhttp-proxy:latest ports: - "8080:8080" environment: - UPSTREAM_URL=http://host.docker.internal:18789 - METRICS_PORT=9090 - ENABLE_ACCESS_LOG=true networks: - clawdbot-net注意：
host.docker.internal是Docker Desktop默认提供的宿主机别名；若在Linux服务器上运行，请改用宿主机真实IP，或添加--add-host=host.docker.internal:host-gateway
启动后，访问http://localhost:9090/metrics即可看到类似以下指标：
# HELP http_request_duration_seconds HTTP request duration in seconds # TYPE http_request_duration_seconds histogram http_request_duration_seconds_bucket{le="0.1",method="POST",path="/api/chat",status_code="200"} 124 http_request_duration_seconds_bucket{le="0.2",method="POST",path="/api/chat",status_code="200"} 138 ...此时，你的代理不再只是“管道”，而成了第一道可观测性入口。
3.2 步骤二：启用Ollama的Prometheus原生指标
Ollama v0.4.0起已原生支持Prometheus metrics。你只需确保启动Ollama时设置了环境变量：
# 停止原有Ollama服务 systemctl stop ollama # 启动带指标支持的Ollama OLLAMA_PROMETHEUS=1 OLLAMA_HOST=0.0.0.0:18789 ollama serve或使用systemd配置（/etc/systemd/system/ollama.service）：
[Service] Environment="OLLAMA_PROMETHEUS=1" Environment="OLLAMA_HOST=0.0.0.0:18789" ExecStart=/usr/bin/ollama serve然后重载并启动：
sudo systemctl daemon-reload sudo systemctl start ollama验证是否生效：
curl http://localhost:18789/metrics | head -20你会看到类似：
# HELP ollama_gpu_memory_bytes GPU memory usage in bytes # TYPE ollama_gpu_memory_bytes gauge ollama_gpu_memory_bytes{device="nvidia0",model="qwen3:32b"} 12457890200 # HELP ollama_inference_duration_seconds Inference duration in seconds # TYPE ollama_inference_duration_seconds histogram这些指标直接来自Ollama底层，包含GPU显存、KV缓存命中率、推理延迟等硬核数据，无需额外开发。
3.3 步骤三：配置Prometheus抓取目标
创建Prometheus配置文件prometheus.yml：
global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'clawdbot-proxy' static_configs: - targets: ['promhttp-proxy:9090'] metrics_path: '/metrics' - job_name: 'ollama' static_configs: - targets: ['host.docker.internal:18789'] metrics_path: '/metrics' - job_name: 'clawdbot-app' static_configs: - targets: ['clawdbot:8000'] # 假设Clawdbot暴露/metrics端点 metrics_path: '/metrics'小技巧：如果你的Clawdbot应用尚未暴露指标端点，可先跳过第三项；后续可通过Python的
prometheus_client库在Flask/FastAPI中快速添加（2行代码即可）。
启动Prometheus：
docker run -d \ --name prometheus \ -p 9090:9090 \ -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \ -v $(pwd)/data:/prometheus \ --network clawdbot-net \ prom/prometheus稍等30秒，打开http://localhost:9090/targets，确认三个job状态均为UP。
3.4 步骤四：用Grafana搭建专属看板
启动Grafana（Docker）
docker run -d \ --name grafana \ -p 3000:3000 \ --network clawdbot-net \ -v $(pwd)/grafana-storage:/var/lib/grafana \ grafana/grafana-enterprise配置数据源
- 访问
http://localhost:3000（默认账号 admin/admin，首次登录需改密） - 「Connections」→「Data sources」→「Add data source」→ 选择 Prometheus
- URL填
http://prometheus:9090（注意：这是容器内网络地址，不是localhost） - 保存并测试（Test按钮应显示 Data source is working）
导入预置看板（推荐）
我们为你准备了一个专为Clawdbot+Qwen3-32B优化的Grafana看板JSON（含GPU负载、API成功率、Token吞吐、会话延迟四大核心视图），可直接导入：
- 下载地址：clawdbot-qwen3-monitor-dashboard.json（示例链接，实际使用时请替换为真实托管地址）
- 在Grafana中：「+」→「Import」→ 粘贴JSON或上传文件 → 选择刚配置的Prometheus数据源 → Import
导入后，你将看到如下核心视图：
| 视图模块 | 关键指标说明 |
|---|---|
| 全局健康概览 | API成功率（2xx/4xx/5xx占比）、平均P95延迟、QPS实时曲线 |
| GPU资源透视 | ollama_gpu_memory_bytes（显存占用）、ollama_gpu_utilization（GPU利用率）、温度（如有NVML支持） |
| 会话深度分析 | 每次请求的input_tokens / output_tokens分布、长上下文会话占比（>4k tokens） |
| 模型性能对比 | Qwen3-32B vs 其他已加载模型（如qwen2:7b）的平均延迟与错误率对比（需多模型共存场景） |
提示：所有图表均支持下钻——点击任意时间点，可联动查看该时刻的原始日志（需配合Loki部署）或具体请求trace（需Jaeger集成，本教程暂不展开）。
4. 关键问题排查与调优建议
4.1 常见问题速查表
| 现象 | 可能原因 | 快速验证命令 | 解决方向 |
|---|---|---|---|
| Prometheus中看不到ollama指标 | Ollama未启用OLLAMA_PROMETHEUS=1 | curl http://localhost:18789/metrics | head -5 | 检查Ollama启动参数，重启服务 |
clawdbot-proxytarget显示DOWN | promhttp-proxy无法连接18789端口 | docker exec -it promhttp-proxy curl -v http://host.docker.internal:18789/health | 检查网络连通性、Ollama是否监听0.0.0.0 |
| Grafana图表为空但targets正常 | 查询语句错误或无数据 | 在Explore中输入count(http_requests_total)查看是否有计数 | 检查时间范围、指标名称拼写、label过滤条件 |
| GPU显存指标始终为0 | Ollama未检测到NVIDIA驱动 | docker exec -it ollama nvidia-smi -L | 确保Docker运行时启用--gpus all |
4.2 面向生产环境的三项加固建议
指标采样降频，避免性能扰动
Qwen3-32B单次推理耗时较长（尤其长文本），高频打点可能增加延迟。建议在promhttp-proxy中设置-SAMPLE_RATE=0.1（仅采集10%请求），或对/api/chat路径单独限流采样。为关键指标设置告警阈值
在Prometheus中添加如下告警规则（alerts.yml）：groups: - name: clawdbot-alerts rules: - alert: Qwen3HighLatency expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{path="/api/chat"}[5m])) by (le)) > 15 for: 2m labels: severity: warning annotations: summary: "Qwen3-32B P95延迟超过15秒"再通过Alertmanager对接企业微信/钉钉，实现故障主动触达。
日志与指标关联分析（进阶）
若你使用结构化日志（如Clawdbot输出JSON日志），可用Promtail + Loki + Grafana实现“点击延迟高峰 → 查看对应时间段原始请求日志 → 定位具体prompt内容”。这对分析bad case（如崩溃、幻觉）极为高效。
5. 总结：让大模型服务真正“可运维”
回看整个过程，你并没有改动一行Qwen3-32B的模型代码，也没有重写Clawdbot的业务逻辑。
只是在代理层加了一个轻量代理、在Ollama启动时加了一个环境变量、再配好Prometheus和Grafana——就完成了从“能用”到“可控、可管、可优化”的跃迁。
这套方案的价值不止于监控本身：
- 问题定位从小时级缩短至秒级：延迟突增？立刻看GPU利用率曲线，而非翻几十页日志
- 资源投入有据可依：显存长期低于60%？说明当前GPU规格过剩，可降配节省成本
- 用户体验可量化：P95延迟从8秒降到3秒，用户对话中断率下降42%——这才是技术落地的真实声音
更重要的是，这套模式可无缝复制到其他大模型服务：只要它走HTTP协议、有可暴露的metrics端点，就能被纳入同一套监控体系。你构建的不是某个模型的看板，而是一套面向AI时代的基础设施观测范式。
下一步，你可以尝试：
→ 为Clawdbot添加/metrics端点，统计每类prompt的调用频次
→ 将Grafana看板嵌入内部运营后台，让产品同学也能实时查看模型健康度
→ 用Prometheus指标训练一个轻量预测模型，提前预警GPU显存溢出风险
真正的AI工程化，始于每一次对系统健康的认真凝视。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
