可信信创时代：多元混合数据库运维监控体系建设白皮书

 目录

多元混合数据库时代

从“被动救火”到“主动预防”的运维监控体系建设白皮书

引言：数据库运维，正站在一个不得不变的十字路口

第一章 数据库技术栈的“大爆炸”：运维正在面对怎样的新现实？

1.1 从“单一数据库”到“混合数据库”的十年变迁

1.2 国产化替代浪潮下的新变量

1.3 混合数据库架构带来的三大“不对称”

第二章 政策与合规：数据库运维不再是“选修课”

2.1 等保2.0对数据库审计与日志的刚性要求

2.2 信创替代的时间表正在倒逼运维体系升级

2.3 行业监管对数据库可用性与数据安全的关注

第三章 数据库运维的五大“老大难”问题

3.1 监控盲区：看不见的风险最可怕

3.2 告警风暴：狼来了太多次，真狼来了就没人信了

3.3 知识断层：经验沉淀不下来，事故反复踩坑

3.4 阈值误判：要么草木皆兵，要么形同虚设

3.5 国产数据库“水土不服”

第四章 数据库运维监控体系：从指标定义到模板落地

4.1 监控指标设计的“三层漏斗模型”

4.2 六大核心监控维度的定义与解读

4.3 阈值设定的艺术：危险阈值 vs 故障阈值

4.4 从“单库”到“多库”：统一监控模板的设计思路

第五章 分库施策：主流数据库的监控要点与最佳实践

5.1 关系型数据库的监控精髓

5.2 NoSQL数据库的监控特点

5.3 国产数据库的监控适配

5.4 阈值配置速查表

第六章 监控易：数据库运维监控体系的工程化落地

6.1 16种数据库的统一监控能力

6.2 自定义指标：让监控适配“你的业务”

6.3 监测模板管理：标准化监控的“加速器”

6.4 信创环境下的数据库监控适配

第七章 从监控到可观测性：监控数据的价值转化

7.1 监控不是目的，避免停机和快速恢复才是

7.2 告警治理：告别“狼来了”

7.3 知识库的沉淀：把经验留在系统里

第八章 落地路径：从零搭建数据库运维监控体系的三个阶段

8.1 第一阶段（1-4周）：摸清家底，核心库先上线

8.2 第二阶段（1-3个月）：补齐维度，建立告警基线

8.3 第三阶段（持续迭代）：模板标准化，覆盖全库

结语：数据库运维的下半场，拼的是体系化能力

附录：监控指标速查手册

一、连通性监测（全部数据库通用）

二、MySQL核心指标

三、Oracle核心指标

四、SQL Server核心指标

五、PostgreSQL核心指标

六、Redis核心指标

七、MongoDB核心指标

八、达梦数据库核心指标

九、人大金仓核心指标

引言：从“可用”到“可信”，数据库运维的时代命题

随着国产化替代进入深水区，数据库技术栈正从单一走向多元，从国外为主转向国产与开源并重。这场深刻变革带来的不仅是软件的替换，更是对运维体系的一次全面重构——系统不仅要“跑起来”，更要“管得住、看得清、可追溯、可审计”。

这正是“可信信创”的核心要义。

“可信信创”并非凭空而来，它根植于我国“可信计算”领域的长期积累，成型于以中国电信等头部企业为代表的信创2.0实践探索，并已成为产业界对信创运维质量与安全性的共同承诺。“可信”二字，包含三个层面的要求：操作可审计、权限可管控、数据可验证。 在数据库运维领域，这意味着每一次连接、每一个查询、每一次配置变更都应有迹可循；每一类数据库（无论是Oracle还是达梦）都应被同等深度的监控覆盖；每一条告警都应能被准确溯源，而非淹没在噪音之中。

数据库是数字经济的“心脏”。任何一次数据库宕机，都意味着业务的停摆、数据的损失、客户的流失。 然而，数据库运维正面临前所未有的复杂局面。

五年前，一家企业的数据库选型还相对简单——金融行业用Oracle，互联网公司用MySQL，缓存用Redis。今天，情况已截然不同。国产化替代加速推进，达梦、人大金仓、神通、GBase等国产数据库快速进入核心系统。与此同时，MongoDB、PostgreSQL等开源数据库也在各行业遍地开花。一套系统里同时运行着Oracle、MySQL、Redis和达梦，已是常态而非特例。

这不是简单的“多装了几个软件”的问题。它意味着：同一套监控系统要认识16种不同的协议和指标体系；精通Oracle的DBA不一定会调优MongoDB；运维人员要在N个控制台之间来回切换。数据库运维的难点，已经从“怎么装”变成了“怎么管”，从“怎么修”变成了“怎么防”。

