3. Prometheus 基础回顾：数据模型、Metric 类型、PromQL 入门、Pull 与 Push 模式
在深入 Helm 应用资源模型性能优化之前，必须牢固掌握 Prometheus 的核心基础。本章将系统回顾 Prometheus 的数据模型、Metric 类型、PromQL 入门语法以及 Pull 与 Push 两种采集模式，为后续的监控配置与性能调优打下坚实根基。
3.1 数据模型：时间序列与标签
Prometheus 将所有监控数据存储为时间序列（Time Series）。每个时间序列由 Metric Name 和一组 Labels 唯一标识。
- Metric Name：描述被监控指标的名称，例如
http_requests_total、cpu_usage_seconds。 - Labels：键值对，用于对时间序列进行维度划分。例如
method="GET"、status="200"、instance="localhost:9090"。 - Sample：时间序列中的单个数据点，包含一个
float64值和一个毫秒精度的时间戳。
一个典型的时间序列标识如下：
http_requests_total{method="POST", handler="/api/v1/orders", instance="10.0.1.5:8080"}标签的基数（Cardinality）是性能优化的关键因素。高基数标签（如 user_id、request_id）会导致时间序列数量爆炸，严重影响 Prometheus 的存储和查询性能。
性能提示：在 Helm 应用资源模型中，应避免将 Pod 名称或容器 ID 作为高基数标签直接暴露。优先使用
deployment、namespace、app 等有限维度的标签。
3.2 Metric 类型
Prometheus 客户端库提供四种核心 Metric 类型，理解其语义是编写正确 PromQL 的前提。
| 类型 | 描述 | 典型用例 | 数据特点 |
|---|---|---|---|
| Counter | 只增不减的计数器，重启后归零。 | 请求总数、错误总数、任务完成数。 | 适用于 rate() 和 increase() 函数。 |
| Gauge | 可增可减的瞬时值。 | CPU 使用率、内存使用量、当前连接数。 | 直接使用原始值，适用于 avg()、max()。 |
| Histogram | 对观测值进行分桶统计，提供 _bucket、_count、_sum 序列。 |
请求延迟、响应大小。 | 可计算分位数（P50、P99），但精度受桶边界影响。 |
| Summary | 类似 Histogram，但由客户端计算分位数。 | 请求延迟（已知分位数需求）。 | 分位数精确，但无法聚合多个实例。 |
常见误区：对 Counter 类型直接使用
avg() 或 sum() 通常没有意义，因为 Counter 是累积值。必须使用 rate() 或 increase() 将其转换为每秒速率或增量后再进行聚合。
3.3 PromQL 入门
PromQL（Prometheus Query Language）是 Prometheus 内置的数据查询语言。掌握以下核心操作即可应对大部分监控场景。
3.3.1 基础查询与选择器
- 瞬时向量选择器：
http_requests_total返回该 Metric 的所有时间序列的最新值。 - 标签匹配器：
=：精确匹配，如http_requests_total{status="200"}!=：不匹配，如http_requests_total{status!="500"}=~：正则匹配，如http_requests_total{method=~"GET|POST"}!~：正则不匹配
- 范围向量选择器：
http_requests_total[5m]返回过去 5 分钟内每个时间序列的所有样本。
3.3.2 常用函数
| 函数 | 用途 | 示例 |
|---|---|---|
rate() |
计算 Counter 在指定时间窗口内的每秒平均增长率。 | rate(http_requests_total[5m]) |
increase() |
计算 Counter 在指定时间窗口内的增量。 | increase(http_requests_total[1h]) |
avg_over_time() |
计算 Gauge 在指定时间窗口内的平均值。 | avg_over_time(node_cpu_seconds_total[10m]) |
histogram_quantile() |
从 Histogram 中计算分位数。 | histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) |
3.3.3 聚合操作
使用 sum()、avg()、min()、max()、count() 等聚合运算符，配合 by 或 without 子句进行维度聚合。
# 按状态码聚合请求速率
sum(rate(http_requests_total[5m])) by (status)
# 按命名空间和 Deployment 聚合 CPU 使用率
avg(rate(container_cpu_usage_seconds_total[5m])) by (namespace, deployment)
优化要点：在 Helm 应用的资源模型中，推荐使用
sum by (namespace, deployment) 进行聚合，避免因 Pod 级别的高基数标签导致查询性能下降。
3.4 Pull 与 Push 模式
Prometheus 默认采用 Pull 模式，即 Prometheus Server 主动从目标端点（Exporter）拉取指标。同时，通过 Pushgateway 支持 Push 模式，用于短期任务或无法被 Pull 的场景。
3.4.1 Pull 模式的优势与挑战
- 优势：
- Prometheus Server 控制采集节奏，避免目标端过载。
- 天然支持服务发现（Kubernetes、Consul、DNS SRV）。
- 易于检测目标是否存活（Up/Down）。
- 挑战：
- 目标必须暴露 HTTP 端点，且网络可达。
- 对于生命周期极短的作业（如 CronJob），可能来不及采集。
3.4.2 Push 模式的使用场景
- 短期作业：批处理任务、数据管道作业，在退出前将指标推送到 Pushgateway。
- 网络隔离环境：目标位于防火墙后，无法被 Prometheus 直接 Pull。
- 注意事项：Pushgateway 是单点，且无法自动清理过时指标，需要手动管理。
Helm 应用实践：对于 Helm 部署的长期运行服务（如 Web 应用、API 服务），始终优先使用 Pull 模式。仅在 CronJob 或 Job 场景下考虑 Push 模式，并注意为 Pushgateway 配置合理的指标过期时间。