容量压测异常检测与多维水位阈值校准 - 第1节
1.1 Metric 的定义与本质
Metric（度量指标）是系统在某一时刻或某一时间窗口内可量化的观测值，是可观测性工程的基石。一个合格的 Metric 必须满足：可采集、可聚合、可对比。它通常由 指标名称、标签（Label/Tag） 和 数值 三部分组成。
| 组成部分 | 说明 | 示例 |
|---|---|---|
| 指标名称 | 描述被观测对象的语义 | http_requests_total |
| 标签 | 维度信息，用于分组和过滤 | method="GET", status="200" |
| 数值 | 具体的测量值（整数、浮点数） | 1024 |
设计原则： Metric 名称应遵循
命名空间_子系统_单位_类型 的规范，例如 app_db_query_duration_seconds。避免在名称中嵌入可变维度，应使用标签承载。
1.2 四大黄金信号（The Four Golden Signals）
Google SRE 经典著作中提出的四大黄金信号，是衡量用户面对系统时最核心的四个维度。任何 Metric 设计都应优先覆盖这四个方面。
- 延迟（Latency）： 请求处理所花费的时间。区分成功请求与失败请求的延迟，避免平均值掩盖长尾问题。
- 流量（Traffic）： 系统承载的请求量级。对于 Web 服务是 QPS/RPS，对于数据库是 TPS，对于网络是带宽吞吐。
- 错误（Errors）： 显式错误（HTTP 5xx）与隐式错误（返回 200 但业务逻辑错误）。
- 饱和度（Saturation）： 系统资源被占用的程度，通常表现为排队长度或利用率超过阈值。
实战建议： 在建设新系统的 Metric 时，先问自己：“这四个信号是否都有至少一个核心指标覆盖？” 如果缺少任何一个，说明可观测性存在盲区。
1.3 USE 方法论（资源视角）
USE 方法论由 Brendan Gregg 提出，专注于 资源 维度的检查，适用于硬件、软件资源（CPU、内存、磁盘、网络、连接池等）。
| 维度 | 含义 | 典型指标示例 |
|---|---|---|
| Utilization | 资源忙于服务的时间占比 | CPU 使用率、磁盘 I/O 利用率 |
| Saturation | 资源无法及时服务的额外排队量 | CPU 运行队列长度、磁盘 I/O 等待队列 |
| Errors | 资源层面的错误计数 | 网卡丢包、磁盘坏道、内存 ECC 错误 |
注意： USE 方法论不直接关注延迟，因为延迟通常是饱和度的结果。如果发现延迟升高，应优先检查对应资源的饱和度指标。
1.4 RED 方法论（服务视角）
RED 方法论由 Tom Wilkie 提出，专注于 服务 维度的检查，适用于微服务、API 网关等请求驱动型组件。
| 维度 | 含义 | 典型指标示例 |
|---|---|---|
| Rate | 每秒请求数（QPS/RPS） | rate(http_requests_total[1m]) |
| Errors | 失败请求的比例或计数 | rate(http_requests_total{status=~"5.."}[1m]) |
| Duration | 请求处理耗时分布 | histogram_quantile(0.99, ...) |
选择指南： 对于基础设施层（主机、容器、中间件），优先使用 USE；对于业务服务层（API、微服务），优先使用 RED。两者互补，共同构成完整的可观测性视图。
1.5 三大方法论对比与融合
1.6 Metric 设计在异常检测与容量压测中的定位
Metric 设计不是孤立的工作，它直接决定了后续异常检测的灵敏度和容量压测的准确性。
- 异常检测： 依赖高分辨率、多维度的时间序列数据。如果 Metric 设计缺少饱和度指标，系统在过载前将无任何告警。
- 容量压测： 需要明确的水位阈值（如 CPU 利用率 70% 为警告，85% 为危险）。这些阈值必须基于 USE/RED 方法论定义，并与业务 SLI 挂钩。
- 水位口径优化： 不同资源的水位定义不同（如 CPU 使用率 vs 磁盘 I/O 等待），Metric 设计必须统一口径，避免“鸡同鸭讲”。
核心结论： 一个设计良好的 Metric 体系，能让异常检测提前 5-10 分钟发现风险，能让容量压测的“水位线”与真实故障点误差小于 10%。这是 SRE 从“被动救火”转向“主动预防”的关键一步。