RED、USE 与可观测性方法学

• route 的匹配与嵌套
• 分组（grouping）机制
• 抑制（inhibition）机制

Alertmanager 的 route 配置按标签路由告警到不同 receiver。route 是树状结构，根 route 定义默认 receiver 与聚合配置，子 route 用 match/match_re 按标签匹配（如 severity: critical、team: payment）将告警路由到对应 receiver，告警从上到下匹配，取第一个匹配的 route。分组（grouping）：用 group_by 按标签把告警聚合为一条通知（如按 alertname、cluster 分组），group_wait 等待攒批、group_interval 组内重发间隔、repeat_interval 重复通知间隔，减少告警风暴。抑制（inhibition）：当一条告警被抑制时，抑制其他告警（如某个节点宕机时抑制该节点上所有 Pod 的告警，用 inhibit_rules 配置 source 与 target 标签匹配），避免重复告警干扰。三者的配合：route 决定"告警去哪、如何分组"，inhibit 决定"哪些告警被压住"，共同降低告警噪音、聚焦根因。

route 是"入口分流"，group 是"聚合降噪"，inhibit 是"抑制冗余"。三者结合实现"告警按需送达、风暴收敛、根因聚焦"。配置核心是标签匹配与分组参数。

• 四大黄金信号
• RED 与 USE 的方法
• 三套方法的互补

Google SRE 四大黄金信号是延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation），是服务健康的总览。RED 方法（Rate/Errors/Duration）从服务视角看请求：请求量、错误率、请求耗时，是"服务请求"的三要素。USE 方法（Utilization/Saturation/Errors）从资源视角看：资源利用率、饱和度、错误，是"资源"的三要素。映射关系：黄金信号的"延迟"对应 RED 的 Duration、"错误"对应 RED 的 Errors、"流量"对应 RED 的 Rate、"饱和度"对应 USE 的 Saturation。互补性：RED 面向"服务请求"（用户感知），USE 面向"资源"（底层能力），黄金信号是综合总览。三套方法互补：用 RED 看服务是否健康（请求是否正常）、用 USE 看资源是否够用（是否饱和）、用黄金信号做整体概览。排障时先看黄金信号总览，再用 RED 定位服务、用 USE 定位资源。

三套方法互补的本质是"服务 vs 资源视角"：黄金信号是总览，RED 看服务请求，USE 看资源。它们从不同角度覆盖可观测性，组合使用才能完整定位。

• RED 的三个指标
• 服务视角的含义
• 落地实践

RED 指标是面向"服务请求"的三要素，从服务视角衡量服务健康。Rate（请求量）：单位时间内服务的请求数，反映流量与负载，如 sum(rate(http_requests_total[5m]))；Errors（错误率）：请求失败的比例，反映服务质量，如 HTTP 5xx/4xx 占比、业务错误率；Duration（耗时）：请求处理时间，反映性能，通常用分位数（p50/p95/p99）衡量。RED 的目的是把"服务是否健康"量化成"请求、错误、耗时"三个值，是服务层可观测性的核心。落地时，每个服务暴露这三个指标（埋点或 exporter），结合错误预算与阈值的告警。RED 面向"用户视角"——服务是否正常响应、是否快速、是否无错误，区别于 USE 的资源视角。排障时先看 RED 判断服务是否异常，再下钻。

RED 是"服务请求的三维健康度"：量、质、速。它回答"服务是否正常"（用户视角），为告警与 SLO 提供基础。核心是把每个服务的三指标标准化暴露。

• 请求量的度量
• 流量突增的解读
• 流量突降的解读

请求量（Rate）是单位时间内进入服务的请求数，用计数器速率计算，如 sum(rate(http_requests_total[5m])) by (service)，按服务/端点/环境维度聚合。度量时用 rate 平滑窗口，避免瞬时抖动；区分正常流量波动与异常。流量突增可能说明：正常增长（业务上涨、促销）、异常爬虫/攻击（DDoS）、错误重试放大（客户端重试导致流量放大）、发布后流量变化。流量突降可能说明：上游不再调用（链路断裂、依赖异常）、服务不可达（健康检查失败、接入层故障）、流量被分流、业务低峰/故障。解读关键：结合上下文——突增看是否伴随错误率上升（判断是攻击/重试还是正常），突降看是否伴随上游错误（判断链路断裂）。请求量是"第一信号"，突增/突降都需要结合错误率与延迟判断根因。

请求量的解读不能孤立：突增/突降只是现象，需结合 Errors 与 Duration 判断是正常波动、攻击、重试放大还是链路断裂。度量用 rate 平滑窗口。

