RED 方法是什么
RED 是面向请求型服务的最小监控集合：Rate 请求速率、Errors 错误比例、Duration 耗时分布。它由 Tom Wilkie 提出，主张服务的健康度只需这三个指标就能覆盖，任何一次发布或故障变化都会在这三条曲线上体现，特别适合微服务与 API 网关这类请求驱动的组件。
基本信息
| 适用对象 | 受理请求的服务：HTTP/gRPC/RPC、消息队列消费者 |
|---|---|
| 三个指标 | Rate 请求速率 / Errors 错误比例 / Duration 耗时分布 |
| 常用维度 | service、route（路径模板）、method、status |
| 配套方法 | 资源侧用 USE 方法（利用率、饱和度、错误） |
典型使用场景
- 服务面板模板：同一套三个查询复制到所有服务，看板维护成本极低
- 发布效果验证：发布后比较 Rate 是否下降、Errors 是否抬升、Duration 是否偏移
- 接口级定位：按 route 拆分后能直接看到是哪个接口拖慢了整体
- 容量规划：Rate 的长期增长曲线与实例数对比，判断扩容时机
- SLO 度量：Errors 与 Duration 直接构成成功率与延迟两类 SLI
三个指标的查询要点
| 指标 | 推荐函数 | 注意点 |
|---|---|---|
| Rate | rate() 或 irate() | 用 rate 做告警更平稳，irate 适合看瞬时变化 |
| Errors | sum(rate()) 后做除法 | 只算 5xx 会漏业务失败，需按接口语义补充 |
| Duration | histogram_quantile 配合 le 聚合 | 不能对分位数再做平均，需从桶重算 |
RED 三件套查询
RED 三件套查询
# Rate：每秒请求数（按服务聚合）
sum by (service) (rate(http_requests_total[5m]))
# Errors：5xx 请求占比
sum by (service) (rate(http_requests_total{code=~"5.."}[5m]))
/ sum by (service) (rate(http_requests_total[5m]))
# Duration：P99 耗时（先聚合桶再算分位）
histogram_quantile(0.99, sum by (service, le) (rate(http_request_duration_seconds_bucket[5m])))按 route 拆分后的读法
| 现象 | 方向 | 下一步 |
|---|---|---|
| 某 route 的 Rate 下降 | 上游调用减少或路由被摘除 | 查网关配置与上游改动记录 |
| 某 route 的 Errors 抬升 | 该接口自身或独占依赖异常 | 取 trace_id 查链路，定位下游 |
| 整体 Duration 上抬 | 公共依赖变慢（DB、缓存、下游） | 对比各 route，看是否同时劣化 |
| 仅高峰时段劣化 | 容量不足或连接池耗尽 | 结合饱和度与线程池指标判断 |
RED 聚焦请求结果，回答不慢不坏；遇到慢的问题时再配合 USE 方法检查资源侧瓶颈，两者是互补关系而非竞争关系。
把错误只定义为 5xx 会漏掉业务级失败：HTTP 200 但响应体业务码非零、部分成功、静默降级都需要按接口语义补充错误标签。
与黄金指标和 USE 的关系
RED 可以看作黄金指标面向请求型服务的落地版本：Rate 对应流量，Errors 对应错误，Duration 对应延迟，缺的是偏资源侧的饱和度，因此要靠 USE 补上。三个指标的取数都来自同一份请求埋点，只要在应用侧统一指标名与标签口径，就能用同一套查询模板覆盖所有服务。
落地时的常见约定
- 指标命名固定为 <域>_requests_total 与 <域>_request_duration_seconds，避免每个团队各起一套名字
- 状态标签使用标准状态码，不要自造二值标签，否则无法按错误类型细分
- 路由标签用路径模板而不是原始 URL，既控制基数又保留可读性
- 错误定义写入接口契约：业务失败用独立标签体现，不要混进 5xx 计数
- 看板与告警共用同一份查询表达式，避免两处口径随时间漂移
三个指标的窗口长度要与告警持续时长匹配：五分钟窗口配五到十分钟的持续判断，通常能在灵敏度与抖动之间取得平衡。
异常组合的排查方向
| 组合 | 可能原因 | 排查方向 |
|---|---|---|
| Rate 降、Errors 升 | 上游摘流或大量请求失败 | 查网关配置与上游变更记录 |
| Errors 升、Duration 平 | 部分请求快速失败，如连接被拒 | 查依赖可用性与连接池上限 |
| Duration 升、Errors 平 | 依赖变慢但仍在超时阈值内 | 看链路定位具体下游耗时 |
| 三者同时劣化 | 公共依赖或基础设施故障 | 先看饱和度，再查数据库与网络 |
三个指标要组合起来看：单条曲线的变化方向往往有多种解释，组合判断才能快速收窄假设范围。