3. Prometheus基础回顾

在深入 Kubernetes 控制面策略命中率与误报分析之前,必须夯实 Prometheus 监控基础。本章从数据模型、指标类型、查询语言以及 Kubernetes 原生监控资源四个维度,构建后续章节所需的监控知识底座。

3.1 数据模型:时间序列与标签

Prometheus 存储的核心是时间序列(Time Series)。每个时间序列由 Metric Name 和一组 Label 唯一标识。

概念 说明 示例
Metric Name 指标名称,描述被监控对象的语义 http_requests_total
Label 键值对,用于维度过滤与聚合 method="GET", status="200"
Sample 时间戳 + 浮点数值 @1620000000 1024
Time Series Metric Name + Labels 组合的唯一序列 http_requests_total{method="GET",status="200"}
关键认知: 在 Kubernetes 环境中,namespace、pod、container 等标签自动注入,使得我们可以按工作负载维度精确查询策略命中率。
Prometheus 时间序列结构 Metric Name Labels (key=value) Sample (T, V) 完整时间序列标识 http_requests_total{method="GET", status="200", namespace="prod"} 每个唯一的 Metric Name + Labels 组合构成一个独立的时间序列 时间序列在 TSDB 中按时间窗口存储样本数据

3.2 Metric 类型:四种核心指标

Prometheus 客户端库提供四种标准指标类型,理解其语义是编写正确 PromQL 的前提。

类型 语义 典型场景 PromQL 常用函数
Counter 只增不减的累计值 请求总数、错误总数、CPU 时间 rate(), increase()
Gauge 可增可减的瞬时值 内存使用量、Pod 副本数、队列深度 avg(), max(), min()
Histogram 分桶统计,可计算分位数 请求延迟、响应大小 histogram_quantile()
Summary 预计算的分位数,客户端侧聚合 SLI 延迟分位数(服务端无法聚合) 直接读取 quantile 标签
常见误区: 对 Counter 类型直接使用 avg() 或 sum() 而不加 rate(),会导致结果受采集周期影响,无法反映真实速率。策略命中率计算必须使用 rate() 或 increase()。

3.3 PromQL 入门:查询与聚合

PromQL(Prometheus Query Language)是分析监控数据的核心工具。以下为后续章节高频使用的查询模式。

3.3.1 基础查询

# 查询所有 HTTP 请求总数
http_requests_total

# 带标签过滤
http_requests_total{method="POST", status=~"5.."}

# 范围向量:过去 5 分钟
http_requests_total[5m]

3.3.2 常用函数

函数 用途 示例
rate() 计算 Counter 每秒平均增长率 rate(http_requests_total[5m])
increase() 计算 Counter 在时间范围内的增量 increase(http_requests_total[1h])
avg() 聚合:平均值 avg(rate(http_requests_total[5m])) by (namespace)
sum() 聚合:求和 sum(rate(http_requests_total[5m])) by (status)
histogram_quantile() 从 Histogram 计算分位数 histogram_quantile(0.99, ...)

3.3.3 策略命中率计算模板

# 策略命中率 = 策略匹配请求数 / 总请求数
sum(rate(kyverno_policy_rule_hit_total[5m]))
/
sum(rate(kyverno_policy_rule_evaluation_total[5m]))
最佳实践: 在计算比率时,务必使用 rate() 将 Counter 转换为速率,避免因采集时间差导致分母为零或比率失真。

3.4 ServiceMonitor 与 PodMonitor:Kubernetes 监控资源

在 Kubernetes 环境中,Prometheus Operator 通过 CRD(Custom Resource Definition)动态管理抓取目标。两个核心资源是 ServiceMonitor 和 PodMonitor。

ServiceMonitor vs PodMonitor 抓取流程 ServiceMonitor Service Endpoints Prometheus 通过 Service 发现 Pod IP:Port PodMonitor 直接匹配 Pod Labels Prometheus 直接抓取 Pod IP:Port 核心区别 ServiceMonitor 依赖 Service 进行服务发现;PodMonitor 直接基于 Pod 标签选择,适用于无需 Service 的监控场景 选择建议:有 Service 层 → ServiceMonitor;无 Service 或需抓取 Sidecar → PodMonitor

3.4.1 ServiceMonitor 配置示例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kyverno-admission-controller
  namespace: kyverno
spec:
  selector:
    matchLabels:
      app: kyverno
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics
  namespaceSelector:
    matchNames:
    - kyverno

3.4.2 PodMonitor 配置示例

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: kyverno-admission-controller
  namespace: kyverno
spec:
  selector:
    matchLabels:
      app: kyverno
  podMetricsEndpoints:
  - port: metrics
    interval: 30s
    path: /metrics
  namespaceSelector:
    matchNames:
    - kyverno

3.4.3 选择对比

维度 ServiceMonitor PodMonitor
发现机制 通过 Service 的 Endpoints 发现 Pod 直接通过 Pod Labels 发现
适用场景 有 Service 层,需要负载均衡 无 Service 或 Sidecar 模式
标签继承 继承 Service 的标签 继承 Pod 的标签
策略命中率场景 推荐:Kyverno 通常有 Service 备选:直接抓取 Admission Webhook
实践建议: 在控制面策略监控中,优先使用 ServiceMonitor。它提供更稳定的抓取目标,且 Service 标签可以携带环境信息(如 environment=prod),便于后续策略命中率的多维度聚合分析。