与此同时，政策与合规的要求正在将数据库运维从“可选项”变为“必选项”。等保2.0要求数据库访问日志留存至少6个月；关键信息基础设施安全保护条例对金融、能源、政务等行业的数据安全提出刚性要求；信创政策要求金融、电信、能源等八大行业在2027年实现数据库100%国产替代。

当合规成为底线、当混合架构成为常态、当国产数据库的运维生态还在追赶期——数据库运维体系化建设的紧迫性，从未如此之高。

本白皮书正是基于“可信信创”的理念撰写。我们立足于多元混合数据库时代的运维新现实，系统梳理了16种主流数据库、200+监控指标，提出了一套从“被动救火”走向“主动预防”的可信运维监控体系建设方法论。这套方法论的最终目标，是帮助运维团队在复杂混合数据库环境中建立确定性——让每一台数据库的状态都是透明的，让每一次风险都能被提前感知，让每一次故障都能被快速定位，从而真正实现“可信”的运维承诺。

第一章 数据库技术栈的“大爆炸”：运维正在面对怎样的新现实？

1.1 从“单一数据库”到“混合数据库”的十年变迁

过去十年，数据库技术栈经历了从“大一统”到“百花齐放”的剧烈演变。

2015年之前，绝大多数企业的数据库选型相对集中：金融、政务等行业以Oracle为主力，互联网公司以MySQL为主流，辅以少量SQL Server。彼时一个DBA团队只需要精通一两种数据库，就能应对绝大部分运维需求。

今天的情况已完全不同。一家中型企业的数据库集群可能同时包含：

· 关系型数据库：Oracle承载核心交易、MySQL支撑业务系统、PostgreSQL处理复杂分析

· NoSQL数据库：Redis做缓存加速、MongoDB处理非结构化数据

· 国产数据库：达梦、人大金仓满足信创合规要求

根据赛迪顾问发布的《2025-2026年中国数据库市场研究报告》，达梦以13.2%的市场份额位居国产数据库第一，人大金仓以11.5%紧随其后。国产数据库从“备选项”正在变成“必选项”。

混合数据库架构不再是“未来趋势”，而是“眼前现实”。

1.2 国产化替代浪潮下的新变量

2026年被业界视为国产数据库落地的“冲刺年”。政策要求已从“建议替换”转为“强制替换”。金融、政务、能源等关键基础设施领域的国产化替代已进入“深水区”。

具体时间表已经明确：

· 2026年起，党政机关核心业务信创采购占比不低于85%，国企不低于65%

· 金融、电信、能源等八大行业要求2027年实现数据库100%国产替代

· 核心业务系统数据库国产化替代率预计突破80%

· 2026年5月26日，中国信息安全测评中心正式发布第四期安全可靠测评结果，16家厂商的23款数据库产品入围核心信创准入目录

这一进程带来的不仅是“换一个软件”那么简单。

国产数据库的生态——监控工具、运维工具、人才储备——尚在追赶期。以达梦为例，其技术路线更接近Oracle的开发与运维习惯；人大金仓则更强调国产统一平台的定位。两种路线各有优劣，但对运维团队的要求截然不同。

一个现实问题摆在面前：当Oracle被替换为达梦或金仓，原有的监控模板、告警规则、故障处理SOP还能直接用吗？答案是否定的。国产数据库的指标体系、日志格式、性能模型与传统数据库存在显著差异，直接套用往往导致监控盲区或误报。

1.3 混合数据库架构带来的三大“不对称”

技术栈不对称：同一套监控系统要认识16种不同的协议和指标体系。Oracle的AWR报告、MySQL的performance_schema、Redis的INFO命令、MongoDB的db.stats()——每种数据库都有自己的“语言”，运维团队需要掌握全部。

人才不对称：精通Oracle的DBA不一定会调优MongoDB，熟悉MySQL的工程师未必理解达梦的缓冲池机制。在国产数据库快速上线的背景下，这一矛盾尤为突出——既懂传统数据库又懂国产数据库的复合型人才极度稀缺。

工具不对称：每种数据库都有自己的管理工具——Oracle有EMCC、MySQL有Workbench、Redis有RedisInsight、MongoDB有Compass。运维人员需要在N个控制台之间来回切换，效率低下且容易遗漏。

对这三大“不对称”，一个清晰的结论浮现出来：混合数据库时代的运维，不能再依赖“人肉盯屏”和“经验主义”。 运维人员需要一套标准化的、可复用的、全栈覆盖的监控体系来统一管理异构数据库，将不确定性转化为确定性。这不仅是效率问题，更是“可信信创”对运维体系的刚性要求——只有监控全覆盖、指标可量化、操作可追溯，才能支撑起“可信”的承诺。

