📚 课程目录第2章 Prometheus核心架构与数据模型

2. Prometheus 核心架构与数据模型：理解 Pull 模型、TSDB、Metric 类型及 Label 设计对故障定位的影响

2.1 核心架构：Pull 模型与组件协作

Prometheus 采用 主动拉取（Pull） 的监控数据采集模式，区别于传统的 Push 模型。这种设计使得监控系统对目标实例的存活状态、数据采集周期具有完全的控制权，是构建可靠容量压测与巡检体系的基础。

  Pull 模型核心优势：
  故障隔离：单个 Target 故障不会导致监控系统过载或数据丢失。
健康探测：无法 Pull 到数据即表明目标实例或网络路径存在异常，天然具备探活能力。
配置驱动：通过 scrape_config 即可动态调整采集目标，适合压测场景中频繁变动的实例列表。

下图展示了 Prometheus 在压测与巡检场景下的核心组件协作关系：

2.2 TSDB：时序数据存储与压缩

Prometheus 内置的 TSDB（Time Series Database） 是存储所有监控数据的核心引擎。在容量压测场景下，TSDB 的写入与查询性能直接决定巡检脚本的实时性与可靠性。

TSDB 特性	压测巡检场景价值
自定义 Block 结构（2h 时间窗口）	压测数据按时间块组织，便于巡检脚本按时间范围快速扫描
压缩算法（Gorilla / XOR）	高密度压测数据点（秒级采集）可压缩至原始大小的 1/10，降低存储成本
内存映射（mmap）	查询历史压测数据时无需全量加载，减少巡检脚本的响应延迟
WAL（Write-Ahead Log）	压测过程中若 Prometheus 崩溃，重启后可恢复数据，保障巡检连续性

故障定位提示： 当巡检脚本查询压测历史数据出现延迟或超时时，优先检查 TSDB 的 prometheus_tsdb_head_series 和 prometheus_tsdb_compactions_total 指标。若 series 数量超过 1000 万或 compaction 持续失败，说明 TSDB 处于高负载状态，需调整采集频率或增加资源。

2.3 Metric 类型：Counter / Gauge / Histogram / Summary

Prometheus 定义了四种核心 Metric 类型，每种类型在容量压测与巡检脚本中有不同的适用场景。错误选择 Metric 类型是导致故障定位困难的常见原因。

类型	语义	典型压测指标	巡检脚本注意事项
Counter	只增不减的累计值	请求总数、错误总数、CPU 时间	必须使用 `rate()` 或 `increase()` 函数计算速率，直接查询原始值无意义
Gauge	可增可减的瞬时值	内存使用量、当前连接数、CPU 使用率	可直接查询，但需注意采样点之间的波动，建议配合 `avg_over_time()` 平滑
Histogram	分桶统计的分布值	请求延迟分布、响应大小分布	使用 `histogram_quantile()` 计算 P99/P95，需确保桶边界覆盖压测预期范围
Summary	预计算的分位数	请求延迟分位数（服务端预计算）	无法跨进程聚合，压测多实例场景下推荐使用 Histogram 替代

常见故障陷阱： 在压测巡检脚本中，若使用 Counter 类型的 http_requests_total 直接设置告警阈值（如 http_requests_total > 1000），会导致误报。因为 Counter 值随时间持续增长，正确做法是使用 rate(http_requests_total[1m]) > 100 计算每秒速率。

2.4 Label 设计：故障定位的关键元数据

Label（标签）是 Prometheus 数据模型中最重要的元数据设计。在容量压测与巡检场景中，合理的 Label 设计可以大幅缩短故障定位时间，而不合理的 Label 设计则会导致数据爆炸或查询困难。

2.4.1 Label 设计原则

高基数（High Cardinality）控制：避免将用户 ID、Session ID、IP 地址等无限增长的字段作为 Label。高基数 Label 会导致 TSDB 性能急剧下降，甚至 OOM。
可过滤性（Filterability）：Label 应支持按压测场景、服务名、实例、区域等维度快速过滤。例如：job="loadtest"、instance="web-01"、region="us-east-1"。
一致性（Consistency）：同一类指标（如所有 HTTP 请求指标）应使用相同的 Label 名称和取值规范，避免巡检脚本中频繁使用 or 或正则匹配。

2.4.2 Label 设计对故障定位的影响对比

场景	不良 Label 设计	良好 Label 设计	故障定位影响
压测多区域部署	`region="us-east-1"` 缺失	`region="us-east-1"` 存在	无法快速区分是全局故障还是区域故障
压测多版本对比	`version="v1.2.3"` 缺失	`version="v1.2.3"` 存在	无法定位新版本上线导致的性能回退
压测实例级监控	`instance="pod-xyz"` 使用 Pod IP	`instance="web-svc-abc"` 使用服务名	Pod IP 变化后历史数据无法关联，巡检脚本失效
压测请求类型区分	`handler="/api/v1/*"` 使用通配符	`handler="/api/v1/users"` 精确路径	通配符导致 Label 基数膨胀，查询性能下降

巡检脚本最佳实践： 在编写巡检脚本时，始终通过 label_replace() 或 relabel_configs 将高基数 Label（如 Pod IP）映射为低基数 Label（如服务名）。例如：

# 在 prometheus.yml 中使用 relabel_configs
relabel_configs:
  - source_labels: [__meta_kubernetes_pod_ip]
    target_label: instance
    replacement: 'web-svc-${1}'  # 将 IP 映射为服务名

2.5 数据模型与故障定位的关联总结

下表总结了 Pull 模型、TSDB、Metric 类型和 Label 设计在故障定位中的关键作用：

组件	故障定位作用	压测巡检典型问题
Pull 模型	通过 `up` 指标快速判断 Target 存活状态	压测目标实例宕机，Prometheus 无法 Pull 数据，巡检脚本立即告警
TSDB	通过 `prometheus_tsdb_*` 指标诊断存储性能瓶颈	压测数据量过大导致 TSDB 写入延迟，巡检脚本查询超时
Metric 类型	通过 `rate()` / `histogram_quantile()` 等函数提取有效信号	误用 Counter 原始值导致告警阈值失效，或 Histogram 桶边界不合理导致 P99 计算错误
Label 设计	通过 `{job="loadtest", region="us-east-1"}` 快速缩小故障范围	高基数 Label 导致 TSDB 性能下降，或 Label 缺失导致无法区分故障域

实战建议： 在容量压测开始前，先通过 promtool check metrics 检查暴露的指标是否符合 Label 设计规范。同时，在巡检脚本中增加 label_join() 或 label_map() 逻辑，确保查询结果包含足够的故障定位维度。