作者介绍

监控系统作为IT运维之眼，在运维管理工作中发挥着重要的作用。而监控报警作为监控系统的主要输出，在生产故障早期预警、故障定位分析和故障恢复验证等多个运维场景中提供了技术工具的支撑。

G行上一代监控报警系统使用国外的商业套件，报警采集和报警处理受限于商业套件的单机单线程处理能力，而报警存储采用的是单机版的内存数据库。

为解决上述问题，G行新一代监控报警系统基于开源组件进行自主研发，既能满足海量报警消息的高并发处理及规则灵活配置的要求，又能满足报警全生命周期的运维管理需求，最终实现监控报警的高效处理。

下文将从报警信息的生命周期管理出发，介绍一下G行新一代监控报警系统规划与建设。

报警消息的管理我们遵从闭环管理机制，其生命周期可以从产生到恢复的全过程分为报警产生和接入、报警预处理、报警存储、报警通知和报警恢复后关闭等多个环节。

主要目标是为了实现：

围绕报警的生命周期管理，监控报警系统的功能框架应包含的主要功能如下：

监控报警系统在整个监控体系的作用是接收企业内各类专业监控工具产生的报警消息，其功能定位是报警MOM（Managerof Manager），通过本其定位以及前面的功能说明可以看出，监控报警系统有以下关键特性：

作为企业级的报警管理中心，是对企业的所有报警作统一的监控管理，报警接入的范围和监控工具覆盖的范围是一致的，从底层的基础设施、物理服务器、网络设备、存储设备、操作系统、云平台等，到中间件组件、数据库、WebServer和大数据组件等等，再到上层的业务和应用，如交易、应用等。

当设备有异常情况出现时，设备可能产生大量的报警，有时会达到每秒几万条，而形成报警风暴，当报警接入范围很广时，报警风暴可能随时时不时发生，报警管理中心必须自身必须能应对这种情况，对报警数据进行有效处理。

报警处理分为流处理和批处理，所谓流处理，是指一条报警接入之后过来之后，需要实时经过很多个逻辑处理单元之后才能入库，而在每个逻辑处理单元里面，都会频繁地操作告警数据库，和原有的报警上下文进行关联分析。无论是告警本身的处理，还是告警数据库，都存在巨大的性能压力。所谓批处理，是指定时地对报警库里面的数据做二次处理，报警处理中心有大量的批处理规则来处理各类不同的报警数据，同样会对报警处理机和数据库造成巨大的压力。

由于报警接入范围很广，报警类型和报文格式复杂多样，每一类报警的解析不一样，每一类报警的处理逻辑也不一样。而且，随着时间的推移和业务的变化，报警类型会增加，原来的报警处理逻辑也需要随着运维场景的变化持续改进会变化，因此报警处理规则所以，不可能将报警处理逻辑写死，而必须做到灵活定义和可扩展高度可配。

上面的四个特性中，前三个合起来产生一个问题，那就是报警管理系统中心高性能的问题。

第四个特性是报警管理系统规则灵活配置的问题，那如何解决高性能和高可配的问题呢？

G行新一代上一代监控报警系统使用国外的商业套件，报警采集和报警处理都是采用的单机单线程处理，而报警存储采用的是单机版的内存数据库。

存在的问题是为解决告警风暴、高频报警的问题，而我们：

当出现告警风暴时，采集器可能丢数据，而数据库也会发生阻塞，导致告警处理效率低下，报警延迟时间达到分钟级。

告警处理逻辑只能支持比较简单的处理，对于复杂的高并发高频率的处理，是无法应付的。

为解决上述问题，G行新一代监控报警系统基于开源组件进行自主研发，从报警采集、处理和入库三大关键环节入手，解决报警高性能和规则高可配的问题的。

其中主要的关键设计包括报警采集器的设计、分布式服务框架的引入和分布式数据库的选型和适配处理引擎和后面的几点对上。结合需求和技术约束，监控报警的整体框架为：

由于报警接入范围很广，采集器需要接收各种数据报文，当产生报警风暴时，必须要并行接收和预处理各种报警，才能使报警得到及时处理；采集器以Akka并行框架为基础实现。

Akka是Java虚拟机平台上构建的高并发、分布式和容错应用的工具包和运行时。Akka用Scala语言编写，同时提供了Scala和Java的开发接口。Akka处理并发的方法基于Actor模型，Actor之间通信的唯一机制就是消息传递。

其最大优势是消息发送者与已经发送的消息解耦，允许异步通信同时又满足消息传递模式的控制结构。以Akka为基础的报警采集器架构如下：

各层次作用说明如下：

新一代监控报警系统，以ApacheDubbo分布式框架为基础搭建分布式处理集群，集群的每一个节点都并行处理报警，当未来报警规模扩大时，集群的节点可以水平扩充，当集群的处理能力有冗余时，宕掉一个或多个节点不影响报警处理。

Apache Dubbo是一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务的自动注册和发现。为了保证集群本身的高可用，还可以搭建备集群，主备集群之间的数据可以实时同步。

在报警处理集群中，实现了两个Dubbo服务：

Dubbo服务的调用关系如下图所示：

处理节点的内部逻辑架构为：

由于报警处理逻辑复杂多变，所以报警处理集群的每一个处理节点都设计成一个报警处理APP容器，一个报警处理APP是指一个逻辑功能部件，用来处理某一类业务，比如进维护期、事件丰富、事件通知等等，APP容器具有以下特点：

由于报警数据量大报警会不时产生风暴、每一条告警处理过程中会大量的读写报警库，所以需要一个分布式内存数据库作为报警库。

因为常见以往的如MySQL、Oracle磁盘型关系数据库，在这样高频度访问和复杂逻辑处理下，无法满足监控报警系统高并发读写的需求，而采用单机版的内存数据库，在报警风暴的时候，同样会产生报警库瘫痪的问题。

在G行新一代报警系统开发和建设时，采用分布式内存数据库ApacheIgnite存储告警，可以将访问和逻辑处理分离并且在多节点内存中进行并行处理，所以性能完全能满足实际需求。

报警处理引擎对Ignite的使用如下：

G行现已在生产环境实际部署了自主研发的报警处理系统，进行功能和性能验证。关键运行指标经测试如下：

通过此次新一代监控报警系统的部署，G行的监控管理平台实现全部组件的开源和自主可控，大幅度提升了报警处理的效率，减少了报警处理延迟时间。

通过自研监控报警系统，提升了平台整体报警的处理能力和管理规则的可定制化能力，为后续提升报警智能分析能力打下了数据和处理能力层面的技术基础。

未来，优化和改进的方向包括：