3. Prometheus 数据模型：Metric 类型、Label 设计原则、样本与时间序列
Prometheus 的数据模型是整个监控体系的核心。理解 Metric 类型、Label 设计原则以及样本与时间序列的关系，是构建高效、可维护监控系统的基石。本章将深入剖析这些概念，并结合实际运维场景给出最佳实践。
3.1 样本与时间序列：监控数据的原子单元
Prometheus 采集的所有数据最终都以时间序列的形式存储。一个时间序列由 Metric Name（指标名）和一组 Labels（标签）唯一标识。
- 样本 (Sample)：时间序列中的一个数据点，包含一个
float64值和一个毫秒精度的时间戳。 - 时间序列 (Time Series)：同一 Metric 和 Labels 组合下，按时间排序的样本流。
核心公式：
<metric_name>{<label_name>="<label_value>", ...} <value> [<timestamp>]例如：http_requests_total{method="POST", handler="/api/v1/login"} 1024 1700000000000
下图展示了从数据采集到时间序列存储的完整链路：
3.2 Metric 类型详解
Prometheus 客户端库提供了四种核心 Metric 类型。理解它们的语义差异，是正确设计监控指标的前提。
| Metric 类型 | 核心特征 | 典型场景 | 数据特点 |
|---|---|---|---|
| Counter | 只增不减（重启可归零） | 请求总数、错误次数、任务完成数 | 适用于累积量，常用 rate() 计算速率 |
| Gauge | 可增可减，反映当前状态 | CPU 使用率、内存占用、连接数、温度 | 直接使用原始值，无需速率计算 |
| Histogram | 分桶统计，可计算分位数 | 请求延迟、响应大小 | 包含 _bucket、_sum、_count 三个子序列 |
| Summary | 预计算分位数，客户端侧聚合 | SLI 分位数监控、延迟 P99 跟踪 | 包含 _quantile、_sum、_count 子序列 |
选型建议：
- 需要计算速率或累积量 → Counter
- 需要反映当前瞬时值 → Gauge
- 需要计算分位数且不确定分位点 → Histogram（服务端计算，灵活但资源消耗大）
- 需要精确分位数且分位点固定 → Summary（客户端计算，资源消耗小但不可聚合）
3.3 Label 设计原则：高基数陷阱与最佳实践
Label 是 Prometheus 数据模型的灵魂，但也是性能瓶颈的根源。不合理的 Label 设计会导致高基数 (High Cardinality) 问题，直接拖垮 TSDB。
3.3.1 高基数陷阱
每个唯一的 Label 组合都会创建一个新的时间序列。当某个 Label 的取值过多时，时间序列数量会呈爆炸式增长。
| Label 示例 | 取值数量 | 影响 |
|---|---|---|
user_id |
10 万 | 每个用户一个时间序列，内存和存储急剧膨胀 |
request_id |
无限 | 导致时间序列数量无限增长，最终 OOM |
ip_address |
数千 | 中等基数，需评估是否必要 |
status_code |
~10 | 低基数，安全 |
禁止：将
user_id、email、session_id、request_id 等具有无限或极高基数的字段作为 Label。这些应通过日志系统处理，而非 Prometheus。
3.3.2 Label 设计黄金法则
- 少即是多：每个 Metric 的 Label 数量控制在 5 个以内。
- 可枚举性：Label 的取值应该是可枚举且有限的（如
method、status、region）。 - 业务语义：Label 应反映监控维度的业务含义，而非技术实现细节。
- 避免冗余：不要将 Metric Name 中已包含的信息重复放入 Label。
- 统一命名：团队内统一 Label 命名规范，如
env、service、instance。
3.4 Metric 类型与 Label 的协同设计
下图展示了不同 Metric 类型与 Label 组合后的数据模型结构：
3.5 实战：Metric 与 Label 设计检查清单
在定义新的 Metric 时，请对照以下清单进行审查：
- 类型选择：该指标是累积量（Counter）、瞬时值（Gauge）、分布统计（Histogram/Summary）？
- Label 必要性：每个 Label 是否都有明确的查询或聚合需求？
- 基数评估：该 Label 的取值数量是否可控？是否可能超过 1000？
- 命名规范：Metric Name 是否遵循
namespace_metric_units格式？ - 文档化：是否在
HELP和TYPE注释中说明了 Metric 含义？
性能调优要点：
- 单个 Prometheus 实例建议管理的时间序列数量不超过 100 万。
- 单个 Metric 的 Label 基数建议控制在 1000 以内。
- 使用
rate()、increase()等函数时，注意避免对高基数 Label 进行聚合。 - 对于 Histogram，合理设置桶边界，避免过多桶导致序列爆炸。
通过本章的学习，你应该能够准确区分四种 Metric 类型，掌握 Label 设计原则，并理解样本与时间序列的关系。这些知识将直接应用于后续的采集配置和告警规则编写中。