分级告警需结合业务语义与响应逻辑，按影响定级而非技术指标；p0/p1/p2对应差异化通知方式；恢复告警自动推送；每月复盘优化阈值与淘汰沉默规则。
分级告警不是简单把“高、中、低”贴在告警上，而是让每条告警都带着业务语义和响应逻辑。核心是让运维只在该出手时被叫醒，其他时候不被打扰。
按业务影响定级，不是按技术指标硬套
同一项指标在不同角色服务器上意义完全不同：
- 数据库服务器 CPU 持续 75% 超过 3 分钟 → 影响查询延迟，应归为 P0（紧急）
- 批处理服务器短时冲到 95% → 属正常峰值，但需同步检查 /var/log 剩余空间是否
- Windows 上 w3svc 或 sqlserver 进程状态变为 Stopped → 直接关联业务不可用，必须 P0，电话+钉钉+短信三通道
- Java 应用进程内存占用超 2GB 且 5 分钟内持续增长 → 比 CPU 高更危险，优先级高于同台机器的 CPU 告警
设置多维触发条件，过滤瞬时抖动
单看一个数字容易误报，要叠加时间、趋势、关联性三个维度：
- CPU > 85% 必须满足「连续 5 分钟」才触发，避免 GC 或定时任务造成的秒级尖峰干扰
- 磁盘使用率告警分两级：>85% 触发 P2（邮件汇总），>95% 且剩余空间
- 当核心服务宕机时，自动抑制其下游所有依赖服务的“连接失败”类告警，只留一条“根因告警”
- 对 JVM 类应用，Full GC 频次 >3 次/分钟 + STW 时间 >200ms → 合并为一条 P1 告警，附带最近 GC 日志片段
通知方式严格匹配等级，拒绝“一锅端”
不是所有告警都值得弹窗+响铃，渠道错配是疲劳主因：
- P0（紧急）：电话呼出 + 钉钉强提醒 + 短信，值班人必须 5 分钟内确认；浏览器右下角弹窗卡片强制置顶，点击直达故障拓扑图
- P1（严重）：钉钉全员@ + 邮件，铃声用中频持续音（如“滴——滴——”），同一时段只播最高级一次
- P2（次要）：仅邮件汇总，每日早 8 点推送到运维日报，不弹窗、不响铃、不 @
- 恢复告警：P0/P1 故障修复后自动推送“已恢复”，带修复操作记录和耗时，避免人工反复确认
定期做告警复盘，动态优化规则
每月抽样分析上周全部告警：
- 标记“无效告警”：未引发任何处置动作、30 分钟内自动恢复、无业务影响佐证
- 统计“漏报场景”：事后发现的问题，监控系统当时为何没发声
- 调整阈值依据：参考过去 7 天同一时段基线（比如双11前将 CPU 阈值从 80% 动态上浮至 88%）
- 淘汰沉默规则：连续 30 天零触发的 P2 规则，直接归档或转为日志审计项
