DeepAnalyze步骤详解：如何用Prometheus+Grafana监控DeepAnalyze服务状态与分析吞吐量-洪萨配资

DeepAnalyze步骤详解：如何用Prometheus+Grafana监控DeepAnalyze服务状态与分析吞吐量

1. 为什么需要监控DeepAnalyze服务

你刚部署好DeepAnalyze，输入一段产品评论，几秒钟就拿到了结构化分析报告——核心观点、关键信息、潜在情感一目了然。这感觉很爽。但当团队开始批量上传内部会议纪要、客户反馈日志、竞品新闻稿时，问题来了：

第100次请求响应变慢了，是模型推理卡顿，还是WebUI前端阻塞？
某天凌晨三点，分析任务突然全部失败，日志里只有一行“connection refused”，可Ollama进程明明还在运行；
你想知道今天总共处理了多少文本、平均单次分析耗时多少、哪个时间段并发最高，但翻遍容器日志也找不到汇总数据。

这些问题，单靠docker logs和top命令解决不了。DeepAnalyze不是玩具Demo，它是一套承载真实业务分析需求的私有化AI服务。而任何值得信赖的服务，都必须具备可观测性——不是“能不能用”，而是“用得怎么样”、“哪里可能出问题”、“性能瓶颈在哪”。

Prometheus + Grafana这套组合，就是为这类场景量身定制的：

Prometheus负责持续抓取DeepAnalyze各层指标（HTTP接口响应、Ollama推理耗时、内存占用、请求队列长度）；
Grafana负责把枯燥的数字变成一眼看懂的图表（比如“过去一小时分析吞吐量曲线”、“失败请求按错误类型分布饼图”）；
整个过程不侵入业务代码，不修改DeepAnalyze源码，只通过轻量级Exporter和配置就能完成。

这不是锦上添花的“高级功能”，而是让DeepAnalyze真正从“能跑起来”走向“可运维、可优化、可信任”的关键一步。

2. 监控架构设计：三层指标采集体系

DeepAnalyze由多个组件协同工作：用户通过WebUI发起HTTP请求 → 后端服务调用Ollama API → Ollama加载Llama 3模型执行推理 → 返回结构化结果。监控必须覆盖这整条链路，我们采用分层采集策略，避免单点故障导致全链路失明。

2.1 基础设施层：容器与宿主机健康

这是最底层的“生命体征”。我们不直接在宿主机装Prometheus Agent，而是利用Docker自带的metrics接口，通过Prometheus的docker_sd_configs自动发现所有容器。重点关注：

container_cpu_usage_seconds_total{container="deepanalyze"}：DeepAnalyze主容器CPU使用率，持续高于80%说明计算资源吃紧；
container_memory_usage_bytes{container="deepanalyze"}：内存占用，若接近限制值（如2GB），可能触发OOM Killer杀掉Ollama进程；
container_network_receive_bytes_total{container="ollama"}：Ollama容器网络流入量，突增可能意味着大量文本请求涌入。

实操提示：在prometheus.yml中添加如下配置，Prometheus会自动识别并抓取所有容器指标，无需在每个容器内安装额外Agent。
scrape_configs: - job_name: 'docker' docker_sd_configs: - host: unix:///var/run/docker.sock refresh_interval: 30s

2.2 应用服务层：HTTP接口与后端逻辑

DeepAnalyze WebUI本质是一个Python Flask应用，它暴露了/analyze这个核心API。我们在其代码中嵌入prometheus_client库，暴露4类关键指标：

请求计数：http_requests_total{method="POST", endpoint="/analyze", status_code="200"}—— 成功分析请求数；
请求耗时：http_request_duration_seconds_bucket{le="5.0", endpoint="/analyze"}—— 耗时在5秒内的请求数（直方图）；
错误计数：http_requests_total{status_code=~"4..|5.."}—— 客户端错误（4xx）与服务端错误（5xx）；
并发数：http_requests_in_flight{endpoint="/analyze"}—— 当前正在处理的请求数，超过阈值（如10）需告警。

这些指标通过/metrics端点暴露，Prometheus每15秒抓取一次。你不需要改业务逻辑，只需在Flask启动时初始化一个全局Registry，并在请求处理函数前后调用start_timer()和observe()即可。

2.3 模型推理层：Ollama的黑盒内部

