1. 告警驱动设计概述
1.1 什么是告警驱动设计
告警驱动设计（Alert-Driven Design）是一种以告警规则为起点、反向推导监控指标定义与采集策略的工程方法。传统监控设计往往先“能采什么就采什么”，再事后配置告警阈值；告警驱动设计则要求团队在定义告警规则之前，先明确“什么故障必须被感知”、“什么行为代表系统不健康”，然后根据这些告警需求来裁剪、聚合、衍生出必要的 Metric 指标。
核心转变：从“采集驱动”到“告警驱动”——不是指标决定告警，而是告警决定指标。
| 维度 | 传统采集驱动 | 告警驱动设计 |
|---|---|---|
| 起点 | 基础设施/中间件暴露的原始指标 | 业务SLO与故障场景 |
| 指标数量 | 膨胀，大量无用指标 | 精简，每个指标都有告警归属 |
| 阈值定义 | 拍脑袋或默认值 | 基于基线校准与故障复现 |
| 维护成本 | 高，告警噪声大 | 低，告警精准可解释 |
1.2 为什么需要 Metric 驱动
在可观测性体系中，Logs、Traces、Metrics 三者各有分工。Metric 驱动（以指标为核心）之所以成为告警设计的基础，是因为 Metric 具备以下不可替代的特性：
- 低开销、高密度：一个时间序列可以聚合数万次请求，存储成本远低于全量日志。
- 可计算、可聚合：支持 sum/avg/p95/p99/rate 等数学运算，适合定义阈值条件。
- 可预测、可基线：历史指标可以建立动态基线，识别异常偏离。
- Grafana 原生支持：PromQL、Graphite、Loki 等数据源均以 Metric 为核心查询对象。
实践建议：优先使用 RED 方法论（Rate/Errors/Duration）定义服务级 Metric，再基于这些 Metric 构建告警规则。避免直接对原始日志或 Trace 做实时告警——延迟高且难以聚合。
| 可观测性支柱 | 告警适用性 | 典型场景 |
|---|---|---|
| Metrics（指标） | ★★★★★ 首选 | CPU > 90%、错误率 > 5%、P99延迟 > 500ms |
| Logs（日志） | ★★☆☆☆ 辅助 | 特定错误关键字匹配、审计合规 |
| Traces（链路） | ★★★☆☆ 诊断 | 慢调用根因定位、依赖拓扑异常 |
1.3 告警与监控的关系
监控（Monitoring）与告警（Alerting）是“数据采集”与“事件响应”的两端，二者存在明确的层次关系：
- 监控层：持续采集、存储、可视化 Metric 数据，回答“系统现在怎么样”。
- 告警层：基于监控数据定义规则，当指标偏离预期时产生通知，回答“哪里出了问题”。
- 响应层：告警触发后，SRE 通过 Runbook 执行故障恢复，回答“如何修复”。
没有监控的告警是“盲人摸象”——阈值拍脑袋、误报率高；没有告警的监控是“数据坟墓”——指标堆积却无人关注。告警驱动设计的本质，就是用告警规则来反向校准监控 Metric 的采集粒度、聚合方式和存储周期。
常见误区：不要将监控 Dashboard 上的每一个图表都配上告警。告警应该只覆盖“需要人工介入”的故障场景，而监控 Dashboard 可以展示更多“仅供参考”的指标。告警驱动设计帮助你区分“需要告警的 Metric”和“仅用于可视化的 Metric”。