本文根据胖亚鹏老师在〖deeplus直播第期〗线上分享演讲内容整理而成。（文末有获取本期PPT回放的途径，不要错过）
胖亚鹏
光大银行科技部系统架构师
光大银行科技部系统架构师、技术专家，具有十余年监控系统建设的项目实施经验。目前主要负责光大银行统一监控管理平台的总体架构规划和栏目内部研发管理等工作。
对监控系统的管理模型优化、监控服务化的实现以及分布式监控等领域有较深入的研究和理解。对于将AI技术运用到监控领域有浓厚兴趣。
大家好，我今天分享的主题是光大银行统一监控平台建设实践。
光大银行统一监控平台，定位是服务全行科技条线的IT监控系统，是运维之眼。该平台体系比较庞大，今天主要介绍偏向于监控管理和报警管理的相关功能。这部分功能是我行根据多年的经验自主研发实现的，里面蕴含着监控管理方面的理念和思路，希望此次分享能给大家带来一些参考和启发。
一、监控系统发展现状分析
1、发展背景金融科技是一个炙手可热的话题，通过互联网、大数据、云计算、人工智能、区块连等新技术的应用，支持和引领着业务的快速发展。
这个过程中，对银行科技运维和运营都带来了很大的挑战，主要表现在：
业务对服务的稳定性、可靠性要求越来越高；
业务对IT支撑能力的依赖性越来越强；
IT架构本身的复杂度越来越高。
为了提升整体的IT运营和运维能力，银行业的数据中心较早引入了ITIL管理理念，建立流程管理的模式，形成运维管理工作的流程化和标准化模式。
随着云计算、大数据和人工智能的发展，在原有的ITIL的基础上引入了DevOps和AIOps理念的相关技术，逐步转向为数据和业务价值驱动，向着IT运营和数字化运营的目标转型。
从我们光大银行的角度，科技部运维中心提出了BCDT的理念，作为运维相关工作的总体指导思想和理念。从监控系统建设的角度，主要的内容就是：
底线思维：不漏报、不误报、全覆盖，监控系统自身高可用，安全可靠；
闭环思维：监控能力建设要向开发、测试前移，监控策略的部署、故障处置、定位和后分析，要形成闭环持续优化；
发展思维:是研究和引入新的监控手段和管理方法，适应和满足新的管理要求；
技术思维：强调技术是核心驱动力，通过技术带动监控能力的提升。
2、建设历程光大银行监控体系经过了多年的建设，历经了几个主要阶段，通过分析可以看到主要的趋势是朝着集中化、平台化和数字化的发展方向。
1）年开始配置独立的监控工具。
2）年开始进入平台化建设，报警统一。
3）年开始全面监控，实现应用交易监控，搭建了大数据平台的框架。
4）年新一代的监控管理平台上线运行，这是我行自主研发的平台，在报警管理、标准化和自动化能力上的提升明显。
5）年科技运营数据平台投产，这个系统通过产学研合作的方式落地AI分析处理能力，监控系统向着数字化转型。
3、思考总结在我行监控管理系统持续演进的过程中，我们也在思考和总结，哪些是不变的，哪些是频繁变化的。
相对稳定不变的内容包括：
平台职能目标：保障IT系统稳定运行，不变。运维中心对监控系统设定的主动发现率这个KPI指标，一直没有变；
报警管理的目标：事前预警、事中发现和定位、事后分析，这个工作方法没有变。
监控管理的模型：监控管理作为业务去分析，它包含的监控对象、监控指标、监控策略，这个管理模型没有变。
变化的内容就比较多了，比如：
监控对象更复杂；
监控技术和工具日新月异；
监控范围涵盖指标、日志、Tracing等；
更加认识到数据的价值；
引入很多智能算法；
运维和开发更加紧密合作等等。
我们回顾和总结这个变化，对我们监控系统建设有很强的指导作用。不变的点更多是管理相关的能力和要求，这在市场上没有完全满足我们要求的产品，于是我们选择了自主进行研发，最终形成了监控管理平台。
而对于更多变化的内容，我们的策略是快速引入专业领域的监控工具纳入到我行监控体系中使用，对接到管理平台进行统一管理。发展趋势中，大数据平台的作用和价值凸显，我们也以此作为监控乃至IT运营的转型的方向，基于开源的产品重点建设和优化。
二、光大银行监控体系总体介绍
1、总体架构在重点介绍监控管理平台之前，有必要让大家对光大银行监控体系的总体架构和功能有个了解。
光大银行监控系统的定位是面向全行科技部门的IT监控系统。从功能层面分为3层，分别是监控工具层、平台层和统一展示层。
1）监控工具层，包含各类开源或者商业的专业领域的监控工具，他们实现对各类监控工具的实时的数据采集。常见的比如Zabbix、Nagios、Prometheus、BPC、Tivoli等等，都定位在监控工具层。监控工具会把报警数据、性能数据、日志数据，上送到平台层。
2）平台层，包含两大部分功能：一是由监控报警处理、监控标准化和自服务等功能模块组成的管理平台；二是基于大数据架构的科技运营数据平台，包括大数据处理、存储、AI分析以及数据服务接口等子系统。在平台层，还实现了和行内其他运维系统的对接。
3）统一展示层，根据不同用户的角色和场景，提供PC、大屏和手机端展示。
总的来说，平台层的建设思路是开源+自研，是整个体系的核心；工具层的建设思路是专业+敏捷+统一管理。
通过多年的建设，监控系统的指标覆盖从底层的机房设施到最上层的应用交易，实现了指标全覆盖。借助多种监控工具的部署，对监控指标的实现，一般都具备多种监控手段。
我们内部有个原则：对于关键指标，要有两种的工具能够覆盖。这样做有两个好处：一是能够确保监控策略有冗余，二是确保当我们识别出一个新的指标要纳入监控时，我们一定有工具能快速实现监控部署。
2、交易监控交易监控，一直是所有监控系统建设的重点功能。我们通过多种手段，实现端到端的交易全方位监控：
1）采用了网络旁路抓包、流水表镜像和交易日志分析等多种方式监控交易成功率、响应率、响应时间等指标，实现了对应用无侵入的、实时的监控。
2）TCP网络层监控，通过旁路方式对应用的全链路“通讯对”进行监控和分析，能够快速发现网络的异常，也能从网络层面对应用故障进行协助定位和分析。
3）模拟监控，从互联网以及内网探点模拟访问应用系统，主动获取可用性和性能数据，并接入到监控平台进行集中处理和分析。
4）通过网络抓包和日志Api的方式进行端到端追踪系统应用间和应用系统内部的交易路径。这个功能目前在部分新架构下的应用系统已经实现，更多传统的应用系统正在改造过程中。
3、大数据和智能化大数据和智能算法，是我们现在的工作重心。年我们的科技运营数据平台完成上线投产，这个平台综合运用了多种算法，实现了指标异常检测、多维检测、批处理异常检测等多种功能。
对银行业最重要的就是联机交易和批量执行，智能监控为传统监控提供了重要的补充手段：
一个场景是交易监控，综合节假日、促销等各种因素实现动态的异常交易检测和告警，可以细化到每一只交易单独进行监控，相比于传统的固定阈值监控能提前3-5分钟进行提示。
第二个场景，是对批量任务时长的智能分析，相比于传统的固定批量执行时长的监控，智能分析的结果能够做到提前预警，为夜间故障处置赢得了时间。
在数据展示方面，我们建设了统一视图系统。支持移动端、大屏端、PC端实时数据展示。根据业务场景，定制了日常运维视图、应急保障视图、和重保运营视图。
按照用户角色的使用需求，对各类视图进行分类，如一线偏重于故障发现、和按照预案处置以及事后的验证；二线偏重于故障的解决以及趋势分析和隐患排查。
4、技术栈对于监控系统的建设，我们的原则是以开源为主，自主可控。
在数据采集层面，我们使用了zabbix、nagios、prometheus等常见的开源软件。另外也有国产的网络流量采集和分析的产品。对于存量的国外商业套件，我们已经制定了替换的计划，预计会逐步下线。
需要特别提到的是，我们正在实施部署的统一采控Agent子系统，采用自研方式建设，目标是能够成为一个采集脚本编写和管理的基础平台，提供通用的Agent驱动能力，独立实现服务器上所有数据的实时采集，成为大数据平台最稳定可靠的数据来源。
在数据处理、数据存储、前端展示以及开发部署各个层面，也就是平台层的产品则基本都是开源的产品和技术。
上面是对我行监控系统整体的功能和架构进行了简要介绍。
三、监控管理平台建设实践分享
前面介绍了光大银行总体监控体系，在本章节我来介绍一下监控体系中的监控管理子系统。
1、管理平台功能架构这是监控管理平台的总体功能架构图：
主要是两大部分，第一个是左半部分，从下到上包括报警采集、预处理和处理，构成了报警处理引擎子系统，其中还包括了报警通知和维护期管理的功能。
第二是右半部分从上到下，监控标准化管理子系统，包含监控对象、策略、指标和规则等标准化管理功能，以及监控配置自动化、监控评价等功能。
通俗的说，左面部分解决的是报警来了怎么处理的问题，右面部分解决的是报警如何配置，怎么产生的问题。
2、监控报警引擎下面分别介绍一下报警处理引擎和监控标准化管理两大部分功能。报警处理引擎，是光大银行自主研发实现的核心组件，所以这个部分是本次分享的重点内容。
首先，我们先来分析报警管理的技术和业务特点：
在事件采集层，数据源丰富、报文格式多种多样，并且期望的采集延迟在毫秒级；
在报警处理层，特点包括报警量大、可能存在报警风暴、报警之间相关性高、处理逻辑复杂，要考虑扩展性并且还要合理继承原有的规则，处理延迟要求在秒级完成；
在展示和处置层，要求的是展现形式多种多样，前端页面能够高频刷新或主动的接收服务器推送的报警，保证时效性。
基于上述报警管理的特点，我们制定了报警处理引擎的选型和开发的目标：
1）事件采集和处理要解耦，这样能够保证采集器的采集时效性。
2）事件处理集中化，规则、外部对象资源都要加载，通过集中处理可以更加充分的利用资源，一次加载重复使用。
3）事件处理分布式，处理集中之后就要有分布式处理可水平扩展的能力。
4）分布式内存数据库，针对报警反复读写数据库的情况，这是从性能角度考虑。
5）对SQL的支持好，数据库的访问就能非常灵活和简洁，监控报警规则就更容易实现。
6）去商业化，自主构建。基于开源软件构建，能够最大程度满足管理要求。
上述几点是我们最初选择报警处理引擎的一些考量或者是目标。这和我们之前用的产品也有一定关系，我们之前采用的是IBMOmnibus产品，到现在也有很多金融机构在使用该产品，它是一个基于内存的支持SQL的报警处理引擎，它的最大问题就是单节点、单进程运行，所以对于大数据量的处理存在瓶颈。
所以我们开发的新报警引擎一方面要解决处理能力的瓶颈，另一方面要能够完全兼容原平台的处理逻辑和规则。这是我们在技术选型前的另外一个约束。
在产品选型的过程中，我们主要考虑的是两部分，一是数据库，二是分布式开发的框架。
在数据库选型中，我们选择了ApacheIgnite作为分布式数据库。和其他数据库的对比，比如Oracle、MySQL、Eedis、Geode、ES，主要考量几个特征是内存关系数据库、支持SQL、支持持久化等。
第二个选型，是分布式开发框架，因为框架主要用于引擎内各个组件的高性能交互，所以我们选择了Dubbo框架，相对更轻量和小巧。
关于ApacheIgnite，是基于Java语言开发的，可以用作一个分布式的缓存，也是一个分布式内存数据库，可以作为关系数据库使用。它的数据储存在堆外内存的，不受GC影响，性能更好。作为内存数据库，它还能将数据持久化到磁盘，保证数据不丢失。另外一些特点比如支持事务、可配置为CP或者AP使用，支持SQL函数扩展以及内置消息订阅发布模型。
作为报警引擎来讲，我们更加
