在本地或服务器上运行 Ollama 后，最常见的问题不是“模型能不能回答”，而是“为什么突然变慢、是否出现请求堆积、显存是否不足”。仅靠日志很难持续观察这些变化。📊 通过 Exporter 暴露指标、Prometheus 定时采集、Grafana 展示与告警，可以建立一套从异常发现到通知推送的完整监控链路。
一、整体监控架构
推荐采用“Ollama → 指标 Exporter → Prometheus → Grafana/Alertmanager”的结构。Ollama 负责模型推理；Exporter 从代理请求或 Ollama API 中提取指标，并提供 Prometheus 格式的 /metrics 端点；Prometheus 保存时序数据；Grafana 负责看板和告警管理。
需要注意的是，Ollama 的常规服务端口通常用于 API 调用，并不能直接等同于完整的 Prometheus 指标端点。因此，实际接入时一般需要增加 Exporter 或 Sidecar。社区项目 ollama-metrics 可以作为透明代理，采集请求耗时、Token 数量、生成速度和模型加载状态等数据；也可以根据团队安全规范自行开发 Exporter。citeturn1search3
二、部署 Ollama 指标采集组件
以容器方式部署指标代理时，可将 Ollama 地址通过环境变量传入，并把指标服务端口映射到宿主机。应用侧的推理请求应经过代理，才能得到请求级指标；如果 Exporter 只定时调用 Ollama 的模型状态接口，则通常只能获得服务存活、已加载模型、内存占用等状态数据。
docker run -d --name ollama-metrics \
-e OLLAMA_HOST=http://ollama:11434 \
-p 8080:8080 \
ghcr.io/norskhelsenett/ollama-metrics:latest
启动后，在 Prometheus 所在主机访问 来源链接，确认页面能够返回指标文本。验证时重点检查指标名称、标签和值是否持续更新，同时确保 Exporter 能访问 Ollama，Prometheus 也能访问 Exporter。🔍
三、配置 Prometheus 抓取任务
编辑 prometheus.yml，在 scrape_configs 下新增抓取任务。Prometheus 官方配置说明指出，抓取目标、任务实例以及规则文件都由 YAML 配置管理；修改后可通过重载机制应用新配置。Prometheus 配置文档citeturn1search7
scrape_configs:
- job_name: ollama-metrics
scrape_interval: 15s
metrics_path: /metrics
static_configs:
- targets: ["ollama-metrics:8080"]
labels:
service: ollama
env: production
保存配置后，先使用 promtool check config prometheus.yml 检查语法，再重载或重启 Prometheus。进入 Prometheus 的 Targets 页面，确认任务状态为 UP。如果状态为 DOWN，应依次排查容器网络、目标端口、防火墙、metrics_path 和 DNS 解析。
四、设计 Grafana 推理看板
在 Grafana 中添加 Prometheus 数据源后，建议围绕“可用性、负载、性能、资源”四个维度设计面板，而不是单纯堆叠全部指标。不同 Exporter 的指标名称可能不同，以下查询思路需要按实际暴露的名称调整。
- 服务存活：使用 up{job="ollama-metrics"} 判断 Exporter 是否可采集。
- 请求速率：对请求总数 Counter 使用 rate(指标名[5m])，观察调用量变化。
- 推理吞吐：展示每秒生成 Token 数，并按模型标签进行分组。
- 响应延迟：优先显示平均值、P95 或 P99，避免平均值掩盖慢请求。
- 模型状态：展示已加载模型数量、加载状态及模型内存占用。
- 主机资源：配合 Node Exporter 或 GPU Exporter，补充 CPU、内存、磁盘和显存指标。
Grafana 变量可以设置为 instance、model 和 env，便于在同一套看板中切换节点与模型。对于直方图指标，可使用 histogram_quantile 计算延迟分位数；对累计值则应使用 rate 或 increase，避免把总量误认为瞬时性能。
五、配置关键告警规则
第一类是服务不可用告警，例如 up{job="ollama-metrics"} == 0 持续两分钟后触发。设置持续时间可以过滤短暂重启或网络抖动，避免产生大量无效通知。🚨
第二类是推理性能告警。可以针对 P95 响应时间、Token 生成速度下降或请求错误率设置阈值。阈值不宜直接照搬他人配置，应先观察自身模型、硬件和上下文长度下的正常基线，再根据业务可接受范围确定 Warning 与 Critical 两级条件。
第三类是资源告警。CPU、内存、GPU 显存与温度通常需要 Node Exporter、cAdvisor 或厂商 GPU Exporter 提供。建议将“显存占用持续偏高”与“推理延迟同步升高”组合判断，减少仅因模型正常驻留显存而产生的误报。
告警可以由 Grafana 统一管理，也可以在 Prometheus 中定义规则并交给 Alertmanager 路由。Grafana 支持使用 Prometheus 数据源创建 Grafana 托管告警，配置流程包括 PromQL 查询、触发条件、评估间隔、等待时间、标签和通知策略。Grafana Prometheus 告警文档citeturn1search13
告警通知与降噪建议
- 为告警添加 severity、service、instance 和 model 标签。
- 在通知内容中写明当前值、触发阈值、节点地址和排查入口。
- 使用分组、静默和抑制规则，防止同一故障重复发送。
- 配置恢复通知，确保负责人知道服务已经回到正常状态。
- 上线前主动停止 Exporter 或制造测试负载，验证通知链路是否有效。
如果采用 Prometheus 原生告警，告警规则由 Prometheus 评估，再发送给 Alertmanager；Alertmanager 负责聚合、去重、静默、抑制和通知路由。Prometheus 告警说明citeturn1search14
总结
Ollama 的监控重点不仅是进程是否存活，还包括请求量、响应延迟、Token 吞吐、模型加载状态以及主机和 GPU 资源。✅ 落地时应先确认 Exporter 指标真实可用，再完成 Prometheus 抓取、Grafana 看板和告警通知；最后通过故障演练检查整条链路。只有让指标能够解释问题、告警能够推动行动，这套监控系统才真正具备生产价值。
