最近我们团队接手了一个典型的信创环境改造项目要把原来跑在商业数据库和商业中间件上的业务系统整体迁移到国产数据库和国产中间件上。迁移本身倒还好真正让我头疼的是监控体系以前靠现成管理工具能看到的那些指标在信创环境里几乎全部失效。数据库的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{instance192.0.2.10,dborder_system} 326 db_session_active{instance192.0.2.10,dborder_system} 28 db_lock_wait_count{instance192.0.2.10,dborder_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{instanceorder-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 监控体系在故障里真正值钱的地方这次故障让我对监控体系的定位有了新的认识监控不是为了事后看曲线而是要在故障发生前甚至更早就给出方向。如果当时没有队列积压和连接数的先后时间线对比故障定位至少要翻三四台服务器的日志才能找到线索。数据库和中间件的指标是互相印证的中间件的主动信号往往比数据库告警更早。另外告警规则的持续迭代也很重要。第一次故障之后我们专门花了两周时间把数据库锁等待、日志切换频率、中间件连接池等待时间这些容易后置暴露的指标全都补上了。这些指标平时看起来没什么用但真出问题时它们才是区分“系统慢”和“系统坏了”的关键证据。最后整套体系搭完之后如果让我给正在做信创监控建设的朋友一个建议那就是不要一上来就纠结工具选型先把指标清单和告警分级想清楚再让工具为你服务。信创环境的特殊性决定了没有哪套现成方案能直接抄但只要你把“采什么、怎么采、采完怎么用”这条链路走通剩下的就只是工作量问题了。先把数据库和中间件的核心指标采准再逐步加厚告警和分析能力这套监控体系会越用越顺手。