1. Metric 基础概念：定义、类型与可观测性角色
Metric（度量指标）是可观测性三大支柱（Logs、Traces、Metrics）中唯一以数值聚合为核心的数据类型。它通过固定时间窗口内的计数、求和、分位数等统计量，反映系统状态与趋势，是告警阈值设计的直接数据源。
1.1 Metric 的定义
Metric 是一组带时间戳的数值序列，通常由 Metric Name、Labels（标签） 和 Value 三元组构成。其核心特征包括：
- 时序性：每个数据点都关联一个时间戳，形成连续的时间序列。
- 可聚合：支持 sum、avg、max、min、count 等聚合操作，便于从全局视角观察系统。
- 低基数：相比 Logs 和 Traces，Metric 的数据量更小，适合长期存储与实时告警。
关键公式： Metric 数据模型 = Metric Name + Labels (key=value) + Timestamp + Value
1.2 Metric 的四种核心类型
Prometheus 生态定义了四种 Metric 类型，每种类型对应不同的数据采集与计算语义。下表对比了它们的核心差异：
| 类型 | 数据语义 | 典型场景 | 告警阈值设计要点 |
|---|---|---|---|
| Counter | 只增不减的累计值（重启归零） | 请求总数、错误总数、CPU 时间 | 使用 rate() 或 increase() 转换为速率后设阈值 |
| Gauge | 可增可减的瞬时值 | 内存使用量、连接数、温度 | 直接对原始值设上下限阈值 |
| Histogram | 分桶计数 + 总和 + 总次数 | 请求延迟分布、响应大小分布 | 基于 histogram_quantile() 计算分位数告警 |
| Summary | 客户端预计算的分位数 + 总和 + 总次数 | SLI 延迟分位数（p99/p95） | 直接读取预计算分位数，无需服务端聚合 |
1.3 Metric 在可观测性中的角色
Metric 在可观测性体系中承担 “量化仪表盘” 的角色，与 Logs、Traces 形成互补：
- 快速检测：通过持续采集的数值序列，在数秒内发现异常波动，触发告警。
- 趋势分析：基于长时间序列数据，识别容量瓶颈、周期性负载模式。
- 成本控制：相比全量 Logs 存储，Metric 的存储成本更低，适合长期保留。
- 阈值基准：为告警阈值提供历史基线数据，避免静态阈值误报。
实践建议： 在告警阈值设计时，优先使用 Counter + rate() 检测突发流量，使用 Gauge 监控资源水位，使用 Histogram/Summary 评估服务质量（SLI）。
1.4 Metric 数据流与告警阈值关系
下图展示了 Metric 从采集到触发告警的完整链路，以及阈值精度优化的关键介入点：
1.5 类型选择对告警阈值精度的影响
错误的 Metric 类型选择会直接导致告警阈值失效。以下对比了常见误用场景：
| 误用场景 | 错误做法 | 后果 | 正确做法 |
|---|---|---|---|
| 监控请求速率 | 对 Counter 直接设阈值（如 > 1000） | 重启后归零导致漏报 | 使用 rate(http_requests_total[5m]) |
| 监控内存水位 | 使用 Counter 类型 | 无法反映下降趋势 | 使用 Gauge 类型 |
| 监控 p99 延迟 | 使用 Gauge 记录原始值 | 无法准确反映分布尾延迟 | 使用 Histogram 或 Summary |
| 监控错误率 | 直接对错误 Counter 设阈值 | 忽略总请求量变化 | 使用 rate(errors_total[5m]) / rate(requests_total[5m]) |
注意： Histogram 和 Summary 虽然都用于分位数计算，但 Histogram 支持服务端聚合（适合多实例汇总），Summary 由客户端预计算（适合精确分位数但无法跨实例聚合）。选择时需权衡聚合需求与资源开销。
1.6 小结：Metric 与告警阈值精度的关系
理解 Metric 的基础概念是设计高精度告警阈值的前提：
- Counter 必须配合速率函数使用，避免静态阈值误判。
- Gauge 适合直接设上下限，但需考虑毛刺噪声。
- Histogram/Summary 是 SLI 延迟告警的标准选择，但需注意分位数计算方式差异。
- Labels 的基数控制直接影响 Metric 的采集性能和阈值计算的准确性。