SQL数据库告警需基于业务水位动态设阈值、多维关联判断、分级收敛与静默、附带可回溯上下文，避免噪音，聚焦真实故障。
SQL数据库告警不能只靠“CPU > 80%”这种粗放规则，否则运维会被噪音淹没。核心是让告警真正反映业务影响或潜在故障，而不是指标抖动。
基于业务水位动态设定阈值
固定阈值（如慢查询 > 1s）在流量高峰时误报率高，在低谷时又可能漏掉真实异常。应结合历史基线动态计算阈值：
- 按小时/天粒度统计过去7天同时间段的P95响应时间、QPS、连接数等关键指标，生成基准区间
- 使用移动标准差或IQR（四分位距）识别离群点，而非简单加减固定值（例如：当前值 > 基线均值 + 2.5 × 标准差才触发）
- 对写入类指标（如binlog增长速率）单独建模，避免被读请求掩盖真实压力
多维关联判断减少单点误报
单一指标突增未必代表故障，需叠加上下文验证：
- 慢查询告警必须同时满足：平均响应时间上升 + 错误率上升 + 对应表的锁等待次数增加
- CPU飙升需关联检查：是否伴随大量临时表创建、sort_merge_passes激增或InnoDB buffer pool命中率跌破90%
- 连接数告警要过滤掉应用端健康检查心跳连接（可通过user/host/client_ip字段识别）
分级收敛与静默策略
同一故障链路可能引发多个指标告警，需聚合降噪：
- 设置告警等级：L1（实例不可用）、L2（核心表延迟 > 5s）、L3（非核心指标异常），仅L1/L2推送电话，L3仅站内通知
- 启用“风暴抑制”：5分钟内同一实例触发3次以上同类告警，后续告警自动合并为一条，并附带趋势图链接
- 维护维护窗口白名单：备份时段允许buffer pool命中率短暂下降，自动屏蔽该时段相关告警
可回溯的告警上下文
每次告警必须自带诊断线索，避免人工反复查日志：
- 附带最近10分钟的Top 3慢SQL（含执行计划摘要和扫描行数）
- 给出关键资源占用快照：当前活跃连接数、未提交事务数、主从延迟秒数
- 标记是否与最近一次DDL操作、配置变更或发布窗口重叠（通过CMDB或发布系统API关联）
告警不是越响越好，而是要让收到的人一眼看懂“哪里出了问题、影响多大、下一步查什么”。设计时多花一小时建模，能省下运维每天半小时的无效排查。