• 错误率的定义
• 应计入的错误类型
• 阈值设定

错误率（Error rate）是失败请求占全部请求的比例，定义需明确"什么是错误"。应计入的错误：HTTP 5xx（服务端错误）、超时、业务明确失败（如下单失败、支付失败）、异常返回；是否计入 4xx 需权衡——4xx 多为客户端错误，通常不计入服务错误率，但业务语义错误（如校验失败）是否计入需按业务定义。度量用 sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))，错误与请求用同一计数器统计。阈值设定：基于错误预算与 SLO，如正常错误率 < 1%，SLO 定义 99.9% 成功率则错误率 < 0.1%；阈值需按服务重要性分层（核心服务更严），并设置窗口（如 5 分钟错误率超阈值告警）避免瞬时抖动。关键：错误定义要一致（埋点与告警用同一标准），否则误报。

错误率的核心是"错误定义"与"阈值"：明确哪些计入（5xx、超时、业务失败），阈值与 SLO/错误预算绑定并按服务分层。定义一致性是避免误报的关键。

• Apdex 的计算公式
• 阈值（T）设定
• 用户感知量化

Apdex（应用性能指数）把用户感知的响应时间量化成 0-1 的单一分数。计算公式：设定一个满意阈值 T（如 200ms），响应时间 ≤ T 记为"满意"（1 分），T < 响应时间 ≤ 4T 记为"可容忍"（0.5 分），> 4T 记为"不满意"（0 分）。Apdex =（满意数 + 0.5×可容忍数）/ 总请求数。T 的设定是关键：取用户可接受的响应时间（如 200-500ms），通常取 p50 或业务目标值，4T 是容忍上限。Apdex 的价值：把"响应时间分布"压缩成单一分数，便于跨服务对比与趋势监控，反映用户真实体验（而非只看平均）。阈值设定：T 按业务场景（如页面 < 500ms、接口 < 200ms），Apdex 目标（如 0.9）作为性能 KPI。Apdex 分数下降说明体验变差，可结合分位数定位。

Apdex 的核心是"用 T 和 4T 把响应时间分成三档并加权"：满意 1 分、可容忍 0.5、不满意 0，得到 0-1 分数。T 的设定反映用户阈值，是关键调参。

• RED 告警阈值设计
• USE 告警阈值设计
• 阈值联动

RED 指标（请求错误率、延迟）与 USE 指标（资源利用率、饱和度）在告警阈值设计中需联动。RED 告警：错误率超阈值（如 5% 5 分钟）、p99 延迟超阈值（如 500ms），反映服务请求是否正常。USE 告警：CPU/内存/磁盘利用率超阈值（如 85%）、饱和度（等待队列、IO 压力）超阈值，反映资源是否够用。联动的意义：错误率/延迟上升往往由资源饱和驱动——当请求错误率升高时，需同时看资源利用率是否饱和，判断是"资源不足导致"还是"服务自身问题"。设计上：设置资源饱和度预警（如 80% 预警、90% 告警），当资源饱和时主动扩容，避免其演变为错误率上升；错误率告警与资源告警关联，排障时先看资源是否饱和。联动原则：资源饱和是"根因预警"，错误率/延迟恶化是"结果告警"，两者结合实现"先预防、后响应"。

联动的核心是"资源饱和是根因、请求恶化是结果"：资源利用率告警是前置预警，错误率/延迟告警是结果告警，两者结合避免"只等结果恶化"。

• USE 的三个指标
• 资源视角的含义
• 落地实践

USE 指标从资源视角评估资源（CPU、内存、磁盘、网络），包括 Utilization（利用率）、Saturation（饱和度）、Errors（错误）。Utilization：资源在给定时间被使用的比例，如 CPU 利用率、内存使用率、磁盘空间、网络带宽，反映"资源被占多少"；Saturation：资源有多少排队/过载，如 CPU 运行队列长度、磁盘 IO 等待、内存 swap、网络丢包，反映"资源是否超额"；Errors：资源层的错误，如磁盘 IO 错误、网络错误、内存分配失败，反映"资源是否故障"。USE 适合"资源节点"诊断：当 Utilization 高时看 Saturation 判断是否过载，看 Errors 判断是否故障。它与 RED 互补：RED 看服务请求，USE 看底层资源。落地时对每个资源暴露 Utilization/Saturation/Errors 三指标，配合告警与容量规划。

USE 是"资源的健康三要素"：利用率看占用、饱和度看过载、错误看故障。它回答"资源是否够用、是否过载、是否故障"，是资源层诊断的核心方法。

