信创环境下数据库与中间件监控体系搭建实战复盘-平芜编程栈

最近我们团队接手了一个典型的信创环境改造项目，要把原来跑在商业数据库和商业中间件上的业务系统，整体迁移到国产数据库和国产中间件上。迁移本身倒还好，真正让我头疼的是监控体系：以前靠现成管理工具能看到的那些指标，在信创环境里几乎全部失效。数据库的SQL方言不一样，中间件监控接口路径不一样，连操作系统上的采集工具都因为CPU架构不同需要重新找版本。这篇文章是我们在搭建信创环境下数据库与中间件监控体系过程中的一次完整复盘，内容包括指标采集清单、工具适配和告警体系设计，希望能给正在做同类改造的朋友省点时间。

1. 为什么信创环境的监控不能直接照搬传统架构那套

老实说，刚开始接到这个任务时，我以为只是把新数据库的IP地址加到监控平台里，然后等着指标出来。结果一动手才发现，信创环境的监控，难的并不是“监控”本身，而是环境变了之后，那些默认能看的东西全都不是原来的样子了。

1.1 传统监控经验为什么大面积失效

拿数据库来说，过去我们习惯用商业数据库自带的管理工具，点几下就能看到会话、锁、等待事件、SQL执行计划。但在新的国产数据库上，这套工具用不了，而且很多系统视图、动态性能视图的命名和字段语义都变了。更麻烦的是，国产数据库虽然大多兼容常见SQL标准，但各自的“方言”并不一样。有的数据库把当前连接数放在一张系统表里，有的放在全局状态变量里，还有的只提供了存储过程接口。你以前写的那些监控SQL，拿到新环境里基本是废的。

中间件的情况更典型。以前的商业Web中间件有成熟的管理控制台，能监控到JVM、线程池、请求队列，甚至能导出HTTP会话数和JDBC连接池使用率。换到国产中间件之后，管理控制台是有的，但对外开放的监控接口、MBean路径、参数命名都不一样。你原来配置的那套监控规则只能删掉重来。如果中间件再套上容器化部署，那连JMX端口都不会随便暴露出来，需要额外配置才能打开。

底层平台的变化也不容忽视。信创环境里常见的CPU架构和操作系统组合，和之前x86环境差别很大。很多开源监控代理或采集器默认只提供x86二进制包，放到新平台上一跑直接报执行格式错误。这不是配置问题，是编译目标平台不对。还有些采集器依赖的系统库版本不够，或者缺少某些动态链接库，也得专门处理。

所有这些因素叠加起来，结论只有一条：信创环境的监控体系必须重新设计，不能拿旧配置硬套。所以我在项目立项阶段就坚持先做指标盘点，再做工具选型，而不是反过来。先搞清楚这个环境里到底能采到什么，再决定用什么采。

1.2 四层监控对象全景

为了避免漏项，我把监控对象拆成了四层，每一层单独梳理指标：

硬件与操作系统层：CPU、内存、磁盘、网络、文件句柄、操作系统关键内核参数。这一层最容易遗漏，但很多上层故障的根源都在这里。
数据库集群层：连接数、活跃会话数、锁等待、慢SQL、日志切换、缓冲池命中率、复制延迟、备份状态等。
中间件集群层：JVM内存、GC、线程池、请求队列、JDBC连接池、HTTP响应时间与错误率等。
应用业务层：接口成功率、交易耗时、业务错误码、自定义业务指标。这一层往往需要业务侧配合做侵入式埋点。

这个分层看起来基础，但实际操作中特别有用。很多团队在信创改造时只盯着数据库，结果中间件出了问题还要一层层翻日志；或者只做了应用监控，数据库都被连接池打满了还不知道。四层各管各的，告警的时候也能快速判断问题到底从哪层发起。

1.3 监控体系的目标不是“有图看”，而是“能定位”

在开始建设之前，我和团队还定了一个原则：监控不是为了把大屏做得好看，而是为了回答三个问题——当前系统健康吗？如果出问题，是哪一层、哪个节点、什么原因？容量还够撑多久？

