故障管理告警数据分布式处理

中国移动通信集团河北有限公司 潘霞

作为移动运营商的核心生产系统，故障管理系统在日常的运维保障中起着至关的作用。故障管理系统主要包含三类基础数据：资源、性能和告警数据。随着LTE的建设和无线WIFI普及的拉动，移动的网络规模不断扩大。其资源、性能和告警数据也随之爆炸增长，这给故障管理系统告警数据的实时处理带来了不小的压力。本文从告警的处理流程入手，分析其中的性能瓶颈，并结合实际情况建立起告警数据的分布式处理机制。

告警处理过程中的性能瓶颈

故障管理系统每天要处理大量的告警数据，这些数据有以下特点：

1、数据量大：告警数据超400万条/天（含设备和性能告警）；

2、数据变化非线性：存在瞬时峰值超过1000条/秒情况，超过平时处理量十倍以上；

3、数据实时性高：告警数据需要实时处理并及时呈现在页面上，其中设备告警时延控制在秒级；

4、处理复杂度高：单条告警要经资源填充、标准化处理、关联分析、派单规则匹配、预处理规则匹配等多批次长流程操作；

5、数据的时序性：同一条告警内部以及同一网元产生的新告警和清除告警都需要按照顺序执行相应的操作。

以前，告警系统为了满足数据处理的实时性、时序性和复杂度高的要求，采用了单线程的处理机制。即首先把告警消息缓存到一个消息队列中，然后通过一个单独的线程做后续的相关操作。由于告警数据巨大，常出现处理不及时导致入库延时、派单延时、页面呈现延时等一系列问题。

另外，这些实时处理模块都是部署在实体机上，且单机部署单机运行。不仅扩展存在成本和升级困难情况，也存在程序故障或者服务器故障多方面的安全隐患。

总结起来，以前的告警处理机制存在并发数受限、处理延时较大、安全性低、不易扩展等问题。在数据量日益增长的趋势下，已经不能满足故障管理系统的要求。

问题分析

我们以告警的处理流程为例来分析问题所在，如图1所示：

1、从告警队列里边取出一条告警，通过和资源关联把相关必要字段填充到告警对象中；

2、根据标准化规则对告警做标准化处理；

3、根据事先定义好的关联规则对告警做关联分析；

4、根据事先定义好的派单规则对告警做派单匹配，如果有匹配上的规则，则在对应的时间做自动派单；

5、根据事先定义好的智能预处理规则对告警做匹配，如果有匹配上的规则，则把告警发给预处理模块做智能预处理；

6、告警消息发送到各应用模块进行数据消费；

7、告警入库。

由告警处理流程图可以看出：

每条告警中的处理步骤需要按顺序执行；

根据告警数据的特点，同一网元产生的新告警和清除告警处理顺序不能错乱；

由于告警数据量大，告警的入库环节采用定时批量入库的方式；

关键问题：

告警的处理环节多，过程复杂，耗时长是影响告警数据准确可靠的重要问题；

告警的数据量大，且执行顺序要求较高，是影响告警处理效率的主要原因；

上述关键问题的解决点在于在每条告警被完整有序处理的前提下尽可能地

提高并发处理的能力。

技术支撑

该方案的主要目标是为了解决两个关键问题：即每条告警被完整有序的处理，以及增加并发处理能力。

告警实时数据量大是告警处理效率低下的主要原因，因此方案中必须解决对大数据的高效处理能力，否则处理过程再优美，逻辑再严谨也无济于事。传统的解决方案是在单一服务器上通过尽可能地增加硬件配置（如cpu、内存等）来提高实时数据的处理能力。但事实上现在先进的系统不仅要求处理能力出众，还必须具有可扩展、高容错、高并发等特点。显然单机运行方案已经完全不能适应系统的技术要求，尤其是移动运营商的核心生产系统。

图1 告警处理流程

