daily_stock_analysis镜像资源监控：Prometheus+Grafana显存/CPU/延迟可视化

1. 为什么需要监控AI股票分析师的运行状态

你刚部署好daily_stock_analysis镜像，输入AAPL，点击“生成分析报告”，几秒后一份结构清晰的虚构分析报告就出现在屏幕上——这感觉很酷。但当你连续提交10次请求、或让同事同时访问、或想测试它在高负载下的稳定性时，问题就来了：响应变慢了？模型卡住了？GPU显存爆了却没人知道？服务器悄悄过热降频了？

这就是为什么我们不能只关注“功能是否可用”，更要关心“系统是否健康”。AI应用不是黑盒，它运行在真实的硬件上：CPU要计算、GPU显存要加载模型、内存要缓存上下文、网络要传输请求。这些资源一旦吃紧，用户体验就会断崖式下滑——从“秒出结果”变成“转圈三分钟”。

本篇不讲怎么写股票分析提示词，也不教Ollama怎么拉取模型。我们要做一件更务实的事：把这套本地AI分析服务的“生命体征”实时可视化出来。用Prometheus采集指标，用Grafana画出图表，让你一眼看清——此刻GPU还剩多少显存、CPU使用率是否持续超80%、每次请求平均耗时多少毫秒、模型加载是否成功、Web服务是否存活。

这不是给运维工程师看的，而是给每一位部署并依赖这个AI工具的你准备的“驾驶舱仪表盘”。

2. 监控体系架构：轻量、嵌入、零侵入

2.1 整体设计原则

daily_stock_analysis镜像的监控方案，严格遵循三个核心原则：

• 不修改业务逻辑：不碰Ollama服务、不改WebUI代码、不重写任何一行分析逻辑
• 不增加外部依赖：所有组件（Prometheus、Grafana、Exporter）均以内嵌方式打包进同一镜像，启动即用
• 不暴露额外端口：监控数据通过容器内网互通，仅对外暴露一个Grafana Web界面（默认端口3000），无需开放Prometheus或节点端口

这意味着：你不需要单独部署Prometheus服务器，不需要配置远程写入，不需要学习YAML服务发现规则。只要docker run启动这个镜像，监控系统就已就绪。

2.2 组件分工与数据流向

整个监控链路只有4个角色，全部运行在单容器内：

