1. RED 指标体系概述
RED 指标体系是微服务可观测性领域最核心的黄金信号框架之一，由 Google SRE 团队在《Site Reliability Engineering》一书中正式提出。它通过三个关键维度——Rate（速率）、Error（错误）、Duration（持续时间）——对每个服务实例进行健康度与性能画像，帮助 SRE 团队快速定位瓶颈、评估容量、识别异常。
核心定义：RED 指标是面向用户请求的度量模型，每个服务端点都应被 Rate、Error、Duration 三个指标覆盖，形成完整的服务级可观测性基线。
1.1 RED 指标三要素
| 指标 | 定义 | 典型度量方式 | 业务含义 |
|---|---|---|---|
| Rate | 服务每秒处理的请求数（RPS）或每分钟请求数（RPM） | counter 类型指标，按时间窗口聚合（如 1m/5m/1h） | 反映服务负载水平、流量趋势、扩缩容依据 |
| Error | 请求失败的比率或数量 | HTTP 5xx、4xx、业务错误码、超时、异常抛出 | 反映服务正确性、依赖故障、代码缺陷 |
| Duration | 请求处理耗时分布（延迟） | histogram 指标，关注 p50/p90/p99 分位值 | 反映服务性能、用户体验、资源瓶颈 |
实践要点：Duration 指标建议同时记录
p50（典型延迟）、p90（尾部延迟）、p99（极端延迟），三个分位值共同构成完整的延迟画像。
1.2 RED 与 USE 指标的核心区别
USE 指标（Utilization、Saturation、Errors）由 Brendan Gregg 提出，面向系统资源（CPU、内存、磁盘、网络）；RED 指标面向用户请求（服务端点）。两者互补，构成从基础设施到业务请求的全栈可观测性。
| 对比维度 | RED 指标 | USE 指标 |
|---|---|---|
| 观察对象 | 服务请求 / 端点 | 系统资源（CPU、内存、磁盘、网络） |
| 核心问题 | 请求速率多少？错误率多少？延迟多高？ | 资源利用率多高？饱和度如何？是否有错误？ |
| 典型场景 | 微服务调用链、API 网关、业务服务 | 操作系统、容器、中间件、数据库 |
| 指标类型 | Rate（counter）、Error（counter/ratio）、Duration（histogram） | Utilization（gauge）、Saturation（gauge）、Errors（counter） |
| 故障定位方向 | 从用户体验向下排查 | 从资源瓶颈向上排查 |
常见误区：不要将 RED 与 USE 混用在同一张仪表盘上。RED 用于服务级健康看板，USE 用于基础设施容量看板。混合使用会导致信号混淆，增加排障认知负担。
1.3 RED 在微服务可观测性中的核心地位
在微服务架构中，服务数量可能成百上千，调用关系错综复杂。RED 指标之所以成为可观测性的基石，原因如下：
- 信号精简：三个指标即可覆盖服务健康度的 90% 场景，避免指标爆炸。
- 层级统一：每个服务、每个端点都遵循同一套 RED 定义，便于跨服务对比和聚合。
- 故障快速定界：通过 RED 仪表盘，SRE 可在 10 秒内判断是流量突增（Rate 飙升）、代码缺陷（Error 上升）还是资源瓶颈（Duration 恶化）。
- 容量规划基础：Rate 与 Duration 的联合分析可推导出服务饱和度，指导扩缩容决策。
1.4 RED 指标在微服务调用链中的映射
在微服务调用链中，每个服务节点都独立暴露 RED 指标。上游服务调用下游服务时，RED 指标会逐层传递并叠加。例如：
- 网关层：Rate 反映外部流量入口，Error 反映整体可用性，Duration 反映端到端延迟。
- 业务服务层：Rate 反映业务请求量，Error 反映业务逻辑异常，Duration 反映业务处理耗时。
- 基础服务层（如 Redis、MySQL）：Rate 反映查询频率，Error 反映连接/超时异常，Duration 反映存储延迟。
最佳实践：每个微服务至少暴露以下四个指标端点：
requests_total（Rate counter）、requests_duration_seconds（Duration histogram）、requests_errors_total（Error counter）、requests_in_flight（并发量 gauge）。前三个构成标准 RED，第四个用于饱和度判断。
1.5 RED 指标落地要点
- 指标命名规范：统一使用
service_requests_total、service_requests_duration_seconds、service_requests_errors_total格式，便于全局聚合。 - 标签设计：至少包含
service、endpoint、method、status_code四个标签，支持多维下钻。 - 采集周期：Rate 和 Error 建议 10-15 秒采集一次，Duration 建议 30-60 秒聚合一次 histogram。
- 告警规则：Error 率 > 1% 触发警告，> 5% 触发严重；Duration p99 超过基线 2 倍触发警告。
推荐工具链：Prometheus + Grafana 是 RED 指标最成熟的落地组合。Prometheus 负责指标采集与告警，Grafana 负责 RED 仪表盘可视化。配合 Loki 日志和 Tempo 链路追踪，形成完整的可观测性三支柱。