2. Prometheus 基础回顾：架构、数据模型、PromQL 核心概念

在深入成本调优与配置漂移审计之前，必须夯实 Prometheus 的核心基础。本章将快速回顾 Prometheus 的宏观架构、核心数据模型以及四种关键指标类型（Counter、Gauge、Histogram、Summary），为后续章节的实战操作建立统一的技术语境。

2.1 整体架构与数据采集流程

Prometheus 采用“拉取（Pull）”模式采集指标，其核心组件包括 Prometheus Server、Exporter、Pushgateway、Alertmanager 以及客户端 SDK。下图展示了从指标暴露到告警触发的完整链路：

2.2 数据模型：时间序列与标签

Prometheus 所有数据均以时间序列（Time Series）形式存储。一个时间序列由指标名称（Metric Name）和一组键值对标签（Labels）唯一标识。每个时间序列包含按时间排序的数据点（Timestamp, Value）。

标签是 Prometheus 数据模型的灵魂。在成本审计场景中，通过标签可以精确聚合某个命名空间、某个 Deployment 或某个 Pod 的资源消耗。配置漂移审计则依赖标签的稳定性——标签值的变化往往意味着配置变更。

2.3 PromQL 核心概念与四种指标类型

PromQL（Prometheus Query Language）是查询和分析指标数据的语言。理解四种核心指标类型是编写高效 PromQL 的前提。

2.3.1 Counter（计数器）

Counter 只增不减（除非系统重启），适用于累计类指标，如请求总数、CPU 总时间、错误总数。在 PromQL 中通常配合 rate() 或 increase() 函数计算每秒增长率或增量。

# 计算过去 5 分钟每秒请求增长率
rate(http_requests_total[5m])

# 计算过去 1 小时的总增量
increase(node_cpu_seconds_total[1h])

2.3.2 Gauge（仪表盘）

Gauge 可增可减，反映当前状态，如内存使用量、CPU 使用率、连接数。直接查询即可获得瞬时值，也可使用 avg_over_time() 等聚合函数。

# 当前内存使用量
node_memory_MemTotal_bytes - node_memory_MemFree_bytes

# 过去 10 分钟的平均 CPU 使用率
avg_over_time(node_cpu_seconds_total{mode="idle"}[10m])

2.3.3 Histogram（直方图）

Histogram 将观测值（如请求延迟、响应大小）分配到可配置的桶（Bucket）中，同时记录所有观测值的总和与计数。它提供 _bucket、_sum、_count 三类时间序列，可计算分位数（如 P99）。

# 计算过去 5 分钟请求延迟的 P99
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

2.3.4 Summary（摘要）

Summary 在客户端直接计算分位数，暴露 _quantile、_sum、_count 序列。与 Histogram 不同，Summary 的分位数是预定义的（如 0.5、0.9、0.99），无法在查询时动态调整。

# 直接查询预计算的分位数
http_request_duration_seconds_summary{quantile="0.99"}

2.4 四种指标类型对比总览

2.5 指标类型在成本与审计场景中的应用

在后续章节中，我们将频繁使用上述指标类型进行成本分析和配置漂移检测：

• 成本调优：使用 container_cpu_usage_seconds_total（Counter）配合 rate() 计算 Pod 的 CPU 使用率；使用 container_memory_working_set_bytes（Gauge）直接获取内存使用量，并与 Request/Limit 对比。
• 配置漂移审计：通过 kube_deployment_spec_replicas（Gauge）监控副本数变化；利用 kube_pod_container_resource_requests（Gauge）的标签变化检测资源配置漂移。
• SLA 验证：使用 Histogram 计算请求延迟的 P99，确保成本优化未导致性能降级。