2. Prometheus 基础回顾:指标类型、数据模型与 PromQL 入门

在深入成本分摊与性能调优之前,必须牢固掌握 Prometheus 的核心基础。本章将系统回顾 Prometheus 的四种核心指标类型、其分层数据模型,以及 PromQL 的入门查询语法。这些知识是后续所有成本分析与优化策略的基石。

2.1 核心指标类型 (Metric Types)

Prometheus 客户端库提供了四种核心指标类型,每种类型服务于不同的监控场景。理解它们的差异是编写正确 PromQL 和设计高效采集方案的前提。

指标类型 语义 典型场景 数据特点
Counter 只增不减的累计值 请求总数、错误总数、CPU 时间片 单调递增,重启归零
Gauge 可增可减的瞬时值 内存使用量、当前连接数、温度 反映当前状态,可上下波动
Histogram 对观测值进行分桶统计 请求延迟、响应大小 提供 _bucket、_count、_sum 序列
Summary 计算滑动时间窗口内的分位数 请求延迟的 p99、p50 客户端直接计算分位数,提供 _quantile 序列
关键区别: Histogram 的分位数需要在服务端通过 histogram_quantile() 函数计算,而 Summary 的分位数由客户端直接计算并暴露。Histogram 允许聚合多个实例的分桶数据,Summary 则无法聚合。

2.2 数据模型:标签驱动的多维存储

Prometheus 的数据模型是其强大灵活性的根源。每个时间序列由 指标名称 和一组 标签 (Labels) 唯一标识。

  • 指标名称 (Metric Name): 描述被监控的通用特征,例如 http_requests_total。
  • 标签 (Labels): 键值对,用于对同一指标进行多维度的细分,例如 method="GET"、status="200"、pod="nginx-abc123"。
  • 样本 (Sample): 由时间戳 (Timestamp) 和值 (Value) 组成。

这种设计使得我们可以通过标签的任意组合来灵活地聚合和过滤数据,例如:查询所有 GET 请求的总数,或查询特定 pod 的 CPU 使用率。

Prometheus 多维数据模型结构 Prometheus 多维数据模型结构 指标名称 http_requests_total 标签集 1 method="GET" status="200" pod="web-1" 标签集 2 method="POST" status="500" pod="web-2" 标签集 3 method="GET" status="200" pod="web-2" 样本: (t, v) 每个标签集 + 指标名称 = 唯一时间序列

2.3 PromQL 入门:查询与聚合

PromQL (Prometheus Query Language) 是用于从 Prometheus 中检索和聚合时间序列数据的函数式语言。掌握基础语法是进行成本分析和性能调优的第一步。

2.3.1 基础查询与选择器

  • 指标名称查询: node_cpu_seconds_total — 返回该指标下的所有时间序列。
  • 标签匹配器:
    • = : 精确匹配。例如:node_cpu_seconds_total{mode="idle"}
    • != : 不匹配。例如:node_cpu_seconds_total{mode!="idle"}
    • =~ : 正则匹配。例如:node_cpu_seconds_total{mode=~"user|system"}
    • !~ : 正则不匹配。
  • 范围向量选择器: 获取过去一段时间内的样本。例如:node_memory_MemAvailable_bytes[5m] 返回过去 5 分钟的所有样本。

2.3.2 常用聚合与函数

聚合操作是成本分摊的核心,它允许我们将细粒度的指标按团队、服务或命名空间进行汇总。

操作/函数 语法示例 用途
sum sum(rate(http_requests_total[5m])) by (namespace) 按命名空间聚合请求速率
avg avg(container_memory_usage_bytes) by (pod) 计算每个 Pod 的平均内存使用量
topk topk(5, sum(rate(cpu_usage_total[1h])) by (service)) 找出过去 1 小时 CPU 使用率最高的 5 个服务
rate rate(container_network_receive_bytes_total[1m]) 计算 Counter 类型指标的每秒平均增长率
histogram_quantile histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)) 计算服务维度的 p95 请求延迟
成本分摊实战提示: 在成本模型中,我们通常使用 sum by (team, service) 来聚合资源消耗指标(如 CPU 核心秒数、内存 GB-小时),然后乘以单位成本系数,从而得到每个团队或服务的应分摊成本。

2.3.3 二元运算符与向量匹配

PromQL 支持算术、比较和逻辑/集合运算符。向量匹配允许我们将两个不同指标的时间序列进行关联计算,这是实现成本分摊公式的关键。

  • 算术运算符: +, -, *, /, %, ^
  • 比较运算符: ==, !=, >, <, >=, <=
  • 向量匹配 (on / ignoring):
      # 将 CPU 使用率与 Pod 的成本系数相乘
      sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))
      * on (pod) group_left(team)
      pod_cost_coefficient
PromQL 聚合与成本分摊流程 PromQL 聚合与成本分摊流程 原始指标 container_cpu_usage_seconds_total 速率计算 rate(metric[5m]) 标签聚合 sum by (team, service) 成本系数 pod_cost_coefficient 最终成本 team_cost_total 核心公式:成本 = sum by (team) (rate(资源消耗指标[窗口]) * on (pod) 成本系数)
常见陷阱: 使用 rate() 或 increase() 时,必须指定一个足够大的时间窗口(例如 [5m]),以避免因 Counter 重置或数据抓取间隔导致计算不准确。对于成本分摊,建议使用至少 [1h] 或 [24h] 的窗口来平滑短期波动。