• burn rate 的概念
• 多窗口告警
• 减少误报与漏报

burn rate（错误预算燃烧速率）是实际错误率与 SLO 允许错误率的比值，表示错误预算消耗的速度。如 SLO 允许 0.1% 错误率，实际 0.5%，burn rate = 5，即 5 倍速消耗预算。多窗口告警设计：用 burn rate 触发告警，设置多个时间窗口（如 1 小时、5 分钟）分别设阈值——短窗口（高 burn rate）快速发现严重问题，长窗口（低 burn rate）发现持续轻微问题，避免单一窗口的误报/漏报。例如：1 小时窗口 burn rate ≥ 14 告警（严重，快速响应），5 分钟窗口 burn rate ≥ 5 告警（中）；1 小时窗口 burn rate ≥ 6 告警（警告，持续劣化）。相比静态阈值，burn rate 告警的优势：与 SLO 绑定（反映预算消耗），减少误报（短窗口需高 burn rate 才触发，避免偶发抖动），减少漏报（长窗口捕捉持续低水平超标）。核心是"用预算消耗速率 + 多窗口"替代"单一静态阈值"。

burn rate 告警的核心是"与错误预算绑定 + 多窗口多层级"：短窗口高 burn rate 快速发现严重问题，长窗口低 burn rate 抓持续劣化，兼顾误报与漏报。比静态阈值更贴合 SLO。

• 分组去重
• 抑制去重
• 告警风暴控制

Alertmanager 通过分组与抑制去重告警。分组（grouping）：用 group_by 按标签（如 alertname、cluster、instance）把同类告警聚合为一条通知，group_wait 等在窗口内攒批、group_interval 限制组内重发、repeat_interval 限制重复通知，避免同一告警反复通知（如 100 个实例同时触发同一告警只发一条）。抑制（inhibition）：用 inhibit_rules 配置父子关系——当 source 告警存在时抑制 target 告警（如节点宕机时抑制该节点上所有 Pod 告警，根因告警抑制派生告警），减少重复与噪音。两者叠加：分组把"同类"合并，抑制把"由根因派生的"压住，配合告警静默（silence）使告警风暴收敛。去重后告警聚焦根因，减少值班干扰。关键是合理配置 group_by 标签与 inhibit 规则，避免过度抑制漏掉关键告警。

去重的核心是"同类合并（分组）+ 根因压制（抑制）"：分组把同类聚合，抑制把派生告警压住，配合静默收敛风暴。核心是标签与规则配置。

• SLI 的定义
• 错误率/延迟转 SLI
• 错误预算

SLI（服务级别指标）是衡量服务质量的量化指标，RED 中的错误率与延迟可转化为 SLI。如"可用性 SLI" = 成功请求比例（1 - 错误率），"延迟 SLI" = 满足耗时阈值的请求比例（如 p99 或 Apdex）。转化方式：从 RED 指标计算——可用性 = 1 - 错误率，延迟达标率 = 满足阈值请求 / 总请求。SLO 是对 SLI 的目标值（如可用性 ≥ 99.9%），错误预算 = 1 - SLO（如 0.1%），表示允许失联的额度。错误预算管理：监控实际错误率相对 SLO 的消耗（burn rate），当预算快耗尽时进入"冻结发布"（冻结新功能、优先修复），通过减少变更保护预算。RED/USE 与 SLO 关联：RED 的请求量/错误率/延迟是 SLI 的数据源，USE 的资源指标支撑容量（保证错误率不因资源不足超标）。SLO 把 RED 指标转化为"可量化的目标"并驱动工程决策。

关联的核心是"RED 提供 SLI 数据，SLO 设定目标，错误预算驱动决策"：错误率/延迟转成 SLI，SLO 定义目标，错误预算控制发布节奏。这是 SRE 的核心闭环。

• eBPF 自动观测的指标
• 对 RED/USE 的补充
• 替代手动埋点的边界

eBPF 自动观测（如 Pixie、Cilium Hubble）通过内核观测，无侵入地采集请求级指标与网络指标，影响 RED/USE 方法。对 RED 的补充：eBPF 自动解析 HTTP/gRPC/DNS 流量，生成请求量、错误率、延迟（RED 指标），无需应用埋点即可覆盖；对 USE 的补充：eBPF 采集网络/内核指标（吞吐、丢包、重传、运行队列），补充资源层的 utilization/saturation。价值：无侵入覆盖未埋点或第三方服务，快速获得 RED/USE 指标，降低埋点成本。替代手动埋点的边界：eBPF 能观测"网络可见的请求"（HTTP/gRPC/DNS），但无法观测"业务内部语义"（应用层业务逻辑、自研状态、非网络操作），这些仍需手动埋点。因此 eBPF 是"补充与快速覆盖"，手动埋点保留"业务语义精度"，两者结合：eBPF 提供通用请求与资源指标，手动埋点补充业务细节。