第二章 政策与合规：数据库运维不再是“选修课”

2.1 等保2.0对数据库审计与日志的刚性要求

等保2.0（GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》）对数据库安全提出了明确要求：

· 日志留存：审计日志至少留存6个月。这是等保测评中出现频率最高的不合格项之一，很多企业的系统默认日志保留策略只有30天。

· 审计覆盖：需覆盖网络设备、服务器、数据库、应用系统全类型日志。

· 审计内容：记录需包含时间、用户、操作类型、操作对象、操作结果等完整信息。

· 细粒度管控：涉及等保三级的系统需具备细粒度的访问控制、操作审计和异常行为检测能力。

日志分散存储、操作无记录、配置变更不可追溯——这些都将成为等保检查中的不合规项。

2.2 信创替代的时间表正在倒逼运维体系升级

2025年9月，国务院发布新政，明确信创产品在政府采购中的优先地位。2026年5月，中国信息安全测评中心正式发布第四期安全可靠测评结果，16家厂商的23款数据库产品入围核心信创准入目录。

这一政策链条传导到数据库运维层面，产生了两个直接影响：

第一，数据库替换速度加快，运维团队必须快速掌握新数据库的监控与管理能力。从Oracle迁移到达梦，不仅是数据迁移的问题，更是监控体系、告警规则、故障处理流程的全面重构。

第二，合规与安全已成为数据库选型的“入场券”。具备内生安全机制、支持国密算法及符合等保三级要求的国产数据库，已成为政策硬性要求。

2.3 行业监管对数据库可用性与数据安全的关注

2025年，《网络数据安全管理条例》（国务院令第790号）正式施行。同年，中国人民银行发布《中国人民银行业务领域数据安全管理办法》。政务数据处理安全要求国家标准（GB/T 45396-2025）于2025年发布，2025年10月1日正式实施，由国家信息中心牵头编制。

关键信息基础设施安全保护条例明确将公共通信和信息服务、能源、交通、水利、金融、公共服务、电子政务、国防科技工业等重要行业纳入保护范围。

这些法规的共通点是：数据安全不再是“加分项”，而是“及格线”。而数据库作为数据资产的核心载体，其安全运维水平直接决定了合规的成败。

第三章 数据库运维的五大“老大难”问题

在“可信信创”的视角下，数据库运维的“可信”至少要回答三个问题：

1. 可不可见？ ——所有数据库的运行状态、性能指标是否被完整采集和呈现？

2. 可不可控？ ——所有操作是否有权限管控、是否可追溯？

3. 可不可预？ ——潜在风险能否被提前发现、主动预防？

遗憾的是，当前大量企业的数据库运维在这三个维度上都存在明显短板。以下五大“老大难”问题，正是阻碍运维达到“可信”状态的核心障碍。

3.1 监控盲区：看不见的风险最可怕

数据库“活着”不等于“健康运行”。

很多运维团队对数据库的监控停留在“Ping得通”和“服务没挂”的层面。然而，真正导致业务中断的往往不是数据库宕机，而是性能劣化——连接池快耗尽了，DBA还以为是业务高峰；锁等待已经堆到几百个，系统还在硬扛；表空间即将写满，备份任务还在继续写入。

典型场景一：某制造企业MES（生产执行系统）数据库在产线高峰时段连接数缓慢攀升，在达到最大连接数上限后，新连接全部失败，产线报工系统瘫痪，工人无法扫码上件、无法报工，整条产线被迫停产。监控系统显示数据库“在线”，但业务已经不可用。问题根源：连接数监控阈值设置过高，未能在达到上限前触发告警。

典型场景二：某能源企业SCADA（数据采集与监视控制）系统数据库，一条慢查询在夜间数据同步时段悄然出现，未被及时发现。第二天业务高峰期，调度人员频繁查询实时数据，该慢查询被大量调用，数据库CPU瞬间飙升至100%，调度大屏数据刷新延迟严重，调度员无法获得实时态势感知。问题根源：慢查询监控缺失，未能提前发现隐患。

监控易的应对思路：传统监控工具对国产数据库的监控颗粒度极粗，往往只能检查“进程是否存活”，这留下了巨大的运维盲区和性能风险。真正的数据库监控必须能透视数据库内核，将“黑盒”变为“白盒”。通过对16种数据库、200+监控指标的体系化梳理，实现对数据库“活得好不好”的深度感知。

3.2 告警风暴：狼来了太多次，真狼来了就没人信了

没有根因定位的告警，等于把排查压力转嫁给值班人员。

