2. Grafana 告警体系回顾

在深入降噪规则测试验证之前，必须对 Grafana Alerting 的核心架构、数据源与告警规则的绑定关系、以及告警状态机的生命周期有清晰的理解。本节将系统梳理这三个关键维度，为后续的降噪策略设计打下基础。

2.1 Grafana Alerting 架构总览

Grafana Alerting 采用 统一告警引擎 架构，将数据源查询、告警规则评估、通知路由与静默/分组等降噪机制整合在一个平面内。其核心组件包括：

• Alert Rule（告警规则）：定义查询表达式、评估频率、条件阈值及持续时间。
• Evaluation Engine（评估引擎）：周期性执行规则，计算是否触发告警。
• Alert Instance（告警实例）：规则每次评估产生的具体告警对象，携带标签与时间序列数据。
• Notification Policy（通知策略）：基于标签匹配将告警实例路由到不同的联系人点（Contact Point）。
• Silence / Mute Timing（静默/屏蔽时段）：在指定时间窗口内抑制告警通知。
• Alert Grouping（告警分组）：将相似告警合并为一条通知，减少告警风暴。

2.2 数据源与告警规则的绑定

Grafana 告警规则必须关联一个 数据源，评估引擎通过该数据源执行查询。支持的数据源类型包括：

告警规则的核心结构包含以下字段：

// 告警规则 YAML 示例（Grafana 8.x+）
apiVersion: 1
groups:
  - name: "production_alerts"
    interval: 30s
    rules:
      - uid: "high_cpu_rule"
        title: "CPU 使用率过高"
        condition: "A"
        data:
          - refId: "A"
            datasourceUid: "prometheus_prod"
            model:
              expr: 'avg(rate(node_cpu_seconds_total{mode="user"}[5m])) > 0.8'
              intervalMs: 30000
              maxDataPoints: 100
        for: "5m"
        labels:
          severity: "critical"
        annotations:
          summary: "CPU 使用率超过 80%"

2.3 告警状态机：Pending → Firing → Resolved

Grafana 告警实例遵循严格的状态机转换逻辑。理解状态机是配置降噪规则（如静默、分组、抑制）的前提。

状态转换的详细说明：

2.4 告警实例的标签与分组

每个告警实例在触发时会携带一组 标签（Labels），这些标签来自：

• 规则定义标签：在规则中静态指定的标签（如 severity: critical）。
• 数据源查询结果标签：PromQL 查询返回的时间序列标签（如 instance、job）。
• 自动注入标签：Grafana 自动添加的 alertname、grafana_folder 等。

标签是降噪规则的核心匹配依据。在后续章节中，我们将基于标签设计静默规则、分组策略和抑制规则。