核心内容摘要
《斗罗大陆》：小舞的“巴雷特”之殇，一场关于爱与成长的史诗
DeepAnalyze步骤详解如何用PrometheusGrafana监控DeepAnalyze服务状态与分析吞吐量
为什么需要监控DeepAnalyze服务你刚部署好DeepAnalyze输入一段产品评论几秒钟就拿到了结构化分析报告——核心观点、关键信息、潜在情感一目了然。
这感觉很爽。
但当团队开始批量上传内部会议纪要、客户反馈日志、竞品新闻稿时问题来了第100次请求响应变慢了是模型推理卡顿还是WebUI前端阻塞某天凌晨三点分析任务突然全部失败日志里只有一行“connection refused”可Ollama进程明明还在运行你想知道今天总共处理了多少文本、平均单次分析耗时多少、哪个时间段并发最高但翻遍容器日志也找不到汇总数据。
这些问题单靠docker logs和top命令解决不了。
DeepAnalyze不是玩具Demo它是一套承载真实业务分析需求的私有化AI服务。
而任何值得信赖的服务都必须具备可观测性——不是“能不能用”而是“用得怎么样”、“哪里可能出问题”、“性能瓶颈在哪”。
Prometheus Grafana这套组合就是为这类场景量身定制的Prometheus负责持续抓取DeepAnalyze各层指标HTTP接口响应、Ollama推理耗时、内存占用、请求队列长度Grafana负责把枯燥的数字变成一眼看懂的图表比如“过去一小时分析吞吐量曲线”、“失败请求按错误类型分布饼图”整个过程不侵入业务代码不修改DeepAnalyze源码只通过轻量级Exporter和配置就能完成。
这不是锦上添花的“高级功能”而是让DeepAnalyze真正从“能跑起来”走向“可运维、可优化、可信任”的关键一步。
监控架构设计三层指标采集体系DeepAnalyze由多个组件协同工作用户通过WebUI发起HTTP请求 → 后端服务调用Ollama API → Ollama加载Llama 3模型执行推理 → 返回结构化结果。
监控必须覆盖这整条链路我们采用分层采集策略避免单点故障导致全链路失明。
1 基础设施层容器与宿主机健康这是最底层的“生命体征”。
我们不直接在宿主机装Prometheus Agent而是利用Docker自带的metrics接口通过Prometheus的docker_sd_configs自动发现所有容器。
重点关注container_cpu_usage_seconds_total{containerdeepanalyze}DeepAnalyze主容器CPU使用率持续高于80%说明计算资源吃紧container_memory_usage_bytes{containerdeepanalyze}内存占用若接近限制值如2GB可能触发OOM Killer杀掉Ollama进程container_network_receive_bytes_total{containerollama}Ollama容器网络流入量突增可能意味着大量文本请求涌入。
实操提示在prometheus.yml中添加如下配置Prometheus会自动识别并抓取所有容器指标无需在每个容器内安装额外Agent。
scrape_configs: - job_name: docker docker_sd_configs: - host: unix:///var/run/docker.sock refresh_interval: 30s
2 应用服务层HTTP接口与后端逻辑DeepAnalyze WebUI本质是一个Python Flask应用它暴露了/analyze这个核心API。
我们在其代码中嵌入prometheus_client库暴露4类关键指标请求计数http_requests_total{methodPOST, endpoint/analyze, status_code200}—— 成功分析请求数请求耗时http_request_duration_seconds_bucket{le
0, endpoint/analyze}—— 耗时在5秒内的请求数直方图错误计数http_requests_total{status_code~
.|
.}—— 客户端错误4xx与服务端错误5xx并发数http_requests_in_flight{endpoint/analyze}—— 当前正在处理的请求数超过阈值如10需告警。
这些指标通过/metrics端点暴露Prometheus每15秒抓取一次。
你不需要改业务逻辑只需在Flask启动时初始化一个全局Registry并在请求处理函数前后调用start_timer()和observe()即可。
3 模型推理层Ollama的黑盒内部Ollama本身不提供原生Prometheus指标但它的REST API是公开的。
我们编写一个轻量级ollama_exporterPython脚本定期调用http://localhost:11434/api/tags获取模型状态并解析/api/chat的响应头中的X-Response-Time字段Ollama默认返回该Header。
导出以下指标ollama_model_loaded{modelllama3:8b}值为1表示模型已加载0表示未加载启动中或加载失败ollama_inference_duration_seconds{modelllama3:8b}单次推理实际耗时秒比HTTP层更精准反映模型性能ollama_queue_lengthOllama内部等待队列长度值0说明请求在排队是性能瓶颈的早期信号。
这个Exporter独立运行不依赖DeepAnalyze代码即使WebUI崩溃只要Ollama活着它就能继续上报指标。
部署实施三步完成监控栈搭建整个监控栈部署无需复杂编排所有组件均以Docker容器方式运行与DeepAnalyze镜像完全解耦。
1 步骤一启动Prometheus与Grafana创建docker-compose.monitor.yml定义两个服务version:
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_PASSWORDadmin执行docker compose -f docker-compose.monitor.yml up -dPrometheus将在http://localhost:9090Grafana在http://localhost:3000账号admin/admin。
2 步骤二配置Prometheus抓取目标编辑prometheus.yml添加三个jobscrape_configs: #
抓取容器基础指标 - job_name: docker static_configs: - targets: [host.docker.internal:9323] # 使用cAdvisor暴露容器指标 # ...cAdvisor配置略 #
抓取DeepAnalyze应用指标 - job_name: deepanalyze static_configs: - targets: [host.docker.internal:5000] # 假设DeepAnalyze暴露/metrics在5000端口 metrics_path: /metrics #
抓取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 步骤三部署Ollama Exporter并验证下载预编译的ollama_exporter或克隆GitHub仓库运行./ollama_exporter --web.listen-address:9101 --ollama.hosthttp://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
0} 0 ollama_inference_duration_seconds_bucket{le
0} 127 ollama_inference_duration_seconds_sum
4
8 ollama_inference_duration_seconds_count 127回到Prometheus UI (http://localhost:
输入查询ollama_inference_duration_seconds_count若返回非零值说明数据已成功接入。
Grafana看板6个核心图表读懂服务健康度登录Grafana添加Prometheus为Data SourceURL填http://prometheus:9090注意是容器名而非localhost然后导入我们预置的DeepAnalyze看板JSON文件。
以下是6个最实用的图表及其解读逻辑
1 实时吞吐量仪表盘Requests per Second图表类型Time series折线图查询语句rate(http_requests_total{endpoint/analyze,status_code200}[1m])解读显示过去1分钟每秒成功分析请求数。
平稳在
之间属正常若突然跌至0检查Ollama是否崩溃若持续高于10且延迟上升说明需扩容。
2 分析耗时热力图Latency Heatmap图表类型Heatmap查询语句histogram_quantile(
95, rate(http_request_duration_seconds_bucket{endpoint/analyze}[5m]))解读95%的请求耗时。
绿色区域3s代表流畅黄色
s需关注红色8s表明模型或CPU严重过载。
3 错误率趋势Error Rate图表类型Stat大数字面板查询语句100 * sum(rate(http_requests_total{endpoint/analyze,status_code~
.|
.}[1h])) by (status_code) / sum(rate(http_requests_total{endpoint/analyze}[1h])) by (status_code)解读当前小时错误率百分比。
1%即触发告警常见原因Ollama模型未加载
请求超时
内存不足500。
4 模型加载状态Model Status图表类型State timeline查询语句ollama_model_loaded{modelllama3:8b}解读一条横线值为1表示模型就绪若出现0值断点说明Ollama重启或模型被意外卸载需检查日志。
5 内存使用对比Memory Usage图表类型Bar gauge查询语句container_memory_usage_bytes{container~deepanalyze|ollama}解读并排显示DeepAnalyze容器与Ollama容器内存占用。
若Ollama内存远高于DeepAnalyze如2GB vs 200MB说明模型加载正常若两者接近可能Ollama未真正加载模型。
6 并发请求数Concurrent Requests图表类型Time series查询语句http_requests_in_flight{endpoint/analyze}解读当前正在处理的请求数。
理想值为
若长期5说明后端处理能力跟不上需优化Flask线程池或增加Ollama workers。
看板使用技巧将所有图表设置为“Last 6 hours”时间范围并开启“Auto refresh”30s。
当你在WebUI点击“开始深度分析”时实时观察“吞吐量”和“耗时”图表的跳动这就是服务在呼吸的脉搏。
故障排查实战从指标异常到根因定位监控的价值不在“好看”而在“好用”。
下面演示一个典型故障的完整排查链路。
1 现象用户反馈“分析变慢经常超时”第一步看吞吐量与耗时在Grafana中发现“实时吞吐量”稳定在6 QPS但“分析耗时热力图”95分位线从
5s飙升至12s且大量请求落入红色区间。
确认是性能问题非服务宕机。
第二步查并发与队列“并发请求数”图表显示值长期为
“Ollama队列长度”指标也持续为
。
说明请求在Ollama层堆积瓶颈在模型推理而非WebUI。
第三步验模型状态与内存“模型加载状态”显示为1正常“内存使用对比”中Ollama内存占用达
8GB接近2GB限制而CPU使用率仅40%。
线索指向内存不足导致频繁GC垃圾回收拖慢推理。
第四步验证与解决进入Ollama容器执行ollama list确认模型存在再运行ollama run llama3:8b hello测试单次推理耗时确为10s。
最终解决方案将Ollama容器内存限制从2GB提升至3GB重启后所有指标回归绿色。
这个过程从发现问题到定位根因全程不超过3分钟全部基于图表数据无需SSH进容器翻日志。
6.
总结让DeepAnalyze真正成为可信赖的生产级服务部署PrometheusGrafana监控对DeepAnalyze而言绝非给服务器贴一张“高科技”标签。
它带来的是三重确定性确定性可用当ollama_model_loaded指标为1你知道模型已就绪当http_requests_total持续增长你知道服务正稳定工作确定性性能http_request_duration_seconds告诉你“快”或“慢”的具体数值而非用户模糊的“感觉有点卡”确定性归因当问题发生指标链路HTTP层→应用层→Ollama层帮你快速锁定是代码bug、配置错误还是资源瓶颈。
更重要的是这一套监控方案完全适配DeepAnalyze的私有化基因所有指标采集、存储、可视化都在你的服务器内完成没有数据出域没有第三方SaaS依赖。
你掌控的不仅是文本分析能力更是对这项能力的全部洞察权。
下一步你可以基于这些指标做更多事设置告警规则如“耗时10s持续5分钟”自动邮件通知、用Grafana Explore功能深入分析某次慢请求的完整调用链、甚至将吞吐量数据接入CI/CD在模型升级后自动比对性能变化。
监控是让AI服务从“能用”走向“好用”、“敢用”、“离不开”的起点。