数据库监控告警信息

凌晨两点十七分，数据我被手机震醒。库监控告屏幕上是警信DBA群里跳出的红色告警：主库CPU使用率98%，持续五分钟。数据我眯着眼点开详情，库监控告慢查询日志里密密麻麻全是警信同一个SQL的变体——某张表的数据量过了三千万，索引失效了。数据这是库监控告本周第三次。

告警信息本身没错，警信错的数据是我们太依赖它“事后喊救命”。真正该问的库监控告是：为什么每次都要等到CPU飙到98%才知道出问题？监控告警不该是火灾报警器，而应该是警信体温计——你得在发烧前看见趋势。

我见过最典型的数据告警疲劳案例，在某电商公司。库监控告他们半夜三点收到“磁盘空间不足”的警信告警，值班同事爬起来加了个临时清理脚本，倒头继续睡。第二天中午，存储直接写满，订单表卡死。回看告警记录，其实从下午六点开始，磁盘使用率就以每小时2%的速度爬升，但阈值设在90%，没人触发过提前预警。告警系统像个只会喊“着火了”的哨兵，却没人让它留意“墙角的烟头”。

真正的监控应该分层。基础层看存活，ping不通、端口挂了，立刻通知；中间层看性能，响应时间超过200毫秒就记录，超过500毫秒才告警；最上层看容量和趋势，比如每日慢查询数量环比增长30%，哪怕当前CPU才20%，也该提醒你该优化索引了。这套逻辑不复杂，但多数团队把三层混成一层，只设一个“高水位”阈值，结果要么天天被垃圾告警淹没，要么真出事时已经晚了。

还有个容易被忽略的点：告警信息要带上下文。光说“连接数超限”毫无意义，你得知道是哪个应用、哪类请求、从什么时候开始的。我曾在日志里见过最蠢的告警文案：“Error: null”。连报错对象都没有，排查的人得从几千行代码里猜。后来我们定了个规矩，告警必须附带最近五分钟的关键指标快照，像病历一样，让接手的人一眼看到“发病前”的状态。

说句掏心窝的话，监控告警的本质不是技术问题，是信任问题。如果告警十次有八次是误报，DBA会下意识忽略所有通知。我认识一位老运维，他把告警级别从P1到P5重新定义，P1只留给“数据丢失风险”和“主库不可用”，其他全降级。结果半年后，P1告警的响应时间从十分钟缩短到两分钟——因为大家知道，响了的都是真事。

最后聊点实在的。别指望“智能告警”能替你思考，它顶多帮你过滤噪音。真正的功夫在日常：每周花半小时看告警趋势图，哪类错误在重复出现，哪条SQL的耗时在悄悄变长。这些慢变量才是数据库的“慢性病”。告警信息只是症状，病根往往写在历史数据里。你得多翻翻旧账。