信创数据库可观测：达梦、人大金仓的慢 SQL 与连接池监控

换库之后，排查工具也换了

业务迁到信创数据库（达梦 DM、人大金仓 KingbaseES）之后，DBA 最先发现的一件事是：原来的慢查询日志、performance_schema、pg_stat_statements 这些习惯动作都没了，或者长得完全不一样。故障来了，常常只能靠数据库自带的模糊日志硬猜。可观测系统要做的第一件事，是把信创库纳入统一监控，和业务主机、应用放在同一套体系里看，而不是让它成为一块"黑盒"孤岛。

该采哪些指标

不管底层是 DM 还是 KingbaseES，先用通用指标建立基线：

• 连接数：当前连接 / 最大连接。逼近上限就是隐患，往往是连接池配置不当或连接泄漏的信号，值得单独告警；
• 活跃事务 / 长事务：长事务会拖慢锁释放，是最常见的性能杀手，超过阈值（比如 30 秒）就该报警；
• 缓冲命中率：读多写少的业务，命中率骤降通常意味着内存配置不够或发生了大表扫描；
• 锁等待：死锁次数、锁等待时长，直接对应"卡住"的现场，配合慢 SQL 一起看能还原因果关系；
• 磁盘与归档：归档日志积压会撑爆磁盘，属于最容易被忽视的硬件级故障；
• 进程级 CPU/IO：数据库进程自身的 CPU 和磁盘 IO，配合主机指标能区分"是库的锅还是机器的锅"。

炬鲸 OBSERVE 通过 JDBC/标准采集器对接这两类库，把以上指标统一收进监控面板，和主机、应用的指标放在同一时间轴上对齐，方便交叉比对。基线不必一开始就求全，先把连接数、长事务、锁等待这三项稳定采集一周，画出曲线，再谈告警阈值。

慢 SQL 采集

DM 和 KingbaseES 都保留了慢 SQL 视图，但字段名和启用方式不同。以 DM 为例，先开启慢语句记录：

-- 达梦：开启慢语句记录，阈值 200ms
SP_SET_PARA_VALUE(1, 'MONITOR_SQL_EXEC', 1);
ALTER SYSTEM SET 'SQL_TRACE_MASK' = 3;

采集端定时拉取慢 SQL 视图，把执行次数、平均耗时、扫描行数、SQL 文本摘要一起上报。注意两点：一是 SQL 文本要做脱敏，参数值替换成 ?，避免敏感数据进日志；二是按"模板"聚合，同样的 SQL 不同参数只算一条，方便找出高频慢语句，而不是被一千个一次性变体淹没。

采集器怎么部署

采集器建议跑在数据库主机旁边或应用侧，用只读账号连接，权限只给到系统视图查询。生产库不要用 DBA 账号做采集，一次误操作就是事故。采集频率默认 30 秒，指标量不大的环境可以调到 60 秒省开销；慢 SQL 视图可以按分钟拉，配合趋势判断比单点值更有意义。信创环境常见"内网隔离 + 私有化部署"，采集器要支持离线安装、内网直连，不依赖外网。

踩过的坑

1. 字符集：DM 默认 GB18030/UTF-8 混用，采集器要显式指定连接字符集，否则中文注释和字段值会乱码，检索时对不上。
2. 驱动版本：老版本 DM JDBC 驱动对连接池支持不好，高并发下会出现连接不释放，务必用官方最新驱动并开启连接泄漏检测。
3. 时间口径：慢 SQL 的"执行时间"在不同版本里口径不一致，有的含排队时间、有的不含，做基线对比前先确认口径，否则告警阈值会飘。
4. 授权与许可证：部分监控视图需要单独的系统权限或企业版授权，开源/标准版可能查不到，接入前先用测试账号跑一遍，别等到上线才发现拿不到数。

最后一条建议：迁移阶段先把"慢 SQL 数量、长事务数、锁等待"三个指标盯住，它们最能反映业务是否吃下了新库的性能特征。等基线稳定了，再逐步加告警规则，否则你会一直在追阈值，而不是追真正的回退。