一台核心存储设备网络抖动，可能触发几十条数据库连接超时告警。值班人员面对满屏的红色告警，根本无法判断哪一条是根源、哪一条是衍生。最终只能“凭经验猜”——而经验往往在关键时刻失效。

告警风暴的恶性循环：告警太多 → 运维人员麻木 → 真告警被忽略 → 故障扩大 → 更多告警。这是无数运维团队每天都在经历的噩梦。

监控易的应对思路：通过告警去重（同一监测点重复告警只发送第一次）、告警压缩（将同一根源事件引发的多个告警合并为一条根因告警）、告警依赖（被依赖的监测点已告警则依赖点不再重复告警），从源头治理告警噪音，让每一条告警都值得认真对待。

3.3 知识断层：经验沉淀不下来，事故反复踩坑

资深DBA的经验是“人走茶凉”。一个老DBA离职，带走的不仅是一个人，而是一套隐性的知识体系——哪些指标需要重点关注、什么阈值最适合当前业务、某种异常通常是什么原因导致的。

没有标准化的知识库，每次故障排查都在从零开始。同一个问题，不同的人排查路径不同、耗时不同、结论不同。运维效率严重依赖于个人经验，而非体系能力。

监控易的应对思路：通过标准化监控模板将16种数据库、200+监控指标的定义、阈值配置、告警规则固化为可复用的知识资产，让新DBA也能快速上手；通过知识库模块将故障案例、处理方案结构化沉淀，让经验留在系统里而不是某个人脑子里。

3.4 阈值误判：要么草木皆兵，要么形同虚设

静态阈值无法适应业务高低峰的变化。

凌晨的CPU高是异常——可能有人在跑未授权的批处理任务；白天业务高峰的CPU高反而是正常——业务量上来了，CPU自然升高。用同一套阈值去判断两种截然不同的场景，结果必然是：要么误报频出（草木皆兵），要么漏报不断（形同虚设）。

更复杂的是，不同数据库的指标含义和正常范围差异巨大。Redis的内存使用率80%可能还算健康，但Oracle的表空间使用率80%就需要立即关注。一套统一的阈值模板无法适配所有数据库类型。

监控易的应对思路：通过“危险阈值”与“故障阈值”两级设计区分“需要关注”和“需要立即介入”；通过分库分策的差异化阈值配置，为每类数据库适配最合适的监控策略。

3.5 国产数据库“水土不服”

国产数据库的监控指标体系和传统数据库有显著差异。直接用Oracle那套监控模板去监控达梦，会发现很多指标对不上、很多告警不准确、很多性能数据采集不到。

具体表现：

· 指标名称和定义不同：达梦的“缓冲池命中率”与Oracle的“Buffer Cache Hit Ratio”计算方式有差异

· 系统视图不同：国产数据库的系统表、动态视图与Oracle/MySQL不兼容

· 日志格式不同：错误日志、慢查询日志的格式和位置各不相同

· 工具链缺失：很多国产数据库缺乏成熟的第三方监控工具支持

监控易的应对思路：通过自主研发的数据采集技术，直连数据库核心性能视图，采集上百个关键性能指标。内置针对达梦、人大金仓、南大通用、神州通用等国产数据库的监控模板，实现国产数据库“开箱即监控”，从“跑得起来”到“跑得漂亮”。

第四章 数据库运维监控体系：从指标定义到模板落地

4.1 监控指标设计的“三层漏斗模型”

有效的数据库监控指标体系应遵循“三层漏斗”设计原则：

第一层：可用层——数据库能不能用

这是监控的“底线”。连通性（能否建立连接）、响应时间（每次查询的延迟）、服务状态（数据库进程是否存活）是最基础的监控项。这一层的任何异常都是P0级故障，需要秒级响应。

第二层：健康层——数据库运行得好不好

当数据库“活着”之后，需要回答“活得好不好”。连接数是否接近上限、内存使用是否合理、缓存命中率是否达标、磁盘I/O是否存在瓶颈——这些指标反映了数据库的“生活质量”。

第三层：风险层——有没有潜在隐患正在酝酿

这是从“被动发现”到“主动预防”的关键跃迁。锁等待趋势是否在上升、表空间增长速度是否异常、慢查询数量是否在增加——这些指标指向的是“未来可能出问题的地方”。

4.2 六大核心监控维度的定义与解读

基于对16种数据库、200+监控指标的梳理，可将数据库监控归纳为六大核心维度：

每个维度回答一个具体的运维问题，避免“为监控而监控”。

以连通性维度为例：对于任何数据库，第一步要解决的都是“能不能连上”。监控模板中统一设计了Time（响应时间）和ret（连接状态）两个指标——响应时间超过阈值触发告警，连接失败立即上报故障。这是所有数据库监控的“第一道防线”。

