4. Prometheus 架构回顾：Pull 模型与 Push 模型、指标收集与存储、Alertmanager 告警体系、Service Discovery 机制

在构建 Serverless 生命周期配置漂移审计体系时，Prometheus 作为核心的指标与事件平台，其架构设计直接决定了审计数据的采集效率、存储可靠性与告警实时性。本节从架构演进视角，系统回顾 Prometheus 的四大核心支柱：数据采集模型、指标存储引擎、告警处理体系以及动态发现机制。

4.1 Pull 模型与 Push 模型：架构哲学与适用场景

Prometheus 原生采用 Pull（拉取）模型，即 Prometheus Server 主动向目标端点（Exporter）发起 HTTP 请求获取指标数据。这一设计带来了以下关键优势：

• 健康探测天然集成：如果目标无法响应，Prometheus 立即感知，无需额外心跳机制。
• 控制权在服务端：采集频率、超时、重试均由中心端统一管理，避免被采集端过载。
• 网络拓扑清晰：适合内部网络环境，防火墙规则可精确控制出站方向。

然而，在 Serverless 场景下，函数实例生命周期极短（秒级），Pull 模型可能错过已销毁的实例。此时需要 Push 模型作为补充，通过 Pushgateway 组件实现：

4.2 指标收集与存储：从抓取到持久化的完整链路

Prometheus 的指标收集与存储链路可拆解为四个阶段：抓取（Scrape） → 预聚合（Recording Rules） → 存储（TSDB） → 查询（PromQL）。每个阶段在审计场景中都有特定的优化点。

4.2.1 抓取生命周期

1. 服务发现：通过 Service Discovery 获取目标列表。
2. 目标配置：应用 scrape_interval、scrape_timeout、metrics_path 等参数。
3. HTTP 请求：向目标端点发起 GET /metrics 请求。
4. 数据解析：解析 Prometheus 文本格式或 Protobuf 格式的指标数据。
5. 标签处理：添加或覆盖标签（relabel_configs），用于后续聚合与过滤。
6. 样本写入：将时间序列样本写入 TSDB 内存缓存。

4.2.2 TSDB 存储引擎核心特性

# prometheus.yml
storage:
  tsdb:
    retention.time: 90d          # 审计数据保留 90 天
    retention.size: 50GB         # 最大存储限制
    wal-compression: true        # 启用 WAL 压缩
    out-of-order-time-window: 10m # 允许乱序样本窗口

4.3 Alertmanager 告警体系：从规则到通知的完整闭环

Alertmanager 是 Prometheus 告警体系的核心枢纽，负责接收、分组、抑制、静默和发送告警。在配置漂移审计中，Alertmanager 将配置变更事件转化为可操作的告警通知。

4.3.1 告警处理流程

1. 告警规则评估：Prometheus Server 定期评估告警规则，当表达式结果为 true 时生成告警。
2. 告警发送：Prometheus 将告警推送到 Alertmanager API。
3. 分组（Grouping）：按标签将相似告警合并，避免告警风暴。
4. 抑制（Inhibition）：当存在高优先级告警时，抑制低优先级告警。
5. 静默（Silencing）：基于匹配规则临时屏蔽特定告警。
6. 路由（Routing）：根据告警标签路由到不同的接收器（Receiver）。
7. 通知发送：通过邮件、Slack、PagerDuty、Webhook 等渠道发送。

4.3.2 配置漂移告警规则示例

# 检测配置指纹变化
groups:
  - name: config_drift_alerts
    rules:
      - alert: ConfigFingerprintChanged
        expr: |
          changes(config_fingerprint[5m]) > 0
        for: 1m
        labels:
          severity: warning
          audit_type: config_drift
        annotations:
          summary: "配置指纹在 5 分钟内发生变化"
          description: "服务 {{ $labels.instance }} 的配置指纹从 {{ $value }} 发生变化"

      - alert: ConfigDriftThresholdExceeded
        expr: |
          count by (service) (config_fingerprint != on(instance) group_left config_fingerprint offset 1h) > 3
        for: 5m
        labels:
          severity: critical
          audit_type: config_drift
        annotations:
          summary: "服务 {{ $labels.service }} 配置漂移超过阈值"
          description: "1 小时内配置变更次数超过 3 次"

4.4 Service Discovery 机制：动态目标管理的基石

在 Serverless 环境中，函数实例的 IP 和端口动态变化，静态配置无法满足需求。Prometheus 的 Service Discovery（SD） 机制通过集成云平台 API 或服务注册中心，自动发现并管理监控目标。

4.4.1 支持的发现机制

4.4.2 标签重标注（Relabeling）在审计中的应用

标签重标注是 Service Discovery 的核心能力，允许在采集前对目标标签进行增删改。在配置漂移审计中，常用以下模式：

# 保留审计相关标签，过滤无关目标
relabel_configs:
  - source_labels: [__meta_kubernetes_pod_label_audit_enabled]
    regex: "true"
    action: keep

  # 添加审计维度标签
  - target_label: audit_source
    replacement: "kubernetes_sd"

  # 将 Pod 名称映射为 instance 标签
  - source_labels: [__meta_kubernetes_pod_name]
    target_label: instance
    action: replace

  # 丢弃临时 Pod（如 Job 完成后的 Pod）
  - source_labels: [__meta_kubernetes_pod_phase]
    regex: "Succeeded|Failed"
    action: drop

4.5 架构总结：审计场景下的 Prometheus 组件协同

在 Serverless 配置漂移审计中，Prometheus 各组件协同工作：

• Service Discovery 动态发现 Serverless 函数实例，并通过标签重标注注入审计维度。
• Pull / Push 混合模型 确保长期运行组件和临时函数实例的配置数据均被采集。
• TSDB 存储 提供高效的时序数据压缩与查询能力，支持 90 天以上的审计数据保留。
• Alertmanager 将配置变更事件转化为分级告警，通过路由分发到不同审计团队。