Skip to content

0012.md

Latest commit

 

History

History
295 lines (190 loc) · 5.69 KB

0012.md

File metadata and controls

295 lines (190 loc) · 5.69 KB

面试题：Metrics 的数据模型有了解吗？

Metrics 是可观测性的三大支柱之一，它的核心是：

用结构化的数值型数据，持续记录系统状态，用于告警、趋势分析、容量预测。

业内的数据模型几乎都对齐 OpenTelemetry（OTel）与 Prometheus 标准。

面试官一般期待你回答：

  1. Metrics 的三类模型是什么？
  2. 为什么要这样设计？
  3. Label、时间序列、Sample 是怎么构造的？
  4. Counter / Gauge / Histogram / Summary 区别？
  5. Push、Pull 模型以及存储结构？

下面完整拆解。

一、Metrics 的数据模型是什么？（核心定义）

OpenTelemetry + Prometheus 的 Metrics 数据模型由 3 个核心组成：

  1. Metric（指标）：一类业务指标，例如 http_request_total
  2. Time Series（时间序列）：一个 Metric + 一组标签
  3. Sample（样本点）：某个时间点的数值

一句话：

Metric + Labels → 一个 Time Series → 存储若干 Samples，他们一起构成完整的 Metrics 数据模型。

示例：

Metric: http_requests_total
Labels: method="GET", handler="/api/v1/order"
一个唯一时间序列：
http_requests_total{method="GET", handler="/api/v1/order"}

Sample:
( timestamp=1712148091000, value=342 )

二、Metrics 的三类基本类型（数据模型基础）

在 Prometheus / OpenTelemetry 中，所有 Metrics 可以归为四大类：

1）Counter（计数器）

  • 单调递增
  • 只能增加不能减少
  • 常用于统计次数、累计量

例子：

  • 总请求数
  • 总错误数
  • 总用户注册数

数据模型：

counter:
  name: http_requests_total
  value: 120392

2）Gauge（仪表盘）

  • 可增可减
  • 表示某一时刻的状态

例子：

  • 当前 goroutine 数量
  • 当前内存使用量
  • Redis 连接数

数据模型：

gauge:
  name: cpu_usage
  value: 72.5

3）Histogram（直方图）

用于测分布的指标，如延迟、包大小等。

结构：

  • buckets（多个桶）
  • count（总数量）
  • sum（总和）

示例：

http_request_duration_seconds_bucket{le="0.1"}  1390
http_request_duration_seconds_bucket{le="0.3"}  2345
http_request_duration_seconds_sum   532.1
http_request_duration_seconds_count 2895

Histogram 是最常用的延迟指标模型。

4）Summary（分位数直方图）

用于客户端直接计算 p99/p95 的分布。

但：

  • 不可聚合（分布不能 merge）
  • 大规模生产推荐 Histogram + server-side quantile

数据模型：

summary:
  quantile=0.9 value=33ms
  quantile=0.99 value=70ms

三、Metric → TimeSeries → Sample 的完整数据结构（深度）

下面是 Prometheus 的完整模型：

1. Metric 名称（Name）

表示指标类型：

http_requests_total
go_goroutines
process_cpu_seconds_total

有命名规范（如 _total, _count, _bucket 等）。

2. Labels（维度）

Labels 是 Metrics 的“维度”，扩展时间序列。

例如：

method="GET"
status="200"
region="us-east-1"

每一种 Label 组合会产生 一个新的时间序列。

例如：

http_requests_total{method="GET", status="200"} → 一条 TimeSeries  
http_requests_total{method="POST", status="500"} → 另一条 TimeSeries

**标签爆炸问题（cardinality explosion）**是 Metrics 最大的陷阱。

3. Time Series（时间序列）

定义为：

MetricName + LabelSet

例如：

http_requests_total{method="GET", status="200"}

这是一条“唯一的时间序列”。

4. Sample（样本点）

一个时间点的测量数据。

结构：

timestamp（int64）
value（float64）

Prometheus 存储的就是所有 TimeSeries 的 Sample。

四、为什么 Metrics 要设计成这种模型？

面试加分点：设计哲学。

1）高压缩比、高性能存储

Time Series 数据可高度压缩：

  • 单条 Series 只有两列（timestamp, value）
  • 存储引擎（TSDB）压缩率极高

2）天然聚合能力（PromQL）

聚合维度可自由组合：

sum by (method) (http_requests_total)
avg(rate(http_request_duration_seconds[5m]))

3）分布式不可变性

Sample 是不可变的 append-only data： 不需要更新，只需要 append。

五、Push vs Pull 数据模型（架构差异）

Prometheus = Pull 模型

Prometheus 主动拉取：

/metrics

优点：统一发现、自动采集、减少压力。

OpenTelemetry = Push 模型（OTLP）

Agent/SDK 将 Metrics 主动 push 到 Collector。

云原生下常用架构：

App → OTEL SDK → Collector → Prometheus/Tempo/Grafana Cloud

六、Metrics 的落地标准（OpenMetrics）

未来标准： OpenMetrics（基于 Prometheus，但更通用） 被 CNCF 广泛支持。

数据模型：

## TYPE http_requests_total counter
http_requests_total{method="GET"} 1234 1712148091000

七、面试可背总结

“Metrics 的数据模型由三个核心概念组成： Metric（指标定义）、TimeSeries（指标+标签的唯一组合）、Sample（某个时间点的值）。

常用类型有四种：

  • Counter：递增，用于累计值。
  • Gauge：可增可减，用于当前状态。
  • Histogram：用于延迟、大小等的分布统计，包含 buckets、count、sum。
  • Summary：客户端计算分位数，但不便聚合。

Metrics 使用标签（Label）扩展时间序列，使得 promQL 可以从多维度聚合。 数据通常以 append-only 的方式写入 TSDB，具有高压缩、高性能和强聚合能力。 采集模型有 Pull（Prometheus）和 Push（OpenTelemetry）。 这是现代可观测性体系的基础。”
⚡