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弃用迁移过程中,从基础设施到业务层的完整监控指标体系,以及各指标之间的关联关系。

API弃用迁移监控指标体系 自定义业务指标 Rate(请求量) Errors(错误率) Duration(延迟) 饱和度(CPU/内存/连接池) 基础设施指标(节点/容器/网络) 迁移验证逻辑: 1. 旧API流量下降 → Rate指标下降;新API流量上升 → Rate指标上升 2. 新API错误率 ≤ 旧API错误率 × 1.1;新API p99延迟 ≤ 旧API p99延迟 × 1.2 3. 自定义业务指标(如注册成功率、订单完成率)必须与旧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指标和饱和度指标都正常,如果业务指标(如订单成功率、支付完成率)出现下降,也必须立即暂停迁移并回滚。