围绕这三个问题，我们把指标分成两类：一类是“体检指标”，用来判断健康度，比如连接数、GC频率、错误率；另一类是“溯源指标”，用来支持故障回溯，比如慢SQL文本、锁等待链、堆栈快照。前者适合落到告警规则上，后者适合进日志系统或调用链系统。如果你也准备搭一套信创监控，我建议不要一上来就找工具，先把这两类指标列出来，跟运维、数据库管理员、应用负责人一起过一遍。这个动作能省掉后面大量的无效采集。

2. 指标采集清单：哪些指标值得长期盯着

有了分层思路，下一步就是把每层要采的指标确定下来。这里不打算面面俱到，只讲数据库和中间件这两个重点，因为这是信创监控的核心。主机和应用的指标大家比较熟悉，一带而过。

2.1 数据库指标：别只顾连接数和慢SQL

我见过不少团队的数据库监控面板上只有连接数和慢SQL两张图，这远远不够。真正要长期盯着的是这么几组：

连接与会话：当前连接数、活跃会话数、等待会话数、会话最大限制。连接数暴涨往往是应用连接池配置不当或存在异常调用；活跃会话数涨则多半是某条SQL把资源占死了。
锁与事务：锁等待次数、当前阻塞的会话数量、事务回滚率、长事务数量。信创数据库的锁机制各有差异，有的默认行锁，有的在某些场景下会升级为表锁，监控时要特别关注长时间未提交的事务。
SQL质量：慢SQL数量、SQL执行总耗时分布、Top SQL的CPU和IO开销。慢SQL不能只监控数量，还要把Top SQL明细抓出来，否则告警响了不知道杀谁。
存储引擎与日志：缓冲区命中率、日志切换频率、临时表空间使用率、数据文件增长趋势。日志切换频繁可能是刷盘能力不足，也可能是事务量真实增加。
高可用状态：主备复制延迟、归档日志连续性、集群保护状态、备份作业状态。这个经常被忽略，但信创环境下数据库高可用组件差异很大，同一套脚本不一定兼容。

举个例子，我之前在监控脚本里用过一个查询逻辑，就是从系统动态性能视图里抓当前连接数、活跃会话数和等待事件分布。这段SQL本身不难，难的是搞清楚视图里的字段语义。有的数据库里“活跃会话”不仅包含正在执行SQL的会话，还包括处于阻塞状态的会话，别把两者混在一起算，否则活跃会话数会虚高，告警阈值怎么调都不准。

2.2 中间件指标：Java进程的命门就那几个

多数国产中间件都是Java技术栈，所以JVM相关的指标是重点。具体来说：

堆内存与GC：堆内存使用率、GC次数、GC耗时、Full GC频率。堆内存使用率持续高位且GC后不降，基本就是内存泄漏；Full GC频繁往往伴随着长暂停，会导致接口超时。
线程池：活跃线程数、最大线程数、队列积压、拒绝任务数。如果队列积压持续上涨，说明后端处理能力跟不上；如果线程池触发了拒绝策略，说明线程数配置过小，或者下游数据库和外部服务卡住了。
连接池：JDBC连接池活跃连接数、空闲连接数、获取连接等待时间。中间件的数据库连接池健康度，往往是数据库连接数告警的前置信号。
请求处理：每秒请求数、平均响应时间、错误率、超时请求数。这些指标直接对应业务体验。

JMX是采集这些指标最通用的途径。很多国产中间件虽然兼容JMX，但MBean的对象名路径和商业软件不一样。我第一次接入时，光找线程池对应的MBean路径就花了大半天，最后是用开发工具自带的JMX客户端连上后一层一层翻才找到。如果你也遇到这种情况，我的建议是先把JMX客户端连上去，手动定位关键指标对应的路径，再写采集配置。

2.3 采集频率和最小权限：少采高频，多采低频