基于以上原因，本方案致力于寻求一种可以对实时大量数据进行快速处理，并能够保证数据处理顺序和完整可靠的解决手段。伴随着近几年互联网的高速发展，应运而生的是海量的信息数据，并且已经出现一些实时处理海量数据的可靠方法。这次我们选用的是较为成熟的Storm技术。一个实时的、分布式的、具备高容错的计算系统，来作为告警数据实时处理的解决方案。

Storm主要特点：

1、可以处理大批量的数据；

2、在保证高可靠性（所有的信息都会被处理）的前提下让处理进行的更加实时；

3、易于扩展，通过新增设备来提高系统处理能力；

4、具备容错机制，如果任务执行失败，Storm会重新分配再次执行。

解决方案

Storm处理逻辑，业界也称为流式处理。图2是基于Storm架构的告警实时数据处理流程图：

图2 基于Storm的告警处理流程

在此架构下，所有的告警处理节点任务可以被平均分配在不同服务器上，并受Supervisor进程的调度和管理。系统会根据事先配置好的策略来分配告警数据的流向，最终稳定高效完成所有的处理节点。

方案特点：

对于同一个处理节点，会部署在多台机器上，每台机器都可以启动多个线程来同时处理该节点的任务；

一条告警在经过第n个处理节点后，可以设置不同的分发策略分发给第n+1个节点；

对于无序的两条告警（比如两个网元产生的不同新告警），我们可以采用混排分组策略，此种策略Storm会随机分发给能够处理第n+1个节点的多个任务中的其中一个，并保证每个工作节点可以分配到较为平均的任务数；

对于有序的告警（比如同一个网元和新告警和清除告警，只能先处理新告警，再处理清除告警），我们可以设置按照告警的某个字段分组，比如使用告警标识来分组，那么Storm就会对告警标识相同的告警分配给同一个任务来处理，从而保证了执行的顺序。

对于同一告警处理节点的多个任务，如果有其中一个或多个任务发生了故障或者异常，Storm会记录它的执行状态，使未处理完成的告警重新分配给其它任务来处理，并不再发送告警数据给这些故障的任务直至故障恢复；

分布式的部署和执行，保证了系统的可扩展性。随着移动网络规模的不断扩大，告警数据也必然会大量增加，我们可以很容易地通过新增设备的方式来提高系统的处理能力；

系统中的一个或多个工作节点如果发生故障，主节点将不会再发送告警数据给此工作节点，其它工作节点可以继续工作并分担故障工作节点的任务，待故障工作节点恢复后再接收告警数据。

硬件部署：

使用两台服务器（配置均为：CPU，AMD6100 4*16；内存，96G，硬盘，2*600G）采用分布式的方式来部署故障管理系统，这样系统将会有一个主节点（部署在服务器A上）和两个工作节点（一个部署在服务器A上，一个部署在服务器B上）组成，它们之间通过zookeeper进行协调通信。主节点的后台程序Nimbus用于响应分布在集群中的节点，分配任务和监测故障；工作节点的后台程序Supervisor用于收听工作指派并基于要求运行工作进程。

随着处理数据量的增加，依赖Storm架构的横向扩展能力，系统可灵活增加工作节点。实现当前大数据下的灵活横向扩展。

总结

本方案从告警数据的处理过程入手，分析了告警数据处理过程中的性能瓶颈以及产生的原因，并采用当前相对成熟的Storm实时计算系统，有力提升了故障管理系统中实时数据的处理能力。

目前，基于Storm架构的故障管理流式处理系统已经投入使用。极大提升了运营商对实时告警的处理和监控能力，使得全专业故障管理成为可能。并且实现了系统自身负载均衡和自身监控的能力，减轻了使用人员的劳动强度，降低了系统故障几率。系统使用一年以来，创造了良好的经济效益和社会效益。

本方案中，运营商可以结合自身的网络状况和硬件情况，利于方案中的技术特点来优化符合自身情况的实时数据处理系统。