银行监控报警系统性能提高50倍，用的全是开源组件
监控系统做为IT运维之眼，在运维管理工做中发挥着重要的做用。而监控报警做为监控系统的主要输出，在生产故障早期预警、故障定位分析和故障恢复验证等多个运维场景中提供了技术工具的支撑。前端
G行上一代监控报警系统使用国外的商业套件，报警采集和报警处理受限于商业套件的单机单线程处理能力，而报警存储采用的是单机版的内存数据库。java
存在如下问题web
当出现告警风暴时，采集器可能丢数据，而数据库也会发生阻塞，致使告警处理效率低下，报警延迟时间达到分钟级；算法
告警处理逻辑只能支持比较简单的处理，对于复杂的高并发高频率的处理，是没法应付的。数据库
解决方案缓存
为解决上述问题，G行新一代监控报警系统基于开源组件进行自主研发，既能知足海量报警消息的高并发处理及规则灵活配置的要求，又能知足报警全生命周期的运维管理需求，最终实现监控报警的高效处理。安全
下文将从报警信息的生命周期管理出发，介绍一下G行新一代监控报警系统规划与建设。服务器
1、监控报警系统简介网络
报警消息的管理咱们听从闭环管理机制，其生命周期能够从产生到恢复的全过程分为报警产生和接入、报警预处理、报警存储、报警通知和报警恢复后关闭等多个环节。架构
一、报警生命周期管理
主要目标是为了实现：
全面管理、敏捷接入
下降延迟、及时通报
推荐根因、协助定位
跟踪解决、恢复验证
二、监控报警系统核心功能
围绕报警的生命周期管理，监控报警系统的功能框架应包含的主要功能以下：
报警接入和预处理：对各类不一样来源和协议的报警的原始数据解析为统一的报警记录；
报警丰富：在报警处理过程当中根据cmdb等配置信息库的管理信息，对原始报警的内容进行信息补充和完善的功能；
报警维护期：应对平常变动、切换演练以及故障临时处置等场景下，提早屏蔽相关报警避免无效报警产生干扰；
报警压缩：对于重复发生的报警信息，只记录报警的首次发生时间、末次发生时间和发生次数，减小报警的记录数，避免对用户查看和处理报警形成干扰。报警压缩的规则通常是由多个报警消息的属性值组成压缩因子，可根据不一样的报警源和报警内容提早预置压缩因子的组合规则。常见的压缩因子包括：IP地址、报警对象、报警类别、报警策略、报警实例等；
报警恢复：为了可以真实反映生产系统运行的故障和恢复的状态，除了常见的故障外，还有恢复报警的处理和关联机制。在已报警在监控对象恢复正常运行状态之后，须要监控工具可以及时准确的识别恢复的状态并产生恢复报警到监控报警平台。报警平台支持自动进行关联恢复，即自动找到对应的故障报警，而后进行关联，并将原报警设置为恢复状态。关联的算法能够灵活进行设置，需确保恢复报警的产生时间晚于故障报警；
报警定级：报警的定级分为两个阶段，一是默认级别，即根据每一个报警原始的严重程度定义，二是报警管理系统平台对多个独立的报警进行关联分析，从新定义新的报警级别；
根因分析：随着监控策略的覆盖度和监控颗粒度的不断提高，在发生一个生产故障时会从关联的各个组件、各个层面产生大量报警，所以须要从众多报警中自动化找出根因的报警，成为报警处理重要目标；
报警通知：对于某些重大报警，须要通知给相关的运维人员，采起相应的措施。
2、监控报警系统的关键特性
监控报警系统在整个监控体系的做用是接收企业内各种专业监控工具产生的报警消息，其功能定位是报警MOM（Managerof Manager），经过本其定位以及前面的功能说明能够看出，监控报警系统有如下关键特性：
报警接入范围很广：
做为企业级的报警管理中心，是对企业的全部报警做统一的监控管理，报警接入的范围和监控工具覆盖的范围是一致的，从底层的基础设施、物理服务器、网络设备、存储设备、操做系统、云平台等，到中间件组件、数据库、WebServer和大数据组件等等，再到上层的业务和应用，如交易、应用等。
必须应对报警风暴：
当设备有异常状况出现时，设备可能产生大量的报警，有时会达到每秒几万条，而造成报警风暴，当报警接入范围很广时，报警风暴可能随时时不时发生，报警管理中心必须自身必须能应对这种状况，对报警数据进行有效处理。
报警处理逻辑复杂：
报警处理分为流处理和批处理，所谓流处理，是指一条报警接入以后过来以后，须要实时通过不少个逻辑处理单元以后才能入库，而在每一个逻辑处理单元里面，都会频繁地操做告警数据库，和原有的报警上下文进行关联分析。不管是告警自己的处理，仍是告警数据库，都存在巨大的性能压力。所谓批处理，是指定时地对报警库里面的数据作二次处理，报警处理中心有大量的批处理规则来处理各种不一样的报警数据，一样会对报警处理机和数据库形成巨大的压力。
处理逻辑灵活配置可扩展：
因为报警接入范围很广，报警类型和报文格式复杂多样，每一类报警的解析不同，每一类报警的处理逻辑也不同。并且，随着时间的推移和业务的变化，报警类型会增长，原来的报警处理逻辑也须要随着运维场景的变化持续改进会变化，所以报警处理规则因此，不可能将报警处理逻辑写死，而必须作到灵活定义和可扩展高度可配。
上面的四个特性中，前三个合起来产生一个问题，那就是报警管理系统中心高性能的问题。
第四个特性是报警管理系统规则灵活配置的问题，那如何解决高性能和高可配的问题呢？
3、监控报警系统的关键技术实现设计
G行新一代上一代监控报警系统使用国外的商业套件，报警采集和报警处理都是采用的单机单线程处理，而报警存储采用的是单机版的内存数据库。
存在的问题是为解决告警风暴、高频报警的问题，而咱们：
当出现告警风暴时，采集器可能丢数据，而数据库也会发生阻塞，致使告警处理效率低下，报警延迟时间达到分钟级。
告警处理逻辑只能支持比较简单的处理，对于复杂的高并发高频率的处理，是没法应付的。
为解决上述问题，G行新一代监控报警系统基于开源组件进行自主研发，从报警采集、处理和入库三大关键环节入手，解决报警高性能和规则高可配的问题的。
其中主要的关键设计包括报警采集器的设计、分布式服务框架的引入和分布式数据库的选型和适配处理引擎和后面的几点对上。结合需求和技术约束，监控报警的总体框架为：
一、以Akka并行框架为基础解决报警采集高性能问题
因为报警接入范围很广，采集器须要接收各类数据报文，当产生报警风暴时，必需要并行接收和预处理各类报警，才能使报警获得及时处理；采集器以Akka并行框架为基础实现。
Akka是Java虚拟机平台上构建的高并发、分布式和容错应用的工具包和运行时。Akka用Scala语言编写，同时提供了Scala和Java的开发接口。Akka处理并发的方法基于Actor模型，Actor之间通讯的惟一机制就是消息传递。
其最大优点是消息发送者与已经发送的消息解耦，容许异步通讯同时又知足消息传递模式的控制结构。以Akka为基础的报警采集器架构以下：
各层次做用说明以下：
数据采集Actor：原始数据采集，或者主动采集，或者被动接收，不一样类型的数据有一个Actor采集，对于主动采集的Actor，采用轮询的方式，定时采集数据；
原始数据分发Actor：全部采集到的原始数据都会发送到原始数据分发Actor，由它来分发到数据分析Actor，同时，这个Actor能够对原始数据作总体调度控制；
数据分析Actor：这是一组Actor，采集器主要业务处理和资源消耗的组件，可灵活配置Actor的并发个数;
持久化数据分发Actor：全部须要持久化的数据都发送到这个Actor，它对须要持久化的数据分发到持久化Actor，同时对持久化数据作总体的控制，好比数据库有问题或网络有问题，致使持久化没法进行或很慢，能够控制实现背压；
数据持久化Actor：这是一组Actor，对数据进行持久化，Actor个数能够配置，采集器的IO主要消耗者。
二、 以Apache Dubbo分布式框架为基础解决报警处理高性能问题
新一代监控报警系统，以ApacheDubbo分布式框架为基础搭建分布式处理集群，集群的每个节点都并行处理报警，当将来报警规模扩大时，集群的节点能够水平扩充，当集群的处理能力有冗余时，宕掉一个或多个节点不影响报警处理。
Apache Dubbo是一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务的自动注册和发现。为了保证集群自己的高可用，还能够搭建备集群，主备集群之间的数据能够实时同步。
在报警处理集群中，实现了两个Dubbo服务：
数据处理服务：提供了数据的增、删、改、查接口，用于采集器(EPP)调用和其它应用调用，采集器用来发送数据给报警处理集群进一步处理，如告警压缩、告警恢复等，其它应用用来查询和操做告警，如删除、接管等；
数据同步服务：集群数据同步服务，提供数据的定时备份接口和增量备份接口，用于从主集群同步数据多备集群，备集群能够是多个。
Dubbo服务的调用关系以下图所示：
处理节点的内部逻辑架构为：
三、处理逻辑APP化解决高可配问题
因为报警处理逻辑复杂多变，因此报警处理集群的每个处理节点都设计成一个报警处理APP容器，一个报警处理APP是指一个逻辑功能部件，用来处理某一类业务，好比进维护期、事件丰富、事件通知等等，APP容器具备如下特色：
报警处理APP采用热拔插方式。当APP数量很大致使，容器资源不够时，能够经过水平扩张集群节点解决；
报警处理APP的开发能够用系统提供的脚本开发，也能够用scala或java开发，对于脚本开发的APP，容器采用Antlr进行语法分析，翻译成Java代码，而后用Java动态编译技术编译成字节码运行，以提升处理速度；
优雅停启：当更新一个APP时，它正在处理的数据会处理完毕才自动中止，须要立刻处理的数据由新的APP处理，即新老APP可能有一个重叠的时间在同时运行。
报警处理APP有如下类型：
流APP：在每个处理节点上都运行的APP，处理实时报警，若是一个报警符合此APP的条件，则运行此APP逻辑；
调度型批APP：由报警处理集群的调度引擎将这类APP分布在不一样的节点上运行，每一个APP只有一个实例，定时从报警库中取一批特定的报警进行处理。
订阅型批APP：由报警处理集群的调度引擎将这类APP分布在不一样的节点上运行，每APP只有一个实例，从流APP或调度型批APP订阅数据，进行统一集中处理；
广播型批APP：在每个节点都运行的批处理APP，事件来源为某个调度型APP分配的数据，起到分布式处理的做用；
Restful APP：动态生成Restful接口的APP，以便访问APP的内部数据。
四、 Apache Ignite分布式存储解决存储高性能问题
因为报警数据量大报警会不时产生风暴、每一条告警处理过程当中会大量的读写报警库，因此须要一个分布式内存数据库做为报警库。
由于常见以往的如MySQL、Oracle磁盘型关系数据库，在这样高频度访问和复杂逻辑处理下，没法知足监控报警系统高并发读写的需求，而采用单机版的内存数据库，在报警风暴的时候，一样会产生报警库瘫痪的问题。
在G行新一代报警系统开发和建设时，采用分布式内存数据库ApacheIgnite存储告警，能够将访问和逻辑处理分离而且在多节点内存中进行并行处理，因此性能彻底能知足实际需求。
报警处理引擎对Ignite的使用以下：
持久化数据(SQL方式存取)：活动告警、历史告警、通知归档、配置数据；
缓存数据(key-value方式存取)：定时从其它应用查询资源数据，如用于丰富的MO、用于事件预处理的Lookup数据；
内存分区(5个节点，每一个节点总内存128G)：活动库16G，资源8G，历史库：52G，通知库：16G；
事务方式：告警处理几乎没有须要ACID强一致性保证，而且告警库访问频繁，为提升性能，配置为ATOMIC方式，即保证单个数据操做的一致性，当遇到更新冲突时，重复执行此更新操做直至成功。
五、实现效果
G行现已在生产环境实际部署了自主研发的报警处理系统，进行功能和性能验证。关键运行指标经测试以下：
活动库报警数量：最高可达千万级报警数据，是原有商业套件存储能力的200倍；
历史库数量：最高可归档存储亿级数据；
写入TPS：存1000万平均速度，11653条/s，是原有商业套件的10倍；
报警处理延迟：100毫秒之内，性能提高30-50倍以上；
扩展性：每增长1台服务器，写入速度提高：2000条/s。
经过这次新一代监控报警系统的部署，G行的监控管理平台实现所有组件的开源和自主可控，大幅度提高了报警处理的效率，减小了报警处理延迟时间。
4、将来展望
经过自研监控报警系统，提高了平台总体报警的处理能力和管理规则的可定制化能力，为后续提高报警智能分析能力打下了数据和处理能力层面的技术基础。
将来，优化和改进的方向包括：
报警接入方面：基于微服务的理念，提供企业级的监控报警接入服务。技术上提供webhook等事件集成接口，更加简便、友好的接收应用程序内部推送的各种报警信息，而且提高报警接口的管理能力；
报警处理能力方面：须要增强报警分析能力，尤为是大规模报警的状况下报警根因的定向和定位能力，提高运用AI算法解决报警压缩和收敛的能力；
报警展现和关联：提高报警与性能数据、配置数据的关联能力，在阅读报警时可以同步了解到故障点KPI快照、指标趋势分析、变动切换操做等相关的运维数据信息，提高故障处置效率，缩短故障影响的时间。
【编辑推荐】
【责任编辑：庞桂玉 TEL：（010）68476606】