采集方案设计时最容易犯的错，是恨不得把所有指标都以5秒间隔采一遍。实际上监控本身也要消耗资源。我的做法是分三档：

高频（10到15秒）：数据库连接数、活跃会话数、中间件JVM堆内存、GC次数、请求错误率。这些指标变化快，适合高频采集用于告警。
中频（30到60秒）：缓冲区命中率、锁等待、线程池队列积压、磁盘空间。这些用于看趋势，频率太高意义不大。
低频（5分钟以上）：慢SQL明细、日志增长、容量类指标。这类指标数据量大，按需采集即可。

另外，监控账号一定不能申请数据库的超级管理员权限。我出现过一次小事故：监控脚本为了采集所有会话信息，在数据库里执行了消耗极高的查询，结果把生产库拖慢了。后来专门建了一个只读监控账号，只授予查询系统视图和少量统计表的权限，并且给所有采集SQL加了超时控制。中间件的JMX账号同理，尽量只读。

3. 工具适配：开源监控栈在国产化平台上的实际玩法

指标清单确定之后，工具选型就不是拍脑袋了。我的选择是开源监控栈为主，因为信创环境虽然换了底座，但标准化接口依然存在，开源工具通过适配完全能用。

3.1 选型：三个核心组件

我用的是一套“采集器加时序库加可视化与告警”的组合：采集器负责从数据库、中间件、主机抓指标；时序库负责存储和查询；可视化与告警引擎负责出图和发规则。具体用哪个组件，看你团队熟悉程度，不用盲目追新。

在这个结构里，采集器是最需要改的，因为信创环境的数据库和中间件的接口不标准。时序库和可视化组件基本上不用动。我当时的策略是：先用自研脚本把数据库的指标抓成标准格式，再推到采集器里；中间件则通过JMX导出器来抓。

3.2 数据库指标导出：自己写采集器比找现成插件更靠谱

开源生态里虽然有几个数据库导出器，但大多为开源关系型数据库设计。换成国产数据库后，直接套用往往不行，因为内部状态查询语句不兼容。我最后是写了一个轻量采集器，定期在目标数据库上执行自定义SQL，再把结果转换成指标格式输出。这种方式虽然原始，但可控性最好。

比如要采集连接数和活跃会话数，采集器会连数据库执行一组SQL，拿到结果后生成这样的指标文本：

db_conn_current{instance="192.0.2.10",db="order_system"} 326 db_session_active{instance="192.0.2.10",db="order_system"} 28 db_lock_wait_count{instance="192.0.2.10",db="order_system"} 3

这里需要说明一下，上面只是示意，实际字段名可以按你的命名规范调整。关键是你要把实例、数据库名、指标名都做成标签，后面出图、聚合、告警都会方便很多。完事之后，用采集器自带的文本协议让监控服务器过来抓，一行行解析，不用开发什么复杂接口。

3.3 中间件指标接入：JMX导出器的适配

中间件相对好办一些，因为它基本都遵循JMX规范。我采用的方式是部署一个JMX导出器进程，让它通过JMX端口连到中间件，每隔15秒采集一次指标并暴露为HTTP接口。需要注意的是，中间件的MBean路径必须先探测清楚。我踩过一个坑：同一个中间件厂商的不同小版本，线程池MBean路径居然不一样。后来把版本因素也写进了配置管理，否则中间件一升级，监控数据突然就黑了。

另外，如果中间件部署在容器里，JMX端口暴露方式也要注意。容器场景推荐额外暴露一个仅用于监控的端口，并用防火墙限制来源IP，避免把JMX裸暴露到业务网络里。这里不要嫌麻烦，安全策略做严格一点，后面能省很多事。

3.4 部署过程中的几个常见坑

我按部署顺序总结几个坑：

