大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
做DBA这些年，我踩过最冤的一个坑，跟技术本身没关系——是告警。
有一阵子我们团队的告警群特别热闹。连接数超了、慢查询多了、缓冲池命中率降了，一天响几十次。刚开始大家还认真看，后来慢慢麻木了，看到消息连点都懒得点。
直到有天晚上，主从复制断了三个小时，告警在群里安安静静地躺着，没人发现。
第二天复盘，领导问了一句：“你们不是有监控吗？怎么没告警？”
我们面面相觑。告警发了，但没人看到。 因为它淹没在几十条“缓冲池命中率下降”“慢查询数量增加”的通知里。
那次之后我才明白，数据库监控的核心矛盾，从来都不是指标不够，是指标没有分层。
先把几个关键概念说清楚：
症状指标——直接反映业务受影响程度的指标。响应时间、错误率、连接拒绝数。这类指标异常了，说明用户已经在骂娘了。
根因指标——反映系统内部状态的指标。锁等待、脏页比例、缓冲池命中率、复制延迟。这类指标异常了，说明问题正在酝酿，但用户可能还没感觉。
静态阈值——固定的数值边界。比如连接数超过max_connections的80%、磁盘使用率超过80%。
动态基线——基于历史数据自动学习的正常范围。比如QPS与过去7天同时段对比，偏离超过50%触发告警。
一、为什么你的告警天天响
我后来复盘过，那套监控体系有一个通病：所有指标用同一套阈值策略，所有异常触发同样级别的告警。
结果就是：
缓冲池命中率从99%降到97%就告警，但业务毫无影响
慢查询从每分钟2条涨到5条就告警，响应时间纹丝不动
真正需要立即处理的主从断开，反而被淹没了
根因不在于指标选得不对，在于没有区分“症状”和“根因”。 症状指标应该触发告警，根因指标应该用于定位。两者混在一起，告警就失去了优先级。
二、指标分层：症状指标 vs 根因指标
症状指标（触发告警）
| 指标 | 含义 | 为什么是症状 |
|---|---|---|
| 平均响应时间 | 查询从发起到返回的耗时 | 用户直接感知 |
| 错误率 | 失败请求占比 | 业务已经受损 |
| 连接拒绝数 | 因连接池耗尽被拒绝的请求 | 服务不可用 |
| 事务失败率 | 事务回滚或超时的比例 | 数据操作失败 |
症状指标的特征是：异常发生时，用户已经或即将受到影响。这些指标应该配置最严格的告警，P0/P1级别，多渠道通知。
根因指标（用于定位）
| 指标 | 含义 | 为什么是根因 |
|---|---|---|
| 锁等待时长 | 事务等待锁的时间 | 可能导致响应变慢 |
| 脏页比例 | Buffer Pool中脏页占比 | 过高会触发强制刷盘 |
| 缓冲池命中率 | 缓存命中比例 | 过低说明内存不足 |
| 主从延迟 | 从库落后主库的时间 | 读写不一致的源头 |
| 慢查询数量 | 执行超过阈值的查询数 | 响应变慢的常见原因 |
根因指标的特征是：异常是“早期信号”，不直接等于业务受损。它们应该用于趋势监控和定位，而不是每条都触发告警。
一个实用的判断规则：如果一个指标异常了，但用户没有感知，它大概率是根因指标。如果一个指标异常了，用户已经在投诉了，它是症状指标。
三、阈值怎么设才不误报
第一层：静态阈值（硬边界）
适用于有明确物理上限或安全边界的指标：
连接数 >
max_connections× 80%：连接池即将耗尽磁盘使用率 > 80%：空间不足会导致写入失败
缓冲池命中率 < 95%：内存可能不足或查询模式异常
静态阈值不需要“学习”，设了就生效。但只适合少数硬指标。
第二层：动态基线（趋势偏离）
适用于波动大、没有固定安全边界的指标：
QPS与过去7天同时段对比，偏离 > 50%
平均响应时间与基线对比，突增 > 100%
慢查询数量与基线对比，突增 > 200%
动态基线的价值在于捕捉“业务异常”而非“系统异常”。比如大促期间QPS自然上涨，静态阈值会误报，动态基线不会。
第三层：防误报机制
参考Oracle的Number of Occurrences机制：连续N个采集点超过阈值才触发告警。比如连接数连续3次采集（间隔10秒）超过80%才告警，单次抖动不触发。
告警收敛同样重要：同一指标3分钟内最多3次告警，避免告警风暴。
四、数据库的监控接入：KDDM的差异化能力
指标分层和阈值策略是通用方法论，但落地到具体数据库时，不同产品的监控能力差异很大。
MySQL生态有成熟的mysqld_exporter + Prometheus方案，指标采集、告警规则、看板模板都有现成的社区资源。但国产数据库的监控接入往往需要额外评估——采集器是否支持、指标是否完整、有没有官方维护的Grafana模板。
KDDM（Kingbase Database Diagnostic Monitor）在这块做了一个值得关注的设计：它不是简单的指标采集器，而是内置了诊断分析能力。
能力一：性能快照采集与历史回溯。 KDDM按固定间隔采集数据库的运行快照，记录CPU、内存、I/O、锁等待、慢SQL、会话状态等多维指标。这些快照不是孤立的点，而是可以按时间轴回溯的序列。当告警触发时，DBA可以直接回看告警发生前几分钟的快照，定位是哪个会话、哪条SQL、哪个锁等待导致了异常。
能力二：瓶颈自动识别。 这是KDDM和普通指标采集器最大的差异。Prometheus采集的是“数据”，KDDM输出的是“判断”。它基于历史快照自动分析慢查询的成因——是索引缺失、统计信息过期、还是锁争用？然后给出具体的优化建议。对于经验不足的DBA，这个能力相当于把资深DBA的诊断逻辑固化到了工具里。
能力三：生态的深度集成。 KDDM不是独立的外部工具，它和KES的日志体系、性能视图、审计模块是打通的。这意味着它能采集到外部工具难以获取的内核级指标，比如具体的Latch等待类型、Buffer Pool的页级状态。外部Prometheus方案需要额外开发Exporter才能拿到这些数据。
能力四：降低监控体系的维护成本。 自建Prometheus + Grafana + Alertmanager，需要维护采集器版本、告警规则、看板模板，还要处理Exporter和目标数据库的版本兼容问题。KDDM是原生工具，版本跟随数据库一起升级，不需要额外维护采集链路。
一个务实的判断逻辑：如果团队只维护数据库，KDDM可以作为主监控工具，覆盖从采集到诊断的完整链路。如果团队同时维护MySQL、PostgreSQL和金仓，统一监控平台（Prometheus + Grafana）仍然是更现实的选择——但的Exporter可以复用KDDM的部分采集能力，减少重复开发。
一个选型时容易忽略的点：监控工具的价值不只在于“出问题时能看到什么”，更在于“平时能帮你发现什么”。KDDM的瓶颈自动识别能力，在日常巡检中就能持续输出优化建议，而不是等到告警响了才被动响应。这个差异在长期运维中会逐渐显现。
五、小结
数据库监控的核心不是“监控更多指标”，是把指标分层。症状指标触发告警，根因指标用于定位。静态阈值管硬边界，动态基线管趋势偏离。连续N次超阈值才告警，避免单次抖动误报。
国产数据库的监控接入需要额外评估。KDDM在指标采集之外，提供了性能快照回溯、瓶颈自动识别、内核级指标采集和原生生态集成四个差异化能力，适合以金仓为主的团队作为主监控工具。多数据库混合环境，统一监控平台仍是更务实的选择。
那次主从断开没人发现的事之后，我们把告警重新分了级。症状指标走P0，直接打电话；根因指标走日报，每天看一眼趋势。告警群清净了，真正的问题反而能第一时间看到。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
