CN1761245A - 告警消息处理方法 - Google Patents

Abstract

本发明涉及通信领域，公开了一种告警消息处理方法，能够有效地减少系统向告警接收节点上报闪断告警，由此减小告警振荡上报对系统正常工作的影响，保证对实际存在的真正告警的处理。本发明的原理在于，在告警服务器中增加了告警缓冲队列，用于缓冲告警消息和限制预定时间段内的告警总数。并且通过关键域匹配等方式对新的告警产生进行查询，判断在告警缓冲队列中是否有与之对应的告警消失，如果有，则使它们相互抵消，并移出告警缓冲队列。

Description

告警消息处理方法

技术领域

本发明涉及通信领域，特别涉及通信领域中对告警消息的处理技术。

背景技术

电信设备的发展趋势是采用标准化、模块化的开发方式，电信设备开发商大量使用各种任务不同的板卡构成各个电信设备模块，再由这些具有不同功能的模块搭建成完整的电信设备系统，这些电信设备开发商由此可以大量降低开发专属架构所需的成本。所以采用标准化的模、共享模块较容易达到经济规模所需要的数量，有了经济规模，成本自然降低。

由此可见，电信设备实际上是由许多相对独立的板卡或者模块构成，各自形成一个子系统，再组合成一个整系统。对于整个系统来说，监控并保证各个子系统正常运行是维持整个电信设备正常的关键。

对于电信设备，经常需要实时监控的是其上的单板、接口、时钟等的运行状态。为了能够实时监控它们，一般系统中都会采用告警的方式。系统中的单板对自己的各个部件、子系统的告警一般都在其检测到后上报。如图1所示：

图1是通信设备中常用的一种板卡模块布局方式，告警服务器10独立于插框11之外，在插框11的插槽中，并列插入业务板110、业务板120、业务板130、业务板150和系统板140。其中，插框11中的业务板担负具体的处理业务数据流的任务，系统板140负责收集各单独业务板的告警，或者其它一些信息，将其上报到告警服务器10，并接受上级系统传来的信息，对其所管理的插框中的业务板进行控制。

熟悉本领域的技术人员都知道，插框11中的业务板数量不是固定不变的，可以根据业务量的大小增加或者减少业务板数量，实现电信设备系统对业务处理能力的灵活性要求。而一个插框中，通常系统板数量是比较固定的，或者有少量的变化，视其管理业务板数量能力的大小而定。

各个单板告警的上报路径以业务板110为例，路径依次为业务板110、系统板140、告警服务器10，其它业务板的上报路径与此类似。需要说明的是，在图1中，业务板与系统板的联系箭头为了便于标识，是画在板卡外，实际系统中，它们之间的联系通道是通过插框11背板电路板中的电子线路来担当的。而系统板140与告警服务器间的联系，则大部分是通过系统板的外接数据口加数据传输线与之相连，称之为带外网管通道。当然二者之间的各种信息也有沿业务数据流通道联系的可能，称之为带内网管通道。除此之外，业务板和告警服务器也可以建立这种基于业务数据流通道的带内网管方式，即在有些电信设备系统中，各业务板的告警可以不必经过系统板而直接到达告警服务器。使用何种网管通道联系，视具体情况而定。

在实际应用中，上述方案存在以下问题：在某些情况下，无法有效处理真正的告警。具体的说，当同一个告警内容频繁的出现和消失，即发生闪断告警，产生告警振荡上报时，由于反复产生的告警消失和告警产生之间的间隔很小，以至于系统无法通过告警过滤门限有效消除，因此诸如后台界面之类的告警接收节点会大量出现这些告警，再加上后台界面显示的速度跟不上告警上报的速度，因此会使用户对后台界面难以操作，扰乱对真正告警的处理。

发明内容

有鉴于此，本发明的主要目的在于提供一种告警消息处理方法，能有效地减少系统向告警接收节点上报闪断告警，由此减小告警振荡上报对系统正常工作的影响，保证对实际存在的真正告警的处理。

为实现上述目的，本发明提供了一种告警消息处理方法，包含以下步骤：

A告警服务器收到告警消息后判断其类型是告警消失还是告警产生，如果是告警消失则进入步骤C，如果是告警产生则进入步骤B；

B判断在所述告警缓冲队列中是否存在与所述告警产生相对应的告警消失，如果是，则从所述告警缓冲队列中删除该告警消失，丢弃所述告警消息，否则进入步骤C；

C将所述告警消息保存到告警缓冲队列；

D在延迟预定时间长度后，将所述告警缓冲队列中的告警消息显示或向后继告警接收节点转发。

其中，在所述步骤B中，通过关键域匹配的方式，判断所述告警缓冲队列中是否存在与所述告警产生相对应的告警消失。

所述告警服务器位于告警接收或告警转发节点。

所述预定时间长度可以是1至5秒范围内的一个值。

所述告警缓冲队列的长度根据所述预定时间长度内最多可显示的告警消息总数和可以接收的告警消息总数确定。

