1. 信创监控的痛点与整体架构设计1.1 为什么信创环境的监控不能照搬旧方案之前负责的某业务系统做信创替换数据库从国外商业数据库换成某国产关系型数据库中间件也换成了国产Web中间件。系统切过去第一天监控大屏上将近一半的指标直接变成了灰色。原来那套基于特定管理视图和特定产品生态的监控脚本在国产环境下基本全部失效。最尴尬的是连最基础的会话数采集都报错排查半天发现是系统视图名称、字段结构都不一样甚至某些权限点在国产库里压根不存在。这就是信创监控的第一个核心痛点监控链路里每一环都可能出现兼容性断层。过去成熟的方案从采集Agent、SQL模板到告警阈值全都绑定在原有生态上。换到国产化环境后这些资产不能说完全作废但至少需要逐项验证。更麻烦的是底层操作系统也国产化了部分命令行工具行为差异很大很多旧脚本跑在上面要么语法不兼容要么输出格式对不上解析逻辑全得重写。但话说回来信创环境监控也不是从零开始。整体思路依然是“采集-存储-分析-告警-展现”这条链路只是每一层的技术选型都要多考虑一层国产化适配。我个人落地时采用的是“统一采集框架多源适配器”的方案底层用统一的采集调度框架每一种国产数据库、国产中间件写对应的适配采集插件采集上来的数据统一格式入库上层用一套指标模型和告警引擎来处理。这样避免了每接一个组件就重复造一套轮子的问题。这个方案选择不是拍脑袋决定的核心考量是风险隔离。如果每个组件都各自为政后期维护成本会成倍增长。统一采集框架虽然前期要搭骨架、定规范但后续每新接入一个国产组件只是多写一个适配器的事。实测下来第二套组件接入的耗时比第一套少了约60%这就是架构设计带来的长期收益。1.2 从指标到告警的完整链路规划整个体系的设计我分为四层来讲。第一层是采集层。负责定时从各类信创组件中拉取指标数据包括操作系统、数据库、中间件、应用进程四类对象。这层要解决的关键问题是采集方式多样有的组件只提供命令行接口有的提供SQL查询有的是JMX端口有的是REST API。适配器模式统一封装这些差异对外暴露一致的指标获取接口。第二层是存储与计算层。采集到的指标数据统一汇聚到时序数据库中按标签维度组织。这一层要解决指标归一化的问题。比如数据库的连接数、中间件的活跃线程数、操作系统的进程数虽然来源不同但语义上都属于“资源占用类”指标要有一套统一的命名规范否则告警规则和展示面板都没法复用。第三层是告警引擎层。负责规则匹配、状态计算、聚合抑制和通知分发。这里的核心设计是“规则表达与执行分离”。运维人员只需要在前端配置可视化的规则模板比如“指标连续5分钟超过阈值则触发”引擎层将其转换为内部计算任务统一执行。这种方式让非开发人员也能维护告警策略不依赖写代码。第四层是展现与消费层。包括趋势图、仪表盘、日报、月度报告等。这部分相对容易但容易被忽视的反而是“告警历史复盘视图”用来统计告警分布、误报率、响应时效。没有这个视图告警体系就无法迭代优化。实际项目中我建议按这个顺序逐步建设先解决指标采集的“有无”问题再解决指标沉淀的“规范”问题然后做告警规则的“敏态”配置最后才是展示和报表。一次性全量建设往往会导致战线过长中间某个环节卡住整个项目就停滞了。2. 数据库监控指标采集的拆解与实操2.1 国产数据库需要盯住哪些核心指标数据库监控是整个体系中最需要细抠的部分。国产数据库虽然种类多但大多数产品在设计上借鉴了成熟数据库的体系结构所以监控的核心维度是相通的实例健康度、连接管理、存储空间、性能吞吐、主备复制状态。实例健康度关注的是数据库进程是否活着、能否正常响应请求。最简单的手段是每30秒执行一次轻量级查询比如查询当前时间或版本号通过返回耗时判断实例响应能力。如果这个操作都超时说明数据库已经陷入严重阻塞或资源耗尽状态这是最高优先级告警。连接管理是国产库经常出问题的地方。很多国产库默认最大连接数相对保守应用侧连接池配置不当就容易把连接数打满。要采集的指标包括当前总连接数、活跃连接数、等待连接数、连接超时次数。其中“连接超时次数”这个指标最容易被忽略它的突增往往是应用侧连接池泄漏的前兆。存储空间包含表空间使用率、数据文件剩余空间、归档日志增长速度。在信创项目中很多业务系统迁移后数据量比预期增长更快表空间告急是出现频率最高的告警之一。建议不仅监控使用率百分比还要结合剩余绝对空间和每日增长量做趋势预测。性能吞吐包括每秒事务数、每秒查询数、缓存命中率、锁等待次数、慢查询数量。这些指标反映系统支撑业务的能力。国产库在缓存命中率上和主流商业库存在差距尤其是某些OLTP场景下命中率掉到85%以下就要警惕了。主备复制状态在信创场景尤为重要。国产库的高可用方案通常采用一主一备或一主多备架构备库通过日志同步追赶主库。要监控的关键点位是复制状态是否正常、主备延迟秒数、日志同步中断告警、备库回放异常。主备延迟不能只看瞬时值要看持续趋势——延迟不断上涨说明备库性能跟不上或归档日志积压。2.2 采集方式选择SQL查询、命令行工具与系统视图的取舍国产数据库的指标采集主要有三条路径。第一条是系统视图查询。大多数国产库内置了类似数据字典的系统视图存放会话、锁、事务、表空间等运行状态信息。你可以用普通SQL去查询这些视图这是最标准、最稳定的采集方式。但要注意国产库版本升级时视图名称和字段可能调整适配器里要预留视图名映射配置避免硬编码。第二条是命令行工具。国内主流国产库都提供类似交互式命令行工具支持执行SQL脚本并输出结构化结果。我的经验是命令行工具非常适合做批量巡检和标准输出解析但它的输出格式在不同版本间变化较大脚本解析时要做容错处理。效率上命令行启动开销较大不适合高频率采集比如10秒一次适合低频分钟级巡检。第三条是日志解析。数据库运行日志、慢查询日志都含有丰富的信息。慢日志采集尤其有价值——通过解析慢日志可以还原出具体的慢SQL文本、执行计划、等待时间辅助性能调优。但日志解析有三个坑要处理一是日志滚动导致文件切换丢失二是日志格式不一致导致解析失败三是日志采集对磁盘IO有影响高频读日志文件会影响数据库性能。我通常把日志采集频率控制在每分钟一次且优先采集已轮转的老日志文件。实测下来最优组合是“高频SQL查询YAML配置式巡检低频日志解析”。SQL查询负责核心运行指标命令行巡检负责批量检查表空间、归档状态等低频指标日志解析专门负责慢查询采集。三者各司其职既能保证时效性又控制了采集开销。采集账号权限配置的经验这里有一个很容易踩坑的点采集账号的权限设置。信创环境普遍安全基线要求高DBA不愿给采集账号过大的权限。但权限过小又采不到关键指标。我的建议是创建独立专用账号只赋予查询系统视图和读取日志的权限不授予任何写权限。具体来说连接类指标需要查询会话视图的权限空间类指标需要查询表空间视图的权限状态类指标需要查询系统状态视图的权限慢日志需要操作系统层面的日志文件读取权限在申请权限时把需要的视图清单和操作命令列表先给DBA审核一次性申请到位。避免上线后发现少一个权限等流程审批又等了一周。2.3 一个可复用的SQL采集模板参考对于SQL查询方式建议直接设计一套参数化指标采集SQL通过配置文件管理连接信息和采集项。这里提供一个简化版参考思路# 每隔30秒采集数据库关键运行指标 # 指标包括当前连接数、活跃事务数、缓存命中率、锁等待数 SELECT metric_name, metric_value FROM ( SELECT instance_status AS metric_name, 1 AS metric_value FROM dual UNION ALL SELECT session_count, COUNT(*) FROM v$sessions UNION ALL SELECT active_session_count, COUNT(*) FROM v$sessions WHERE status ACTIVE UNION ALL SELECT active_txn_count, COUNT(*) FROM v$transactions UNION ALL SELECT cache_hit_ratio, ROUND((1 - (physical_reads / (db_block_gets consistent_gets))) * 100, 2) FROM v$sysstat UNION ALL SELECT lock_wait_count, COUNT(*) FROM v$lock WHERE block 1 );注意不同国产库的系统视图名称和字段不一定完全相同这里只是抛砖引玉。实操中必须先通过查询视图元数据来确认字段结构再调整SQL模板。采集频率上我的经验是连接类、锁等待类指标用30秒周期因为这些异常发展非常快5分钟采一次根本来不及发现空间类和复制延迟类可以用5分钟周期这类指标变化相对平缓高频采集反而浪费资源慢查询日志每分钟解析一次即可。3. 中间件监控指标采集的拆解与实操3.1 国产中间件的监控难点与核心指标如果说数据库监控是“照虎画猫尚有章法”中间件监控就完全是“盲人摸象绕坑行”。国产中间件品类多、标准杂、文档少是信创监控项目中最容易翻车的地方。国产中间件大致分为几类Web应用服务器部署Java应用、消息队列业务异步解耦、缓存中间件热点数据加速。每类的监控重点完全不同。Web应用服务器的监控核心是JVM健康和线程池状态。要关注堆内存使用率、GC频率和耗时、活跃线程数、队列积压任务数、连接池活跃连接数。这类中间件大多基于Java技术栈所以JMX协议是通用的采集入口——基本上是唯一好消息。但国产Web中间件对JMX端口的默认配置各家差异很大有的默认开启有的需要手动修改配置启封。消息队列的核心监控指标是生产消费状态Broker节点状态、Topic分区数量、消息堆积量、消费延迟时间、吞吐率。消息堆积是最关键的告警源堆积量持续增长通常意味着消费者处理能力不足或消费者宕机。要采集消费组(client group)级别的Lag——已经有部分国产消息队列产品提供了类似命令行工具可以查询这一指标但输出格式比较随意需要做文本解析。缓存中间件的监控核心是内存效率和命中情况内存使用量、键数量、内存碎片率、命中率、每秒操作数、慢查询数。缓存中间件的采集方式相对统一官方命令行工具提供了丰富的指标输出解析也相对简单。3.2 JMX、API与日志解析三种采集路径的实战要点JMX路径适合Java系中间件。具体操作分三步第一步确认JMX端口是否开启。国产Web中间件的配置文件里通常有类似“JMX服务端口”的配置项可能默认是空值或空端口需要手工指定。这里有一个安全运维建议JMX监听地址务必绑定内网专用管理IP而不是0.0.0.0且要设置强密码认证。第二步用JMX客户端工具验证连通性。可以用简单的命令行工具带用户名密码去拉取堆内存指标确认能够正常连上再做数据采集。第三步在采集框架中配置JMX Endpoint定期抓取MBean指标。可以抓JVM的标准MBean堆内存、GC、线程数以及中间件自管理的MBean线程池、连接池、请求处理量。国产Web中间件管理MBean的对象名各家不同建议在正式部署前先用探查工具把对象名列表导出来写进配置文件里做映射。REST API路径适合自带管理接口的中间件。消息队列类和部分缓存类国产中间件提供HTTP管理接口可以直接通过JSON接口拉取状态指标。这种方式最省事不依赖额外协议但要关注接口鉴权和频控。我遇到过的情况某国产消息队列的管理接口返回的数据量巨大默认一次性返回全部主题的全部指标采集进程拉一次要好几秒钟还容易超时。解决办法是循环分页获取只拉需要的主题列表再逐个主题拉详情虽然请求次数多了但单次开销小、稳定不超时。同时把采集频率拉到60秒一次降低对管理接口的压力。日志解析路径适用于没有标准化管理接口的中间件。要解析的主要是访问日志和错误日志。访问日志可以统计请求量、状态码分布、平均响应时间这些指标对网关类中间件尤其有价值。错误日志则用于发现异常堆栈和连接失败记录。日志采集的通用做法是配置一个轻量级的日志采集Agent使用通配符匹配日志文件路径支持按行解析格式。信创环境下部分日志编码和换行符不标准解析规则里要预留编码转换和容错处理。3.3 中间件指标建模的归一化思路中间件采集最大的坑是同类指标命名不统一。比如Web中间件叫“work thread count”缓存中间件叫“connected clients”运行时都是“worker number”如果不做归一化后续告警规则和展示面板都要为每个组件单独配置工作量巨大。我的解决思路是定义一套统一指标字典。把所有中间件指标映射到几个通用语义类别里资源水位类内存使用率、CPU使用率、磁盘IO等待并发压力类活跃线程数、连接数、请求处理速率队列积压类消息堆积量、任务队列长度、未处理请求数依赖健康类下游连接成功率、外部调用响应时间稳定性类GC次数、长时间停顿、错误率、重启次数同一类语义下不同中间件的具体指标通过标签如组件类型标签来区分来源。告警规则只需要针对统一语义来配置阈值比如“队列积压类指标持续5分钟超过1000则告警”这条规则对消息队列、任务队列、请求队列都适用。这套归一化思路把中间件告警规则的代码量减少了约七成。4. 监控工具选型与信创环境适配4.1 开源监控栈在信创环境的可用性验证监控工具本身也面临信创适配问题。目前主流监控工具以Prometheus、Grafana、Zabbix为代表在信创环境下的可用性我分三个维度来说。部署层面。Prometheus和Grafana都是Go/前端技术栈编译产物是静态二进制文件不依赖特定运行时环境部署到国产操作系统上问题不大。Zabbix基于C语言编写虽然编译麻烦一些但主流国产系统厂商已经将其纳入软件仓库直接安装即可。采集层面。Prometheus生态的核心优势是Exporter机制。官方和社区有一大堆现成Exporter但大多数是针对主流开源组件的。国产数据库和国产中间件往往没有现成Exporter需要自己开发。这个环节工作量最大。我的方案是使用PushGateway模式做一个自定义脚本采集适配器把采集逻辑封装在脚本里脚本输出Prometheus格式暴露指标数据由PushGateway接收。这样不需要编写独立的HTTP服务进程降低开发和调试成本。数据存储层面。Prometheus自带的本地存储不建议长期保存大量历史数据通常要对接对象存储或集中式时序存储。信创环境下这部分可能需要做一些兼容测试比如确认时序存储能否跑在国产操作系统上。展示层面。Grafana在不同操作系统下的表现有一些细微差异画图渲染依赖的字体如果缺失会乱码。建议在部署时一并安装中文字体包否则仪表盘上的中文标题会显示成方块。4.2 自研轻量采集脚本还是依赖商业监控平台这里有一个很现实的取舍问题。信创项目预算充足时商业信创监控平台往往是首选厂商适配好、开箱即用、有原厂支持。但如果项目预算有限或者需要深度定制指标我倾向于“Prometheus技术栈自研适配脚本”的路线。自研采集脚本最大的优势是灵活可控。你可以精确控制采集频率、采集内容、输出格式不受商业产品黑盒限制。缺点是开发维护有成本。如果你只有一个数据库加一个中间件需要监控自研适配器可能不划算但如果是几十套数据库和中间件适配器的工作量就被摊薄了自研优势明显。我之前评估过一个商业信创监控平台它的数据库监控插件确实做得不错内置了大量指标模板但中间件监控插件比较薄弱只覆盖了通用的Java线程和堆内存指标针对某些国产消息队列的堆积监控完全没有。这意味着即使买了商业平台还是要自研一部分采集脚本。所以“开源栈自研适配”路线在信创环境中往往更可控。4.3 采集调度与数据上报的稳定性设计监控系统最怕的不是采集不到数据而是采集过程给业务系统带来意外影响。这里分享几个稳定性设计要点。一是采集进程与业务进程隔离。采集服务部署在独立的监控主机上避免监控Agent故障拖垮业务应用。数据库采集走网络连接不安装本地Agent中间件采集走JMX或API也不安装本地Agent。只有操作系统层面的指标采集需要部署轻量Agent这部分风险较低但资源占用要严格限制。二是采集超时与降频。每个采集任务都要配置超时时间和失败重试策略。例如SQL查询30秒无响应即放弃连续3次失败则标记该采集源异常并告警但不要把告警风暴扩散到所有指标。同时如果某个采集源频繁超时应自动降级采集频率从30秒降到5分钟避免持续打高频请求加重目标负载。三是采集链路自身的守护。采集调度器需要实现“看门狗”机制如果采集进程卡死或重复执行要能自动拉起和去重。我遇到过调度器进程假死导致所有采集停摆2小时的情况事前没有任何告警——因为告警规则依赖的指标没有新数据检查“数据新鲜度”这条基础规则当时没配置。现在我做任何监控系统都会强制加一条“数据新鲜度”规则某个指标源超过2倍采集周期没有新数据上报即触发告警。这条规则能兜底绝大多数采集链路故障。5. 告警体系设计与落地细节5.1 告警分级与规则设计从“响”到“准”告警体系是整个监控系统价值兑现的最后一环。很多项目采集指标做得很好但告警一上线就变成“狼来了”——误报太多最后运维同学把告警通道静音了真正出问题时反而没人看到。要解决这个问题关键在告警分级和阈值设计。我的分级设计是四级紧急告警P0业务直接受损或即将受损需要立即响应。比如数据库不可用、主备切换失败、消息堆积量突破预设上限。严重告警P1)性能明显劣化但业务尚可用需要在30分钟内介入处理。比如缓存命中率跌破阈值、连接数达到上限的80%。警告告警P2趋于恶化需要关注但暂不打断。比如表空间使用率达到75%、慢查询数量环比增长一倍。提示信息P3仅供了解不触发通知。比如日常巡检报告、下周容量预测。阈值设计上建议遵循“绝对值持续时间趋势变化”三位一体规则。绝对值是触发基线持续时间用于滤掉瞬时抖动趋势变化用于预判风险走向。例如数据库连接数规则配置rules: - metric_query: db_connection_usage_ratio condition: 0.85 for_duration: 5m trend_check: window: 15m rising_rate: 10%这条规则表示连接使用率超过85%且持续5分钟同时15分钟内还有加速上涨趋势才会触发P1告警。持续时间的滤抖效果立竿见影——偶发尖峰不会误报真正的持续恶化必然触发。5.2 通知路由与值班闭环通知渠道上我配置了三级递进IM机器人是日常主力邮件加短信用于升级电话人工调用仅用于P0紧急场景。IM机器人优点是好聚合、能推送详细上下文链路短信用于IM没被看的情况电话用于真正影响业务的紧急时刻。但通知渠道多不意味着所有告警都要全渠道轰炸。我的路由规则是P3 只进入告警平台和日报P2 推送IM机器人不打扰手机P1 推送IM机器人短信P0 全渠道触发并自动呼叫值班人同时要配置通知升级链。P1告警触发后如果15分钟无人确认系统自动升为P0并通知值班负责人的上级。这个机制保证告警永远有人负责闭环。告警升级里有个细节容易被忽略告警触发的“值班时段”判断。夜间和节假日的响应人力更少阈值可以适度收紧比如持续5分钟即可触发P1工作时间则要放宽需要10分钟持续才触发。这样既不打扰夜间休息又能保证夜间有真实问题时能及时响应。5.3 告警去重与抑制避免“告警风暴”告警风暴是监控系统上线初期最常遇到的问题——一个根因故障触发几十条关联告警运维人员瞬间被淹没。我实践中最有效的三个策略基于根因指纹的聚类去重。每一条告警都附带告警指纹由指标源、指标名、告警级别的哈希生成。在同一时间窗口内如果出现了相同指纹即同一指标的多次触发或关联指纹比如数据库连接池告警和活跃会话告警同时出现系统只推送一条根因告警其余关联告警进入“伴随告警”列表只记录不推送。依赖关系的向上抑制。如果数据库宕机应用层的所有请求都会失败此时应用健康度告警、批量任务失败告警都是数据库故障的下游表现。通过配置依赖关系应用依赖数据库当数据库进入P0告警状态后抑制依赖该数据库的所有应用层告警只在数据库恢复后统一补发一条“依赖恢复通知”。维护窗口静默。业务系统发布、数据迁移等窗口期间部分指标剧烈波动是预期的不该触发告警。我在告警引擎配置了维护时间表基于“时间和对象”双维度的豁免规则维护期间只记录告警不推送通知。6. 实战常见问题与排查技巧6.1 指标采集链路常见故障速查信创监控项目上线前后有很大概率踩到下面这些坑。我整理一个速查表现象可能原因排查步骤与解法采集SQL执行报权限不足采集账号系统视图访问权限缺失与DBA确认视图授权范围重新授权使用专用低权限账号指标数值显示异常大/小单位不统一字节/ KB / MB或字段含义误读核对系统视图字段说明对数值做单位标准化换算部分指标偶尔采集为空瞬时统计无快照或系统视图在空闲时无记录在采集脚本中做空值默认处理如返回0并标记数据点可信度消息队列管理接口超时管理接口一次性返回数据量过大改为分页获取降低采集频率按主题精确查询日志文件滚动后采集中断日志采集器没有正确处理日志轮转启用日志采集的通配符监控和轮转检测测试旧文件轮换场景窗口图形出现间隙采集任务阻塞或目标端拒绝连接检查采集进程日志确认目标端防火墙是否放行管理端口告警延迟明显告警评估循环周期过长或规则数量过大优化规则计算的批次处理检查依赖关系计算的性能6.2 国产环境的三个“隐形坑”字符集坑。部分国产数据库默认字符集不是UTF-8执行采集SQL时中文条件或返回中文描述会出现乱码。现象就是指标值正常但描述字段是乱码日志解析时更是完全解析不了。解法是采集连接串里显式指定字符集以及在日志采集器中设置编码自动探测。时区坑。信创环境跨区域部署时操作系统时区可能设置为UTC而数据库和中间件的默认时区是本地时区导致时间戳对不上——告警时间看着有偏差趋势图出现“未来数据”。解法是统一各组件时区配置采集数据统一转换为UTC存储展示时按用户时区渲染。权限管理坑。国产操作系统的用户权限控制更严格普通用户无法读取某些日志路径。监控脚本手动执行正常但放入计划任务后因为环境变量不同比如PATH缺失而执行失败。解法是脚本头部显式设置PATH、LANG等关键环境变量并用调试模式验证计划任务环境。6.3 阈值调优与误报压降的实操经验刚上线时告警数量往往会远超预期别急着“调大阈值”来压告警——这样做只是掩盖了问题。我的调优流程新告警规则统一进入“观察模式”运行两周只记录不推送。每一条真实触发的记录都标记是否应该告警标签有效/无效两周后统计准确率。准确率低于80%的规则分析触发时间点、数据分布和业务活动重新设计阈值或持续时间。准确率高于90%的规则才正式进入推送通道。为什么这样有效因为新规则对应的系统往往还没建立业务基线和时段特征盲目设阈值本身就是猜。观察模式下用真实运行数据校准告警准确性才会稳步提高。有一次我上线了慢查询量告警规则设定一分钟超过50条触发。观察期数据显示业务高峰时经常到80条但无实际性能问题调整阈值后一周告警量下降了60%但真实性能问题一条没漏。还有一个经验告警规则的迭代周期要固定。每季度回看一次告警命中记录删除超过一个季度从未触发或频繁误报的规则下线的规则保留在规则库的禁用状态以便回溯。通过这种持续优化告警体系会越来越贴合业务真实状态。7. 写在最后信创监控建设的几个建议如果上面的内容能帮你少踩几个坑那这篇文章就值了。最后分享几条个人体会。第一信创监控是一个持续适配的过程。国产软硬件生态还在快速迭代数据库三个月发一个小版本、中间件半年一个大版本是常态。每次版本升级都要做一次监控插件的回归验证。我建议在版本升级评审里强制加上“监控兼容性验证”这一项确认新版组件管理接口、系统视图没有变化之后再允许上线。第二监控体系的价值不在于指标多而在于指标的“可解释性”。采集了上百个指标如果每个指标对应的业务影响说不清楚那这个指标大概率没人看。我倾向于宁可少采20个指标也要把每个指标的定义、采集周期、告警阈值、触发含义在监控元数据中记录清楚。这样后续人员交接时才不会把监控系统当成一个说不清的黑盒。第三告警体系的建设比指标采集更考验持续投入。采集是一阵子的工程告警是一辈子的运营。业务在变、数据量在变、系统架构在变告警规则必须跟着变。建立常态化的告警质量回看机制才是监控体系长治久安的根基。我在信创监控项目里深度参与了一段时间之后最大的感触是技术问题往往不是最难的最难的是“在未知的生态里重建确定性的秩序”。数据库从A换到B、中间件从C换到D底层逻辑还是那一套只要把握住“指标采集有方法、工具选型有边界、告警运营有节奏”这三个原则信创监控这关就能稳稳过去。