二进制兼容：采集器、导出器如果官方没有提供信创平台二进制，就需要在目标平台上用源码编译，或者找支持交叉编译的构建方式。编译前先确认目标CPU架构和操作系统的动态库版本，别拿到x86包直接跑。
网络策略：很多信创项目的网络策略比传统环境更严格，监控服务器不一定能直接访问所有被管节点。我的做法是规划一个监控专用网段，让所有采集源把指标代理到这个网段，再统一被监控服务器拉取。
时钟同步：信创平台同样需要时间同步服务。告警时间不统一，排查故障时时间线就对不上，这是特别容易忽略的点。
权限边界：监控账号要遵守最小权限，上面已经说过。再补充一点，采集器本身的运行用户也不要给超级管理员权限，能用一个普通服务账号最好。

这些坑单独看都不大，但叠在一起就会让部署周期变得很长。尤其是二进制兼容问题，建议在项目启动第一天就下载好目标平台的编译工具链，提前做验证，不要等数据库都上线了再补。

4. 告警体系设计：阈值、通知与值班闭环

指标能采上来了，如果告警乱发，监控体系建设就等于白做。告警设计的核心不是“多”，而是“准”。要让每次告警都有可执行的处置动作，而不是让值班人员看了一堆消息后仍然不知道要干嘛。

4.1 告警分级：先定义灾难度，再定义阈值

我把告警分成三个级别，并和响应时效绑定：

P0级别：数据库整体不可用、主备切换失败、中间件集群过半节点宕机、核心业务接口错误率持续超过阈值。这类告警必须即时触达值班人员和二线负责人，人工确认后进入应急流程。

P1级别：连接数使用率超过90%、活跃会话持续飙升、Full GC连续触发多次、线程池队列积压超限、磁盘空间低于20%。这类告警需要运维介入排查，但不需要深夜电话。

P2级别：慢SQL数量上升、临时表空间增长、CPU使用率持续超过80%、备份延时。这类告警在工作时间处理即可。

阈值怎么定？不能拍脑袋。我的办法是先采集两周的基线数据，看正常波动范围，然后取“超过正常峰值约20%到30%”作为告警阈值。比如连接数平时峰值是300到400，那阈值就设在500左右。注意要区分不同环境：测试环境阈值可以宽松一点，生产环境严格一些。一张示例表：

级别	对象	监控项	建议阈值	持续多久触发
P0	数据库	主备复制延迟	超过120秒	持续1分钟
P1	数据库	活跃会话数	超过120	持续5分钟
P1	中间件	Full GC次数	10分钟内超过5次	持续触发
P2	主机	磁盘使用率	超过80%	持续15分钟

这个表只是示例，实际数值要根据你系统的容量重新算。关键是要设置“持续多久”，避免抖动造成告警风暴。

4.2 告警规则配置：用查询表达式怎么写分级

如果你用的是支持查询表达式的告警引擎，可以这样写一条连接数告警：

- alert: DBConnectionPoolHigh expr: db_conn_current{instance="order-db1"} > 500 for: 5m labels: severity: P1 annotations: summary: "数据库order-db1连接数超过500" description: "当前连接数: {{ $value }}，请检查应用连接池和数据源配置"

这里的 for: 5m 就是持续5分钟才触发，能有效过滤瞬时抖动。“符合持续时长”再告警，比刚过阈值就告警要实用得多。实际项目里，每个级别的告警规则都要单独写清楚标签，方便告警路由分发到不同的人或群。

4.3 告警去重、抑制和通知升级

告警风暴是监控体系里最打击团队信心的事。我做了几件事：

聚合规则：同一实例同一指标的连续告警，只保留一条，关闭自动恢复通知，等真正恢复再发恢复消息。
维护窗口：在明确的发版窗口或者计划维护时间内，自动抑制相关告警。
依赖抑制：如果数据库已经P0，那么中间件的连接池告警可以先抑制一段时间，避免同一根因引发大量关联告警。

通知渠道上，P2发即时通信机器人群即可；P1同时发即时通信和短信；P0必须电话加短信，且15分钟未确认自动升级到值班长。这里最重要的一环是值班确认机制：告警发出后必须有人点确认，否则不算闭环。我们内部做了一个简单的确认脚本，告警推送里带着一个确认链接，值班人员点一下就能回写状态。这个机制看着简单，但在快速应急时特别有用。如果你团队有值班系统，直接把告警状态做成工单，效果更好。

