Prometheus基础概念与核心特性解析

时间序列数据模型

Prometheus的核心是时间序列数据模型，每个时间序列由以下部分组成：

• 指标名称(Metric Name): 描述被监控内容的特征（如http_requests_total）
• 标签(Labels): 键值对形式的维度标识（如method="POST", status="200"）
• 时间戳(Timestamp): 数据点采集的时间
• 样本值(Value): 该时间点的测量值（如1024）

示例数据点：

http_requests_total{method="POST", status="200"} 1024 @1434055562

实践建议：

• 指标命名采用snake_case风格
• 避免在指标名称中包含可变部分（应使用标签代替）

Metric类型详解

1. Counter（计数器）

单调递增的累积指标，适合记录请求数、错误数等。

# 计算5分钟内请求增长率
rate(http_requests_total[5m])

2. Gauge（仪表盘）

可增减的瞬时值，适合记录内存使用量、温度等。

# 获取当前内存使用量
node_memory_Active_bytes

3. Histogram（直方图）

对观测值进行分桶统计，适合记录响应时间分布。

4. Summary（摘要）

类似Histogram但客户端计算分位数，适合高精度延迟统计。

实践建议：

• 优先使用Histogram（服务端聚合更灵活）
• Summary适用于需要精确分位数的场景

标签（Labels）设计与作用

标签是Prometheus强大的维度分析工具：

// 良好标签设计示例
http_requests_total{
  method="POST",
  status="200",
  endpoint="/api/v1/users",
  service="user-service"
}

标签设计原则：

1. 避免高基数标签（如用户ID、IP地址）
2. 标签值保持有限的可能值
3. 业务相关维度应作为标签

实践建议：

• 使用label_replace函数动态修改标签
• 通过group_left实现多对一标签关联

Pull vs Push模型

拉取模式（Pull）

优势：

• 集中控制抓取频率
• 自动服务发现集成
• 避免单点问题

Pushgateway的特殊用途

适用场景：

• 批处理作业监控
• 服务生命周期短于抓取间隔
• 无法暴露HTTP端点的场景

限制：

• 不存储时间戳（由Prometheus抓取时添加）
• 需要手动清理过期数据

数据存储与保留

本地TSDB存储机制

data/
├── wal/              # 预写日志目录
│   └── 00000001
├── chunks_head/      # 最新数据块
├── 01BKGTZQ1HHWH...  # 持久化块
└── 01BKGV7JC0RY8...  # 压缩后的块

关键过程：

1. WAL（Write-Ahead Log）：先写日志再内存处理，确保崩溃恢复
2. Block：每2小时将内存数据持久化为不可变块
3. Compaction：合并相邻块并删除重复数据

配置示例：

# prometheus.yml
storage:
  tsdb:
    retention: 15d          # 数据保留15天
    min-block-duration: 2h  # 最小块时长
    max-block-duration: 24h # 最大块时长

远程存储集成

Thanos架构示例：

实践建议：

• 本地保留7-15天数据平衡查询性能与存储成本
• 远程存储选择考虑查询延迟和成本因素
• 监控TSDB的prometheus_tsdb_*指标预防存储问题

总结

Prometheus的基础概念构成了其强大的监控能力核心。理解这些特性后，您可以：

1. 设计合理的指标和标签体系
2. 根据场景选择Pull/Push数据采集方式
3. 规划适合业务需求的存储方案
4. 为后续告警规则和可视化打下基础

下一步可结合具体Exporter实践指标采集，或学习PromQL进行数据查询分析。