2. Metric Design 基础：设计原则、类型与命名规范
可观测性体系的核心是 Metric（指标）。设计不良的 Metric 会导致告警风暴、误报频发，甚至无法定位故障根因。本节从设计原则、类型选择、命名规范三个维度，建立 Metric Design 的底层共识，为后续异常检测与 MTTR 复盘打下基础。
2.1 Metric 设计三大原则
优秀的 Metric 设计遵循以下原则，确保数据在采集、存储、查询、告警全链路中保持高信噪比。
| 原则 | 说明 | 反例 | 正例 |
|---|---|---|---|
| USE 原则 | 每个资源关注 Utilization（利用率）、Saturation（饱和度）、Errors（错误） | 只监控 CPU 使用率，忽略队列长度 | CPU 使用率 + 运行队列长度 + 错误计数 |
| RED 原则 | 每个服务关注 Rate（速率）、Errors（错误）、Duration（延迟） | 只监控 QPS，忽略错误率 | 请求速率 + 5xx 错误率 + P99 延迟 |
| 面向用户 | 优先定义用户可见的指标（SLO），再推导内部组件指标 | 先定义数据库连接池大小 | 先定义首页加载时间 SLO，再反推各依赖指标 |
实践建议： 新服务上线时，先按 RED 原则定义 3 个黄金指标，再按 USE 原则补充基础设施指标。避免一开始就设计上百个指标，导致存储成本激增和信噪比下降。
2.2 Metric 类型：Counter、Gauge、Histogram
主流可观测性系统（Prometheus、OpenTelemetry）将 Metric 分为三种核心类型。选择错误的类型会导致数据语义失真，直接影响异常检测的准确性。
| 类型 | 语义 | 典型场景 | 运算方式 | 异常检测关注点 |
|---|---|---|---|---|
| Counter | 只增不减的累计值（重启后归零） | 请求总数、错误总数、CPU 时间 | rate() / increase() | 速率突增或突降 |
| Gauge | 可增可减的瞬时值 | 内存使用量、连接数、温度 | 直接取值 / avg() / max() | 阈值越界、波动幅度 |
| Histogram | 观测值的分布统计（桶 + 总和 + 计数） | 请求延迟、响应大小 | histogram_quantile() | 延迟分位数（P50/P99）漂移 |
常见误区： 将延迟用 Gauge 记录每次请求的耗时，而不是用 Histogram。Gauge 会丢失分布信息，无法计算 P99，且频繁更新导致存储膨胀。始终使用 Histogram 记录延迟分布。
2.3 Metric 命名规范
统一的命名规范是团队协作和自动化工具（告警规则、仪表盘、异常检测模型）正确解析指标的前提。推荐遵循 OpenMetrics 命名标准，并结合组织内部约定。
2.3.1 核心命名规则
- 命名空间前缀：使用
namespace_区分层级，如kube_、node_、app_。 - 下划线分隔：全部小写，单词间用下划线连接，禁止使用驼峰或连字符。
- 单位后缀：明确单位，如
_bytes、_seconds、_total、_count。 - 类型后缀：Counter 以
_total结尾，Histogram 包含_bucket、_sum、_count。 - 避免冗余：不重复命名空间内的信息，如
app_requests_total而非app_app_requests_total。
2.3.2 命名规范示例
| 类型 | 错误命名 | 正确命名 | 说明 |
|---|---|---|---|
| Counter | http.requests |
http_requests_total |
使用下划线，加 _total 后缀 |
| Gauge | MemoryUsage |
node_memory_usage_bytes |
小写，加单位后缀 |
| Histogram | latency |
http_request_duration_seconds |
明确单位，自动生成 _bucket/_sum/_count |
| Gauge | cpu_utilization_percent |
node_cpu_utilization_ratio |
优先用 ratio（0-1）而非 percent |
Label 设计原则： Label 是 Metric 的维度标签，用于多维度聚合。避免高基数 Label（如 user_id、request_id），会导致存储爆炸。推荐使用
method、status、endpoint、instance 等有限枚举值。
2.4 设计原则与异常检测的关联
Metric 设计直接影响异常检测模型的输入质量。以下映射关系帮助你在设计阶段就为后续 MTTR 复盘铺路：
- Counter + rate()：适合检测流量突增（如 DDoS、热点事件）或突降（如服务宕机）。
- Gauge + 阈值：适合检测资源耗尽（如内存 OOM、磁盘满），但需配合动态基线避免静态阈值误报。
- Histogram + 分位数：适合检测性能劣化（如 P99 延迟从 200ms 升至 2s），是 MTTR 复盘中最关键的指标类型。
- Label 设计：合理的 Label（如
status、method）允许异常检测模型按维度下钻，快速定位故障范围。
MTTR 复盘视角： 在复盘阶段，Histogram 的
_bucket 数据可以重建故障期间的延迟分布，帮助回答“故障影响了多少比例的请求”、“延迟劣化到哪个分位数”。这是 Counter 和 Gauge 无法提供的诊断能力。