当前位置：首页 > news >正文

Clawdbot部署Qwen3:32B的监控大盘搭建：Prometheus+Grafana指标可视化

news 2026/7/1 2:32:18

Clawdbot部署Qwen3:32B的监控大盘搭建：Prometheus+Grafana指标可视化

1. 为什么需要监控Qwen3:32B服务

你刚把Qwen3:32B跑起来，Clawdbot也连上了，聊天界面看着挺顺——但心里是不是总悬着点事儿？比如：模型响应突然变慢，用户开始抱怨；某次批量请求后GPU显存直接飙到98%，接着就OOM崩溃；或者凌晨三点收到告警，发现服务已经挂了两小时没人发现。

这些都不是假设。Qwen3:32B这类32B参数量的大模型，对资源消耗非常敏感：一次推理可能吃掉16GB显存，高并发下CPU负载翻倍，API延迟从300ms跳到2.5秒……而Clawdbot作为前端代理，只管转发请求，不告诉你背后发生了什么。

这时候，光靠docker logs和nvidia-smi手动查，就像用放大镜找火情——太晚、太慢、太被动。真正需要的是一套能实时看见“模型心跳”的监控系统：它得知道每秒处理多少请求、平均耗时多少、失败率有没有异常、GPU用了几成、内存有没有缓慢泄漏……这些数据不是给运维看的，是给整个AI服务团队用的决策依据。

我们这次不讲虚的，直接带你从零搭起一套轻量但完整的监控大盘：用Prometheus采集Qwen3:32B和Clawdbot的真实运行指标，用Grafana做出能一眼看懂的可视化面板——所有操作都在本地完成，不依赖云服务，不改一行模型代码，30分钟内上线。

2. 环境准备与核心组件定位

2.1 明确各角色职责（别搞混谁该监控谁）

先理清三个关键组件的关系，这是后续配置不出错的前提：

Qwen3:32B：由Ollama托管的本地大模型服务，监听在http://localhost:11434（Ollama默认端口），提供/api/chat等标准接口
Clawdbot：你的Web网关层，接收用户HTTP请求，再代理转发给Ollama；它本身运行在http://localhost:8080，但对外暴露的是18789端口（通过内部代理映射）
监控系统：不碰模型也不改网关，只做一件事——安静地“看”它们怎么工作，并把看到的数据存起来、画出来

关键提醒：Ollama原生不暴露详细指标（如token生成速度、KV缓存命中率），所以我们不强求它“自报家门”。转而聚焦两个可落地的监控面：
Clawdbot的HTTP层指标（请求量、延迟、错误码）——它就在你手里，加几行代码就能暴露
宿主机资源指标（GPU显存、CPU、内存、磁盘IO）——用现成的exporter就能抓，真实反映模型负载

2.2 快速部署所需工具（5分钟搞定）

所有组件均采用Docker一键拉起，无需全局安装：

# 创建监控专用目录 mkdir -p ~/clawdbot-monitor && cd ~/clawdbot-monitor # 下载预配置文件（已适配Qwen3:32B场景） curl -O https://raw.githubusercontent.com/csdn-mirror/prometheus-clawdbot/main/docker-compose.yml curl -O https://raw.githubusercontent.com/csdn-mirror/prometheus-clawdbot/main/prometheus.yml curl -O https://raw.githubusercontent.com/csdn-mirror/prometheus-clawdbot/main/grafana-dashboards/qwen3-32b-dashboard.json

这些配置文件已为你做好三件事：
docker-compose.yml：同时启动Prometheus、Grafana、Node Exporter（主机指标）、NVIDIA DCGM Exporter（GPU指标）
prometheus.yml：自动抓取Clawdbot暴露的/metrics端点 + 主机/GPU指标
qwen3-32b-dashboard.json：开箱即用的Grafana面板，专为Qwen3:32B优化

执行启动命令：

docker compose up -d

等待30秒，访问http://localhost:9090（Prometheus）和http://localhost:3000（Grafana，默认账号admin/admin），确认服务正常。

3. 让Clawdbot主动“说话”：暴露HTTP指标

Clawdbot本身不带监控能力，但它的代码你可控。我们只需在它的HTTP服务中注入一个轻量指标中间件——不改业务逻辑，只加10行代码。

3.1 修改Clawdbot服务入口（以Go为例，其他语言同理）

找到Clawdbot的主服务文件（通常是main.go或server.go），在HTTP路由初始化后、http.ListenAndServe前插入以下代码：

// 引入promhttp包（go get github.com/prometheus/client_golang/prometheus/promhttp） http.Handle("/metrics", promhttp.Handler()) // 启动指标收集器（放在main函数开头） prometheus.MustRegister( prometheus.NewCounterVec( prometheus.CounterOpts{ Name: "clawdbot_http_requests_total", Help: "Total HTTP Requests to Clawdbot", }, []string{"method", "endpoint", "status_code"}, ), prometheus.NewHistogramVec( prometheus.HistogramOpts{ Name: "clawdbot_http_request_duration_seconds", Help: "HTTP Request Duration in seconds", Buckets: prometheus.DefBuckets, }, []string{"method", "endpoint"}, ), )

3.2 在请求处理链中埋点（关键！）

在Clawdbot处理每个请求的handler里（比如/chat路由），添加计时和状态统计：

