3. Metric命名规范与标签设计
在可观测性体系中，Metric 的命名与标签设计直接决定了数据的可理解性、查询效率以及存储成本。一个糟糕的命名或不受控的标签基数，会在容量压测水位评估和异常检测中引入大量噪声，甚至导致监控系统崩溃。本节将围绕命名最佳实践、标签基数控制以及高基数标签的危害与治理展开。
3.1 命名最佳实践
Metric 命名应遵循“领域驱动 + 层级清晰”的原则，确保运维人员、开发人员和 SRE 能够通过名称快速理解指标含义。推荐采用 层级命名法，以点号分隔，从左至右范围由大到小。
| 层级 | 示例 | 说明 |
|---|---|---|
| 命名空间 | k8s / mysql / nginx |
标识数据来源系统或组件 |
| 子系统/模块 | node / cluster / upstream |
进一步细化来源模块 |
| 测量对象 | cpu / memory / requests |
描述被测量的资源或行为 |
| 度量类型 | usage / total / latency_seconds |
明确单位或聚合方式 |
命名规范检查清单：
- 使用小写字母和下划线，禁止使用驼峰或连字符。
- 避免在名称中嵌入可变值（如 IP、Pod 名称），应使用标签承载。
- 单位必须显式标注，如
_seconds、_bytes、_total。 - 保持名称简洁，不超过 5 个层级。
# 推荐示例
k8s.node.cpu.usage_seconds_total
mysql.innodb.data_read_bytes
nginx.http.requests_total
# 不推荐示例
K8sNodeCPUUsageSecondsTotal # 驼峰
nginx_192_168_1_1_requests # 名称内嵌IP
3.2 标签基数控制
标签（Label）用于为 Metric 附加维度信息，但每个标签的取值数量（基数）必须严格管控。基数过高会导致时间序列数量爆炸，直接冲击存储层和查询性能。
基数控制的核心原则：标签取值数量应可枚举且稳定。以下表格展示了常见标签的基数等级：
| 标签示例 | 预期基数 | 风险等级 | 控制建议 |
|---|---|---|---|
status_code |
~10 | 低 | 可直接使用 |
method |
~10 | 低 | 可直接使用 |
pod |
~100 | 中 | 建议聚合后使用 |
user_id |
10万+ | 高 | 禁止直接作为标签 |
request_id |
无限 | 极高 | 禁止 |
基数失控的典型症状： 当单个 Metric 的标签组合数超过 10 万时，Prometheus 等时序数据库的 TSDB 索引会急剧膨胀，导致查询超时、内存溢出、磁盘写入放大。在容量压测场景中，高基数标签会掩盖真实的水位趋势，使异常检测模型产生大量误报。
3.3 高基数标签的危害与治理
高基数标签是监控系统中最隐蔽的性能杀手。以下 SVG 图展示了高基数标签如何从数据采集端扩散至存储与查询端，形成系统性危害。
3.4 高基数标签治理策略
针对已存在的高基数标签，SRE 团队应采取分层治理方案，从源头阻断扩散。以下为推荐的治理流程：
- 审计与发现：使用
promtool tsdb analyze或 Grafana Mimir 的 Cardinality API 识别 Top N 高基数 Metric。 - 标签降维：将高基数标签（如
user_id）从 Metric 中移除，改为在日志或 Trace 中记录；Metric 只保留tenant_id、region等低基数标签。 - 聚合前置：在采集端或 Agent 侧对高基数数据进行预聚合，例如将
http_requests_total{user_id="xxx"}聚合为http_requests_total{status_code="200"}。 - 标签白名单：在 Prometheus 或 VictoriaMetrics 的
relabel_config中配置标签白名单，丢弃所有未授权的标签。 - 分片存储：对于必须保留的高基数场景，采用分片存储架构，将不同标签范围的数据路由到不同的存储节点。
容量压测场景下的特殊建议： 在压测期间，应临时关闭非核心的高基数标签采集，避免压测流量产生的海量唯一标签值污染监控系统。压测结束后，再恢复标签采集并清理临时数据。
3.5 标签设计对比：好与坏
以下表格通过具体案例对比了优秀标签设计与糟糕标签设计的差异：
| 维度 | 优秀设计 | 糟糕设计 |
|---|---|---|
| Metric 名称 | api_http_requests_total |
requests |
| 标签 | method, status_code, endpoint |
user_id, request_id, ip |
| 基数 | ~100 | 100万+ |
| 查询性能 | 毫秒级 | 超时或 OOM |
| 存储成本 | 低 | 极高 |
| 异常检测效果 | 准确 | 大量误报 |
在容量压测水位口径阈值优化中，低基数标签设计能够确保水位线计算稳定可靠，异常检测模型能够聚焦于真实的容量瓶颈，而非被标签噪声干扰。SRE 团队应将标签基数治理纳入日常巡检清单，作为可观测性成熟度评估的核心指标之一。