通过比较可以发现，本发明的技术方案与现有技术的区别在于，在告警服务器中增加了告警缓冲队列，用于缓冲告警消息和限制预定时间段内的告警总数。并且通过关键域匹配等方式对新的告警产生进行查询，判断在告警缓冲队列中是否有与之对应的告警消失，如果有，则使它们相互抵消，并移出告警缓冲队列。

这种技术方案上的区别，带来了较为明显的有益效果，即有效抑制告警接收节点收到大量闪断告警的情况，避免其对用户造成的困扰，增强了对实际存在的真正告警的关注。

附图说明

图1是现有技术中系统单板告警上报路径示意图；

图2是根据本发明的一个实施例的告警消息处理方法的原理和工作流程示意图；

图3是根据本发明的一个实施例中告警服务器向告警接收节点发送告警消息的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。

总的来说，本发明的原理在于，一方面在告警服务器中增加告警缓冲队列，用于控制告警消息的数量、延迟告警消息的上报；另一方面，采用诸如关键域匹配之类的方法，达到将新的告警产生和存在于告警缓冲队列中的对应的告警消失进行抵消的目的，从而有效抑制闪断告警的上报。

下面结合图2，通过对本发明的一个实施例的详细展开，进一步说明和解释本发明中提出的告警消息处理方法的原理和工作流程。

首先，告警服务器根据预定时间长度内最多可显示的告警总数和可以接收的告警总数，创建告警缓冲队列。

具体的说，告警服务器预先设定一个时间段，该设定时间段的长短可以根据实际情况调整。举例而言，如果系统要求对告警消息的处理十分及时，比如锅炉恒温自动调节系统，就需较短的设定时间；如果系统对告警消息的处理的及时性要求不是很高，比如车流量记录系统，则设定较长的时间也无妨。在本实施例中，告警服务器设定的时间是3秒。

然后，告警服务器依据自己在设定的3秒钟内可以显示的告警总数和最多可以接收的告警数，创建一个告警缓冲队列。该告警缓冲队列在系统每次上电初启动时为空，告警缓冲队列头指针和尾指针都指向第一个首先到达告警服务器的告警消息，而后到达告警服务器的告警消息则按时间先后顺序依次挂接在队列尾。

需要说明的一个问题是，告警服务器每次在告警缓冲队列的队列尾新加入一个告警消息时，就修改告警缓冲队列尾指针，使告警缓冲队列尾指针始终指向最后一个加入告警缓冲队列的告警消息。在本实施例中，如果有多个告警消息同时到达，则按照发出告警消息的设备优先级来排序，设备优先级高的告警消息排在前面，设备优先级底的告警消息排在后面。

需要说明的另一个问题是，根据本发明的原理，当告警缓冲队列满时，告警服务器就将该队列加锁，不再接收告警消息，一旦该告警缓冲队列中有告警消息被处理完，并被清除出该队列释放出存储空间时，告警服务器马上将该告警缓冲队列去锁，继续接收告警消息。

上述告警缓冲队列的一个作用是控制预定时间段内上报的告警消息总数，另一个作用是将需要上报的告警消息延迟上报，具体的说，当告警缓冲队列头的告警消息在缓冲区缓冲的时间达到预定时间段后，再被告警服务器选中并发送至告警接收节点，例如后台的显示界面。

然后如图2所示，进入步骤200，当系统设备出现故障时，向告警服务器发送新的告警消息。在本实施例中，告警消息包含出故障的设备名、设备优先级和告警消息产生时的时间等信息。

其中设备名作为关键域，告警服务器通过查看该关键域来匹配与该告警消息相关联的告警消失消息，这将在后面详细说明。对于设备优先级，可作为多个告警消息同时申请加入告警缓冲队列时次序先后的一个判断依据。对于记录的告警消息产生时间，则是告警服务器判断告警消息是否在缓冲区缓冲够3秒钟的关键。

随后执行步骤201，判断告警消息是告警消失还是告警产生，如图所示，如果是告警消失，则进入步骤203，如果是告警产生，则进入步骤202。本发明主要针对告警消息中的告警产生进行处理。

在步骤202中，判断告警缓冲队列中是否存在与该新的告警产生对应的告警消失。如果有，着进入步骤204，否则进入步骤203。

具体的说，在本步骤中，告警服务器收到上述新的告警后，首先查看缓冲区的告警缓冲队列是否已经上锁。如果告警缓冲队列已经上锁，则表示告警缓冲队列已满，没有多余的存储空间，告警服务器暂时不再接收告警消息，于是告警服务器返回消息给发生故障的设备，告诉设备告警缓冲队列已满，请设备等待一段时间后重新发送告警消息；如果告警缓冲队列没有上锁，则表示告警缓冲队列未满，告警服务器还可以接收告警消息。

在确定告警缓冲队列未满的情况下，告警服务器通过诸如关键域匹配之类的方法，检查告警缓冲队列是否有与此告警产生消息对应的告警消失消息。

下面对具体的关键域匹配的方法进行举例。

