很多团队一开始建设监控，都会从「先把图画出来」开始：CPU、内存、QPS、延迟、错误率，能接的指标全接上。看板很快变得很丰富，但线上真正出问题时，值班同学仍然不知道该先看哪里、谁应该处理、这条告警是不是必须现在起床。
这说明监控报警体系的核心不是「数据可视化」，而是故障反馈系统：系统出问题时，它能不能把正确的信号，在正确的时间，交给正确的人，并附带足够的上下文让人行动。
所以这篇文章不从某个工具讲起，而是从体系建设讲起。工具可以是 Bosun、Prometheus、Grafana、OpenTSDB、夜莺或自研平台，但它们最终都要回答同一个问题：什么情况值得打断一个人？
一、监控不是看板，是反馈系统
看板回答的是「现在长什么样」；报警回答的是「要不要立刻行动」。这两个目标很容易混在一起，但工程上必须分开。
| 类型 | 核心问题 | 典型读者 | 设计重点 |
|---|---|---|---|
| Dashboard | 系统现在是什么状态？ | 研发、值班、排障人员 | 展示关键指标、支持下钻、辅助定位 |
| Alert | 现在是否需要人介入？ | 值班人员、服务负责人 | 低噪声、可行动、可升级、可恢复 |
| Report | 长期趋势如何？ | 团队负责人、容量规划人员 | 周/月维度趋势、容量、成本、质量 |
一个常见反模式是：把看板上的每条曲线都加一个阈值，超过就报警。这样做会制造大量噪音，因为很多指标只是诊断线索，不是故障信号。比如 CPU 突然升高可能是正常扩容、批任务、缓存预热，也可能是死循环；它值得出现在看板上，但不一定值得半夜叫醒人。
更好的做法是先定义「故障」：用户不可用、请求失败率上升、核心链路延迟恶化、数据积压导致交付超时、容量即将耗尽。然后再倒推需要哪些指标、日志和链路信息。
二、先定义故障，再定义指标
监控建设的第一步不是埋点，而是列出系统承诺。一个支付系统的承诺可能是「下单链路成功率」「支付回调时效」「账务一致性」；一个推荐系统的承诺可能是「接口延迟」「特征新鲜度」「召回结果数量」；一个调度系统的承诺可能是「任务按时完成」「队列积压可控」「异常任务可恢复」。
这些承诺落到监控上，就是 SLI（服务水平指标）。当 SLI 有了目标值，就形成 SLO。报警应该尽量围绕 SLO 或明确的故障症状设计，而不是围绕机器指标设计。
- 用户是否受影响：成功率、端到端延迟、可用性、错误页面比例。
- 业务是否受影响：订单创建量、支付成功量、任务完成量、消息消费延迟。
- 系统是否快到极限：队列积压、连接池耗尽、磁盘剩余、CPU throttling、线程池拒绝。
- 依赖是否异常：数据库慢查询、RPC 错误率、缓存命中率、第三方超时。
指标不是越多越好。指标的价值在于它能支持决策：要不要报警、谁处理、怎么定位、怎么恢复。不能支持决策的指标，可以进看板，不应该进报警。
三、四层指标模型：从用户到机器
一个可维护的监控体系，最好按层分解。每一层解决不同问题，报警级别也不同。
| 层级 | 关注对象 | 典型指标 | 是否适合直接报警 |
|---|---|---|---|
| 用户体验层 | 用户看到的结果 | 可用性、成功率、P95/P99、端到端耗时 | 适合，优先级最高 |
| 业务过程层 | 核心业务流是否正常 | 订单量、支付量、履约时效、任务完成率 | 适合，需结合业务周期 |
| 服务接口层 | 服务自身是否健康 | QPS、错误率、延迟、依赖耗时、线程池 | 适合，是主要报警层 |
| 资源基础层 | 机器和基础设施 | CPU、内存、磁盘、网络、FD、GC | 部分适合，多数用于定位 |
这个分层的价值在于：当用户体验层报警时，说明事故可能已经发生；当服务接口层报警时，说明故障正在形成；当资源基础层报警时，通常只是原因候选。一个成熟体系会把不同层的信号串起来，而不是让所有层都平等地打到值班群。
四、从采集到通知：链路怎么闭合
监控报警链路可以拆成六段：采集、存储、计算、规则、路由、处置。任何一段不稳定，最后都会变成「漏报」或「误报」。
- 采集：应用埋点、exporter、agent、日志采集、链路追踪。关键是命名规范和标签规范。
- 存储：时序数据库保存指标，日志系统保存事件，trace 系统保存调用链。关键是容量、高基数控制和查询性能。
- 计算：窗口聚合、同比环比、分位数、错误预算消耗、异常检测。关键是把原始数据压缩成判断信号。
- 规则：warn/crit、持续时间、缺失数据、依赖抑制、静默策略。关键是可解释、可测试、可版本管理。
- 路由：按服务、业务线、机房、环境、严重级别分派到对应人和渠道。关键是不要让所有告警进一个大群。
- 处置：确认、升级、恢复、复盘、规则修正。关键是把每次告警变成系统改进。
很多团队的问题不在采集，而在后半段：指标已经有了，但规则没有 owner；告警能发出来，但不知道该找谁；故障恢复了，但告警规则不修；重复告警被静默，但根因没有处理。这样的系统只能叫「通知系统」，还不是报警体系。
五、报警生命周期：触发不是结束
一条报警从出生到消失，应该有完整生命周期。
| 阶段 | 系统动作 | 人的动作 | 常见问题 |
|---|---|---|---|
| 触发 | 规则计算为异常，生成事件 | 判断是否真实影响 | 阈值太敏感，瞬时抖动触发 |
| 合并 | 同类事件按服务/集群/故障域聚合 | 只处理主告警 | 同一故障打出几十条消息 |
| 通知 | 按严重级别路由到 IM、电话、工单 | 确认接收 | 所有级别都走同一渠道 |
| 升级 | 超时未 ack 或级别升高后升级 | 接力处理 | 值班人没响应无人兜底 |
| 恢复 | 规则回到正常，自动关闭或等待确认 | 确认业务恢复 | 恢复消息缺失，状态长期悬挂 |
| 复盘 | 沉淀根因和改进项 | 修规则、修系统、修流程 | 只处理事故，不处理告警质量 |
报警平台要保存这条生命周期，因为它是衡量体系质量的原始数据。平均确认时间、平均恢复时间、重复告警率、静默率、误报率、无人认领率，都是监控体系本身的监控指标。
六、降噪原则：每条报警都要有行动
报警噪声不是小问题，它会直接破坏人的响应能力。噪声高到一定程度后，值班人员会形成肌肉记忆：先忽略，再等群里有人问，最后只对电话有反应。到了这个阶段，报警系统已经失去信用。
降噪最重要的原则是：每条报警都必须对应一个行动。如果一条报警没有明确行动，它就不应该打断人。
- 没有行动手册：不要直接进入高优先级报警，先补 runbook。
- 没有 owner：不要进公共大群，先建立服务到责任人的映射。
- 无法判断影响：降级为观察项，补业务或用户体验层指标。
- 总是自动恢复：检查是否需要扩大窗口、增加持续时间或改成趋势告警。
- 总是重复触发：做合并、抑制、升级，而不是让人处理重复消息。
好的报警不是「异常检测器」，而是「行动触发器」。异常检测可以很多，真正进入人类注意力系统的必须很少。
七、一条务实的建设路线
监控报警体系不可能一次建完，比较务实的路线是从核心链路开始，逐步向平台化演进。
- 第一阶段：核心链路可见。为最重要的 3-5 条业务链路建立成功率、延迟、流量、错误率看板。
- 第二阶段：核心故障可叫醒。只把用户影响明确、行动明确的规则接入电话或强提醒。
- 第三阶段：规则可治理。规则进入版本管理，有 owner、说明、runbook、变更记录和回测。
- 第四阶段：告警可运营。统计误报率、重复率、确认时间、恢复时间，定期清理低质量规则。
- 第五阶段：平台化与自动化。服务目录、值班表、变更系统、发布系统、故障复盘系统打通，支持自动抑制、自动归因和自动恢复。
这条路线的重点不是工具升级，而是组织能力升级。监控报警体系本质上是一套生产反馈机制，它把系统故障、人员职责、响应流程和工程改进连接在一起。
结语
监控报警体系做得好，值班的人会更少被无意义打扰，但真正出事时反应更快；系统 owner 会更清楚自己的服务边界；团队会更容易从事故里学习。
下一篇继续讲更具体的问题：一条报警规则到底应该怎么设计，为什么阈值不是 if else，窗口、聚合、同比、缺失数据和依赖抑制分别解决什么问题。