2. Metric Design 原则：指标设计四大黄金信号、指标命名规范、标签（Label）设计最佳实践
在可观测性体系中，指标（Metric）是误差预算台账最核心的数据载体。若指标设计先天不足，后续的采集、存储、查询、告警都将付出高昂的运维成本。本章围绕 四大黄金信号、命名规范 与 标签设计 三个维度，建立 Metric Design 的工程化准则。
2.1 四大黄金信号：从 USE/RED 到 Golden Signals
Google SRE 经典著作《Site Reliability Engineering》提出了监控的 四大黄金信号（Golden Signals）：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。这四类信号覆盖了用户侧与系统侧的可观测性需求，是误差预算指标设计的起点。
| 黄金信号 | 定义 | 典型指标示例 | 与误差预算的关系 |
|---|---|---|---|
| 延迟（Latency） | 请求从发出到收到响应的时间 | http_request_duration_seconds |
高延迟直接降低用户体验，触发 SLO 燃烧速率告警 |
| 流量（Traffic） | 系统承载的请求量或数据量 | http_requests_total |
流量突增可能导致错误率上升，消耗误差预算 |
| 错误（Errors） | 请求失败或返回错误码的比例 | http_requests_errors_total |
错误率直接扣减误差预算，是告警的核心依据 |
| 饱和度（Saturation） | 资源使用程度，通常以百分比表示 | cpu_utilization_ratio |
饱和度接近 100% 时，延迟和错误率会急剧恶化 |
实践建议： 在误差预算台账中，延迟 和 错误 应作为 直接指标 纳入 SLO 计算；流量 和 饱和度 作为 辅助指标，用于根因分析和容量规划。
2.2 指标命名规范：可读性、层级与可发现性
混乱的指标命名是运维事故的温床。一个规范的指标名应具备 可读性、层级结构 和 可发现性。推荐遵循 Prometheus 命名规范 并结合企业自身领域进行扩展。
2.2.1 命名基本规则
- 前缀（Namespace）：使用
层级_组件_结构，例如k8s_node_cpu_、http_request_duration_。 - 基础单位（Base Unit）：指标名末尾应包含单位，如
_seconds、_bytes、_total、_ratio。 - 动词优先：使用
_total表示累计值，_count表示计数，_sum表示求和。 - 禁止缩写：除非是业界公认缩写（如
http、cpu、mem），否则使用全称。
2.2.2 命名规范对比表
| 场景 | 反例（不推荐） | 正例（推荐） | 说明 |
|---|---|---|---|
| HTTP 请求延迟 | req_time |
http_request_duration_seconds |
包含协议、操作、单位 |
| 数据库查询错误数 | db_err |
db_query_errors_total |
明确对象、操作、累计类型 |
| CPU 使用率 | cpu_used |
node_cpu_utilization_ratio |
包含层级、资源、单位 |
| 队列长度 | q_len |
queue_size_current |
使用全称，明确当前值 |
关键原则： 指标名应让新加入的 SRE 在 3 秒内理解其含义。如果做不到，说明命名需要重构。
2.3 标签（Label）设计最佳实践：维度爆炸与基数控制
标签是指标的维度属性，决定了指标的 可聚合性 与 查询灵活性。但标签设计不当会导致 基数爆炸（Cardinality Explosion），拖垮时序数据库。
2.3.1 标签设计核心原则
- 高基数标签必须避免：如
user_id、request_id、session_id等唯一标识符，不应作为标签。 - 有限枚举值标签优先：如
method（GET/POST/PUT/DELETE）、status_code（2xx/3xx/4xx/5xx）、region（us-east-1/cn-north-1）。 - 标签值长度控制：标签值不宜过长，建议不超过 128 字符。
- 标签名语义明确：使用
service_name而非svc，使用http_method而非method（避免歧义）。
2.3.2 标签设计正反例对比
| 维度 | 反例（高基数/模糊） | 正例（低基数/清晰） | 基数影响 |
|---|---|---|---|
| 用户标识 | user_id="u12345" |
user_tier="premium" |
高基数 → 低基数 |
| 请求追踪 | trace_id="abc...xyz" |
service_name="checkout" |
无限 → 有限（< 50） |
| 错误码 | error_code="ERR_12345" |
error_category="timeout" |
高基数 → 低基数 |
| 部署环境 | host="ip-10-0-1-23" |
environment="production" |
高基数 → 低基数 |
2.4 综合案例：误差预算指标设计示例
以下是一个符合上述原则的 HTTP 服务误差预算指标 设计示例：
# 指标名：http_request_duration_seconds
# 类型：Histogram
# 标签：service, method, path, status_class
# 说明：记录所有 HTTP 请求的延迟分布
http_request_duration_seconds_bucket{service="checkout", method="POST", path="/api/order", status_class="2xx", le="0.1"} 1024
http_request_duration_seconds_bucket{service="checkout", method="POST", path="/api/order", status_class="2xx", le="0.5"} 2048
http_request_duration_seconds_bucket{service="checkout", method="POST", path="/api/order", status_class="2xx", le="1.0"} 3072
http_request_duration_seconds_bucket{service="checkout", method="POST", path="/api/order", status_class="2xx", le="+Inf"} 4096
http_request_duration_seconds_count{service="checkout", method="POST", path="/api/order", status_class="2xx"} 4096
http_request_duration_seconds_sum{service="checkout", method="POST", path="/api/order", status_class="2xx"} 1234.56
# 指标名：http_requests_errors_total
# 类型：Counter
# 标签：service, method, path, error_code
# 说明：记录 HTTP 请求错误总数
http_requests_errors_total{service="checkout", method="POST", path="/api/order", error_code="500"} 12
http_requests_errors_total{service="checkout", method="POST", path="/api/order", error_code="503"} 5
避坑提醒： 不要将
path 标签设置为完整 URL 路径（如 /api/order/12345），应使用 路由模板（如 /api/order/:id），否则路径中的动态参数会导致标签基数爆炸。
2.5 本章小结
- 四大黄金信号 是误差预算指标设计的骨架，延迟和错误直接参与 SLO 计算，流量和饱和度用于辅助预警。
- 指标命名规范 遵循
层级_组件_操作_单位结构，确保可读性和可发现性。 - 标签设计 的核心是控制基数，优先使用有限枚举值标签，避免高基数唯一标识符。
- 良好的 Metric Design 是 误差预算台账 准确、高效、可维护的基础。