4. API监控指标体系:请求量、错误率、延迟(RED指标)、饱和度、自定义业务指标
在API弃用迁移过程中,监控体系是判断迁移是否成功、新API是否稳定、旧API是否可安全下线的核心依据。本章围绕RED指标(Rate、Errors、Duration)与饱和度、自定义业务指标,构建完整的API监控指标体系,确保迁移过程可观测、可量化、可告警。
4.1 RED指标:API可观测性的黄金三角
RED指标由Google SRE团队提出,是衡量微服务/API健康度的最小必要集合。在API弃用迁移场景中,RED指标用于对比新旧API的实时表现,验证新API是否达到或超越旧API的服务水平。
| 指标类别 | Prometheus指标名示例 | 含义 | 迁移场景关注点 |
|---|---|---|---|
| Rate(请求量) | api_requests_total |
每秒/每分钟的请求总数 | 旧API流量是否按计划迁移到新API;新API是否承载了预期流量 |
| Errors(错误率) | api_errors_total |
请求失败的比例(4xx/5xx) | 新API错误率是否高于旧API;迁移后是否引入新的错误模式 |
| Duration(延迟) | api_duration_seconds |
请求响应时间的分布(p50/p95/p99) | 新API延迟是否劣化;是否存在长尾请求影响用户体验 |
迁移最佳实践:在迁移窗口期内,同时保留新旧API的RED指标,使用PromQL的
rate()函数计算每秒速率,通过histogram_quantile()计算延迟分位数。对比两组指标时,建议设置1.2倍阈值——新API的p99延迟不应超过旧API的1.2倍,否则触发告警。
4.2 饱和度指标:容量与资源瓶颈
饱和度衡量API服务接近容量极限的程度。在弃用迁移中,新API可能因流量突增而达到资源瓶颈,旧API可能因流量减少而出现资源浪费。饱和度指标帮助SRE在迁移过程中动态调整资源分配。
- CPU饱和度:
node_cpu_seconds_total→ 使用率 > 80% 触发扩容 - 内存饱和度:
node_memory_MemAvailable_bytes→ 可用内存 < 20% 触发告警 - 连接池饱和度:
api_connections_active / api_connections_max→ 比例 > 0.8 需扩容 - 队列深度:
api_queue_length→ 持续增长表明处理能力不足
迁移陷阱:旧API流量下降后,如果未及时缩容,会造成资源浪费;新API流量上升时,如果未提前扩容,可能因资源不足导致错误率飙升。建议在迁移计划中预设自动扩缩容策略,基于饱和度指标触发HPA(Horizontal Pod Autoscaler)。
4.3 自定义业务指标:迁移成功的关键验证
RED指标和饱和度指标反映系统层面的健康度,但无法回答“业务是否正常”。自定义业务指标直接衡量API的业务价值,是迁移是否成功的最终判断依据。
| 业务场景 | 自定义指标示例 | Prometheus指标名 | 迁移验证逻辑 |
|---|---|---|---|
| 用户注册 | 注册成功率 | user_registration_success_total |
新API注册成功率 ≥ 旧API |
| 订单创建 | 订单创建耗时 | order_create_duration_seconds |
新API p95耗时 ≤ 旧API × 1.1 |
| 数据查询 | 查询结果完整性 | query_result_count |
新API返回数据条数与旧API一致 |
| 支付回调 | 回调成功率 | payment_callback_success_total |
新API回调成功率 ≥ 99.9% |
4.4 指标体系架构图
下图展示了API弃用迁移过程中,从基础设施到业务层的完整监控指标体系,以及各指标之间的关联关系。
4.5 Prometheus指标采集与告警规则
以下是一组针对API弃用迁移场景的Prometheus告警规则示例,覆盖RED指标、饱和度和自定义业务指标。
groups:
- name: api_migration_alerts
rules:
# RED指标告警
- alert: NewAPIErrorRateHigh
expr: |
rate(new_api_errors_total[5m]) / rate(new_api_requests_total[5m]) >
rate(old_api_errors_total[5m]) / rate(old_api_requests_total[5m]) * 1.1
for: 5m
labels:
severity: critical
annotations:
summary: "新API错误率超过旧API的1.1倍"
- alert: NewAPILatencyHigh
expr: |
histogram_quantile(0.99, rate(new_api_duration_seconds_bucket[5m])) >
histogram_quantile(0.99, rate(old_api_duration_seconds_bucket[5m])) * 1.2
for: 5m
labels:
severity: warning
annotations:
summary: "新API p99延迟超过旧API的1.2倍"
# 饱和度告警
- alert: NewAPICPUHigh
expr: |
avg by (pod) (rate(container_cpu_usage_seconds_total{container="new-api"}[5m])) > 0.8
for: 3m
labels:
severity: warning
annotations:
summary: "新API CPU使用率超过80%"
# 自定义业务指标告警
- alert: RegistrationSuccessRateDrop
expr: |
rate(user_registration_success_total{api_version="v2"}[5m]) / rate(user_registration_total{api_version="v2"}[5m]) < 0.99
for: 5m
labels:
severity: critical
annotations:
summary: "新API注册成功率低于99%"
4.6 迁移过程中的指标对比策略
在弃用迁移的不同阶段,监控指标的关注重点有所不同。下表总结了各阶段的指标对比策略:
| 迁移阶段 | 核心关注指标 | 对比方式 | 成功标准 |
|---|---|---|---|
| 灰度验证期 | 错误率、延迟、自定义业务指标 | 新API vs 旧API 实时对比 | 新API所有指标不劣于旧API |
| 流量迁移期 | 请求量、饱和度、错误率 | 新API流量占比 vs 预期占比 | 流量按计划迁移,无资源瓶颈 |
| 旧API下线期 | 请求量(旧API趋零)、自定义业务指标 | 旧API流量归零验证 | 旧API连续7天无有效请求 |
关键原则:在迁移全过程中,始终以自定义业务指标作为最终判断依据。即使RED指标和饱和度指标都正常,如果业务指标(如订单成功率、支付完成率)出现下降,也必须立即暂停迁移并回滚。