异构系统适配和监控数据治理——金融一体化监控部署的难点应对

来源：市场资讯

（来源：twt企业IT社区）

导读

传统分散式监控模式已难以满足风险防控、运营效率提升的需求，通过金融一体化监控能够解决这些问题，但面临基础设施类型多、品牌多和技术路线多的场景，如何确保异构系统适配和监控数据治理？本文来自四位金融行业同行，分享了实践中的风险、难点与应对策略。

分享一 / 程宗憬 某城商行 系统工程师

难点主要来自传统架构和技术多样性。金融行业过去系统建设都是相对独立，不同结构和架构，导致服务器、网络设备、数据库、应用系统五花八门，技术标准和接口协议都不一致。想给这么一个混杂的基础环境部署一个统一的监控，最大的挑战就是“接不上”——老系统可能只支持旧协议，云原生系统又是另一套玩法，数据格式千差万别。直接部署还可能影响正在运行的业务，就像给高速行驶的汽车换轮胎，风险很高。

中小金融企业适合务实的技术路线，可采取“分步走”的策略。第一步先统一监控基础设备（服务器、网络），开发一套可灵活插拔的采集工具来适配不同品牌。第二步制定统一的数据标准，把所有监控数据清洗成统一的格式。 同时在建设过程中重视“新旧并行”，让新旧两套监控系统同时运行一段时间，等新系统稳定了再逐步切换。同时成立专门的小组来制定监控规范，把监控配置像写代码一样管理起来。

对行业内的成功经验总结起来有几点很关键。技术上优先选择开源标准，这样能避免被厂商绑定及初期的大投入，同时借鉴云原生的监控思路，即便在传统环境里也很有用。实施时要分领域管理，基础设备强调自动化采集，业务系统则要建立业务指标和技术指标的关联。最关键的是通过小范围试点、灰度发布等方式降低风险，并强制要求新采购的系统必须提供标准监控接口。

同行补充：

姚雅飞 某银行 系统架构师：分享者持续建设的理念值得肯定，一体化监控本身投资大，企业运维必须处在成熟阶段，对于初始或发展中阶段可以参照一体化监控理念，参考建设。

赵子翊 某银行 技术经理：监控能力提升是一个持续化过程，通过开源和自整合能力持续建设提升，是一个切实可行的道路。

分享二 / 王洋 某基金公司 系统架构师

在一体化监控平台实际项目建设过程中，往往需要面临对接各种类型和品牌的基础设施设备的问题，在笔者实践经验看来，需要做好以下几个方面的问题和解决，希望能给更多金融同行参考借鉴。

首先是明确所有对象。梳理出所有需要对接的设备，明确每个设备的品牌和类型，并联系供应商获取每个设备对象的监控方式，一般包括不限于 API 、日志、 SNMP 或者其他协议。对于不能提供对接接口的老式设备，如果不能进行设备替换，又没有其他可以将监控数据输出的方式，则只能延续原先的监控告警方式，但是从中长期的角度看，还是要推进增加数据输出接口。

其次是数据格式标准化。对于从各种类型设备收集上来的数据，基于标准化的数据格式进行调整。在实际项目中需要注意（1）标准化格式需要能够满足一体化监控平台的导入要求（2）甲方在进行设计标准化格式的时候，需要预留字段已备后用，或者采用可弹性按需扩展的模式。

再次是标注数据来源。一体化监控平台在对接各种类型的设备或者监控组件后，应设计一个字段用于标识数据的来源，即一条告警事件应该能够显示出该告警来源于哪个设备或者监控组件，以便出现问题时的排查工作。

最后是持续运营。一体化监控平台在对接各类设备时的数据采集不是一蹴而就的，对于存量中实在无法解决的数据对接，只能先暂缓，后期基于设备更换或者升级时再进行适配。对于新增的设备或者其他监控对象，一定要求其提供开放性的对接接口或者方案，作为产品选型时的一项重要指标。

同行补充：

赵子翊 某银行 技术经理：同上一个专家不谋而合，监控数据治理必须经过一个标准化、治理、提炼的过程。

分享三 / Hsia 某持牌支付机构 架构师