5. 一次真实故障的监控复盘：从告警到定位

写到这里，我想用一个真实发生过的问题来串一遍整套监控体系。为了保护细节，我把涉及的业务和系统名做了脱敏，但链路是完整的，思路可以参考。

5.1 故障现象

那天晚上十点多，值班群里的告警机器人开始连续弹消息：先是某个数据库节点连接数超过600，接着是某个应用中间件线程池队列积压超过2000，然后是活跃会话数超过150。三分钟之内，三条P1告警几乎同时出现。如果按照以前的经验，这大概率是数据库出问题了。但实际原因并没有这么简单。

5.2 定位过程

我没有着急去连数据库执行命令，而是先打开监控大盘看时间线。连接数是晚上7点50开始缓步上涨的，到10点10突然加速；中间件队列积压从10点05开始上升，比连接数暴涨早了5分钟；活跃会话在10点08开始抬头。

这里有个很关键的分析：如果数据库先出问题，中间件队列积压应该和连接数同步上升；但现在队列积压先涨，说明应用已经拿到了连接，但执行SQL变慢了，可能是一条坏SQL把数据库拖住，然后应用端不断创建新连接，导致连接数也被顶上去。

顺着这个思路去查慢SQL明细，发现某个核心查询从7点50之后执行时间持续拉长，从正常200毫秒涨到了3秒以上。再看Top SQL的文本，发现对应业务表当晚有批量任务写入，而那个查询用到的索引列和批量任务更新的是同一个字段，等于批量任务刚提交的行持续被修改，查询需要的索引页不断被更新，行锁竞争非常激烈。

如果没有监控链路的联动，我可能会先去重启应用，那不仅没法解决问题，反而会让连接池重建时的瞬时压力更大，扩大故障范围。而通过监控图确认了故障链路，直接切到数据库层看锁等待和慢SQL，用了不到十分钟就定位了根因。

5.3 优化动作

当务之急是让业务先恢复。我的处理分两步：第一步临时把那个批量任务调整为低并发，减小对索引页的更新压力；第二步在应用侧给相关连接池加了一个上限保护，防止异常情况下连接数继续无限上涨。

事后我们对监控规则做了三个改动：一是给锁等待指标单独建了P1告警，因为这次故障里锁等待才是真正的源头；二是把批量任务运行时间窗口加入维护窗口配置，夜间自动抑制该业务的低优先级告警；三是在中间件告警里增加了“队列积压持续下降后自动恢复”的规则，避免队列积压指标在修复过程中反复抖动造成误报。

5.4 监控体系在故障里真正值钱的地方

这次故障让我对监控体系的定位有了新的认识：监控不是为了事后看曲线，而是要在故障发生前甚至更早就给出方向。如果当时没有队列积压和连接数的先后时间线对比，故障定位至少要翻三四台服务器的日志才能找到线索。数据库和中间件的指标是互相印证的，中间件的主动信号往往比数据库告警更早。

另外，告警规则的持续迭代也很重要。第一次故障之后，我们专门花了两周时间把数据库锁等待、日志切换频率、中间件连接池等待时间这些容易后置暴露的指标全都补上了。这些指标平时看起来没什么用，但真出问题时，它们才是区分“系统慢”和“系统坏了”的关键证据。

最后，整套体系搭完之后，如果让我给正在做信创监控建设的朋友一个建议，那就是：不要一上来就纠结工具选型，先把指标清单和告警分级想清楚，再让工具为你服务。信创环境的特殊性决定了没有哪套现成方案能直接抄，但只要你把“采什么、怎么采、采完怎么用”这条链路走通，剩下的就只是工作量问题了。先把数据库和中间件的核心指标采准，再逐步加厚告警和分析能力，这套监控体系会越用越顺手。