01
背景
当前银行普遍使用的告警处理引擎是IBM商用套件Tivoli Omnibus，由于它的采集和处理都是单线程，并且存储采用的是单机版的内存数据库，具体有如下缺点：
没有平行扩展的能力；
告警存储的数据有限，当告警达到2万条时，它的响应速度下降，不能满足当前业务情况；
部署采用多层结构，每层的数据同步都需要一定的时间，影响告警处理速度；
只负责存储告警，不具有告警逻辑处理能力。
为解决以上问题，我们自主研发了新一代的报警处理引擎，提升平台整体报警的处理能力。
02
新一代告警引擎
1丨总体框架
从技术产品框架的视角看，自下而上分为三层：采集层、处理层和报警管理层，其中采集层采用自主研发的事件采集器，基于spring boot + Akka框架；处理层基于Dubbo分布式服务框架，集群内运行多个事件处理节点，事件处理节点使用的技术包括：ANTLR语法分析、java动态编译tools以及Java RMI。使用Zookeeper作为服务发布和订阅的管理，使用Ignite内存库作为报警数据库。该框架具有如下优点：
事件采集和处理解耦，保证采集器的采集时效性。
事件处理集中化。集中处理规则和外部对象资源加载，更加充分的利用资源，一次加载重复使用。
事件处理分布式，处理能力可水平扩展。
分布式内存数据库，对告警的反复读写，能够快速响应。
支持SQL,数据库的访问能够非常灵活和简洁，监控报警规则更容易实现。
去商业化，自主构建。基于开源软件构建，能够最大程度满足管理要求。
下面将分别介绍新一代告警处理引擎中用到的几个关键技术。
2丨Akka并行框架
由于报警接入范围很广，采集器需要接收数据量庞大且格式多样的告警事件消息：例如网络和存储硬件设备发出的trap数据，syslog数据；Zabbix、ITM、OVO等监控工具发出的告警消息。为了能够及时处理这些事件信息，采集器基于Akka并行接收和预处理框架实现。
Akka是一个开发库和运行环境，可以用于构建高并发、分布式、可容错、事件驱动的基于JVM的应用。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主要消耗者。
3丨Apache Dubbo分布式框架
Apache Dubbo是一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡，以及服务的自动注册和发现。为了保证集群本身的高可用，还可以搭建备集群，主备集群之间的数据可以实时同步。
报警处理集群中，实现了两个Dubbo服务：
数据处理服务：提供了数据的增、删、改、查接口，用于采集器（EPP）调用和其它应用调用，采集器负责发送数据给报警处理集群进行进一步处理，如告警压缩、告警恢复等，其它应用负责查询和操作告警，如删除、接管等；
数据同步服务：集群数据同步服务，提供数据的定时备份接口和增量备份接口，负责从主集群同步数据到备集群，备集群可以是多个。
Dubbo服务的调用关系如下图所示：
4丨Apache Ignite分布式存储
多级存储
Ignite对多级存储的支持主要有三种模式：内存、内存+数据库、内存+原生持久化：
内存：仅使用内存存储数据，为了保证数据不丢失，应该保证数据至少有一份备份；
内存+数据库：在数据库上层用Ignite作为缓存，这里的数据库可以是传统的数据库，例如MySQL、Oracle等。在这里Ignite的作用类似于我们常用的Ehcache、Guava Cache等，但是Ignite是分布式的且更加强大；
内存+原生持久化：Ignite本身支持持久化，可以将数据全部持久化到磁盘，同时将全部或者部分热点数据加载到内存中。
持久化
Ignite本身的持久化支持分布式，但持久化并不是每次有数据更新时直接将内存分布同步到磁盘上面，而是写到预写日志文件(Write-Ahead Log，即WAL)中。持久化流程如下：
图片来源于网络
节点接收到更新请求之后，它会在内存中查找该数据所属的数据页面，该页面会被更新然后标记为脏页面；
更新会被附加到WAL的尾部；
节点会向更新发起方发送一个更新成功的确认信息；
根据配置或者其它参数配置的频率，后台线程会被定期地触发，脏页面会从内存复制到磁盘，然后传递给特定的分区文件。
分布式Key-Value
Ignite底层是一个分布式内存键-值存储，它可以视为一个分布式的分区化哈希映射，每个集群节点都持有所有数据的一部分，这意味着随着集群节点（服务端）的增加，就可以缓存更多的数据。
分布式SQL
Apache Ignite是一个兼容ANSI-99、水平可扩展以及容错的分布式SQL数据库，这个分布式是以数据在集群范围的复制或者分区的形式提供的，具体的形式取决于使用场景。作为一个SQL数据库，Ignite支持所有的DML指令，包括SELECT、UPDATE、INSERT和DELETE，它还实现了一个与分布式系统有关的DDL指令的子集。
图片来源于网络
和很多的分布式SQL数据库不同，对于数据和索引，Ignite将内存和磁盘都视为完整有效的存储层，但是磁盘是可选的，如果禁用，Ignite就变为纯内存数据库。可以像其它的SQL存储一样，根据需要与Ignite进行交互，比如通过外部的工具或者应用使用JDBC或者ODBC驱动进行连接。在这之上，Java、.NET和C++开发者也可以使用Ignite的原生SQL API。
分布式事务
Ignite支持分布式事务，提供了完整的ACID（原子性、一致性、隔离性和持久性）兼容事务来确保一致性，无论是做缓存还是数据持久化到硬盘都可以保证数据的一致性。
图片来源于网络
Ignite在事务中使用二阶段提交（2PC）的协议，不过也会尽可能地使用一阶段提交。在一个事务中当数据更新时，在调用commit()方法之前，Ignite会在本地事务映射中保持事务状态，这时只要需要，数据都会被传输到参与事务的远程节点。
5丨通过商店App模式支持处理功能的定制开发
新一代报警处理引擎App分为如下几类：
流App：在每个处理节点运行，用于实时报警；
调度型批App：定时从Ignite告警库中取一批特定的报警进行处理；
广播型批App：在每个处理节点运行，接收调度型App分配的任务；
订阅型批App：从流App和调度型批App订阅数据，进行汇总和再处理；
-
Restful App：动态的生成访问App内部数据的接口，可以对App运行情况进行监控。
当前该引擎已经开发测试完毕，部署实际生产环境，接入全行实际生产告警事件，和Omnibus告警引擎实现双跑并观察，预计在Q3末实现Omnibus的完全替换。关键运行指标经测试如下：
活动库报警数量：最高可达千万级报警数据，是原有商业套件存储能力的200倍；
历史库数量：最高可归档存储亿级数据；
写入TPS：存1000万平均速度，11653条/s，是原有商业套件的10倍；
报警处理延迟: 100毫秒以内，性能提升30-50倍以上；
扩展性：每增加1台服务器，写入速度提升到2000条/s。
03
未来展望
通过自研新一代报警处理引擎，我们提升了平台整体报警的处理能力和管理规则的可定制化能力，为后续提升报警智能分析、主动预测、提高监控服务覆盖化打下坚实的基础。未来优化的方向包括下面三点：
报警接入方面：基于微服务的理念，提供企业级的监控报警接入服务。技术上提供WebHook等事件集成接口，更加简便、友好的接收应用程序内部推送的各类报警信息，并且提升报警接口的管理能力；
报警处理能力方面：需要加强报警分析能力，尤其是大规模报警的情况下报警根因的定向和定位能力，提升运用AI算法解决报警压缩和收敛的能力；
报警展示和关联：提升报警与性能数据、配置数据的关联能力，在阅读报警时能够同步了解到故障点KPI快照、指标趋势分析、变更切换操作等相关的运维数据信息，提升故障处置效率，缩短故障影响的时间。