📚 课程目录第2章 Metric基础概念

2. Metric 基础概念：类型、命名规范与标签设计原则

在可观测性体系中，Metric（指标）是告警规则的直接数据源。理解 Metric 的底层类型、命名规范以及标签（Label）设计原则，是构建可靠告警基线的第一步。本章将系统梳理这些核心概念，确保你在后续设计告警规则时，能够准确选择指标类型并避免常见陷阱。

2.1 Metric 四大核心类型

Prometheus 生态定义了四种核心 Metric 类型，每种类型对应不同的数据语义和聚合方式。Grafana 告警规则直接依赖这些类型进行阈值计算和趋势分析。

类型	数据特征	典型场景	告警适用性
Counter	只增不减（重启归零）	请求总数、错误计数、CPU 时间	适合检测速率突变（如 5m 错误率飙升）
Gauge	可增可减，反映当前状态	内存使用率、连接数、温度	适合静态阈值（如 > 90%）
Histogram	分桶计数 + 总和 + 计数	请求延迟分布、响应大小	适合分位数告警（如 p99 > 500ms）
Summary	客户端预计算分位数	SLI 延迟、已聚合的百分位数据	适合无法在服务端聚合的场景

  关键区别：Counter 只能通过 rate() 或 increase() 函数转换为速率后使用；Gauge 可直接参与阈值比较；Histogram 和 Summary 都用于延迟分析，但 Histogram 支持服务端聚合，Summary 则不可聚合。

2.2 Metric 命名规范

良好的命名规范是团队协作和自动化告警的基础。遵循以下规则可避免命名冲突并提升可读性：

命名格式：<namespace>_<subsystem>_<unit>[_<suffix>]
使用下划线分隔：全部小写，禁止使用驼峰或连字符。
单位后缀：如 _seconds、_bytes、_total（Counter 必须加 _total）。
避免冗余：不要重复标签中的信息，如 http_requests_total{method="GET"} 而非 http_get_requests_total。

# 推荐示例
node_cpu_seconds_total{ mode="idle" }
http_request_duration_seconds_bucket{ le="0.5" }
db_connections_current{ pool="primary" }

# 不推荐示例
NodeCPUUsage          # 驼峰，无单位
http-get-requests     # 连字符，无 _total
requests_count        # 语义模糊，缺少 namespace

2.3 标签（Label）设计原则

标签是 Metric 的维度标识，直接影响告警规则的灵活性和查询性能。设计不当会导致基数爆炸或告警噪声。

黄金法则：标签的基数（唯一取值数量）应控制在 1000 以内。高基数标签（如 user_id、request_id）会严重拖慢 Prometheus 查询性能，并导致 Grafana 告警评估超时。

2.3.1 标签分类与设计建议

标签类别	示例	基数控制	告警影响
标识标签	`instance`、`job`、`pod`	低（通常 < 100）	用于分组告警，必须保留
维度标签	`method`、`status`、`endpoint`	中（通常 < 50）	用于细化告警范围，建议保留
属性标签	`version`、`region`、`env`	低（通常 < 20）	用于告警路由和静默，可选
高基数标签	`user_id`、`trace_id`、`session_id`	极高（百万级）	禁止作为 Metric 标签

2.3.2 标签设计避坑清单

不要将动态值（如 IP、时间戳、随机 ID）放入标签。
不要在标签中存储完整 URL 或查询参数，应提取关键路径。
不要使用标签替代 Metric 名称，如 metric{type="cpu"} 应拆分为 cpu_metric。
必须为所有相同语义的 Metric 使用一致的标签键（如统一用 status 而非 status_code 和 http_status）。

告警规则陷阱：如果标签基数过高，Grafana 告警引擎在评估 avg() by (instance) 时可能产生数千条告警实例，导致通知渠道被淹没。建议在告警规则中使用 topk() 或 quantile() 聚合后再触发。

2.4 Metric 类型与标签关系图

下图展示了四种 Metric 类型与标签的协作关系，以及它们在告警规则中的典型数据流：

2.5 类型选择与告警规则匹配速查表

在实际告警规则编写中，根据 Metric 类型选择合适的 PromQL 函数和阈值策略：

Metric 类型	推荐 PromQL 函数	告警示例	注意事项
Counter	`rate()` / `increase()`	`rate(http_requests_total[5m]) > 100`	必须使用速率函数，避免直接比较原始值
Gauge	直接比较 / `avg()` / `max()`	`node_memory_usage_percent > 90`	注意数据采集抖动，建议加 `avg_over_time()`
Histogram	`histogram_quantile()`	`histogram_quantile(0.99, rate(...)) > 0.5`	需要足够的桶边界覆盖目标范围
Summary	直接读取 `_p99` 指标	`http_request_duration_p99 > 0.5`	无法跨实例聚合，谨慎用于全局告警

基线校准建议：在告警规则上线前，先使用 avg_over_time() 或 quantile_over_time() 分析历史数据，确定合理的基线阈值。例如：avg_over_time(node_cpu_usage[7d]) 可提供一周的 CPU 平均基线。