2. Metric 设计原则：命名规范、标签设计原则、基数控制、Metric 的粒度选择

在构建服务画像标签体系时，Metric 的设计质量直接决定了告警阈值的精度与可解释性。一个设计良好的 Metric 体系能够降低误报率、提升根因定位效率，并为动态阈值算法提供稳定的输入。本节围绕四个核心维度展开：命名规范、标签设计原则、基数控制与粒度选择。

2.1 命名规范：可读性与可发现性

Metric 命名是观测数据的“身份证”。遵循统一的命名规范可以大幅降低团队协作成本，并支持自动化工具（如告警规则模板、仪表盘变量）的解析。

层级 规范要求 示例（推荐） 反例
命名空间 使用 namespace_ 前缀区分业务域 payment_api_request_total req_total
层级分隔 使用下划线 _ 分隔语义单元 db_query_duration_seconds dbQueryDuration 或 db.query.duration
单位后缀 明确标注基础单位（_seconds, _bytes, _total） http_response_size_bytes http_response_size
方向性 使用 _total 表示累计值，_count 表示计数 request_errors_total error_count（歧义）
实践建议： 在 Prometheus 生态中，推荐遵循 namespace_subsystem_metric_unit 的四段式命名法。例如 payment_gateway_latency_seconds，确保在全局搜索时能快速定位到所属业务域。

2.2 标签设计原则：高内聚、低耦合

标签（Label）是 Metric 的维度属性，决定了数据的分片能力。设计不当的标签会导致数据孤岛或爆炸性增长。

  • 高内聚：标签应描述 Metric 本身的固有属性，而非外部上下文。例如 status_code 是 HTTP 请求的固有属性，而 deploy_version 更适合作为外部元数据。
  • 低耦合：避免将多个维度编码进一个标签值。例如 endpoint="user_api_v2" 优于 endpoint="user_api" + version="v2" 的分离设计。
  • 可枚举性：标签值应来自有限集合。例如 method 标签值限定为 GET, POST, PUT, DELETE。
标签设计检查清单：
  1. 该标签是否用于告警分组或聚合？
  2. 该标签的取值是否会在短时间内无限增长？
  3. 该标签是否可以从其他标签推导得出？
  4. 该标签是否包含敏感信息（如用户 ID、IP）？

2.3 基数控制：避免高基数陷阱

基数（Cardinality）指一个标签或 Metric 组合的唯一取值数量。高基数（High Cardinality）是导致时序数据库性能退化、告警延迟、存储成本飙升的首要原因。

高基数问题影响链路 高基数标签 如 user_id, request_id TSDB 写入放大 索引膨胀，内存压力 查询性能下降 聚合耗时剧增 告警计算延迟 阈值评估超时 存储成本激增 数据分片数暴增 核心原则： • 单个 Metric 的标签组合基数应 < 10,000（推荐 < 1,000） • 避免将连续值（如时间戳、用户 ID）直接作为标签值
高基数典型案例： 将 user_id 作为标签嵌入 http_requests_total。假设日活 100 万用户，每个用户产生 10 个请求，则单日产生 1000 万条时间序列，远超 TSDB 推荐上限（通常 10 万～100 万）。正确做法：在业务层聚合后上报，或使用 histogram 分桶。

2.4 Metric 的粒度选择：从业务视角出发

粒度（Granularity）决定了 Metric 的采集频率与聚合层级。粒度过细会导致数据冗余，粒度过粗则丢失关键信号。

粒度层级 适用场景 采集间隔 典型 Metric
请求级 核心交易链路、SLO 计算 实时 / 秒级 request_duration_seconds
实例级 容器 / 主机资源监控 15s ~ 60s container_cpu_usage_seconds_total
服务级 服务健康状态、告警聚合 1min ~ 5min service_error_rate
业务级 业务大盘、趋势分析 5min ~ 15min order_success_rate
粒度选择决策树：
  • 是否需要追踪单次请求的延迟分布？ → 使用 Histogram 或 Summary，而非 Gauge。
  • 是否需要按实例维度进行告警？ → 保留 instance 标签，但控制实例总数（如 < 500）。
  • 是否需要跨服务聚合？ → 在服务入口处定义 RED 指标（Rate, Errors, Duration），下游服务仅暴露内部健康指标。

2.5 综合设计示例：服务画像标签体系

以下是一个符合上述原则的 Metric 设计示例，用于构建服务画像标签体系，辅助告警阈值精度优化。

# 命名：namespace_subsystem_metric_unit
# 标签：service, endpoint, method, status_class

# 1. 请求速率（Rate）
payment_api_requests_total{
  service="payment-gateway",
  endpoint="/v1/charge",
  method="POST",
  status_class="2xx"
}

# 2. 错误率（Errors）
payment_api_errors_total{
  service="payment-gateway",
  endpoint="/v1/charge",
  method="POST",
  error_type="timeout"
}

# 3. 延迟分布（Duration）
payment_api_duration_seconds{
  service="payment-gateway",
  endpoint="/v1/charge",
  method="POST",
  le="0.1"
}
payment_api_duration_seconds{
  service="payment-gateway",
  endpoint="/v1/charge",
  method="POST",
  le="0.5"
}
payment_api_duration_seconds{
  service="payment-gateway",
  endpoint="/v1/charge",
  method="POST",
  le="1.0"
}
payment_api_duration_seconds{
  service="payment-gateway",
  endpoint="/v1/charge",
  method="POST",
  le="+Inf"
}
标签基数验证： 上述示例中，service 取值约 10 个，endpoint 约 50 个，method 固定 4 个，status_class 固定 4 个。总基数 = 10 × 50 × 4 × 4 = 8,000，处于可控范围。若需增加 region 标签（如 3 个区域），则基数变为 24,000，建议通过 __meta 标签或外部关联表处理。

通过严格遵循命名规范、标签设计原则、基数控制与粒度选择，可以构建一个稳定、可扩展的 Metric 体系，为后续的动态阈值算法和告警精度优化奠定坚实基础。

← 上一章 📖 返回目录 下一章 →