eBPF 自动观测的价值是"无侵入补全 RED/USE 指标"，但受限于"网络可见"边界，业务语义仍需手动埋点。两者是"通用覆盖 + 业务精度"的互补，而非完全替代。

• 仪表盘分层
• 各视图分工
• 避免大盘臃肿

仪表盘分层设计的核心是"按视角拆分，避免一张盘塞满所有指标"。服务视图：展示服务请求层面的 RED 指标（请求量、错误率、延迟、SLO），回答"服务是否正常"，面向服务 owner；资源视图：展示 USE 指标（CPU、内存、磁盘、网络利用率/饱和度/错误），回答"资源是否够用、是否过载"，面向基础架构；容量视图：展示容量使用趋势、预测与配额（如存储用量、节点数、扩缩容），回答"容量是否够用、何时不足"，面向容量规划。分工：服务视图看"用户感知"，资源视图看"底层支撑"，容量视图看"未来趋势"。避免盘臃肿：每张盘聚焦单一视角与目标受众，用 drill-down（下钻）从总览到明细，按需分层（总览→服务→资源→容量），避免把不同视角、不同受众的指标混在一张盘。平衡"信息完整"与"可读性"。

分层设计的核心是"视角分离 + 目标受众分离"：服务视图像用户、资源视图像支撑、容量视图像未来，用下钻而非堆叠。避免臃肿的关键是单一视角、按需下钻。

• 分层监控的层级
• 各层指标
• 可下钻的组织

分层监控按业务层、服务层、资源层组织，形成可下钻的体系。业务层：业务结果指标（订单量、转化率、营收、用户量），反映业务健康，面向业务与产品；服务层：服务请求指标（RED：请求量、错误率、延迟、SLO），反映服务健康，面向服务 owner；资源层：基础设施指标（USE：CPU、内存、磁盘、网络利用率/饱和度），反映资源健康，面向平台。组织成可下钻体系：用统一标签（如 service、cluster、namespace）关联各层，从业务层异常（如订单量下降）下钻到服务层（哪个服务错误率升高）再下钻到资源层（哪个资源饱和），形成"业务→服务→资源"的定位链路。实现上，各层指标用一致维度标签，仪表盘用 drill-down 联动，告警按层分级（业务层告警、服务层告警、资源层告警）。分层监控的价值是"逐层定位、快速下钻"，避免大海捞针。

分层监控的核心是"按业务-服务-资源三层组织 + 统一标签联动下钻"：业务异常下钻到服务再到资源，形成定位链路。统一标签是打通分层的关键。

• 四支柱的定义
• 各自的角色
• 互补关系

可观测性四支柱为指标、日志、追踪与事件。指标（Metrics）：聚合的数值，反映系统状态与趋势（如 CPU、请求量、错误率），适合监控、告警与容量；日志（Logs）：事件级记录，反映系统运行细节（异常堆栈、业务信息），适合排障与审计；追踪（Traces）：请求调用链，反映跨服务的一次请求全貌（各段耗时），适合定位瓶颈与延迟；事件（Events）：离散的结构化变更记录（部署、配置、故障、扩容），提供上下文，解释"为什么变化"。互补关系：指标抓"整体状态"（看趋势与告警），日志抓"细节"（看发生了什么），追踪抓"链路"（看请求全貌），事件抓"上下文"（看变更原因）。四者配合：指标告警 → 事件解释变更 → 追踪定位链路 → 日志深挖细节，形成完整排障闭环。现代可观测性强调四支柱的统一（用 trace_id 关联日志与追踪，指标与事件关联）。

四支柱的互补是"不同粒度与视角"：指标看状态、日志看细节、追踪看链路、事件看上下文。用关联键统一，形成"状态-原因-链路-细节"的完整画像。

• 高价值指标识别
• 指标数量控制
• 避免爆炸与臃肿