4.3 阈值设定的艺术：危险阈值 vs 故障阈值

监控模板中区分了“危险阈值”和“故障阈值”两个级别：

· 危险阈值（Warning）：指标异常但尚未影响业务，需要关注，建议在工作时间内处理。例如：CPU使用率 > 80%、表空间使用率 > 85%。

· 故障阈值（Critical）：指标严重异常，已经或即将影响业务，需要立即介入。例如：数据库无法连接、表空间已满。

两种阈值的设计逻辑不同：危险阈值追求“早发现”，宁可稍微敏感一些；故障阈值追求“零误报”，必须确保触发即真实故障。

实践案例：在MySQL监控模板中，连接数监控的危险阈值设为“当前连接数 > 最大连接数 × 80%”，故障阈值设为“当前连接数 > 最大连接数 × 95%”。前者给运维团队留出扩容时间，后者在连接池即将耗尽时触发紧急告警。

4.4 从“单库”到“多库”：统一监控模板的设计思路

面对16种不同数据库，统一监控模板的设计遵循“求同存异”原则：

“求同”——所有数据库都必须覆盖六大监控维度，确保没有监控盲区。无论监控的是Oracle还是Redis，连通性、连接数、内存、存储、锁、性能这六个维度一个都不能少。

“存异”——不同数据库的指标体系各有特色。Redis必须重点关注内存和持久化，MongoDB需要关注索引命中率和副本集健康，Oracle需要特别关注表空间和库缓存。

模板的“三层结构”：

1. 设备层：代表被监控的数据库实例（如AliRedis、MySQL、Oracle RAC）

2. 监测点层：代表监控的不同维度（如TableSpace、BufferPool、LockInfo）

3. 指标层：代表具体采集的数值（如AvgRt平均响应时间、Usage使用率）

这一结构设计确保了：新增一种数据库时，只需按照“设备-监测点-指标”的框架填充具体内容，即可快速生成标准化监控模板。

第五章 分库施策：主流数据库的监控要点与最佳实践

5.1 关系型数据库的监控精髓

MySQL监控要点

MySQL的监控模板覆盖了连接数、缓冲池、查询缓存、表锁、临时表等十余个监测点。其中几个关键指标尤为值得关注：

· 连接数：Threads_connected和max_connections的比值是最直接的容量预警信号。当连接数持续接近上限时，新连接将被拒绝。

· 缓冲池命中率：Requ_Key_Hit_Rate低于95%意味着索引数据频繁从磁盘读取，性能严重受损。

· 慢查询：Slow_queries的突然增长往往意味着SQL执行计划出了问题，需要立即介入。

Oracle监控要点

Oracle的监控重点在于资源管控：

· 表空间：oracletablespace监测点覆盖了可用空间、使用百分比等指标。表空间写满是Oracle最经典的故障之一，必须在达到90%时提前告警。

· 缓存命中率：bufferhitrate和libcachehitrate是判断Oracle性能的核心指标，命中率低于90%就需要排查。

· 游标数：cursors的异常增长往往意味着SQL未正确关闭，可能导致内存泄漏。

SQL Server监控要点

· 缓存命中率：Buffercachehitratio低于90%说明内存配置不足或查询计划不合理。

· 锁统计：NumberofDeadlockssec（每秒死锁数）是判断并发问题的关键指标。

· 日志文件使用百分比：LogFileUsedPercent超过95%需要立即扩容，否则事务将无法提交。

PostgreSQL监控要点

· Bgwriter：checkpoints_timed和checkpoints_req反映检查点频率，过于频繁的检查点会影响性能。

· 锁信息：total locks和wait locks的比值反映锁竞争程度。

· 数据库统计：numbackends（连接数）、blks_hit_rate（缓存命中率）是核心健康指标。

5.2 NoSQL数据库的监控特点

Redis监控要点

内存是Redis的命门。Redis是内存数据库，一旦内存耗尽，服务将直接崩溃。

· 内存使用：used_memory和used_memory_peak必须持续监控。当使用内存接近maxmemory设定值时，需要立即扩容或清理过期key。

· 持久化状态：rdb_last_bgsave_status反映最近一次持久化是否成功。持久化失败意味着数据可能丢失。

· 主从复制：role和connected_slaves确保高可用架构正常运行。

MongoDB监控要点

· 连接数：CurConnected和availableConn反映当前负载和剩余容量。

· 索引命中率：missRation（索引偏差率）超过15%意味着索引设计不合理，大量查询走了全表扫描。

· 读写锁：activeReaders/activeWriters和curTotal（排队总量）反映锁竞争程度，排队过多意味着性能瓶颈。

· 副本集健康：health、stateStr（角色）、optimeDate（最后一次操作时间）是判断副本集状态的关键。

