4、分组策略设计：基于标签（severity, service, cluster）的多级分组规则

告警分组是聚合规则的核心环节，决定了同一事件源的多条告警如何被合并为一条通知。合理的分组策略能显著降低告警风暴期间的认知负荷，确保接收者只关注最关键的上下文。本章围绕 severity（严重级别）、service（服务名）、cluster（集群标识） 三个核心标签，设计一套可落地、可扩展的多级分组规则。

4.1 分组粒度与标签优先级

分组粒度越细，通知数量越多；粒度越粗，信息聚合度越高，但可能丢失区分度。生产环境推荐采用 三级分组 策略：

4.2 多级分组规则定义（Grafana Alerting 示例）

在 Grafana Alerting 中，分组规则通过 group_by 字段配置。以下是一个基于标签的多级分组配置片段：

# Grafana Alerting 分组配置（YAML 格式）
route:
  receiver: 'default-receiver'
  group_by: ['severity', 'service', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

  # 子路由：按 severity 进一步分流
  routes:
    - receiver: 'critical-pager'
      match:
        severity: 'critical'
      group_by: ['service', 'cluster']
      group_wait: 10s
      group_interval: 1m
      repeat_interval: 1h

    - receiver: 'warning-slack'
      match:
        severity: 'warning'
      group_by: ['service']
      group_wait: 1m
      group_interval: 15m
      repeat_interval: 6h

4.3 分组策略流程图

下图展示了从告警产生到最终通知的多级分组处理流程：

4.4 标签设计规范与避坑指南

分组策略的有效性高度依赖标签的规范性和一致性。以下是生产环境中的关键规范：

• 标签命名统一： 所有服务必须使用相同的标签键（如 service 而非 svc / app_name），避免分组失效。
• 避免高基数标签： 不要将 instance、pod、host 等唯一标识符加入分组键，否则每条告警都会独立成组，失去聚合意义。
• severity 标准化： 建议只使用 critical、warning、info 三级，避免自定义级别导致分组混乱。
• cluster 标签来源： 优先从 Prometheus 的 external_labels 或告警源的元数据注入，确保跨服务一致。

4.5 多级分组与通知渠道的映射

不同分组层级可以映射到不同的通知渠道，实现告警的精细化路由：

4.6 分组策略的验证与调优

分组规则上线后，需要通过以下指标持续评估效果：

• 告警压缩比： 原始告警数 / 通知数，理想值应大于 5:1；低于 3:1 说明分组粒度过细。
• 通知延迟： 从告警产生到通知送达的时间，critical 级别应控制在 1 分钟内。
• 误合并率： 不同故障的告警被错误合并到同一通知的比例，应低于 1%。