Ollama本身不提供原生Prometheus指标，但它的REST API是公开的。我们编写一个轻量级ollama_exporter（Python脚本），定期调用http://localhost:11434/api/tags获取模型状态，并解析/api/chat的响应头中的X-Response-Time字段（Ollama默认返回该Header）。导出以下指标：

ollama_model_loaded{model="llama3:8b"}：值为1表示模型已加载，0表示未加载（启动中或加载失败）；
ollama_inference_duration_seconds{model="llama3:8b"}：单次推理实际耗时（秒），比HTTP层更精准反映模型性能；
ollama_queue_length：Ollama内部等待队列长度，值>0说明请求在排队，是性能瓶颈的早期信号。

这个Exporter独立运行，不依赖DeepAnalyze代码，即使WebUI崩溃，只要Ollama活着，它就能继续上报指标。

3. 部署实施：三步完成监控栈搭建

整个监控栈部署无需复杂编排，所有组件均以Docker容器方式运行，与DeepAnalyze镜像完全解耦。

3.1 步骤一：启动Prometheus与Grafana

创建docker-compose.monitor.yml，定义两个服务：

version: '3.8' services: prometheus: image: prom/prometheus:latest ports: - "9090:9090" volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus command: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' - '--web.console.libraries=/usr/share/prometheus/console_libraries' - '--web.console.templates=/usr/share/prometheus/consoles' grafana: image: grafana/grafana-oss:latest ports: - "3000:3000" volumes: - grafana_data:/var/lib/grafana - ./grafana-provisioning:/etc/grafana/provisioning environment: - GF_SECURITY_ADMIN_PASSWORD=admin

执行docker compose -f docker-compose.monitor.yml up -d，Prometheus将在http://localhost:9090，Grafana在http://localhost:3000（账号admin/admin）。

3.2 步骤二：配置Prometheus抓取目标

编辑prometheus.yml，添加三个job：

scrape_configs: # 1. 抓取容器基础指标 - job_name: 'docker' static_configs: - targets: ['host.docker.internal:9323'] # 使用cAdvisor暴露容器指标 # ...（cAdvisor配置略） # 2. 抓取DeepAnalyze应用指标 - job_name: 'deepanalyze' static_configs: - targets: ['host.docker.internal:5000'] # 假设DeepAnalyze暴露/metrics在5000端口 metrics_path: '/metrics' # 3. 抓取Ollama Exporter指标 - job_name: 'ollama-exporter' static_configs: - targets: ['host.docker.internal:9101'] # Exporter监听9101端口

关键技巧：host.docker.internal是Docker Desktop提供的特殊DNS，让容器内服务能访问宿主机上的其他服务（如本地运行的DeepAnalyze和Ollama）。Linux用户需替换为宿主机真实IP。

3.3 步骤三：部署Ollama Exporter并验证

下载预编译的ollama_exporter（或克隆GitHub仓库），运行：

./ollama_exporter --web.listen-address=":9101" --ollama.host="http://localhost:11434"

然后访问http://localhost:9101/metrics，应看到类似：

# HELP ollama_inference_duration_seconds Llama3 inference duration in seconds # TYPE ollama_inference_duration_seconds histogram ollama_inference_duration_seconds_bucket{le="1.0"} 0 ollama_inference_duration_seconds_bucket{le="5.0"} 127 ollama_inference_duration_seconds_sum 423.8 ollama_inference_duration_seconds_count 127

回到Prometheus UI (http://localhost:9090)，输入查询ollama_inference_duration_seconds_count，若返回非零值，说明数据已成功接入。

4. Grafana看板：6个核心图表读懂服务健康度

登录Grafana，添加Prometheus为Data Source（URL填http://prometheus:9090，注意是容器名而非localhost），然后导入我们预置的DeepAnalyze看板（JSON文件）。以下是6个最实用的图表及其解读逻辑：

4.1 实时吞吐量仪表盘（Requests per Second）

图表类型：Time series（折线图）
查询语句：rate(http_requests_total{endpoint="/analyze",status_code="200"}[1m])
解读：显示过去1分钟每秒成功分析请求数。平稳在5-8之间属正常；若突然跌至0，检查Ollama是否崩溃；若持续高于10且延迟上升，说明需扩容。

4.2 分析耗时热力图（Latency Heatmap）

图表类型：Heatmap
查询语句：histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{endpoint="/analyze"}[5m]))
解读：95%的请求耗时。绿色区域（<3s）代表流畅；黄色（3-8s）需关注；红色（>8s）表明模型或CPU严重过载。

