大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
做DBA这些年，我最怕的不是半夜被电话叫醒，而是被叫醒之后翻半小时监控都不知道问题出在哪。传统监控工具像是后视镜——故障已经发生了，你才知道刚才撞了车。
最近几年，“可观测性”这个概念在数据库圈越来越热。简单说，就是从“被动告警”走向“主动预测”。今天我就聊聊数据库监控的进化路径，以及怎么用更智能的手段提前发现隐患。
这个转变其实是被逼出来的。以前我做运营的时候，看数据是看趋势、找拐点。转行做DBA之后才发现，很多监控工具还停留在“超过阈值就报警”的阶段，等报警响起，业务已经受损了。如果能像做运营分析那样，提前看到指标的异常波动，很多故障完全可以避免。
监控的三个进化阶段
第一阶段：被动告警（救火式）
设置一堆阈值：CPU > 80%告警、连接数 > 1000告警、慢查询 > 10条/分钟告警。问题是等你收到告警，故障已经发生了，用户已经受影响了。而且阈值很难调——设低了天天误报，设高了故障漏报。我早期就是这种模式，结果是凌晨两三点被叫醒已经是常态。
第二阶段：主动发现（基于趋势）
不再只看瞬时值，而是看趋势。比如过去一小时连接数从200匀速涨到800，虽然还没到1000的阈值，但按这个速度半小时后就会超。这时候提前预警，DBA可以在业务高峰前介入。很多开源工具（Prometheus + Grafana）配上合适的告警规则就能做到，关键是要有“预测意识”。我自己用这套方案之后，半夜被叫醒的频率降了不少。
第三阶段：预测性运维（基于AI/ML）
利用历史数据训练模型，识别出故障前的“前兆模式”。比如某条SQL之前每天执行1000次，今天突然变成5000次，很可能执行计划变了。或者某张表的索引碎片率在一周内从10%涨到70%，系统会提前建议你重建索引。这种能力传统监控做不到，需要结合AI算法。
最近也看到一些国产数据库在往这个方向走。比如KingbaseES的运维平台，会采集历史性能数据建立动态基线，根据业务周期自动调整告警阈值，减少误报。它还支持SQL性能预测，能根据执行计划的变化趋势，提前告诉你“这条SQL下周可能会变慢”。另外，当检测到指标异常时，系统会给出根因分析提示，比如“某条SQL执行耗时上升，疑似索引失效，建议重新收集统计信息”。这类能力虽然还不能完全替代人工判断，但至少能帮你把排查范围缩小一大半。
如何落地？从这三步开始
完善指标采集：不光要采集系统级指标（CPU、内存、IO），更要采集数据库级指标（行锁等待时间、临时表创建频率、慢查询详情、InnoDB缓冲池命中率）。
建立历史基线：用监控系统（如Prometheus）存储至少3个月的数据，观察业务周期规律（每天几点高峰、每周哪天最忙）。金仓内置的历史性能仓库可以自动保留最近90天的性能数据，方便做趋势对比。
设置智能告警：从固定阈值升级到动态阈值（基于历史同期数据计算）。比如今天上午10点的QPS比过去7天同一时刻的平均值低40%，可能是有节点挂了或网络分区。
一点体会
数据库监控从救火到预测，本质是让DBA从“被动响应”走向“主动掌控”。这并不一定需要多高深的AI技术，哪怕只是把趋势告警用起来，也能把半夜被叫醒的次数降低一半。监控工具是辅助，关键还是要有“用数据说话”的意识——这一点，做运营出身的我倒是有点天然优势。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
