商业银行一体化监控探索与实践

本文作者：许中华、陈峰

前言

商业银行为了确保系统安全运行，针对各类设备、业务系统构建了各种监控，有网络监控、应用监控、业务监控、操作系统监控、基础设施监控、主机存储 监控、 硬件监控、数据库和中间件监控 、 虚拟化监控 、 云管平台监控 、容器云监控、安全监控 等等，然而各个厂商、不同类别的监控系统就像一座座孤岛占满了监控大屏，有些复杂的故障问题或性能问题的定位就变的尤其复杂，影响了问题的快速定位和故障处置。因此，如何构建一个一体化监控 系统 ，让运维人员掌控系统的整体运行情况和运行效能 ，能高效、快速、精准的进行故障定位诊断 ， 是商业银行保证系统安全、稳定运行急需解决 的问题。

背景和挑战

目前商业银行运维监控现状及挑战大致如下：

1） 现有监控系统建设多按领域或者功能划分，不同厂商直接在信息格式、系统架构等方面存在较多差异，这为商业银行实现监控标准的统一、工具的一致带来了很大的障碍，使得运维资源浪费，管理效率偏低。 目前银行监控领域的分类和主要技术路线如下 ：

2） 监控方式、 监控 类型 较 多，没有做到统一监控、统一分析， 当 告警风暴来临时多个告警平台同时告警，运维人员不仅无法快速判断故障根源，还可能会因多套监控平台的告警事件扰乱故障定位 ， 因此在定位故障过程中，由于缺少相关的样本数据，只能依赖领域专家经验来模糊判断，无法采用告警相关性分析等方法对故障根源进行科学准确的定位。

3 ） 在应用架构层面，伴随着虚拟化、云计算技术的应用，私有云架构成为了主流 ， 伴随着业务的发展，IT系统在不断扩展，不仅对外应用数量不断增长，内部应用和连接的第三方服务数量也在不断扩充，同时应用间相互调用关系持续复杂化。业务 部门以及监管部门 对稳定性要求越来越高，要求故障出现后更加及时的恢复，避免带来业务的损失 、降低客户满意度 。 一体化 监控平台 不仅是 实现业务系统端到端的监控 的需要 ， 同时 一体化监控平台 也是 解决应用、业务、用户视角的监控 的需要 ，帮助用户实现 故障 定位，容量预测等等 , 是企业数字化转型的必备工具 。

整合思路

一体化监控系统建设的基本思路是搭建集中监控平台，实现集中事件管理、集中性能管理、集中展现、配置管理、台账管理、告警管理、维护期管理，实现集中监控；跟CMDB集成，梳理各种业务系统交易场景，建立端到端业务资源模型实现可视化监控，同时对日常监控、故障定位、变更影响分析提供帮助；后续将搭建监控大数据平台实现告警数据、配置数据、工单数据、性能数据、日志数据收集和汇总，为日后的实现AIops做准备。

一、搭建集中监控平台

集中监控逻辑架构

一体化监控逻辑架构如上图所示

一体化监控管理系统是运维管理最基础的核心平台。通过收集各专业监控工具采集的应用、数据库、中间件、服务器、存储、网络、动力环境等数据，进行统一的管理和实时的关联分析，能够快速有效的定位故障的告警根源，提高故障诊断的效率，从而构建不同层级、不同部门间协同解决问题的平台，成为应对突发事件、支持领导决策的一种重要手段。通过对各类监控数据的分类和标准处理，在一个平台上课对所有数据进行有效管理和综合呈现，实现了运维管理可视化、可量化和自动化，有效实现ITIL最佳实践落地过程中的重要步骤。

监控对象层是被管对象的集合，是系统平台所有管理的IT基础架构，如基础设备、动力环境、主机系统、数据库、中间件、网络、存储、应用等，涵盖一切与IT相关的管理对象。

采集层通过多种技术手段实现IT基础架构对象的各种管理数据的采集，如事件（故障）、性能（容量）、配置（运营）、策略（人工录入的运维资料），为管理平台提供必要的、标准化的数据。

功能层提供各种管理书籍的处理逻辑和策略。部署在这一层的系统还提供对其他系统的集成访问的接口平台。对外接口平台是与其他系统（ITIL、CMDB）数据共享的对立自治平台，是系统平台接口标准化的统一，从功能上使得整个平台信息与外部系统信息形成联邦制数据体系。

实现功能

1、集中事件管理：通过主动或者被动方式采集被管对象的各类事件信息，根据预定的规则和策略，自动识别、记录和分析故障事件信息，准确定位故障，并以企业微信、邮件、声光方式通知。主要功能包括过滤和压缩，事件关联分析和根源分析，事件信息再丰富和事件的自动通知。