5.3 国产数据库的监控适配

达梦数据库监控要点

达梦的监控模板借鉴了Oracle的经验，但也有自己的特色：

· 缓冲池：RAT_HIT（命中率）是核心性能指标，与Oracle的Buffer Cache Hit Ratio类似但计算方式有差异。

· 实例：STATUS（系统状态）、START_TIME（启动时间）反映实例健康度。

· 表空间：USAGE（利用率）超过90%需要立即关注。

· 线程：COUNT（数量）异常减少可能意味着线程池出现问题。

达梦数据库的深度监控能力：监控易通过自主研发的数据采集技术，可深度监控达梦的会话与线程池（实时监控活动会话数、等待会话数、线程池使用率）、缓存效率（缓冲区命中率、SQL执行计划缓存命中率）、锁竞争（实时发现阻塞锁、死锁并定位到具体SQL）、SQL性能（自动捕获慢SQL并分析执行计划）、日志与归档（监控重做日志切换频率、归档状态）。

人大金仓监控要点

· 连接数：activesConnects（活跃会话数）和connects（会话数）反映负载情况。

· 表空间：usage（使用率）和status（状态）是存储管理的关键。

· 缓冲区：used_dirty_usage（使用脏页面百分比）超过50%说明写入压力大。

· 锁：waitLocks（等待的锁数）是判断阻塞问题的核心指标。

神通数据库监控要点

· 缓存：hits（命中次数）和misses（命中失败次数）反映缓存效率。

· 锁：total_wait（等待次数）和failed_req（加锁失败次数）判断锁竞争。

· 事务：total_transaction（事务数量）和sql_count（SQL执行数）反映整体负载。

实践经验：国产数据库的监控指标正在快速成熟，但部分状态类指标（如text类型）仍需要人工语义理解。建议在监控平台上建立“指标语义映射”功能，将技术指标翻译为业务可理解的描述。

5.4 阈值配置速查表

以下为基于监控模板提炼的推荐初始阈值（可根据实际业务调整）：

注意：以上阈值为推荐初始值。实际配置时应根据业务特点、硬件规格、历史数据进行调整，避免“一刀切”。

第六章 监控易：数据库运维监控体系的工程化落地

6.1 16种数据库的统一监控能力

面对Oracle、MySQL、SQL Server、PostgreSQL、Redis、MongoDB、DB2、达梦、人大金仓、神通、南大通用（GBase）等16种主流数据库的混合部署，运维团队需要一个统一的监控视角，而非在N个控制台之间疲于奔命。

监控易通过自主研发的统一数据采集引擎，可同时采集从底层国产硬件（CPU、内存、磁盘）到操作系统（麒麟、统信），再到中间件及达梦、神通、金仓等国产数据库，直至上层应用的全栈metrics、log、trace相关数据。各类监控数据在平台内部得到统一的规范化处理、关联及存储，构建起清晰的CI（配置项）关系图谱。

基于对16种数据库、200+监控指标的深度梳理，监控易为每种数据库设计了针对性的监控模板，覆盖连通性、连接与会话、内存与缓存、存储与表空间、锁与事务、操作与性能六大维度。运维人员无需从零配置，选择数据库类型即可获得一套经过验证的监控方案。

6.2 自定义指标：让监控适配“你的业务”

标准监控模板覆盖了绝大多数通用场景，但每家企业的业务特点、技术栈、运维习惯各不相同。当内置指标无法满足特定业务需求时，需要“自己动手”的能力。

监控易提供了多层次的自定义能力：

SQL万能监控API：支持用户对任意SQL查询语句进行监测。除了对数据库的常规性能监控外，有的客户需要对数据库的业务查询语句或性能查询语句进行监控，监控易提供API，客户经过简单界面操作即可添加任意查询SQL语句的监控，实现数据库个性化业务监控。

自定义监测点：对于特殊设备或系统，支持XML自定义监测，用户可以根据设备提供的API或接口，自定义监测点和监控逻辑，实现个性化监控需求。

自定义OID：如果内置监控项无法满足特定业务需求，用户可以通过自定义OID的方式新增监测项。操作简便，只需在平台页面添加监测点，并输入相应的OID值、名称、描述、单位等信息，即可完成监测指标的新增。

被动式自定义监控：支持用户开发的任意个性化被动式监测器。运维人员可以根据自己的管理需求和业务特点，自定义开发适合自己的监测器，监控各种业务指标、系统状态或网络设备，如数据库性能、服务器负载、网络流量等。一旦监测器捕捉到任何异常或变化，就会立即将监控信息发送给监控易运维系统，通过统一界面进行集中展示。

