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