2、集中性能管理包括实时监控和预估监控，实时监控是对信息系统当前的性能指标运行状态进行监控；预估监控是对信息系统在未来某段时期内的性能指标可能的运行情况进行预测分析。

3、告警管理包括告警行为配置、告警规则配置以及告警查询，告警行为配置，通过告警模板实现对告警行为配置管理，告警模板是封装了告警规则、告警级别、告警时间间隔等告警信息的标准模板；告警查询：可以宏观的对被管对象进行总体监控，也可以查看详细的事件信息，并可配合各种复杂工具丰富事件的处置手段，如发送短信、企业微信、邮件通知以及与ITIL流程对接事件的确认、升级、转发、关闭、查询等，从而更方便的进行分析和诊断；告警规则设置：针对不同的应用场景对模板进行相应的告警阈值、级别的调整。

4、维护期管理包维护期规则的增加、删除、修改、查询等功能，维护期规则的设置可根据事件类型、事件源、系统（或者某些IP）、相关设备、时间段进行条件设置。

5、监控配置管理包括监控对象管理、监控指标管理、监控策略管理。监控对象管理：增加、删除、修改、查询，支持批量导入、导出；监控指标管理：增加、删除、修改、查询，支持批量导如、导出；监控策略管理：监控事件告警相关的信息，如事件定义、事件级别、事件类型、告警规则等信息进行配置管理，支持增加、删除、修改、查询功能；人员的管理：增加、删除、修改、查询，状态包括离职、入职，支持批量导入、导出。

二、实现可视化监控

可视化监控 使用业界流行的数据可视化技术 ， 以实时动态的数据为核心 ， 结合KPI指标分析功能 ，从不同层次的使用者角度出发，形象化，直观化、具体化第展示各自所关注的关联对象和相应的指标的宏观和微观运行状态，并支持“钻取式查询”（上钻和下钻），实现对指标的逐层细化、深入分析，从而将运维管理的提升到一个新的高度。

需求分析

在统一的网络架构、业务逻辑架构、应用部署架构下， 需要 展示所有的运维数据， 包括 基础监控数据、业务性能数据 （如天旦BPC）、应用性能数据 、网络性能数据（NPM）、APP终端性能数据（TPM） 、H5页面性能监控、业务拨测性能数据 ，整个统一架构下的，不同数据源的整合让运维人员可视化的 快速 发现可能的根因。利用“IT架构图”与数据相互结合的方式， 构建 业务系统所在的网络架构 图 ，结合NPM的数据和流程数据，网络架构中的节点，可以关联CMDB的数据和NPM性能数据和告警数据等； 构建 业务系统的业务逻辑架构 图 ， 理顺 该业务系统和其他系统的关联关系，关联业务性能指标和流程数据，清晰的知道该业务系统的健康状 如吞吐率、 业务成功率和系统响应率， 以及 告警 事件以及生产变更 ； 构建 业务系统部署架构图， 展现业务系统所依赖 的各 种 组件，比如WEB、中间件、数据库、负载 均衡 、 服务器、存储、光纤交换机 等，关联的数据是基础性能数据和流程等。

实现思路

1、建立端到端业务资源模型，采用垂直分层的建模思路，按照业务资源对象在业务实现中的角色不同，把资源分为直接的业务资源、承载系统、组件三个层次，承载系统在端到端流程中是提供直接服务的依托环境，而组件是以一种透明的方式展示业务完成所经过的处理环节，承载系统和组件层为业务服务提供直接的功能支撑。提现在数据层面上，各层级都为提炼出较为核心的监控指标并基于一定规则的计算方法进行的整合。

2、端到端业务资源的模型设计，根据建模思路可以将端到端业务资源从对象分析、对象见关系定义和对象属性定义三个维度进行模型设计。首先将对象进行层次化分解，即将某一端到端的所有业务资源 按照 业务层、业务承载层和网元曾进行对象分解。其次， 定义对象间的关系，包括包含、继承和关联关系，最后通过 定义对象属性来描述对象的基本和特征信息，通常对象属性可分为资产类、配置类和业务类属性 。资产类通常为静态信息 ，配置类属性是业务、资源的 可配置信息 ，业务类属性是反映对象运行状态的 信息，如 核心系统的 交易量 、响应时间 、响应率、交易成功率 等。

3、实现基于关联分析的故障定位，关联分析模型主要是在告警数据模型、故障数据模型以及端到端业务资源模型三部分模型的基础上，利用三个模型的数据，实现定位故障信息、告警信息上下钻取以及告警相关性分析。

