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 等标签自动注入,使得我们可以按工作负载维度精确查询策略命中率。
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。
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),便于后续策略命中率的多维度聚合分析。