6.3 监测模板管理：标准化监控的“加速器”

当需要监控的数据库从两三种扩展到十几种，逐台配置监控项的工作量将呈指数级增长。监控模板管理功能让用户可以基于设备类型和应用场景，自定义多个监测模板。当设备需要添加监测点时，只需选择相应的监测模板，系统即可自动设置模板中的监测点类型和参数值。

每个模板可以包含多个监测点类型和参数设置，用户可以根据实际需求对模板进行编辑、删除和复制等操作。如果发现模板里的某个阈值设置不合理，修改模板后，可以选择“同步到已应用该模板的设备”，批量更新所有设备的配置。

对于数据库监控场景，这意味着：完成一套达梦数据库的监控配置并保存为模板后，后续新增的达梦实例只需应用该模板即可自动完成监控配置——从“逐台配置”到“一键应用”。

6.4 信创环境下的数据库监控适配

信创迁移完成后，国产数据库的稳定性和性能表现直接关系到核心业务的命脉。然而，传统监控工具对国产数据库的监控颗粒度往往只能检查“进程是否存活”。

监控易通过内置的国产数据库适配器，支持达梦、人大金仓、南大通用、神舟通用等主流国产数据库。以达梦数据库为例，监控易可深度监控会话与线程池（实时监控活动会话数、等待会话数、线程池使用率）、缓存效率（缓冲区命中率、SQL执行计划缓存命中率）、锁竞争（实时发现阻塞锁、死锁并定位到具体SQL）、SQL性能（自动捕获慢SQL并分析执行计划）、日志与归档（监控重做日志切换频率、归档状态）。

对于监控模板未覆盖的数据库类型或个性化指标，支持通过自定义SQL监控和被动式监控进行扩展。这一机制保证了即使是最新的国产数据库版本，也能快速纳入监控范围。

需要强调的是，监控本身不是信创迁移的终点。迁移到国产数据库只是完成了“可用”，而“可信”才是终极目标。 所谓“可信”，是指国产数据库不仅要能运行，还要运行得可观测、可审计、可预测。监控易通过深度适配达梦、人大金仓等国产数据库，为每一类国产数据库建立标准化的监控模板和告警规则，正是为了将“可信”从抽象理念落地为具体的运维能力——让每一台国产数据库的状态都是透明的，让每一次异常都能被及时发现，让每一次变更都有据可查。

第七章 从监控到可观测性：监控数据的价值转化

7.1 监控不是目的，避免停机和快速恢复才是

监控本身不是目的。采集再多的指标、生成再多的报表，如果不能帮助运维团队更快地发现问题和定位根因，就只是一堆无用的数字。

从“监控”到“可观测性”的进阶路径：

1. 指标采集（基础层）：采集CPU、内存、连接数等基础指标

2. 状态判断（感知层）：根据阈值判断正常/异常

3. 根因定位（分析层）：关联多个指标，判断故障根因

4. 预测预防（智能层）：基于历史数据预测未来趋势

多数企业的数据库监控停留在第1-2层，而价值爆发点在第3-4层。

监控易通过“统一数据建模与存储”将各类监控数据规范化、关联化，构建起清晰的CI关系图谱。当收到“应用响应慢”的告警时，运维人员无需协调网络、系统、DBA等多个团队逐一排查，在监控易平台中直接点击对应的应用，凭借内置的拓扑关联功能即可快速定位故障根源——这正是从“监控”走向“可观测性”的关键跃迁。

7.2 告警治理：告别“狼来了”

告警泛滥是数据库运维的最大噪音。治理告警的三个关键手段：

告警去重：同一监测点在短时间内重复触发告警，只发送第一次，后续合并为“持续告警”状态。

告警压缩：将同一根源事件引发的多个告警合并为一条根因告警。例如，一台核心存储设备网络抖动可能触发几十条数据库连接超时告警，压缩后只显示一条根源告警。

告警依赖：如果被依赖的监测点已经发生告警，则依赖的监测点不再重复告警。例如，如果数据库服务器宕机（根源告警），则其上的所有数据库实例告警可被抑制，避免告警风暴。

7.3 知识库的沉淀：把经验留在系统里

监控模板本身就是一种知识资产。16种数据库、200+监控指标的定义、阈值配置、告警规则——这些是运维团队经验的数字化沉淀。

更进一步，故障案例与监控指标的关联可以构建“智能知识库”：

· 当某个告警触发时，系统自动推荐历史上相同告警的处理方案

· 当某个指标的异常模式出现时，系统提示可能的原因列表

· 当运维人员完成一次故障处理，处理过程自动归档为知识条目

最好的运维，是用户感知不到运维的存在。而实现这一目标的前提，是把每一次故障的经验都留在系统里，而不是留在某个人的脑子里。

