银行一体化监控平台建设十大典型问题解读 | 最佳实践

银行一体化监控平台建设十大典型问题解读 | 最佳实践

原创 twt社区 twt企业IT社区

日前，社区针对相关难点组织了在线交流，参与的同行们互相探讨问题，分享经验。以下是参与活动的专家据此整理的银行一体化监控平台建设十个典型问题，供更多读者参考。

整理者：邓毓 某农信社资深骨干工程师；还有以下专家会员分享：he7yong  Canway 研发工程师、jension 某农信 系统工程师、zftang0809 合肥华宇随身软件 软件开发工程师 等

从需求角度分析原因：

从技术发展上，目前很多银行目前已经上了新核心，用到了云，容器，微服务等新技术。从业务要求上，业务对稳定性要求越来越高，要求故障出现后更加及时的恢复，避免带来业务的损失。一方面，目前无论是大型、中型还是小型银行都有统一监控平台的需求，不仅仅因为事件需要集中，为实现业务系统端到端的监控，必然需要多样的监控手段和技术去支撑，带来监控源的多样化，必然也需要统一的运维数据分析平台去揉合这些监控数据，辅助运维人员定位根因，甚至结合历史处理方式，直接定位故障根因和处理方法。另一方面，统一监控平台是应用稳定运行保障的基石（参考谷歌SRE）,一体化的监控平台解决应用、业务、用户视角的监控，帮助用户实现根因分析，根因定位，容量预测等等。是企业数字化转型的必备工具。

从技术角度分析原因：

监控方式、技术和类型过多，需要一个统一的事件平台来集中丰富、处理和分析不同监控源的告警事件；还需要一个统一的数据接入平台（运维大数据）来对不同监控源性能数据、日志和告警数据进行整合、分析、统计，借助AI的能力，智能辅助运维快速定位和根因分析；倘若银行企业端到端的监控源都比较完善（BPM、NPM、基础监控、APM、TPM等），可以进一步结合IT架构可视化系统，深化统一监控平台项目建设，通过将IT架构与多类数据源结合的方式，让架构图更加生动，运维人员在统一的可视化架构下，更为精准的定位故障。没有做到集中、统一监控、统一分析，那么各个系统是一套套毫无关联散沙，告警风暴来临时，多个告警平台同时告警，事件丰富的方式、联系人员也不同，运维人员像没头苍蝇，不仅无法快速判断故障根源，还可能会因多套监控平台的告警事件扰乱故障定位。

第二张图是网络性能管理（NPM）、运维大数据平台及与现有的基础监控和集中事件平台联动的整体功能逻辑架构图。网络流量报文通过TAP设备发送至NPM服务器和BPC服务器的采集口；NPM系统和BPC系统实时解码模块，对网络原始比特流进行解析，输出网络层指标和业务应用层指标；业务层和网络层 数据分析模块实时分析性能指标：交易量、成功率、交易渠道、交易类型、金额、TCP连接状态、丢包状态、网络时延……等等指标；前台展示模块从运维角度，可以实时的展示每一个节点的业务层和网络层指标情况，并配置实时告警，做到快速发现、快速定位、快速恢复；前台展示模块从业务运营角度，可以对全行交易情况进行实时大屏展示，对业务 交易渠道、交易机构、 交易金额、交易量 、 自定义的统计维度 等进行实时分类统计分析；业务性能监控系统对外的接口包括数据输出接口、交易明细输出、告警接口：数据输出接口可将业务监控系统统计的交易性能数据和交易明细数据按JSON、CSV、xml等方式实时输出，提供给第三方系统。或者第三方系统可以通过RestfulAPI的方式来查询所产生的统计数据、告警数据、明细报文数据等。告警信息可通过syslog、socket等方式发送到第三方事件管理平台进行集成，统一进行汇总处理。本次实时解析的各系统性能数据，业务交易字段等实时推送给运维大数据平台，为实时运维大数据分析提供真实可信的数据源；业务交易及网络性能监控产生的告警事件，实时推送到现有集中事件平台 ；运维大数据平台产生的告警事件，实时推送到现有集中事件平台；运维大数据平台可根据故障发生时间点，复原系统的性能、日志、网络报文等信息，辅助故障分析和快速解决 ；在集中了性能、配置、日志、事件等运维数据的基础上， 以运维大数据平台为核心， 开展智能运维在监控方面的建设，如单、多指标预测和分析、建议，告警事件自动关联知识库，指导运维人员快速解决问题，结合多类监控数据，进行可能的根因分析，辅助运维人员快速定位故障源，并在告警日志上下文历史挖掘分析、同类告警周期性规律分析、告警成对成组出现分析、告警相关与因果分析等等方面，进行智能分析，推进运维工作自动化和智能化 ；在各数据源数据统一接入运维大数据平台后，可为不同的用户的行为进行画像，供以后的精准营销或者风控项目消费，进一步指导业务的运营和管理等。

第三张图是运维大数据平台的整体架构图， 自下而上，最下面一层是数据源层，提供各种运维数据库包括结构化数据如关系型数据库以及非结构化数据例如各种系统日志，这些数据可以通过代理采集方式获取；另外一部分数据来源是现有系统，例如监控平台、网管、APM等工具，这些平台本身已经提供了各自该平台的事件或者性能数据，可以通过API的方式进行数据采集或者推送；数据源之上是运维管理总线，运维管理总线提供数据的接入、缓存、预处理，以及各个系统之间的消息传递、API调用。这一层通过搭建异步消息总线例如kafka集群来实现消息交互；第三层是数据处理层，包括两个方面，首先是大数据平台，大数据平台提供的是数据流式解析（例如数据加工、实时告警），数据计算以及存储能力；另外一部分是智能算法层，主要提供、训练各种智能算法模型；数据处理层之上是接口层，接口层是为了根据不同的智能化运维场景提供接口调用，包括服务总线，主要提供API的注册、接口网关、状态、调用的管理，数据网关主要提供数据的查询，数据网关等功能；采用的架构为微服务架构和总线架构：微服务架构可以将运维子系统的所有功能、操作、指令全部转变为原子操作，接受AIOPS的总体调度。运维总线架构可以将各类系统的相互通讯模式由网状变为星型，降低关联耦合度，提高通讯的速度、稳定性、可用性、可扩展性，使得大数据通讯不再成为瓶颈；最上面一层是AIOps场景层，该层次是通过调用API层提供的各种能力来实现智能化场景。场景层的设置是根据事件的生命周期进行设置的，例如在发现问题阶段通过自动基线、通过日志分类来判断异常，发现问题；到通过关联分析、日志深度检查、应用全链路监控等来分析问题；通过匹配知识库，调用运维调度平台来定位问题；最后通过智能预测来预测容量、故障的发生。另外提供了为领导层提供辅助决策的功能，例如系统画像、用户工单、请求分析等。