光大银行统一监控平台,定位是服务全行科技条线的 IT 监控系统,是运维之眼。该平台体系比较庞大,本文主要介绍偏向于监控管理和报警管理的相关功能。这部分功能是光大银行根据多年经验自主研发实现的,里面蕴含着监控管理方面的理念和思路,希望本文能给大家带来一些参考和启发。
金融科技是一个炙手可热的话题,通过互联网、大数据、云计算、人工智能、区块连等新技术的应用,支持和引领着业务的快速发展。
这个过程中,业务对银行科技运维和运营工作都带来很大的挑战,主要表现在:
业务对服务的稳定性、可靠性要求越来越高;
业务对 IT 支撑能力的依赖性越来越强;
IT 架构本身的复杂度越来越高。
为提升整体的 IT 运营和运维能力,银行业的数据中心较早引入了 ITIL 管理理念,建立流程管理模式,形成运维管理工作的流程化和标准化模式。
随着云计算、大数据和人工智能的发展,银行在原有 ITIL 基础上引入 DevOps 和 AIOps 理念的相关技术,逐步转向为数据和业务价值驱动,向 IT 运营和数字化运营的目标转型。
从光大银行的角度,科技部运维中心提出了 BCDT 的理念,作为运维相关工作的总体指导思想和理念。从监控系统建设的角度,主要内容是:
底线思维:不漏报、不误报、全覆盖,监控系统自身高可用,安全可靠;
闭环思维:监控能力建设要向开发、测试前移,监控策略的部署、故障处置、定位和后分析,要形成闭环持续优化;
发展思维:是研究和引入新的监控手段和管理方法,适应和满足新的管理要求;
技术思维:强调技术是核心驱动力,通过技术带动监控能力的提升。
光大银行监控体系经过多年建设,历经几个主要阶段,通过分析可以看到主要的趋势是朝着集中化、平台化和数字化的发展方向。
2005 年开始配置独立的监控工具。
2011 年开始进入平台化建设,报警统一。
2014 年开始全面监控,实现应用交易监控,搭建了大数据平台的框架。
2018 年新一代的监控管理平台上线运行,这是光大银行自主研发的平台,在报警管理、标准化和自动化能力上的提升明显。
2019 年科技运营数据平台投产,这个系统通过产学研合作的方式落地 AI 分析处理能力,监控系统向着数字化转型。
在光大银行监控管理系统持续演进的过程中,我们也在思考和总结,哪些是不变的,哪些是频繁变化的。
相对稳定不变的内容包括:
平台职能目标:保障 IT 系统稳定运行,不变。运维中心对监控系统设定的主动发现率这个 KPI 指标,一直没有变;
报警管理的目标:事前预警、事中发现和定位、事后分析,这个工作方法没有变。
监控管理的模型:监控管理作为业务去分析,它包含的监控对象、监控指标、监控策略,这个管理模型没有变。
变化的内容就比较多,比如:
监控对象更复杂;
监控技术和工具日新月异;
监控范围涵盖指标、日志、Tracing 等;
更加认识到数据的价值;
引入很多智能算法;
运维和开发更加紧密合作等等。
回顾和总结这个变化,这对我们监控系统建设有很强的指导作用。不变的点更多是管理相关的能力和要求,这在市场上没有完全满足我们要求的产品,于是我们选择了自主研发,最终形成了监控管理平台。
而对于更多变化的内容,我们的策略是快速引入专业领域的监控工具纳入到光大银行监控体系中使用,对接到管理平台进行统一管理。发展趋势中,大数据平台的作用和价值凸显,我们也以此作为监控乃至 IT 运营的转型的方向,基于开源的产品重点建设和优化。
在重点介绍监控管理平台前,有必要让大家了解光大银行监控体系的总体架构和功能。
光大银行监控系统的定位是面向全行科技部门的 IT 监控系统。从功能层面分为 3 层,分别是监控工具层、平台层和统一展示层。
监控工具层,包含各类开源或者商业的专业领域的监控工具,他们实现对各类监控工具的实时数据采集。比如 Zabbix、Nagios、Prometheus、BPC、Tivoli 等,它们都定位在监控工具层。监控工具会把报警数据、性能数据、日志数据,上送到平台层。
平台层,包含两大部分功能:一是由监控报警处理、监控标准化和自服务等功能模块组成的管理平台;二是基于大数据架构的科技运营数据平台,包括大数据处理、存储、AI 分析以及数据服务接口等子系统。在平台层,还实现了和行内其他运维系统的对接。
统一展示层 ,根据不同用户的角色和场景,提供 PC、大屏和手机端展示。
总的来说,平台层的建设思路是开源 + 自研,这是整个体系的核心;工具层的建设思路是专业 + 敏捷 + 统一管理。
通过多年建设,监控系统的指标覆盖从底层的机房设施到最上层的应用交易,实现了指标全覆盖。借助多种监控工具的部署,对监控指标的实现,一般都具备多种监控手段。
我们内部有个原则:对于关键指标,要有两种工具能够覆盖。这样做有两个好处:一是能够确保监控策略有冗余,二是确保当我们识别出一个新的指标要纳入监控时,我们一定有工具能快速实现监控部署。
交易监控,一直是所有监控系统建设的重点功能。我们通过多种手段,实现端到端的交易全方位监控:
采用了网络旁路抓包、流水表镜像和交易日志分析等多种方式监控交易成功率、响应率、响应时间等指标,实现了对应用无侵入的、实时的监控。
TCP 网络层监控,通过旁路方式对应用的全链路“通讯对”进行监控和分析,能够快速发现网络异常,也能从网络层面对应用故障进行协助定位和分析。
模拟监控,从互联网以及内网探点模拟访问应用系统,主动获取可用性和性能数据,并接入到监控平台进行集中处理和分析。
通过网络抓包和日志 api 的方式进行端到端追踪系统应用间和应用系统内部的交易路径。这个功能目前在部分新架构下的应用系统已经实现,更多传统的应用系统正在改造过程中。
大数据和智能算法是我们现在的工作重心。2019 年,我们的科技运营数据平台完成上线投产,这个平台综合运用了多种算法,实现了指标异常检测、多维检测、批处理异常检测等多种功能。
对银行业而言,最重要的就是联机交易和批量执行,智能监控为传统监控提供了重要的补充手段:
一个场景是交易监控,综合节假日、促销等各种因素实现动态的异常交易检测和告警,可以细化到每一只交易单独进行监控,相比于传统的固定阈值监控能提前 3-5 分钟进行提示。
第二个场景,是对批量任务时长的智能分析,相比于传统的固定批量执行时长的监控,智能分析的结果能够做到提前预警,为夜间故障处置赢得了时间。
在数据展示方面,我们建设了统一视图系统。支持移动端、大屏端、PC 端实时数据展示。根据业务场景,定制了日常运维视图、 应急保障视图和重保运营视图。
按照用户角色的使用需求,对各类视图进行分类,如一线偏重于故障发现、按照预案处置和事后的验证;二线偏重于故障解决以及趋势分析和隐患排查。
对于监控系统的建设,我们的原则是以开源为主,自主可控。
在数据采集层面,我们使用了 zabbix、nagios、prometheus 等常见的开源软件。另外,也有国产的网络流量采集和分析产品。对于存量的国外商业套件,我们已经制定了替换计划,预计会逐步下线。
需要特别提到的是,我们正在实施部署的统一采控 Agent 子系统,采用自研方式建设,目标是能够成为一个采集脚本编写和管理的基础平台,提供通用的 Agent 驱动能力,独立实现服务器上所有数据的实时采集,成为大数据平台最稳定可靠的数据来源。
在数据处理、数据存储、前端展示以及开发部署各个层面,也就是平台层的产品则基本都是开源的产品和技术。
上面是对光大银行监控系统整体的功能和架构进行了简要介绍。
前面介绍了光大银行总体监控体系,接下来介绍一下监控体系中的监控管理子系统。
这是监控管理平台的总体功能架构图:
主要是两大部分,第一个是左半部分,从下到上包括报警采集、预处理和处理,构成了报警处理引擎子系统,其中还包括报警通知和维护期管理的功能。
第二是右半部分从上到下,监控标准化管理子系统,包含监控对象、策略、指标和规则等标准化管理功能,以及监控配置自动化、监控评价等功能。
通俗的说,左面部分解决的是报警来了怎么处理的问题, 右面部分解决的是报警如何配置,怎么产生的问题。
下面分别介绍一下报警处理引擎和监控标准化管理两大部分功能。报警处理引擎,是光大银行自主研发实现的核心组件,所以这个部分是本次分享的重点内容。
首先,我们先来分析报警管理的技术和业务特点:
在事件采集层 ,数据源丰富、报文格式多种多样,并且期望的采集延迟在毫秒级;
在报警处理层,特点包括报警量大、可能存在报警风暴、报警之间相关性高、处理逻辑复杂,要考虑扩展性并且还要合理继承原有的规则,处理延迟要求在秒级完成;
在展示和处置层,要求的是展现形式多种多样,前端页面能够高频刷新或主动的接收服务器推送的报警,保证时效性。
基于上述报警管理的特点,我们制定了报警处理引擎的选型和开发的目标:
事件采集和处理要解耦,这样能够保证采集器的采集时效性。
事件处理集中化,规则、外部对象资源都要加载,通过集中处理可以更加充分的利用资源,一次加载重复使用。
事件处理分布式,处理集中之后就要有分布式处理可水平扩展的能力。
分布式内存数据库,针对报警反复读写数据库的情况,这是从性能角度考虑。
对 SQL 的支持好,数据库的访问就能非常灵活和简洁,监控报警规则就更容易实现。
去商业化,自主构建。基于开源软件构建,能够最大程度满足管理要求。
上述几点是我们最初选择报警处理引擎的一些考量或者是目标。这和我们之前用的产品也有一定关系,我们之前采用的是 IBM Omnibus 产品,到现在也有很多金融机构在使用该产品,它是一个基于内存的支持 SQL 的报警处理引擎,它的最大问题就是单节点、单进程运行,所以对于大数据量的处理存在瓶颈。
所以,我们开发的新报警引擎一方面要解决处理能力的瓶颈,另一方面要能够完全兼容原平台的处理逻辑和规则。这是我们在技术选型前的另外一个约束。
在产品选型的过程中,我们主要考虑的是两部分,一是数据库,二是分布式开发的框架。
在数据库选型中,我们选择了 Apache Ignite 作为分布式数据库。和其他数据库的对比,比如 Oracle、MySQL、Eedis、Geode、ES,主要考量几个特征是内存关系数据库、支持 SQL、支持持久化等。
第二个选型,是分布式开发框架,因为框架主要用于引擎内各个组件的高性能交互,所以我们选择了 Dubbo 框架,相对更轻量和小巧。
关于 Apache Ignite,是基于 Java 语言开发的,可以用作一个分布式的缓存,也是一个分布式内存数据库,能作为关系数据库使用。它的数据储存在堆外内存的,不受 GC 影响,性能更好。作为内存数据库,它还能将数据持久化到磁盘,保证数据不丢失。另外一些特点,比如支持事务、可配置为 CP 或者 AP 使用,支持 SQL 函数扩展以及内置消息订阅发布模型。
作为报警引擎来讲,我们更加关注分布式缓存、分布式数据库、和持久化。
下面是报警处理引擎的功能架构图,包括接入层、处理层、APP 管理层、数据管理层和接口层。
其中的重点是处理层,分为两大类的处理功能,下层是报警流处理,上层是报警的批处理。这些处理功能模块是动态加载和可扩展的,是在 App 管理层采用应用商店的模式,进行发布和编排的 App。在我们的报警引擎中,将每个处理功能都作为一个 App 来管理。通过这样的灵活管理和部署的架构,满足报警处理的各种需求。
从技术产品框架的视角看,最下层是自主开发的事件采集器使用了 spring boot + akka。应用层采用 Dubbo 的分布式处理集群,集群内运行多个事件处理节点,事件处理节点使用的技术包括:ANTLR 语法分析、java 动态编译 tools 以及 Java RMI。使用 zookeeper 作为服务发布和订阅的管理,ignite 是报警存储库。最上层是报警视图的前后端服务。
一个事件处理节点内部的逻辑架构和数据的流向图如下:
主要内容包括:
数据处理流程是报警从采集器来,送到流处理模块后通过 ignite 客户端节点入库。批处理模块负责把报警取出来进行二次分析,增删改的动作还会送到流处理模块进行处理后入库。
在 ignite 库中分为实时库和历史库,保存所有的报警信息。引擎通过报警跟踪的模块,把所有的报警变化记录同步到 kafka,供第三方消费。批处理分配模块则实现了批任务的分布式处理调度的工作。
控制台提供用户交互接口,管理流处理和批处理中运行的处理功能 App。节点间管理信息的同步则通过 RMI 通讯模块完成。
报警处理功能,是处理引擎的核心功能。什么是处理功能?比如一个报警发生了,要不要进维护期,那这就是一个报警处理功能。那维护期的判断,一定是在报警通知之前执行。那这就是功能间的编排。
我们的报警处理引擎,是以应用商店 App 的模式对报警处理功能进行封装和管理编排,定义了多种 App 类型,支持处理功能的定制开发。也就是说报警功能可以不断的扩充的。
App 的类型,包括:
最普通的流 App 和批量 App;
广播型的 App 本质是为分布式批量;
订阅型批量是和上述类型 App 组合使用的,用于数据的汇总和再处理;
Restful App 可以动态的生成访问 App 内部数据的接口,可以对 App 运行情况进行监控。
在光大银行报警处理引擎正在运行的处理功能,包括一些基本的处理功能,比如报警丰富、报警压缩 、恢复关联、自动升降级、维护期等。在智能化报警方面,主要的处理功能用于报警的根因和影响分析,实现了根因升级和受影响报警的自动降级,场景包括如服务器宕机、应用服务拥堵、DWDM 中断等异常场景。我们正在做的优化工作,包括基于算法的报警和基于 cmdb 规则的排障树等功能。
总结一下报警处理引擎的特性:
特性包括:分布式处理、高可用;完全兼容之前 IBM omnibus 的处理规则,可以平滑过渡;支持 App 热部署热插拔;App 可编排、调度和协作;扩展性强,支持自定义 App 开发和部署以及 SQL 函数扩展;高并发、高性能;支持告警链路追踪和处理性能统计;支持全备 + 增量的备份方式;支持多数据中心主备模式部署。
前面讲了监控管理平台的报警引擎,下面再来分享标准化管理的内容。
在前面介绍监控系统演进过程时,我们讲到过,监控管理的模型到目前为止还是依然适用的:
其中涉及监控对象、监控工具、监控策略、监控指标 ,比较核心的几个概念和关系:
监控指标 是针对每一类对象要监控什么,是对象的一组动态属性,比如 CPU 使用率就是一个指标;
监控策略是如何进行度量指标,比如 CPU 使用率大于 80%,持续 3 分钟,报一个警告 ;
关系是:监控对象关联了监控指标,监控策略实现了监控指标,并且在特定的监控工具上运行,完成对监控对象的监控 ;
监控标准 ,就是哪些对象用哪些策略覆盖哪些指标。把这些规则汇总和发布出来,就是我们企业级的监控标准。
在实际运行中,监控对象、指标、策略和工具自身的内容,都在发生变化,比如我们引入了交易量动态基线的监控,实际上就是用一种新的工具和策略,去检查我们原有的监控对象和指标。
在光大银行监控系统实现时的一些要点总结如下:
在监控对象管理的方面 ,支持对象全覆盖、对象类别和属性扩充、对象关联关系管理。录入对象时,物理的属性是系统自动发现和采集;管理属性优先是从外部的 cmdb 进行同步。支持批量导入。这部分的管理功能可以套用 cmdb 的管理。
指标方面,需要支持虚拟指标和工具指标的定义和关联。
策略方面 ,要支持通用的公式编辑器,利用指标生成策略。对于一些单向支持的工具,支持策略从工具进行抽取。
前面标准化模型的内容都准备好之后,就具备了监控自动化和自服务部署策略的前提。
自动化分为两个层次:
自动化,就是监控的实施人员进行的自动化部署;
自服务,这个是面向专业团队运维人员的操作。自服务是自动化的更高阶的阶段,需要系统提供面向业务场景的、更加易用的交互界面。
实现过程中的技术要点,就是通过监控工具驱动程序的开发,实现平台对底层监控工具的变更操作,而且能够屏蔽工具的差异性,快速接入各类工具。根据工具接口的完备度,有全驱动和半驱动之分,全驱动就是所有的操作都能在平台层完成,半驱动就是常见的标准化策略部署,在平台完成,一些特殊策略部署还需要到工具手工完成。
正是有了驱动能力的不同,所以对于半驱动来说,我们还需要一个策略采集器,确保管理平台有完整的工具策略。
对于监控自服务管理的执行,那我们有一个原则:专业团队的管理员的自助式的配置,是在监控标准下的自服务。
典型场景是操作人员录入设备信息,自动发现或者同步资源的信息,然后补充必要的对象信息,预览自动匹配到的监控策略,进行确认后,下发生效。
在这个流程中,策略的匹配和绑定是基于监控规则的,监控规则是企业级定义和发布的监控标准,所以大家在进行自服务的时候,还是要以规则为准。
对于个性化策略的部署,技术上是可以支持的。目前在我们的实际使用中是要走 ITSM 流程审批过后,由监控管理员去执行非标策略或个性化策略部署的。而且这种非标的策略部署过后,我们是有评价机制来跟踪的。
监控评价模块,用于事后量化评价每个应用系统的监控情况。
评价主要是 3 个指标,监控覆盖率、监控标准化率、超额布控率,这三个指标在设计的时候,从管理上要求是逐级升高的:
监控覆盖率 ,是说需要有监控,这是最基本的要求。计算公式是基于监控指标进行的。
监控标准化率 ,是说除了有监控,还应该按照行里的标准策略进行监控,比如标准的阈值是 90%,如果某个服务器需要改为 80% 的阈值,那这就是不遵从标准了。所以监控标准化率指标是基于监控策略进行计算的。
超额布控率,就是说前面的标准动作都做完了,如果管理员责任心强,又提了额外的监控策略,那就是超额布控率,也是基于指标计算的。
通过这样三个指标,可以对我们的应用系统的监控完备度进行一个量化的评价和排名。有了这个排名后,那我们的管理机制就能够发挥作用了。
监控评价的目标是以评促改。基于评价的结果,我们或者进一步去完善监控标准,或者对于一些非标的特例就要促进相应的应用系统进行整改,进一步符合监控的规范。这样一个持续改进的闭环就形成了。
管理平台还有一个比较重要的功能,维护期管理。这和报警管理以及标准化管理都有一些关系。这个是个常用的功能,技术上并不复杂,但也非常容易出问题。它直接影响了报警的有效性,管理的不好很容易出现漏报警或者误报警。
关于维护期使用,我们在多年的监控运行中,吃了一些亏得到一些教训,这会促进我们不断优化相关的功能。以下经验和大家分享:
维护期最多设置 30 天,单次超过 24 小时,就要进行二次确认,避免出现误操作。
非周期的维护期内发生的高级别报警,也要通知到管理员,避免把维护期报警和故障报警进行混淆。
出维护期前,管理员要去检查维护期内报警的状态,避免出现误报警。
出维护期后,如果报警还没有恢复,那就要重新进入处置流程,避免遗漏报警。
此外,我们还定期导出报表,进行维护期的重检,确认维护期的有效性。
作为监控管理平台,如何对我们整个监控体系的运行效果进行评价,最直接的指标,是发现率和有效率。
目前运维中心设定的 KPI 指标是监控发现率,就是监控系统发现的故障占总体故障的百分比。我们的监控主动发现率基本能保持在 98% 以上,对于监控未主动发现的故障,有相当大比例会引起业务影响,这也从侧面也证明了监控的重要性。
前面讲的偏向于工具功能以及技术实现,在这我还想强调一下体系的作用,体系包括人员的参与和管理流程:
人员各司其职很重要,一线人员、二线人员、专家、运维质量管理人员、监控管理的人员还有监控系统建设的人员,都参与到系统运行中,而且通过二线应用管理人员,开发项目组的人员也间接参与到整个监控体系运转中,尽职尽责。
我们做了很多基础的管理工作和数据分析工作,通过监控报表、事件报表,每天、每周、每月、每年的事件会,对报警相关的事件进行分析,持续的反馈和优化监控标准、补充策略。过去 10 年间,运维中心的领导能够亲身参与到这些工作中。坚持,所以才能让我们的监控系统持续优化。
对于有效率指标,从真实有效的角度去度量,那我行监控系统误报很少,都能如实反应生产的情况。如果站在一个更高的要求去理解这个指标,有效率表示的是事件的数量和报警的比值,提升有效率能够减少无效报警的干扰,提升故障处置的效率。我们目前正在做的优化是基于规则和场景,按照报警的根因和业务影响的分析,这两个视角进行报警的合并和关联,减少孤立报警的数量,提升报警的有效率。
最后我们对监控系统的未来发展,做个展望。总体的方向,我们认为是向数字化运营的转变。
目标是提升对数字化运行态的洞察力和智能分析能力。这里面有 4 个方面:
数字化的思维的建立和数字化的监控转型。
基于这些大数据,进一步丰富完善算法,推广智能算法的应用场景。
监控管理和服务的融合,在强化监控标准化管理的基础上,还要更加快速的纳管新的技术工具,提升自服务的应用范围和场景。
监控云和云监控。监控云是以云原生方式构建监控系统,提升弹性和敏捷的能力,加强工具整合;云监控则是提升容器、k8s、分布式应用的监控能力,通过监控 API 的部署和使用,把运维和开发部门进行打通,提升云应用自身的主动监控能力。
作者介绍:
胖亚鹏,光大银行科技部系统架构师、技术专家,具有十余年监控系统建设的项目实施经验。目前主要负责光大银行统一监控管理平台的总体架构规划和栏目内部研发管理等工作。对监控系统的管理模型优化、监控服务化的实现以及分布式监控等领域有较深入的研究和理解。对于将 AI 技术运用到监控领域有浓厚兴趣。
点个在看少个 bug 👇