4.3 错误率趋势（Error Rate）

图表类型：Stat（大数字面板）
查询语句：100 * sum(rate(http_requests_total{endpoint="/analyze",status_code=~"4..|5.."}[1h])) by (status_code) / sum(rate(http_requests_total{endpoint="/analyze"}[1h])) by (status_code)
解读：当前小时错误率百分比。>1%即触发告警，常见原因：Ollama模型未加载（404）、请求超时（504）、内存不足（500）。

4.4 模型加载状态（Model Status）

图表类型：State timeline
查询语句：ollama_model_loaded{model="llama3:8b"}
解读：一条横线，值为1表示模型就绪；若出现0值断点，说明Ollama重启或模型被意外卸载，需检查日志。

4.5 内存使用对比（Memory Usage）

图表类型：Bar gauge
查询语句：container_memory_usage_bytes{container=~"deepanalyze|ollama"}
解读：并排显示DeepAnalyze容器与Ollama容器内存占用。若Ollama内存远高于DeepAnalyze（如2GB vs 200MB），说明模型加载正常；若两者接近，可能Ollama未真正加载模型。

4.6 并发请求数（Concurrent Requests）

图表类型：Time series
查询语句：http_requests_in_flight{endpoint="/analyze"}
解读：当前正在处理的请求数。理想值为1-3；若长期>5，说明后端处理能力跟不上，需优化Flask线程池或增加Ollama workers。

看板使用技巧：将所有图表设置为“Last 6 hours”时间范围，并开启“Auto refresh”（30s）。当你在WebUI点击“开始深度分析”时，实时观察“吞吐量”和“耗时”图表的跳动，这就是服务在呼吸的脉搏。

5. 故障排查实战：从指标异常到根因定位

监控的价值不在“好看”，而在“好用”。下面演示一个典型故障的完整排查链路。

5.1 现象：用户反馈“分析变慢，经常超时”

第一步：看吞吐量与耗时
在Grafana中，发现“实时吞吐量”稳定在6 QPS，但“分析耗时热力图”95分位线从2.5s飙升至12s，且大量请求落入红色区间。确认是性能问题，非服务宕机。
第二步：查并发与队列
“并发请求数”图表显示值长期为8-10，“Ollama队列长度”指标也持续为3-5。说明请求在Ollama层堆积，瓶颈在模型推理，而非WebUI。
第三步：验模型状态与内存
“模型加载状态”显示为1（正常），“内存使用对比”中Ollama内存占用达1.8GB（接近2GB限制），而CPU使用率仅40%。线索指向：内存不足导致频繁GC（垃圾回收），拖慢推理。
第四步：验证与解决
进入Ollama容器，执行ollama list确认模型存在，再运行ollama run llama3:8b "hello"测试单次推理，耗时确为10s+。最终解决方案：将Ollama容器内存限制从2GB提升至3GB，重启后所有指标回归绿色。

这个过程，从发现问题到定位根因，全程不超过3分钟，全部基于图表数据，无需SSH进容器翻日志。

6. 总结：让DeepAnalyze真正成为可信赖的生产级服务

部署Prometheus+Grafana监控，对DeepAnalyze而言，绝非给服务器贴一张“高科技”标签。它带来的是三重确定性：

确定性可用：当ollama_model_loaded指标为1，你知道模型已就绪；当http_requests_total持续增长，你知道服务正稳定工作；
确定性性能：http_request_duration_seconds告诉你“快”或“慢”的具体数值，而非用户模糊的“感觉有点卡”；
确定性归因：当问题发生，指标链路（HTTP层→应用层→Ollama层）帮你快速锁定是代码bug、配置错误，还是资源瓶颈。

更重要的是，这一套监控方案完全适配DeepAnalyze的私有化基因：所有指标采集、存储、可视化都在你的服务器内完成，没有数据出域，没有第三方SaaS依赖。你掌控的不仅是文本分析能力，更是对这项能力的全部洞察权。

下一步，你可以基于这些指标做更多事：设置告警规则（如“耗时>10s持续5分钟”自动邮件通知）、用Grafana Explore功能深入分析某次慢请求的完整调用链、甚至将吞吐量数据接入CI/CD，在模型升级后自动比对性能变化。监控，是让AI服务从“能用”走向“好用”、“敢用”、“离不开”的起点。