监控的层次

一、基础设施监控：CPU、内存、磁盘、网络、进程存活。

二、应用性能监控（APM）：响应时间、错误率、吞吐量、数据库查询耗时、外部调用耗时。

三、业务监控：注册数、订单量、支付成功率、关键漏斗转化率。

四、日志与链路追踪：用于定位具体问题的根因。

可观测性的三个支柱

指标（Metrics）：数值型的时间序列数据。聚合度高、存储成本低，适合监控和告警。

日志（Logs）：离散的事件记录。信息详细，适合排查问题，但数据量大。

链路追踪（Traces）：一次请求在分布式系统中的完整路径。用于定位跨服务的问题。

三者互补，缺一不可。

告警设计的常见错误

一、基于"原因"而非"症状"告警

例如：CPU 使用率超过 80% 就告警。

问题是：CPU 高不一定意味着有问题（可能是正常的批处理任务）。这类告警会产生大量噪音。

更好的做法：基于症状告警——也就是用户实际感受到的问题：

  • 错误率上升；
  • 响应时间变慢；
  • 订单成功率下降。

CPU 高这类"原因"指标，应该作为排查时的辅助信息，而不是告警本身。

二、阈值设置过于敏感

阈值太紧，稍有波动就告警；太松，真正的问题被漏掉。

改进：

  • 使用持续时长条件（如"错误率连续 5 分钟超过 5%"而非"某一刻超过 5%"）；
  • 结合同比/环比（与昨天同一时间、上周同一时间对比），过滤掉周期性的正常波动；
  • 用统计方法（如标准差、分位数）动态确定阈值，而非拍脑袋定一个固定值。

三、告警没有分级

所有告警都一样"紧急"，导致真正紧急的被淹没。

建议分级：

  • P0（紧急）：影响核心业务，需要立即处理，通常触发电话/短信通知；
  • P1（重要）：影响部分功能或指标恶化，需要在数小时内处理；
  • P2（提示）：需要关注但不紧急，进入工单队列。

四、告警没有可操作性

收到告警的人不知道该做什么。

每条告警都应该附带：

  • 问题描述；
  • 可能的影响范围；
  • 排查方向或 Runbook（处置手册）链接；
  • 相关仪表盘的链接。

五、重复告警与告警风暴

一个根因触发几十条告警，接收者被淹没，反而忽略了关键信息。

应对：告警收敛与聚合（把相关告警合并成一条），以及抑制（上游故障已告警时，抑制下游的连锁告警）。

告警疲劳的代价

当团队习惯了"大部分告警都无所谓"，就会开始忽略告警。

真正的故障发生时，可能被淹没在噪音中，或者被值班人员当作"又是误报"而忽略。

这是最危险的后果：监控系统完好无损地运行着，但没人相信它。

几条实践建议

  • 定期审计告警：哪些告警在过去三个月从未被处理过？哪些一直在响？删掉或调整它们；
  • 每次故障后复盘：告警是否及时？是否准确？有没有噪音干扰？；
  • 值班轮转要合理，避免单人长期承担告警压力；
  • 建立告警—响应—复盘的闭环。

一句话

监控的目标是让人在正确的时间知道正确的事，而不是让人收到尽可能多的通知。

说明：本文为运维实践的知识整理。