1、历史包袱重：体现在各种品牌 、异构、版本等等不一致的问题，对应的监控协议、数据格式也肯定无法统一，收集整理起来相对消耗时间，或者太老，根本没办法迁移到新建系统，造成数据孤岛。

要想解决就不能单单依靠一个系统完美实现，需向下兼容，至少实现大屏统一展现，屏蔽底层接口信息。

2、数据的存储治理：各自产生的监控数据（如日志、指标、告警），分散在不同存储介质（本地文件、ELK、InfluxDB、Oracle等），难以统一采集和关联分析。

可搭建数据中台，采用“采集-清洗-存储-分析”的分层架构，通过Kafka作为数据缓冲队列，解决高并发数据传输压力；利用 Flink、Spark等进行数据清洗，将不同来源的数据统一存储到时序数据和日志中心。

3、业务场景监控：涉及比较广泛且一线的业务和领导层更为关注，诸如交易成功率、响应时间、交易金额笔数、TPS、跑批进度、渠道失败率、接口拨测等等），难点在于数据准确性、实时性如何与业务关联。

数据拉取应尽量从原始库的从库/只读库作为权威数据源，减少中间转发层的延时篡改等风险。但是这也涉及到一个新的问题，如何有效平衡性能与成本。

建立业务+技术+数据的三方例会，业务侧提出监控需求，技术侧落地实现，数据侧保障准确性；明确告警负责人，避免技术告警无人认领。同时建立定期优化机制，复盘监控异常案例，分析失真原因，完成优化迭代。

分享四 / 姚雅飞 某银行 系统架构师

这一问题比较笼统，将集成能力和监控工具自身能力混淆了。

首先，基础设施类型多、品牌多，这部分是由监控工具来完成的，一个合格的监控工具就应有这样的能力，这也是选型的重点之一。

其次，异构系统适配，这部分集成其实难度并不大，老的监控工具基本不能满足新的一体化监控能力要求（频率、监控粒度）多会被淘汰，一般不会参与集成。目前一体化监控平台集成的更多的是每种监控工具的监控结果数据，多协议的问题更多的是监控工具面临的问题，例如modbus协议、SNMP协议等。目前主流的监控工具对外输出结果数据时基本都支持JSON协议，监控数据集成并不算是一体化监控中的难点。参照现有业务系统多协议快速适配（企业总线），也有部分产品集成了这样的能力，要根据企业规模和未来规划，理性选择，切不可不切实际，为了规划而规划。

最后，监控数据治理，确实是一体化监控建设的难点和重点。一方面是财务方面的支持，企业管理者对业务数据治理的投入还基本认可，对IT数据的治理投入太多预算不大好通过。二是自动更新能力，最大限度的确保所选产品数据要能够自动更新，对于不能更新的部分，要分析脏数据对整体效果的影响。三是要考虑核对机制，如何验证数据是正确的。

传统分散式监控主要原因是分散、采集频率不统一，通过运维人员的经验进行风险防控，人充当数据整合分析的工具。基于以上痛点，金融一体化监控主要完成数据汇聚、采集频率统一（时间点）、综合分析研判给出结论，用智能化的分析引擎替代传统的靠人进行综合分析。

金融一体化监控项目的建设重点：

1、采集工具方面：具备精细化采集能力，指标全面、采集频率支持秒级，调整频率便捷（根据不同场景，快速调整整体或部分采集目标的频率）

2、数据汇聚分析能力：这部分工具能力选择难点不大，重点在模型上，监控领域虽然是服务业务、保障业务稳定运行，但不直接产生业务价值，整个行业的沉淀积累相较业务数据分析差距很大，极少数厂商能够具备客户完全满意的数据分析模型（根因分析、健康度评估等），一方面是驱动力不足（企业不愿意投入太多，厂商不好挣钱，投入不足）；另一方面涉及的面太广，技术太复杂。从操作系统、数据库、中间件、服务器、存储、网络、应用程序等，每个方面都要了解的非常细致，才能形成好的根因分析和健康度分析。投入不足、成本高两者比较矛盾，造成雷声大雨点小，落地效果不理想。但对比传统的运维，人的认识进入新的高度，防控风险能力、运营效率还是有很大提升的。