3. Prometheus 监控基础回顾:指标类型、PromQL 与告警规则
在深入 API 弃用迁移与 Prometheus 监控联动升级之前,必须夯实 Prometheus 监控基础。本章将系统回顾 Prometheus 的四大核心指标类型、PromQL 查询语言的核心语法以及告警规则的编写范式,为后续章节的实战操作提供理论支撑。
3.1 四大核心指标类型
Prometheus 的指标模型基于时间序列,每个时间序列由指标名称和一组标签唯一标识。根据数据语义和计算方式,指标分为四种类型:Counter、Gauge、Histogram 和 Summary。理解它们的差异是设计监控方案的前提。
| 指标类型 | 核心特征 | 典型场景 | PromQL 常用函数 |
|---|---|---|---|
| Counter | 只增不减(重启归零) | 请求总数、错误次数、任务完成数 | rate()、increase() |
| Gauge | 可增可减,反映当前状态 | CPU 使用率、内存占用、连接数 | avg()、max()、min() |
| Histogram | 分桶统计,可计算分位数 | 请求延迟分布、响应大小分布 | histogram_quantile() |
| Summary | 客户端预计算分位数 | 延迟分位数(P99/P95) | 直接读取 quantile 标签 |
实战建议:在 API 弃用迁移场景中,Counter 用于统计弃用 API 的调用总量和错误量;Gauge 用于监控迁移过程中的并发连接数;Histogram 用于分析迁移后新 API 的延迟分布,确保性能不退化。
3.2 PromQL 基础:查询与聚合
PromQL(Prometheus Query Language)是 Prometheus 的查询语言,支持即时查询和范围查询。掌握 PromQL 是编写告警规则和构建仪表盘的基础。
3.2.1 选择器与匹配模式
- 精确匹配:
http_requests_total{method="GET", handler="/api/v1/deprecated"} - 正则匹配:
http_requests_total{handler=~"/api/v[12]/.*"} - 负向匹配:
http_requests_total{handler!~"/api/v2/.*"}
3.2.2 常用函数与操作符
| 函数/操作符 | 作用 | 示例 |
|---|---|---|
rate() |
计算 Counter 在时间窗口内的每秒平均增长率 | rate(http_requests_total[5m]) |
increase() |
计算 Counter 在时间窗口内的增量 | increase(http_requests_total[1h]) |
avg_over_time() |
计算 Gauge 在时间窗口内的平均值 | avg_over_time(node_cpu_seconds_total[5m]) |
histogram_quantile() |
基于 Histogram 计算分位数 | histogram_quantile(0.99, ...) |
by / without |
聚合操作中的分组与排除 | sum by(handler) (rate(...)) |
3.2.3 典型查询示例
# 查询弃用 API 的 QPS(每秒请求数)
rate(http_requests_total{handler="/api/v1/deprecated"}[5m])
# 查询弃用 API 的错误率(错误请求 / 总请求)
sum(rate(http_requests_total{handler="/api/v1/deprecated", status=~"5.."}[5m]))
/
sum(rate(http_requests_total{handler="/api/v1/deprecated"}[5m]))
# 查询新 API 的 P99 延迟(基于 Histogram)
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{handler="/api/v2/new"}[5m])) by (le)
)
常见陷阱:使用
rate() 时,时间窗口应至少为采集间隔的 4 倍(例如采集间隔 15s,窗口至少 1m),以避免数据稀疏导致结果抖动。对于 histogram_quantile(),必须确保 Histogram 的桶(bucket)覆盖了目标分位数的范围,否则计算结果会失真。
3.3 告警规则:从指标到通知
告警规则是 Prometheus 监控体系的核心输出。通过 PromQL 表达式定义告警条件,Prometheus 会持续评估规则,并在满足条件时触发告警。告警规则通常定义在 rules.yml 文件中,并通过 rule_files 配置加载。
3.3.1 告警规则结构
groups:
- name: api_deprecation_alerts
rules:
- alert: HighDeprecatedAPIErrorRate
expr: |
sum(rate(http_requests_total{handler="/api/v1/deprecated", status=~"5.."}[5m]))
/
sum(rate(http_requests_total{handler="/api/v1/deprecated"}[5m])) > 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "弃用 API 错误率过高(当前值:{{ $value | humanizePercentage }})"
description: "弃用 API /api/v1/deprecated 的 5xx 错误率已超过 5%,持续 5 分钟。请立即检查后端服务状态。"
3.3.2 规则关键字段说明
| 字段 | 说明 | 示例值 |
|---|---|---|
alert |
告警名称,必须唯一 | HighDeprecatedAPIErrorRate |
expr |
PromQL 表达式,返回非零值时触发 | rate(...) > 0.05 |
for |
持续时间,防止瞬时抖动误报 | 5m |
labels |
附加标签,用于告警路由和分组 | severity: critical |
annotations |
告警描述信息,支持模板变量 | {{ $value }} |
3.3.3 告警规则设计原则
- 避免空泛告警:每个告警规则必须有明确的业务含义和可操作的动作。例如“弃用 API 错误率 > 5%”比“错误率过高”更有价值。
- 合理设置 for 持续时间:对于瞬时故障(如网络抖动),设置
for: 1m或5m;对于资源耗尽类问题,可以设置for: 0立即触发。 - 使用模板变量:在
annotations中使用{{ $value }}、{{ $labels.instance }}等变量,让告警信息更具体。 - 分级告警:通过
labels.severity区分告警级别(critical / warning / info),便于告警接收方区分优先级。
迁移场景告警示例:在 API 弃用迁移期间,建议设置以下告警规则:
1. 弃用 API 调用量异常下降:如果调用量在 1 小时内下降超过 80%,可能表示客户端迁移失败或流量被错误路由。
2. 新 API 错误率突增:新 API 的 5xx 错误率超过 1% 时立即告警,防止迁移导致服务不可用。
3. 迁移进度停滞:如果弃用 API 的调用量在 24 小时内未下降,触发告警提醒人工介入。
1. 弃用 API 调用量异常下降:如果调用量在 1 小时内下降超过 80%,可能表示客户端迁移失败或流量被错误路由。
2. 新 API 错误率突增:新 API 的 5xx 错误率超过 1% 时立即告警,防止迁移导致服务不可用。
3. 迁移进度停滞:如果弃用 API 的调用量在 24 小时内未下降,触发告警提醒人工介入。
3.4 指标类型与 PromQL 联动:可视化与告警
理解指标类型与 PromQL 的联动关系,是构建高效监控体系的关键。下面的 SVG 图展示了从指标采集到告警触发的完整链路。
3.5 实战:为 API 弃用迁移设计监控指标
结合本章的知识点,我们为 API 弃用迁移场景设计一套完整的监控指标和告警规则。下面的 SVG 图展示了指标设计的分层架构。
核心要点总结:
- Counter 用于累计量,必须配合
rate()或increase()使用,不能直接用于告警条件(除非是阈值比较)。 - Gauge 用于瞬时值,可以直接用于告警,但要注意设置合理的
for持续时间避免抖动。 - Histogram 和 Summary 都用于分位数计算,但 Histogram 在服务端计算,Summary 在客户端预计算;Histogram 更灵活,但需要合理设置桶边界。
- PromQL 是连接指标和告警的桥梁,掌握
rate()、histogram_quantile()、by等核心函数是编写高效告警规则的关键。 - 告警规则 应遵循“可操作、可分级、可追溯”原则,避免告警风暴和无效告警。