1. 课程导论：为什么告警聚合与 Metric 设计需要协同优化？核心痛点与收益概述
1.1 告警疲劳：一个被低估的系统性故障
在可观测性工程实践中，告警系统是 SRE 团队感知服务健康状态的“神经系统”。然而，当 Metric 设计与告警规则相互脱节时，这个神经系统会陷入一种危险的“过敏状态”——告警风暴。一个底层节点抖动，可能触发数十条关联告警；一个业务指标毛刺，可能淹没在数百条基础设施告警中。这种噪声不仅消耗工程师的精力，更会掩盖真正的根因。
核心痛点： 告警聚合不是简单的“去重”或“静默”，而是需要从 Metric 的标签设计、采集粒度、聚合层级出发，在数据源头就为告警规则提供结构化的“上下文”。否则，告警规则只能基于原始、高基数、无层级的数据做“事后过滤”，效果极其有限。
1.2 告警聚合与 Metric 设计的“鸡与蛋”关系
许多团队将告警规则设计和 Metric 设计视为两个独立阶段：先埋点、再配告警。这种线性思维导致了以下典型问题：
| 问题维度 | 典型表现 | 根因分析 |
|---|---|---|
| 标签爆炸 | 告警规则无法按 service、region、pod 等维度聚合，只能逐条配置 | Metric 标签设计未考虑告警聚合的“分组键”需求 |
| 层级缺失 | 无法区分“单实例故障”与“集群整体过载”，告警严重度混乱 | Metric 缺乏从 instance → node → cluster 的层级聚合 |
| 基数失控 | 高基数标签（如 user_id、request_id）导致 Prometheus 内存爆炸，告警规则无法执行 | 告警规则直接引用高基数标签，未做降维或聚合 |
| 重复告警 | 同一故障触发多条相似告警，如 CPU 高、内存高、延迟高同时告警 | 告警规则之间缺乏“因果链”关联，Metric 设计未提供根因指标 |
1.3 协同优化的核心收益
当告警聚合规则与 Metric 设计形成协同关系后，团队可以获得以下可量化的收益：
- 告警压缩比提升 80%+： 通过标签分组和层级聚合，将原始告警数量压缩为 1-2 条聚合告警。
- MTTR 缩短 40%-60%： 聚合告警自带“上下文标签”（如 region、service、error_class），减少人工排查维度。
- Prometheus 查询性能稳定： 避免高基数标签直接参与告警规则计算，降低 TSDB 内存压力。
- 告警规则可维护性提升： 一套聚合规则覆盖数百个实例，而非为每个实例单独配置。
1.4 协同优化架构总览
下图展示了告警聚合与 Metric 设计协同优化的核心架构。从 Metric 采集层开始，通过标签设计、层级聚合、降维处理，为告警规则层提供结构化的数据输入，最终实现高效的告警聚合与通知。
1.5 典型失败案例：未协同优化的告警风暴
假设一个电商平台部署了 100 个 Pod，每个 Pod 暴露了 http_requests_total 和 cpu_usage 两个 Metric。如果告警规则直接写为：
# 错误示例：未协同优化
- alert: HighCPU
expr: cpu_usage > 0.9
for: 5m
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 5m当某个 Pod 故障时，这两个规则会为每个 Pod 分别触发告警，产生 200 条告警。而如果 Metric 设计时加入了 service 和 region 标签，并通过 Recording Rule 预聚合：
# 预聚合：按 service 和 region 降维
- record: service:cpu_usage:avg
expr: avg by (service, region) (cpu_usage)
- record: service:error_rate:avg
expr: sum by (service, region) (rate(http_requests_total{status=~"5.."}[5m]))告警规则可以简化为：
# 正确示例：协同优化后
- alert: ServiceHighCPU
expr: service:cpu_usage:avg > 0.9
for: 5m
labels:
severity: critical
annotations:
summary: "Service {{ $labels.service }} in {{ $labels.region }} CPU high"
- alert: ServiceHighErrorRate
expr: service:error_rate:avg > 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "Service {{ $labels.service }} in {{ $labels.region }} error rate high"此时，告警数量从 200 条压缩为 2 条，且每条告警直接携带了 service 和 region 上下文。
1.6 课程核心内容预览
本课程将围绕以下四个阶段展开：
- Metric 设计基础： 标签设计原则、基数控制、层级聚合策略。
- 告警聚合规则设计： 分组、抑制、路由、静默规则的最佳实践。
- 协同优化实战： 从 Metric 到告警规则的端到端案例（Kubernetes、微服务、数据库）。
- Grafana Alerting 高级特性： 多维度聚合、时间序列降维、告警分组与通知模板。