组件	作用	默认端口	数据来源
Ollama Exporter	将Ollama运行时状态（模型加载状态、推理延迟、GPU显存占用）转换为Prometheus可读指标	2112	Ollama REST API (http://localhost:11434/api/tags) + nvidia-smi 命令输出
Node Exporter	采集宿主机基础指标（CPU、内存、磁盘、网络）	9100	Linux /proc 文件系统
Prometheus Server	拉取上述两个Exporter的指标，本地存储15天时间序列数据	9090	定期抓取 localhost:2112 和 localhost:9100
Grafana Server	提供可视化界面，预置6个关键看板，支持一键导出PDF	3000	从本地Prometheus读取数据

关键说明：

• 所有Exporter均采用轻量Go二进制，无Python依赖，启动快、内存占用<10MB
• Prometheus配置已固化在镜像中，无需手动编辑prometheus.yml
• Grafana已预装prometheus数据源，并自动关联，开箱即用

2.3 为什么选Prometheus+Grafana而不是其他方案

有人会问：既然只是单机，用htop或nvidia-smi命令不就行了？
答案是：能看≠能管，能查≠能预警。

• nvidia-smi只能告诉你“此刻”显存用了多少，但你看不到“过去5分钟显存是否持续飙升”；
• top能看到CPU瞬时占用，但无法回答“生成一份报告平均消耗多少CPU时间”；
• 更重要的是——没有历史对比，就没有优化依据。比如你发现TSLA分析比AAPL慢2倍，到底是模型本身问题，还是因为前一次请求占满了GPU显存没释放？没有监控数据，这就是个谜。

而Prometheus+Grafana组合提供了三样不可替代的能力：
时间维度：所有指标自带时间戳，可回溯任意时段状态
关联分析：把“GPU显存占用曲线”和“请求延迟曲线”叠在一起，异常一目了然
阈值告警：当GPU显存连续30秒>95%，自动发邮件/钉钉通知（本文暂不展开告警配置，但能力已内置）

3. 一键启用监控：3步完成全部配置

3.1 启动时启用监控模式

daily_stock_analysis镜像默认不启动监控组件（节省资源）。要开启，只需在docker run命令中添加一个环境变量：

docker run -d \
  --name daily-stock-analysis \
  -p 3000:3000 \          # Grafana界面
  -p 11434:11434 \        # Ollama API
  -e ENABLE_MONITORING=true \   # 👈 关键开关！启用监控栈
  -v /path/to/models:/root/.ollama/models \
  registry.csdn.ai/daily-stock-analysis:latest

添加 -e ENABLE_MONITORING=true 后，容器启动时将自动：

• 启动Node Exporter（监听localhost:9100）
• 启动Ollama Exporter（监听localhost:2112）
• 启动Prometheus（监听localhost:9090，配置已就绪）
• 启动Grafana（监听0.0.0.0:3000，数据源已连通）

3.2 验证监控组件是否就绪

等待约45秒（组件启动需要时间），执行以下检查：

# 查看容器日志，确认各组件启动成功
docker logs daily-stock-analysis | grep -E "(Prometheus|Grafana|Exporter) started"

# 检查Prometheus是否可访问（返回HTML表示正常）
curl -s http://localhost:9090 | head -n 1 | grep -q "Prometheus" && echo " Prometheus OK" || echo " Prometheus failed"

# 检查Ollama Exporter指标端点（应返回文本格式指标）
curl -s http://localhost:2112/metrics | grep ollama_model_loaded | head -n 1

如果全部返回预期内容，说明监控底座已稳稳立住。

3.3 访问Grafana看板：你的AI分析师“体检报告”

打开浏览器，访问 http://你的服务器IP:3000
默认登录账号：admin / admin（首次登录会强制修改密码）

进入后，点击左侧菜单 Dashboards → Manage，你会看到6个预置看板，按优先级推荐顺序如下：

看板名称	核心价值	推荐查看场景
1. AI服务健康总览	CPU/GPU/内存/磁盘四维水位图 + 服务存活状态	每日晨会快速扫一眼系统是否“在线且健康”
2. GPU显存深度分析	显存占用率、已分配显存、剩余显存、GPU温度曲线	调试模型加载失败、排查推理卡顿
3. 请求性能全景	平均延迟、P95延迟、请求成功率、QPS（每秒请求数）	评估不同股票代码的响应差异、压测瓶颈
4. Ollama模型状态	当前加载模型名、模型大小、加载时间、推理调用次数	确认gemma:2b是否真正加载成功、统计使用频次
5. CPU热点追踪	按进程划分CPU占用（Ollama、Grafana、Prometheus等）	发现后台进程异常吃CPU（如日志轮转失控）
6. 延迟分解视图	将单次请求拆解为：网络传输、Ollama排队、模型推理、结果渲染四阶段耗时	精确定位慢在哪一环（是网络？是排队？还是模型真慢？）

小技巧：每个看板右上角都有 ⏱ 时间范围选择器。点击“Last 30 minutes”可切换为“Last 24 hours”或“Last 7 days”，方便做趋势对比。例如：对比周一早盘和周五收盘时段的GPU压力，就能看出交易时段的真实负载特征。

4. 关键指标解读：看懂你的AI分析师在“喘气”还是“狂奔”

4.1 GPU显存：AI应用的“呼吸空间”

对daily_stock_analysis而言，gemma:2b模型加载后常驻显存约1.8GB。这是它的“基础呼吸空间”。监控中需重点关注三个指标：

• nvidia_smi_memory_used_bytes{gpu="0"}：当前已用显存（字节）
• nvidia_smi_memory_total_bytes{gpu="0"}：显卡总显存（字节）
• ollama_gpu_memory_utilization_percent{model="gemma:2b"}：模型专属显存占用率（由Exporter计算得出）

健康区间：显存占用率长期维持在 40%–75%
预警信号：连续1分钟 >85% → 可能导致新请求排队或OOM（内存溢出）
危险红线：>95%持续30秒 → Ollama可能拒绝新请求，Web界面显示“模型加载中…”卡死

实际案例：某用户反馈“输入TSLA后页面一直转圈”。查看“GPU显存深度分析”看板发现：显存占用率在98%持续了2分17秒。进一步检查发现，其误将gemma:7b模型也拉入本地，虽未加载，但Ollama后台扫描占用了额外显存。卸载后问题消失。

4.2 请求延迟：用户体验的“心跳节律”

用户不关心你用了什么模型，只关心“我点下去，多久能看见结果”。监控中两个延迟指标最真实：

• http_request_duration_seconds_bucket{le="1.0", handler="analyze"}：1秒内完成的分析请求数
• http_request_duration_seconds_sum{handler="analyze"} / http_request_duration_seconds_count{handler="analyze"}：计算出的平均延迟（秒）

优秀体验：平均延迟 < 1.2秒，P95延迟 < 2.5秒（即95%的请求在2.5秒内完成）
需关注：平均延迟 > 2.0秒，且P95延迟 > 5.0秒 → 存在明显长尾请求
不可接受：P95延迟 > 10秒 → 用户大概率已刷新页面或放弃

延迟高？先看“延迟分解视图”：

• 如果模型推理阶段占比超80% → 模型本身或硬件限制（考虑换更小模型）
• 如果Ollama排队阶段突出 → 并发请求过多，需限流或扩容
• 如果网络传输或结果渲染高 → 前端或网络问题，与AI核心无关

4.3 CPU与内存：系统的“稳定基石”

虽然GPU是主力，但CPU和内存同样关键：

• node_cpu_seconds_total{mode="user"}：Ollama进程实际占用的CPU时间（排除系统空闲）
• node_memory_MemAvailable_bytes：可用内存（非“空闲”，是真正可立即分配的）

安全水位：CPU user时间占比 < 60%，可用内存 > 2GB
风险提示：CPU持续>80% + 内存<1GB → 系统开始频繁swap，所有服务变慢
紧急干预：CPU >95%持续1分钟 → 可能存在死循环或日志刷屏，需docker exec进入容器排查

快速定位CPU大户：
在容器内执行 top -b -n1 | head -20，观察ollama serve和python3 app.py进程的%CPU列，数值最高者即元凶。

5. 进阶实践：从监控到优化的闭环

5.1 基于监控数据的3个典型优化动作

监控不是终点，而是优化的起点。以下是三个真实、可立即执行的优化动作：

动作1：动态调整Ollama并发数（防雪崩）

默认Ollama允许无限并发请求，但在显存有限的消费级显卡（如RTX 4090 24GB）上，同时处理3个以上gemma:2b推理请求，显存极易打满。

优化方案：利用Prometheus指标自动限流

• 在Grafana中创建一个告警规则：当ollama_gpu_memory_utilization_percent > 85持续60秒，触发动作
• 动作脚本：自动执行 ollama serve --num_ctx 2048 --num_threads 4（降低上下文长度和线程数，减少显存峰值）
• 恢复规则：当显存回落至<70%，自动切回高性能参数

脚本已内置在镜像/opt/monitoring/auto_tune.sh中，只需在Grafana告警中配置调用路径。

动作2：识别低效股票代码，建立白名单

监控发现：输入XYZ-FAKE（虚构代码）时，平均延迟高达8.2秒，远高于AAPL(1.1秒)或TSLA(1.3秒)。原因在于Prompt工程对未知代码做了大量兜底推理。

优化方案：构建高频/低延迟股票白名单

• 导出“请求性能全景”看板中P95延迟Top 10的股票代码
• 将其加入前端输入框的自动补全列表（/app/static/js/autocomplete.js）
• 对非白名单代码，前端弹窗提示：“该代码暂未优化，分析可能较慢，是否继续？”

既保障核心用户体验，又不牺牲功能完整性。

动作3：模型冷启动预热（消灭首请求延迟）

首次请求总是最慢——因为Ollama要加载模型到GPU。监控数据显示，首请求延迟达4.7秒，后续降至1.1秒。

优化方案：利用Prometheus Up指标触发预热

• 创建一个简单Job：当up{job="ollama-exporter"} == 1（Ollama服务就绪），立即发送一次curl -X POST http://localhost:11434/api/chat -d '{"model":"gemma:2b","messages":[{"role":"user","content":"ping"}]}'
• 此请求不返回给用户，仅用于“唤醒”模型，耗时约3.5秒，但换来后续所有请求稳定在1.1秒

该预热脚本已集成在镜像启动流程中，ENABLE_MONITORING=true时自动生效。

5.2 你的监控数据，也可以成为训练数据

你可能没意识到：每一次成功的分析请求，都产生了一条带时间戳、股票代码、响应延迟、GPU显存占用的完整记录。这些数据天然具备两大价值：

• 性能基线建模：积累1周数据后，Grafana可自动生成“AAPL平均延迟基线”，当某天延迟突然偏离基线2个标准差，即自动标红预警
• 模型效果反馈：将用户对报告的点赞/点踩行为（如有前端埋点）与对应请求的延迟、显存数据关联，可分析“用户更愿意为更快的响应付费，还是为更长的分析篇幅付费”

这些高级能力已在镜像中预留接口（/metrics/feedback端点），等待你用几行代码接入。

6. 总结：让AI服务从“能用”走向“可信”

部署一个AI股票分析师，只是第一步；让它稳定、可预期、可解释、可优化，才是让它真正融入你工作流的关键。

通过本文介绍的Prometheus+Grafana监控方案，你现在可以：

• 实时掌握：GPU显存是否充足、CPU是否过载、每次请求到底花了多少时间
• 快速归因：当用户说“太慢了”，你能30秒内定位是网络、排队、还是模型本身的问题
• 主动防御：在服务崩溃前，通过显存预警提前干预，避免用户遭遇白屏
• 持续进化：用真实监控数据驱动参数调优、白名单建设、预热策略，形成正向闭环

技术的价值，不在于它多炫酷，而在于它多可靠。当你不再担心“它会不会突然挂掉”，而是专注思考“如何让分析报告更有洞见”时，这套本地AI工具，才真正成为了你值得信赖的数字同事。

---

获取更多AI镜像

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