2. Metric 基础概念:什么是 Metric?四种核心类型详解
在可观测性体系中,Metric(度量指标) 是描述系统状态与行为的数值化快照。它通过时间序列的方式记录系统在某一时刻或某一时间窗口内的特征,是故障发现、根因定位与 MTTR 复盘的核心数据基础。
2.1 什么是 Metric?
Metric 本质上是一个 带标签(Label)的数值序列,由以下三要素构成:
- Metric Name(指标名):描述被测量对象的语义,如
http_requests_total、cpu_usage_seconds。 - Labels(标签):键值对形式的维度,用于区分同一指标的不同实例,如
method="GET"、status="200"。 - Value(数值):在特定时间戳下的测量值,通常为 64 位浮点数。
关键认知:Metric 不是日志,也不是 Trace。它牺牲了单次事件的细节,换取了极低的存储成本与极高的聚合查询效率。在 SRE 实践中,Metric 是告警与仪表盘的第一数据源。
2.2 四种核心 Metric 类型详解
Prometheus 生态定义了四种标准 Metric 类型,覆盖了绝大多数系统监控场景。下表从核心特征、适用场景与典型故障特征三个维度进行对比:
| 类型 | 核心特征 | 典型场景 | 故障特征提取价值 |
|---|---|---|---|
| Counter | 只增不减(除重启归零) | 请求总数、错误计数、CPU 时间 | 突增/突降检测,速率异常 |
| Gauge | 可增可减,反映当前值 | 内存使用率、连接数、温度 | 阈值越界、波动幅度异常 |
| Histogram | 分桶统计,可计算分位数 | 请求延迟、响应大小 | 延迟分布偏移、P99 突增 |
| Summary | 客户端预计算分位数 | 延迟分位数(P50/P90/P99) | 分位数直接告警,无需聚合 |
2.3 Counter:只增不减的计数器
Counter 是最基础的 Metric 类型,其值在进程生命周期内单调递增。常见的 Counter 指标包括:
http_requests_total:HTTP 请求总数errors_total:错误发生总数node_cpu_seconds_total:CPU 累计使用时间
在故障特征提取中,Counter 的 速率(rate) 比原始值更有意义。例如,rate(errors_total[5m]) 可以快速发现错误率的突增。
# 典型的 Counter 指标暴露格式(Prometheus 文本格式)
# HELP http_requests_total The total number of HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 1027
http_requests_total{method="POST",status="500"} 13
2.4 Gauge:可上可下的仪表盘
Gauge 用于测量可以任意增减的瞬时值,如内存使用量、当前连接数、队列深度等。Gauge 的原始值直接反映系统当前状态。
常见陷阱:不要对 Gauge 使用
rate() 函数。Gauge 的导数(如内存变化速率)通常没有物理意义,应使用 avg_over_time 或 delta 分析其变化。
# HELP node_memory_MemAvailable_bytes Memory information field MemAvailable_bytes.
# TYPE node_memory_MemAvailable_bytes gauge
node_memory_MemAvailable_bytes 8.123e+09
2.5 Histogram:分桶统计与延迟分布
Histogram 将观测值放入预定义的桶(Bucket)中,同时记录所有观测值的总和与计数。它允许在服务端计算分位数(如 P99),而无需客户端预计算。
Histogram 暴露三个核心序列:
<basename>_bucket{le="<upper_inclusive>"}:每个桶的累积计数<basename>_sum:所有观测值的总和<basename>_count:观测事件总数
# HELP http_request_duration_seconds request duration histogram
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 240
http_request_duration_seconds_bucket{le="0.5"} 455
http_request_duration_seconds_bucket{le="1.0"} 502
http_request_duration_seconds_bucket{le="+Inf"} 510
http_request_duration_seconds_sum 187.3
http_request_duration_seconds_count 510
2.6 Summary:客户端预计算分位数
Summary 与 Histogram 类似,但分位数在客户端预先计算并直接暴露。Summary 适用于无法在服务端聚合分位数的场景,或对分位数精度有严格要求的场景。
Summary 暴露的序列包括:
<basename>{quantile="0.5"}:P50 分位数<basename>{quantile="0.9"}:P90 分位数<basename>{quantile="0.99"}:P99 分位数<basename>_sum与<basename>_count
选型建议:如果需要在多个维度(如按 method、path)聚合分位数,优先使用 Histogram;如果只需要全局分位数且对精度敏感,使用 Summary 可以减少计算开销。
2.7 四种 Metric 类型关系图
下图展示了四种 Metric 类型在数据采集、存储与查询阶段的核心差异:
2.8 选型决策要点
在实际的 Metric 设计中,选择哪种类型需要遵循以下原则:
- 只关心速率或累计值 → 使用 Counter(如请求数、错误数)
- 关心当前瞬时状态 → 使用 Gauge(如内存、连接数)
- 需要分析延迟分布或分位数 → 使用 Histogram(推荐)或 Summary
- 需要跨维度聚合分位数 → 必须使用 Histogram
- 分位数精度要求极高且维度固定 → 使用 Summary
SRE 最佳实践:在故障特征提取阶段,Counter 的速率异常和 Histogram 的延迟分布偏移是最敏感的故障信号。建议将核心接口的延迟指标设计为 Histogram,并配置 P99、P95、P50 三个分位数的告警规则。