3. Prometheus 监控体系：架构、资源定义与采集生命周期

在 Kubernetes 与服务网格的混合治理场景中，Prometheus 不仅是指标存储与告警引擎，更是回滚护栏的数据基座。本节从架构分层、资源对象配置、采集生命周期三个维度，拆解 Prometheus 如何与 K8s 原生机制协同，为后续的指标驱动回滚提供可靠数据管道。

3.1 Prometheus 在 K8s 环境中的分层架构

生产环境通常采用 Prometheus Operator 模式部署，将 Prometheus 实例抽象为 Kubernetes 自定义资源。整体架构分为三层：

  • 采集层：Prometheus Server + ServiceMonitor / PodMonitor 动态发现目标。
  • 存储与查询层：Thanos / VictoriaMetrics 实现长期存储与全局视图。
  • 告警与事件层：Alertmanager 根据指标阈值触发回滚或人工介入。
关键设计原则：每个 Kubernetes 命名空间对应一个 Prometheus 实例或 Shard，避免指标采集互相干扰；ServiceMonitor 与 PodMonitor 通过 label selector 精确控制采集范围，减少无效抓取。
Prometheus 在 K8s 环境中的分层架构 采集层 — Prometheus Server + Operator ServiceMonitor PodMonitor Probe Scrape 存储与查询层 — 长期持久化 Thanos Sidecar VictoriaMetrics Grafana 查询 告警与事件层 — 回滚触发 Alertmanager Webhook → Rollback

3.2 ServiceMonitor 与 PodMonitor 配置详解

Prometheus Operator 通过 ServiceMonitor 和 PodMonitor 两个 CRD 实现动态服务发现。两者核心区别在于发现的目标层级：

对比维度 ServiceMonitor PodMonitor
发现目标 Kubernetes Service 背后的 Endpoints 直接匹配 Pod IP + 端口
适用场景 有 Service 代理的微服务（如 Istio Sidecar） 无 Service 的 DaemonSet / 静态 Pod
标签选择 selector.matchLabels 匹配 Service 标签 selector.matchLabels 匹配 Pod 标签
端口定义 通过 Service 端口名称或端口号 直接指定 Pod 内容器端口
路径与协议 endpoints 级别配置 metrics 路径 pod 级别配置 metrics 路径

3.2.1 ServiceMonitor 配置示例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: productpage-monitor
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: productpage
  endpoints:
  - port: http
    interval: 15s
    path: /metrics
    scheme: http
  namespaceSelector:
    any: true
生产建议：ServiceMonitor 的 namespaceSelector 建议显式指定命名空间，避免跨 namespace 误抓；interval 根据业务抖动容忍度设置，回滚场景建议 ≤ 15s。

3.2.2 PodMonitor 配置示例

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: envoy-stats-monitor
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: sidecar-injector
  podMetricsEndpoints:
  - port: http-envoy-prom
    interval: 10s
    path: /stats/prometheus
    relabelings:
    - sourceLabels: [__meta_kubernetes_pod_node_name]
      targetLabel: node
      action: replace
  namespaceSelector:
    matchNames:
    - default
    - istio-system
避坑提示：PodMonitor 的 relabelings 常用于注入节点标签、工作负载标签；但注意不要覆盖 Prometheus 内置的 __meta_* 标签，否则会导致服务发现失效。

3.3 指标采集生命周期

从 Prometheus 发起 HTTP 请求到指标入库，完整生命周期包含 6 个阶段。理解每个阶段有助于排查采集延迟、指标丢失等问题。

指标采集生命周期 阶段1 服务发现 阶段2 Relabel 阶段3 HTTP 抓取 阶段4 解析 & 过滤 阶段5 存储 阶段6 告警评估 各阶段关键动作 • 服务发现：K8s API → 目标列表 • Relabel：注入标签、过滤目标、修改指标路径 • 告警评估：基于 TSDB 数据触发回滚规则

3.3.1 各阶段详细说明

阶段 核心动作 常见问题 回滚护栏关联
1. 服务发现 Prometheus 通过 K8s API 获取 Service/Pod 列表 RBAC 权限不足导致发现失败 目标缺失 → 回滚指标空洞
2. Relabel 修改/过滤标签，注入工作负载标识 标签覆盖导致唯一标识丢失 无法按版本聚合回滚指标
3. HTTP 抓取 向目标端点发起 GET /metrics 请求 超时、TLS 证书过期 采集延迟 → 回滚判断滞后
4. 解析 & 过滤 解析 Prometheus 文本格式，丢弃无效行 指标名称冲突、标签基数爆炸 高基数导致存储压力
5. 存储 写入 TSDB block，压缩与持久化 磁盘 IO 瓶颈、WAL 损坏 历史数据缺失影响回滚基线
6. 告警评估 PromQL 规则周期性计算 规则语法错误、评估间隔过长 直接决定回滚触发时机

3.4 采集生命周期中的回滚护栏关键指标

在服务网格治理场景下，以下指标必须确保被正确采集并保留足够历史窗口：

  • istio_requests_total：请求总量，用于计算错误率与延迟分位数。
  • istio_request_duration_milliseconds：P99/P95 延迟，回滚触发核心信号。
  • envoy_cluster_upstream_rq_xx：按响应码聚合，5xx 突增直接关联回滚。
  • container_cpu_usage_seconds_total / container_memory_working_set_bytes：资源饱和导致级联故障。
采集配置最佳实践：
1. 每个 ServiceMonitor 只匹配一个微服务，避免 selector 范围过大。
2. 为回滚场景单独设置 scrape_timeout: 10s，避免慢目标拖慢整体采集。
3. 在 relabel 阶段保留 version 标签，用于回滚时的版本对比。
4. 启用 honor_labels: true 防止 Prometheus 覆盖目标暴露的标签。

3.5 本章小结

← 上一章 📖 返回目录 下一章 →