一句话定义：Prometheus 是一个按固定周期主动拉取指标的时序数据库（time series database），Grafana 则是把库里的数字画成看板、并负责把异常推送出去的可视化与告警工具。两者分工明确、常常结对出现，是云原生监控的默认组合。
打个比方。Prometheus 像一位不知疲倦的巡检员，每隔十几秒挨个敲门问一句“你现在怎么样”。被监控的服务只要在一个固定地址（约定俗成是 /metrics）用纯文本报出若干行“指标名 数值”，巡检员就盖上时间戳、记进本子。Grafana 则负责把本子上密密麻麻的数字变成折线图、热力图和红绿灯。
为什么用“拉”（pull）而不是服务主动“推”（push）？好处是服务不必知道监控系统在哪，配置和权限都集中在 Prometheus 一侧；坏处是活得太短的任务来不及被抓到，这类场景通常要借助中转组件，具体的部署方式以官方文档为准。
要监控好，先得认清楚指标类型：
| 类型 | 特点 | 推理服务里的例子 |
|---|---|---|
| Counter 计数器 | 只增不减 | 累计请求数、累计报错数 |
| Gauge 瞬时值 | 可上可下 | 当前显存占用、等待队列长度 |
| Histogram 分桶 | 按数值区间记账 | 请求延迟分布，能算 P95/P99 |
| Summary 摘要 | 客户端直接算分位数 | 延迟分位数（不可跨实例合并） |
推理服务最该盯的三件事，恰好各对应一种类型：
- QPS：用 Counter 求速率，
rate(inference_requests_total[1m])，意思是一分钟内的每秒平均请求数。 - 延迟：用 Histogram 求分位数，
histogram_quantile(0.95, ...)得到 P95，比平均值有用得多。平均值会掩盖“少数用户等了十秒”这种真实痛点。 - 显存：用 Gauge 看占比，
gpu_memory_used_bytes / gpu_memory_total_bytes。显存逼近上限时往往先表现为吞吐骤降，而不是直接报错，所以这个指标要提前告警。
告警规则怎么写？本质是一条表达式加一个“持续多久”的条件：表达式成立且持续 for 指定的时间才触发，避免一次抖动就叫人起床。例如显存占用连续 5 分钟超过 90% 再告警。规则里通常还会附带严重级别和一句人话描述，方便值班的人一眼看懂。
它和相邻概念的区别，可以放进可观测性的三大支柱里看：指标（metrics）回答“整体趋势好不好”，日志（logs）回答“这一次具体发生了什么”，链路追踪（traces）回答“慢在哪一步”。Prometheus 管的是指标这一格，Grafana 则是把头两类数据摆到同一块屏幕上的那层。
对 AI 从业者，意义在于模型上线后，离线评估分数不再是唯一判据：一次发版可能让 P99 延迟翻倍而准确率毫无变化，只有服务层指标能立刻看见。对普通职场人，这套东西的直觉并不神秘：定时体检、画成体检报告、指标越界就打电话，仅此而已。