告警服务器首先查看该告警消息和告警缓冲队列中的每一个告警消失消息包含的设备名信息，如果该告警消息和告警缓冲队列中的某个告警消失的设备名相同，则表示这两个告警消息由同一个设备的故障所触发；接着告警服务器查看该两个设备名相同的告警消息的产生时间，如果它们的产生时间差不远大于发送该两个告警消息的设备因反复故障而产生的闪断告警持续时间，则表明该告警消息和此告警消失是相关联的，则执行步骤204，否则执行步骤203。

在步骤203，由于告警缓冲队列中没有和此告警产生对应的告警消失。于是告警服务器选中该告警产生，将其加入到告警缓冲队列的队列尾，然后修改告警缓冲队列尾指针，使该尾指针指向刚加入到告警缓冲队列的告警产生，接着判断告警消息告警缓冲队列是否已满，如果已满，则将队列上锁；如果未满，则继续处理下一个到达告警服务器的告警消息。

在步骤204，由于告警服务器在告警缓冲队列中查找到与此告警产生相关联的告警消失消息，因此将该告警信息移出告警缓冲队列。

具体的说，如果待删除的告警消失消息位于告警缓冲队列队列头，则告警服务器将该告警消失消息从队列头中移出，然后修改告警缓冲队列头指针，将头指针指向该告警消失消息的后一个告警消息。接着将该告警消失消息和它对应的告警产生消息相互抵消，释放它们在缓冲区占用的存储空间。如果待删除的告警消失消息位于告警消息告警缓冲队列中间，则告警服务器首先将该告警消失消息从队列中间移出，然后修改指向该告警消失消息的后一个告警消息的指针，使指针指向该告警消失消息的前一个告警消息，接着将该告警消失消息和它对应的告警消息相互抵消，释放它们在缓冲区占用的存储空间。如果待删除的告警消失消息位于告警消息告警缓冲队列的队列尾，则告警服务器将该告警消失消息从队列尾中移出，然后修改告警缓冲队列尾指针，使该尾指针指向该告警消失消息的前一个告警消息，接着将该告警消失消息和它对应的告警消息相互抵消，释放它们在缓冲区占用的存储空间。

需要说明的是，告警服务器所采取的上述处理闪断告警的机制同样适合于任何一个告警接收点或者告警转发节点，针对具体的某一个告警接收点或告警转发接点，系统只需要根据具体实际情况设置合适的告警缓冲队列的等待时间，而具体的操作细节则和上述的告警服务器所采取的操作细节一样，这里就不再累述。

下面参照图3，说明本实施例中，告警服务器发送告警消息的过程。如图3所示，首先在步骤310，在该告警消息被送往后台显示界面显示前，告警服务器用当前时间减去告警消息中记录的告警消息产生时间，得到一个时间差。如果该时间差小于预定时间段长度，则告警服务器依然将该告警消息缓冲在缓冲区；如果该时间差达到预定时间长度，则进入步骤320，告警服务器将该告警消息发送至后台显示界面。

需要指出的是，在本实施例中，由于告警消息分为两种，分别是触发告警消息和告警消失消息，因此当告警服务器选中一个告警消息向显示界面发送时，对这两种不同的告警消息分别采取不同操作。

举例而言，如果告警服务器选中的告警消息是触发告警消息，则由该告警消息触发响铃开关鸣铃，然后系统在界面将该告警消息对应的出故障的设备以高亮度显示，接着告警服务器丢弃该触发告警消息，释放它占用的缓冲区存储空间，并将告警缓冲队列头指针指向队列的下一个告警消息；如果告警服务器选中的告警消息是告警消失消息，则系统将与该告警消包对应的设备以低亮度显示，撤消该设备的告警，接着告警服务器丢弃该告警消失消息，释放它占用的缓冲区存储空间，并将告警缓冲队列头指针指向队列的下一个告警消息。

虽然通过参照本发明的某些优选实施例，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种各样的改变，而不偏离所附权利要求书所限定的本发明的精神和范围。

Claims (5)

1.一种告警消息处理方法，其特征在于，包含以下步骤：

A告警服务器收到告警消息后判断其类型是告警消失还是告警产生，如果是告警消失则进入步骤C，如果是告警产生则进入步骤B；

B判断在所述告警缓冲队列中是否存在与所述告警产生相对应的告警消失，如果是，则从所述告警缓冲队列中删除该告警消失，丢弃所述告警消息，否则进入步骤C；

C将所述告警消息保存到告警缓冲队列；

D在延迟预定时间长度后，将所述告警缓冲队列中的告警消息显示或向后继告警接收节点转发。

2.根据权利要求1所述的告警消息处理方法，其特征在于，在所述步骤B中，通过关键域匹配的方式，判断所述告警缓冲队列中是否存在与所述告警产生相对应的告警消失。

3.根据权利要求2所述的告警消息处理方法，其特征在于，所述告警服务器位于告警接收或告警转发节点。

4.根据权利要求2所述的告警消息处理方法，其特征在于，所述预定时间长度可以是1至5秒范围内的一个值。

5.根据权利要求2所述的告警消息处理方法，其特征在于，所述告警缓冲队列的长度根据所述预定时间长度内最多可显示的告警消息总数和可以接收的告警消息总数确定。

Images