func chatHandler(w http.ResponseWriter, r *http.Request) { start := time.Now() // 原有业务逻辑：转发请求给Ollama http://localhost:11434/api/chat resp, err := http.DefaultClient.Do(r.Clone(r.Context())) // 记录指标 status := strconv.Itoa(resp.StatusCode) if err != nil { status = "500" } metrics.HttpRequestsTotal.WithLabelValues(r.Method, "/chat", status).Inc() metrics.HttpRequestDuration.WithLabelValues(r.Method, "/chat").Observe(time.Since(start).Seconds()) // 原有响应逻辑... io.Copy(w, resp.Body) }

效果验证：重启Clawdbot后，访问http://localhost:8080/metrics，你会看到类似这样的输出：
clawdbot_http_requests_total{method="POST",endpoint="/chat",status_code="200"} 42
clawdbot_http_request_duration_seconds_sum{method="POST",endpoint="/chat"} 12.37

这说明Clawdbot已开始“说话”，Prometheus马上就能听见。

4. 监控大盘实战：Grafana面板详解

启动Grafana后，导入我们准备好的qwen3-32b-dashboard.json面板（Configuration → Dashboards → Import → 上传JSON文件）。下面重点解读四个最实用的视图：

4.1 【核心看板】Qwen3:32B服务健康度总览

实时请求速率（RPS）：折线图显示过去5分钟每秒请求数。正常波动范围：1~8 QPS（取决于你的GPU型号）。若持续低于1，说明流量没打进来；若突增至15+并伴随延迟飙升，大概率是显存瓶颈。
P95延迟热力图：横轴时间、纵轴延迟区间（100ms~5s），颜色越深代表该延迟段请求数越多。理想状态是90%请求落在300~800ms区间（A10/A100实测值）。若大量请求堆积在2s+区域，立刻检查Ollama日志是否有CUDA out of memory。
错误率趋势：监控5xx错误占比。Qwen3:32B常见错误：503 Service Unavailable（Ollama队列满）、504 Gateway Timeout（Clawdbot等Ollama超时）。阈值设为>1%即告警。

4.2 【资源透视】GPU与内存使用率联动分析

这个面板解决一个关键问题：到底是模型卡了，还是机器扛不住了？

左侧双Y轴图表：蓝色线为DCGM_FI_DEV_GPU_UTIL（GPU利用率），红色线为DCGM_FI_DEV_MEM_USED（显存已用GB）。
右侧散点图：X轴GPU利用率，Y轴显存占用，每个点代表一个采样时刻。
实用技巧：当GPU利用率<30%但显存占用>90%，说明模型在等数据（IO瓶颈）；当两者都>95%，就是真正的算力饱和——该考虑加卡或降并发了。

4.3 【请求追踪】单次Chat请求全链路耗时分解

点击面板右上角“+ Add query”，输入以下PromQL，查看一次典型请求的耗时构成：

histogram_quantile(0.95, sum(rate(clawdbot_http_request_duration_seconds_bucket[5m])) by (le, job))

结果会显示：

clawdbot_http_request_duration_seconds：Clawdbot自身处理耗时（通常<50ms）
ollama_api_latency_seconds：Ollama处理耗时（即Qwen3:32B实际推理时间，占总耗时90%以上）
两者差值 ≈ 网络传输+序列化开销（应<100ms）

发现问题？比如Ollama耗时稳定在1.2s，但Clawdbot上报总耗时2.8s——那1.6s去哪了？立刻检查Clawdbot到Ollama的网络延迟（ping localhost）和HTTP客户端超时设置。

4.4 【容量预警】显存泄漏检测（防半夜崩盘）

Qwen3:32B长时间运行可能出现显存缓慢增长（尤其在batch_size>1时）。我们用这条PromQL捕捉异常：

avg_over_time(DCGM_FI_DEV_MEM_USED[24h]) - min_over_time(DCGM_FI_DEV_MEM_USED[24h])

若24小时内显存基线增长 > 1.5GB，触发黄色预警（可能有未释放的tensor）
若增长 > 3GB，触发红色告警（建议立即重启Ollama服务）

面板已内置该告警规则，你只需在Grafana Alerting中启用即可。

5. 常见问题与避坑指南

5.1 Prometheus抓不到Clawdbot指标？三步排查

确认端口可达：在宿主机执行curl http://localhost:8080/metrics，必须返回指标文本。若超时，检查Clawdbot是否监听0.0.0.0:8080（而非127.0.0.1:8080）
检查Prometheus配置：打开http://localhost:9090/targets，确认clawdbot目标状态为UP。若为DOWN，查看Labels里的instance地址是否正确（应为宿主机IP，非localhost）
验证指标名称：在Prometheus Graph界面输入clawdbot_http_requests_total，点Execute。无数据？说明Clawdbot代码中的MustRegister未生效，重启服务再试。

5.2 GPU指标显示为0？NVIDIA DCGM配置要点

确保宿主机已安装NVIDIA驱动（>=515）和nvidia-docker2
Docker启动时必须添加--gpus all参数（docker-compose.yml中已配置）
检查DCGM Exporter容器日志：docker logs grafana-dcgm-exporter，出现Failed to initialize DCGM说明驱动版本不兼容，需升级驱动