当 Ollama 从个人试用走向团队共享或业务调用后，仅确认进程“还活着”远远不够。响应是否变慢、模型加载是否频繁、显存是否紧张、请求是否异常，都需要持续观测。本文以 Prometheus、Grafana 和指标导出器为核心，搭建一套轻量、可扩展的 Ollama 监控与告警方案。🚀
一、先明确监控架构
典型的数据链路是：应用请求 Ollama，指标导出器采集请求性能与模型状态，Prometheus 定时拉取指标，Grafana 查询 Prometheus 并生成仪表盘，最后由 Grafana Alerting 或 Alertmanager 发送通知。
应用 → Ollama 或代理型 Exporter → Prometheus → Grafana → 邮件、Webhook 等通知渠道
Ollama 的 API 响应本身包含 total_duration、load_duration、prompt_eval_count、eval_count 和 eval_duration 等字段，其中时间值以纳秒表示，可用于计算整体延迟、模型加载耗时、输入输出 Token 数以及生成速度。具体字段可查看 Ollama Usage API 文档。
二、选择指标采集方式
一种简单做法是部署社区 Exporter 或代理型 Sidecar，对 Ollama API 的返回结果进行解析，再暴露 Prometheus 格式的 /metrics 接口。例如 ollama-metrics 项目可以记录请求耗时、Token 使用量、生成速度、模型内存占用和加载状态。部署前应检查项目维护状态、镜像来源和接口兼容性，并在测试环境验证。
除了请求指标，还应采集主机资源。CPU、内存、磁盘可通过 Node Exporter 获取；如果使用 NVIDIA GPU，可结合 NVIDIA DCGM Exporter 观察显存、利用率、温度和功耗。这样才能判断“响应慢”究竟来自模型推理、模型冷加载，还是系统资源不足。🔍
建议关注的核心指标
- 可用性：Ollama 健康检查结果、Prometheus 目标状态、接口错误数量。
- 性能：请求总耗时、模型加载耗时、Token 生成速度、并发请求量。
- 模型状态：已加载模型数量、模型占用内存或显存、上下文长度。
- 资源：CPU 使用率、剩余内存、磁盘空间、GPU 利用率与显存占用。
Ollama 的 /api/ps 接口可以返回当前运行模型、大小、显存占用和上下文长度，适合由自定义 Exporter 周期性读取，参考 运行模型接口说明。请求级耗时与 Token 数据则更适合由代理层在请求完成时记录，尤其要注意流式响应的统计字段通常位于 done 为 true 的最后一个数据块中。
三、配置 Prometheus 拉取指标
假设指标导出器运行在 ollama-metrics:8080，Prometheus 可新增一个抓取任务：
scrape_configs:
- job_name: ollama
scrape_interval: 15s
static_configs:
- targets: [ollama-metrics:8080]
配置完成后，重载 Prometheus，并在 Targets 页面检查 ollama 任务是否为 UP。Prometheus 使用 YAML 配置抓取任务，scrape_interval 决定拉取频率，scrape_timeout 不能大于抓取间隔，详细规则可参考 Prometheus 配置文档。
生产环境不要盲目把采集间隔调得过短。对于请求计数和资源利用率，15 秒或 30 秒通常便于观察趋势；如果指标标签包含完整提示词、用户 ID 或随机请求 ID，会造成高基数并增加存储压力。建议仅保留 model、instance、status 等稳定标签，同时避免采集敏感提示内容。🔐
四、制作 Grafana 可视化面板
在 Grafana 中添加 Prometheus 数据源后，可以按“总览、性能、模型、资源”划分仪表盘。总览区展示服务状态、每分钟请求量和错误比例；性能区展示平均延迟、P95 延迟及 Token 生成速度；模型区展示各模型调用量和加载状态；资源区展示 CPU、内存与 GPU 指标。
常见 PromQL 思路包括：使用 rate(请求计数指标[5m]) 观察吞吐趋势，使用 histogram_quantile 计算延迟分位数，使用输出 Token 增量除以生成耗时得到生成速度。实际指标名称应以 Exporter 的 /metrics 输出为准，不要直接照搬其他项目的查询语句。
Grafana 已内置 Prometheus 数据源支持，可通过 PromQL 创建图表、变量和告警，具体能力可参考 Grafana Prometheus 数据源文档。建议增加 instance 和 model 变量，让同一套仪表盘能够切换不同节点与模型。
五、设置真正有用的告警
告警应围绕用户影响设计，而不是“数值一波动就通知”。可先从以下规则开始，再依据设备容量和历史基线调整阈值：
- 服务不可用：Ollama 或 Exporter 连续数分钟无法访问。
- 延迟持续升高：P95 响应时间在一个观测窗口内持续超过业务可接受范围。
- 错误比例异常：失败请求占比持续增加，并设置最低请求量条件，避免低流量误报。
- 资源逼近上限：内存、显存或磁盘空间持续紧张，而非瞬时尖峰。
- 生成速度下降：同一模型的 Token 生成速度明显偏离自身历史基线。
Grafana Alerting 可以直接使用 Prometheus 查询创建规则，并配置评估间隔、等待时间、标签和通知策略，步骤可参考 Prometheus 告警文档。建议使用 warning 和 critical 两级严重性标签，同时在通知中加入实例、模型、当前值和排查入口。🔔
六、上线前的验证清单
- 主动停止 Ollama，确认可用性告警能够触发并恢复。
- 发送一次短请求和一次长请求，核对耗时与 Token 指标是否合理。
- 检查 Grafana 时间范围、时区和单位换算，避免把纳秒误当成秒。
- 确认 Exporter 故障与 Ollama 故障能够被区分，防止错误定位。
- 限制 Prometheus、Grafana 和指标端口的访问范围，不直接暴露到公网。
总结
一套实用的 Ollama 监控体系，应同时覆盖服务可用性、请求性能、模型状态和硬件资源。Prometheus 负责可靠地采集与存储指标，Grafana 负责展示趋势与执行告警，而 Exporter 则连接 Ollama API 与 Prometheus 指标格式。先从少量核心指标和低噪声告警起步，再结合真实负载逐步完善，才能让监控真正服务于故障发现、容量规划和性能优化。✅