实现功能

1、 日常监控

提供一线值班视图，直观展现 业务系统 健康状况 、；二线运维人员接到异常告警后， 只需打开一体化 监控平台进行故障判断和问题定位， 无需频繁 登陆和 切换其他监控系统 。

2、 故障定位

在日常IT运维工作中，有时会面对一些较复杂的故障定位场景，比如大量系统几乎同时涌现高级别告警，这些系统之间依托于各类网络，存在着支撑和依赖关系，而每个系统本身也被复杂的系统架构所承载。这种情况下，如何在有限的时间内定位故障并快速恢复业务，是运维人员面临的低频但高风险的疑难问题。而通过 IT架构可视化 ，我们可以先通过对应用墙的整体查看，分析各系统告警的分布情况，之后依照经验初步判断交易关键节点，点击钻取进入应用关系全景图。

3、 变更影响分析

日常的变更管理工作中，分析变更影响，进行变更过程评审是变更管理工作的重点。就变更影响分析而言，如果CMDB数据中的关系数据不够完善，影响范围的确认就变得异常艰辛，需要投入更多的经验判断、多方沟通以及大量思考。依托于可视化 监控 平台，变更影响分析的工作得到了系统化改善。

展望未来

一、搭建监控大数据平台

运维大数据平台架构如上图所示, 最下面一层是数据源层，提供各种运维数据库包括结构化数据如关系型数据库以及非结构化数据例如各种系统日志，这些数据可以通过代理采集方式 、syslog 获取；另外一部分数据来源是现有系统，例如zabbix、网管、APM 、交易监控、业务拨测系统 等工具，这些平台 有的 本身已经提供了各自该平台的事件或者性能数据，可以通过API的方式进行数据采集或者推送；数据源之上是据的接入、缓存、预处理，以及各个系统之间的消息传递。这一层通过搭建异步消息总线例如kafka集群来实现消息交互；第三层是数据 加工 层，数据流式 处理 （例如数据加工、实时告警 、CEP ）， 离线数据分析、数据挖掘。

二、积极探索AIOPS

在监控大数据平台的基础可以探索AIOPS， 帮助实现人工难以实现的海量运维工作 ，以帮助商业银行降本增效体质的目标、助力银行数字化转型。

AIOPS关键技术

根据Gartner的定义，AIOps产品或平台应包含以下要素：

1）数据源：大量并且种类繁多的IT基础设施

2）大数据平台：用于处理历史数据和实时数据

3）计算与分析 ：通过 已有的 IT数据产生新的 数据 ，例如数据清洗、去噪音等

4)算法 ：用于 计算和分析 ，以产生IT运维场景 所需要的结果

5）机器学习：这里一般 指无监督学习，可以根据基于算法的 分析 结果 产生新的算法

AIOPS场景：

AIOPS围绕质量保障、成本管理和效率提升的基本运维场景，逐步构建智能化运维场景。在质量保障方面，保障现网稳定运行细分为异常检测、故障诊断、故障预测、故障自愈等基本场景。在成本管理方面，细分为指标监控，异常检测，资源优化，容量规划，性能优化等基本场景；在效率方面，分为智能预测，智能变更，智能问答，智能决策基本场景。AIOPS的建设是一个长期而艰巨的工作，可以规划几个阶段进行尝试：

第一阶段实现以下目标

效率提升方面：智能变更、智能问答、智能决策、智能预测

质量保障方面：动态基线、指标监控、磁盘异常、网络异常检测等

成本管理方面：资源优化、容量规划，性能优化。

第二阶段实现以下目标

效率提升方面:AI已经将单点应用中的一些模块串联起来,可以结合多个情况进行下一步的分析和操作

质量保障方面:多维下钻分析寻找故障根因。

成本管理方面:可以将成本、资源、容量、性能的实际状况进行下一步的分析和操作。

第三阶段实现以下目标

效率提升方面：基于实际场景实现性能优化，然后进行预测，变更、决策等

质量保障方面：基于故障的实际场景实现故障定位，然后进行故障自愈，

成本管理方面：实现基于成本的自主优化，然后进行智能改进的操作。

最终目标如下：

效率提升方面：人工参与的成分已经很少，性能优化等整个流程由智能大脑统一控制，并由自动化和智能化自主实施

质量保障方面：人工参与的部分很少，从故障发现到诊断到自愈整个流程年由智能大脑统一控制，并由自动化和智能化自主实施。

成本管理方面：人工参与很少，从成本报表方向，资源优化，容量优化等整个流程由智能大脑统一控制，由自动化和智能化自主实施。