第八章 落地路径：从零搭建数据库运维监控体系的三个阶段

8.1 第一阶段：摸清家底，核心库先上线

目标：建立基础监控能力，消除“盲区”。

具体动作：

1. 资产梳理：盘点所有数据库实例，记录类型、版本、部署位置、业务重要性

2. 核心优先：优先覆盖核心业务数据库（交易系统、账务系统、用户中心等）

3. 连通性监控：为所有数据库配置连通性监测（响应时间、连接状态）

4. 基础性能指标：为每种数据库配置CPU、内存、连接数、存储空间等基础指标

5. 告警配置：设置基础告警规则，确保“挂了有人知道”

交付物：数据库资产清单、核心库监控全覆盖、基础告警体系。

8.2 第二阶段：补齐维度，建立告警基线

目标：完善监控维度，消除“噪音告警”。

具体动作：

1. 补齐六大维度：在连通性基础上，逐步增加连接与会话、内存与缓存、存储与表空间、锁与事务、操作与性能等维度的监控

2. 阈值调优：观察1-2周的数据分布，调整阈值，消除误报和漏报

3. 告警治理：配置告警去重、压缩、依赖规则，减少无效告警

4. 模板固化：将调优后的监控配置固化为可复用的模板

交付物：完整的六大维度监控覆盖、调优后的告警规则库、可复用的监控模板。

8.3 第三阶段（持续迭代）：模板标准化，覆盖全库

目标：建立标准化流程，实现“新库上线即监控”。

具体动作：

1. 全库覆盖：将所有数据库（包括非核心、测试库）纳入监控

2. 模板标准化：建立“新数据库上线自动套用监控模板”的标准化流程

3. 知识库建设：将故障案例、处理方案归档到知识库

4. 持续优化：定期review监控覆盖率、告警准确率、MTTR等指标

交付物：标准化监控流程、运维知识库、持续改进机制。

结语：数据库运维的下半场，拼的是体系化能力

数据库运维正在经历一场深刻的范式转变。

过去，我们拼的是“个人英雄”——哪个DBA技术好、经验丰富，哪个团队的数据库就更稳定。今天，当一家企业的数据库从两三种扩展到十几种，当国产数据库快速替代传统数据库，当合规要求从“建议”变为“强制”——单点能力已经失效，体系化能力才是答案。

“可信信创”的提出，正是对这一趋势的前瞻回应。它要求信创系统中的每一个环节——从芯片到操作系统、从数据库到应用——都要做到可验证、可追溯、可审计。数据库作为数据资产的核心载体，自然首当其冲。当一家企业能够清晰地回答“我的数据库当前处于什么状态、历史上发生过什么变化、未来可能面临什么风险”时，它就真正迈入了“可信运维”的门槛。

体系化能力，体现在三个层面：

· 标准化的监控模板：无论什么数据库，上线即有一套经过验证的监控方案

· 可复用的告警规则：不再依赖个人经验配置阈值，而是有数据支撑的最佳实践

· 持续沉淀的知识库：每一次故障都是下一次的教材，经验留在系统里而不是人脑子里

最好的运维，是用户感知不到运维的存在。当数据库稳定运行、故障提前预警、问题快速恢复——用户只会觉得“系统很稳定”，而不会意识到背后有一整套运维体系在默默支撑。

这就是体系化运维的价值：把不确定性变成确定性，把“救火”变成“防火”，把“人治”变成“法治”。

数据库运维的下半场，拼的不是谁更努力，而是谁的体系更完善。

附录：监控指标速查手册

脚注：本附录指标数据来源于监控易对16种数据库监控模板的实践经验总结。监控易基于对16种数据库、200+监控指标的体系化梳理，形成了覆盖连通性、连接与会话、内存与缓存、存储与表空间、锁与事务、操作与性能六大维度的标准化监控指标体系。指标名称与监控易平台保持一致，可直接在平台中引用和配置。

基于16种数据库、200+监控指标的梳理，以下为核心监控指标速查表：

一、连通性监测（全部数据库通用）

二、MySQL核心指标

三、Oracle核心指标

四、SQL Server核心指标

五、PostgreSQL核心指标

六、Redis核心指标

七、MongoDB核心指标

八、达梦数据库核心指标

九、人大金仓核心指标

本白皮书指标数据基于16种数据库、200+监控指标的监控模板整理，涵盖MySQL、Oracle、SQL Server、PostgreSQL、Redis、MongoDB、DB2、达梦、人大金仓、神通、南大通用（GBase）、Sybase等主流数据库。监控指标速查手册来源于监控易对上述数据库监控模板的实践经验总结。