指标选型的目标是"每个服务挑选少量高价值指标"，避免指标爆炸。高价值指标识别：优先选能反映"服务健康与用户感知"的指标——RED 指标（请求量、错误率、延迟）、SLO 相关指标、关键业务指标；围绕"服务是否有问题、是否够用"选择，而非追求面面俱到。数量控制：每个服务锁定 5-10 个核心指标（如 RED + 关键资源 + 业务 KPI），用维度（标签）而非新增指标表达细分；把低频、探索性指标设为可选/按需开启。避免爆炸：控制标签基数（不用高基数标签）、避免相似指标重复、用 recording rules 聚合预计算、native 归并。避免仪表盘臃肿：按视角分层（服务/资源/容量），每张盘聚焦核心指标，用下钻而非堆叠。指标选型原则是"少而精、围绕健康与用户感知"，用统一模板（RED/USE）保证一致性。

指标选型的核心是"围绕健康与用户感知选少而精的指标"：RED 是基础，控制标签基数与数量，分层展示避免臃肿。核心是"少而精 + 高价值导向"。

• 静态阈值
• 分位数基线
• 时序异常检测

指标阈值设定有静态阈值、分位数基线、时序异常检测三种方法。静态阈值：固定阈值（如 CPU > 90%、错误率 > 5%），简单直观、可解释，适合稳定、可预知的指标（资源利用率、明显错误），但无法适应季节性波动，需人工调参。分位数基线：用历史数据的分位数（如 p95）作为动态基线，阈值随基线波动，适合有波动的指标（延迟、流量），能适应变化，但需足够历史数据与季节性处理。时序异常检测：用机器学习/统计模型（如 3σ、ARIMA、AI 检测）学习正常模式，检测偏离，适合复杂、多变的指标，能自动适应但不直观、需调参与样本。调参要点：静态阈值设合理冗余与窗口（避免抖动）；分位数基线选对分位与窗口（平滑程度）；异常检测平衡灵敏度与误报（窗口、灵敏度、回看周期）。选择依据：指标特性（稳定/波动/复杂）与可解释性需求，常结合使用（静态阈值兜底 + 基线/检测适应波动）。

阈值方法的选择是"复杂度 vs 可解释性"的权衡：静态简单直观但呆板，分位基线适应波动，异常检测自动聪明但不直观。按指标特性与可解释性选择并组合。

• RED 的适用场景
• USE 的适用场景
• 日志与追踪的深挖

方法学的适用边界：RED 用于"服务请求"层面——当问题表现为"服务异常"（请求失败、延迟高、错误率升）时，用 RED 看服务的请求量、错误率、延迟，判断服务是否健康；USE 用于"资源"层面——当问题表现为"资源不足/过载"（CPU 高、内存不足、磁盘满、网络拥塞）时，用 USE 看资源的利用率、饱和度、错误，判断资源是否够用；日志与追踪用于"深挖"——当 RED/USE 定位到"哪个服务/资源异常"后，用日志看细节（异常堆栈、业务信息）、用追踪看调用链（各段耗时、跨服务依赖），定位具体根因。适用边界：RED 回答"服务请求是否正常"，USE 回答"资源是否够用"，日志/追踪回答"为什么异常"。实践上按"先 RED/USE 定性、再日志/追踪定位"的顺序，避免一开始就深挖。若 RED 正常但业务异常，直接查日志/业务；若资源正常但请求异常，查应用与链路。

适用边界的核心是"诊断层级"：RED 看服务、USE 看资源、日志/追踪深挖根因。依"先定性后定位"的顺序，避免盲目深挖。

• 服务指标与资源指标关联
• 延迟升高的下钻
• 定位根因

请求延迟升高时，需从服务指标下钻到资源层定位根因。下钻流程：一、服务层确认——用 RED 指标确认延迟升高，定位到具体服务/端点；二、资源层关联——查看该服务所在实例的 USE 指标（CPU、内存、磁盘 IO、网络），判断资源是否瓶颈；三、逐类排查——CPU 高（是否计算密集、GC 频繁、锁竞争）、内存高（是否 GC、内存泄漏、OOM）、磁盘 IO 高（是否慢查询、日志刷盘、IO 等待）、网络高（是否带宽饱和、丢包、重传）；四、结合追踪与日志——用追踪看延迟分布在哪段（自身处理 vs 外部依赖），用日志看异常堆栈；五、定位根因——资源饱和（如 CPU 100% 导致请求排队）或等待外部（如 DB 慢导致 IO 等待）。关联分析的价值是把"服务现象"（延迟高）与"资源原因"（CPU/IO/网络）打通，用同一时间窗口对齐指标，判断是"资源不足"还是"服务自身逻辑"问题。

关联分析的核心是"服务现象 + 资源原因 + 时间对齐"：先 RED 确认服务异常，再用 USE 看资源瓶颈，用追踪/日志深挖，最终区分"资源不足"与"服务逻辑"问题。