一种告警数据的处理方法和处理系统与流程

文档序号:14305021阅读:220来源:国知局
一种告警数据的处理方法和处理系统与流程

本发明属于数据处理领域,尤其涉及一种告警数据的处理方法和处理系统。



背景技术:

在传输网中,用户为了快速发现和定位问题,对由于传输设备故障而产生的告警数据十分关注,对告警数据的上报时延、可靠性和正确性都有很高的要求。目前,烽火ems(elementmanagementsystem,网元管理系统)侧北向接口现有的告警数据上报,存在如下问题:

告警数据上报可靠性不能够保证,当告警数据丢失后无法恢复;

告警上报数据的处理效率较低,存在性能瓶颈;

用户订阅机制受限,仅支持向所有订阅用户广播相同的告警数据。



技术实现要素:

本发明实施例的目的在于提供一种告警数据的处理方法和处理系统,以解决现有技术无法恢复丢失的告警数据的问题。

本发明实施例是这样实现的,一种告警数据的处理方法,所述处理方法包括:

接收客户端发送的告警数据回溯请求;

根据预设的并发读取机制从告警队列中获取所述告警数据回溯请求对应的告警数据;

将所述告警数据发送到所述客户端。

本发明实施例的另一目的在于提供一种告警数据的处理系统,所述处理系统包括:

接收单元,用于接收客户端发送的告警数据回溯请求;

获取单元,用于根据预设的并发读取机制从告警队列中获取所述告警数据回溯请求对应的告警数据;

发送单元,用于将所述告警数据发送到所述客户端。

本发明实施例,接收客户端发送的告警数据回溯请求,根据预设的并发读取机制从告警队列中获取告警数据回溯请求对应的告警数据,将所述告警数据发送到所述客户端,使得不同的用户通过并发读取机制可以分别获取对应的告警数据,且通过在告警队列中设置消息恢复区,使得用户可以方便找回曾经的告警数据。

附图说明

图1为本发明一示例性实施例示出的一种告警数据的处理方法的流程图;

图2为本发明一示例性实施例示出的一种告警数据的处理系统的结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。

为了说明本发明所述的技术方案,下面通过具体实施例来进行说明。

如图1所示为本发明一示例性实施例示出的一种告警数据的处理方法的流程图,所述处理方法包括以下步骤:

步骤s101,接收客户端发送的告警数据回溯请求。

在本发明实施例中,告警数据回溯适用于客户端向网络中的设备获取,且通常是由客户端主动发起的告警数据回溯,因此,网络中的设备首先接收客户端发送的告警数据回溯请求。

步骤s102,根据预设的并发读取机制从告警队列中获取所述告警数据回溯请求对应的告警数据。

在本发明实施例中,网络设备中预设了并发读取机制,使得多个用户可以分别读取不同的告警数据。并发读取机制具体为:在从队列读取告警数据时,实现读写锁区分,不同用户的读操作之间不需要相互等待,同时为了减少对队列的读操作次数,一次读数据时,读取一批告警数据;当队列中无数据可读时,该用户休眠直到写操作完成后。

所述告警队列包括:发送缓冲区和消息恢复区。

在本发明实施例中,发送缓冲区用于用户通过指定告警序号来获取告警数据,该区间的告警数据用户均可任意获取;消息可恢复区是用户补回缺失告警数据,实现重传的保障,如果用户获取告警数据序号落在该区间则为非法,仅做补回告警数据使用。

消息可恢复区的长度m和发送缓冲区n可根据具体要求进行计算得出,δt为用户收到的需要补发的第一条告警数据在北向接口侧的发送的时刻与北向接口发送补发数据前一时刻之间间隔,δt=δt1′+δt2′+δt3′+δt4′,δt1′与δt3′为数据发送的时延,δt2′为用户收到缺失告警数据后处理的响应时间,δt4′为北向接口侧补发告警消息的处理时间。

所述消息恢复区长度m和发送缓冲区长度n满足以下条件:

当m≥n时,n≥n-m、m≥(mx+δt*n),当m<n时,n≥(n-m)*tmax、m≥(mx+δt*n),其中,m为所述告警队列的出队列速率,n为所述告警队列的入队列速率,δt为用户收到的需要补发的第一条告警数据在北向接口侧的发送的时刻与北向接口发送补发数据前一时刻之间间隔,tmax为出现告警消息积压时,可保持告警消息不丢失的最大时长。

在本发明实施例中,假设告警数据的入队速率为n条/s,告警数据的出队列速率为m条/s,根据告警收发速率的不同,分析m与n的取值要求:

当m≧n,告警消息无积压,n理论上可以为0,但在某一个时刻,n远大于m时(告警数据风暴),为了使告警数据不丢失,n需要满足:

n≥n-m

如:m为1000条/s,n的瞬时值为3000条/s,为了满足告警数据风暴在3000条/s时不丢失告警数据,需要n≧2000。

当m<n,告警消息有积压,待发送队列需要满足:

n≥(n-m)*tmax

tma为出现告警消息积压时,可保持告警消息不丢失的最大时长,极端情况下,m为0、n为1000,保持3s,即需要消息不丢失,发送队列n需要大于3000。

m与告警消息进队列和出队列的速率无关,需要满足:

m≥(mx+δt*n)

mx为队列支持补回告警数据的最大长度,如mx为1000,时延δt为2.5s,所以m≥(1000+2.5*1000),即m最大需要大于等于3500,此时m≥3500。

所述获取所述告警数据回溯请求对应的告警数据,具体为:

判断所述告警数据回溯请求要求的告警数据的位置与用户对应的当前告警上报消息的位置的关系,如果所述告警数据的位置在所述当前告警上报消息的位置之后,则向用户返回错误消息,继续从所述当前告警上报消息开始上报告警数据,如果所述告警数据的位置在所述当前告警上报消息的位置之前,则从所述告警数据的位置获取告警数据。

在本发明实施例中,u为当前用户告警上报消息在消息队列中的位置,正常情况下,u应该位于待发送队列中,当需要告警消息补回时,队列根据回溯告警消息序号决定u在队列中的位置u’;如果u’在u之后(即序号在u对应告警序号之后),则向用户返回错误,继续从u开始上报告警;如果队列收到告警补回请求,但位置在u之前(即序号在u对应告警序号之前),此时队列确认u’存在对应的告警数据,则开始从u’获取告警数据;否则返回错误。

当n>m,此时为了保证告警消息的连续行,u’需要以(n-m)条/s的速度向消息可恢复区队尾移动,u以n条/s的速度向消息可恢复区队尾移动,当u’与u重合时,告警补回操作完成,此时清除u’标示,用户恢复以u为当前位置继续上报告警,此时u可能在发送缓冲区中,也可能在消息可恢复区中。当在消息可恢复区中的情况时,队列不能够保证mx条内告警的消息补回功能,此时将用户当前位置u直接更新为发送缓冲区的队首位置;当在发送缓冲区中的情况时,如果告警消息积压,u继续以(n-m)条/s的速度向发送缓冲区队尾移动,直到u到达发送缓冲区队尾时,u处单位时间接收的告警信息为n,但当前上报处理能力为m,不能够保证每条告警均被发送,所以从发送缓冲区队尾处所取告警数据已不能够保证连续,此时将u重置于发送缓冲区队首处进行告警消息的实时上报。

如果u’在与u重合前,u’提前到达可恢复区队尾位置,则将u置于发送缓冲区队首处进行告警消息的实时上报。

当n<m,此时将u以(m-n)条/s的速度向队首移动,直到u与发送缓冲区队首重合后,保持u不变;这里当u对应的告警序号与补回前暂停时刻该用户告警流水号相同时,告警补发完成,继续上报实时告警。

步骤s103,将所述告警数据发送到所述客户端。

本发明实施例,接收客户端发送的告警数据回溯请求,根据预设的并发读取机制从告警队列中获取告警数据回溯请求对应的告警数据,将所述告警数据发送到所述客户端,使得不同的用户通过并发读取机制可以分别获取对应的告警数据,且通过在告警队列中设置消息恢复区,使得用户可以方便找回曾经的告警数据。

作为本发明的一个可选实施例,在所述根据预设的并发读取机制从告警队列中获取所述告警数据回溯请求对应的告警数据的步骤之前,所述处理方法还包括:

通过序号对告警数据进行标记。

在本发明实施例中,为了方便告警数据的管理和恢复,需要给告警数据统一生成序号,使得告警数据具备识别错序和序号定位能力。如以无符号整形来对告警数据进行编号,当达到最大值时,重新从1开始编号,当出现异常情况后,队列恢复后序号仍能够保持相同的基准值,且可以通过序号来判断是否存在告警数据遗漏。

如图2所示为本发明一示例性实施例示出的一种告警数据的处理系统的结构图,所述处理系统包括:

接收单元201,用于接收客户端发送的告警数据回溯请求。

在本发明实施例中,告警数据回溯适用于客户端向网络中的设备获取,且通常是由客户端主动发起的告警数据回溯,因此,网络中的设备首先接收客户端发送的告警数据回溯请求。

获取单元202,用于根据预设的并发读取机制从告警队列中获取所述告警数据回溯请求对应的告警数据。

在本发明实施例中,网络设备中预设了并发读取机制,使得多个用户可以分别读取不同的告警数据。并发读取机制具体为:在从队列读取告警数据时,实现读写锁区分,不同用户的读操作之间不需要相互等待,同时为了减少对队列的读操作次数,一次读数据时,读取一批告警数据;当队列中无数据可读时,该用户休眠直到写操作完成后。

所述告警队列包括:发送缓冲区和消息恢复区。

在本发明实施例中,发送缓冲区用于用户通过指定告警序号来获取告警数据,该区间的告警数据用户均可任意获取;消息可恢复区是用户补回缺失告警数据,实现重传的保障,如果用户获取告警数据序号落在该区间则为非法,仅做补回告警数据使用。

消息可恢复区的长度m和发送缓冲区n可根据具体要求进行计算得出,δt为用户收到的需要补发的第一条告警数据在北向接口侧的发送的时刻与北向接口发送补发数据前一时刻之间间隔,δt=δt1′+δt2′+δt3′+δt4′,δt1′与δt3′为数据发送的时延,δt2′为用户收到缺失告警数据后处理的响应时间,δt4′为北向接口侧补发告警消息的处理时间。

所述消息恢复区长度m和发送缓冲区长度n满足以下条件:

当m≥n时,n≥n-m、m≥(mx+δt*n),当m<n时,n≥(n-m)*tmax、m≥(mx+δt*n),其中,m为所述告警队列的出队列速率,n为所述告警队列的入队列速率,δt为用户收到的需要补发的第一条告警数据在北向接口侧的发送的时刻与北向接口发送补发数据前一时刻之间间隔,tmax为出现告警消息积压时,可保持告警消息不丢失的最大时长。

在本发明实施例中,假设告警数据的入队速率为n条/s,告警数据的出队列速率为m条/s,根据告警收发速率的不同,分析m与n的取值要求:

当m≧n,告警消息无积压,n理论上可以为0,但在某一个时刻,n远大于m时(告警数据风暴),为了使告警数据不丢失,n需要满足:

n≥n-m

如:m为1000条/s,n的瞬时值为3000条/s,为了满足告警数据风暴在3000条/s时不丢失告警数据,需要n≧2000。

当m<n,告警消息有积压,待发送队列需要满足:

n≥(n-m)*tmax

tma为出现告警消息积压时,可保持告警消息不丢失的最大时长,极端情况下,m为0、n为1000,保持3s,即需要消息不丢失,发送队列n需要大于3000。

m与告警消息进队列和出队列的速率无关,需要满足:

m≥(mx+δt*n)

mx为队列支持补回告警数据的最大长度,如mx为1000,时延δt为2.5s,所以m≥(1000+2.5*1000),即m最大需要大于等于3500,此时m≥3500。

所述获取所述告警数据回溯请求对应的告警数据,具体为:

判断所述告警数据回溯请求要求的告警数据的位置与用户对应的当前告警上报消息的位置的关系,如果所述告警数据的位置在所述当前告警上报消息的位置之后,则向用户返回错误消息,继续从所述当前告警上报消息开始上报告警数据,如果所述告警数据的位置在所述当前告警上报消息的位置之前,则从所述告警数据的位置获取告警数据。

在本发明实施例中,u为当前用户告警上报消息在消息队列中的位置,正常情况下,u应该位于待发送队列中,当需要告警消息补回时,队列根据回溯告警消息序号决定u在队列中的位置u’;如果u’在u之后(即序号在u对应告警序号之后),则向用户返回错误,继续从u开始上报告警;如果队列收到告警补回请求,但位置在u之前(即序号在u对应告警序号之前),此时队列确认u’存在对应的告警数据,则开始从u’获取告警数据;否则返回错误。

当n>m,此时为了保证告警消息的连续行,u’需要以(n-m)条/s的速度向消息可恢复区队尾移动,u以n条/s的速度向消息可恢复区队尾移动,当u’与u重合时,告警补回操作完成,此时清除u’标示,用户恢复以u为当前位置继续上报告警,此时u可能在发送缓冲区中,也可能在消息可恢复区中。当在消息可恢复区中的情况时,队列不能够保证mx条内告警的消息补回功能,此时将用户当前位置u直接更新为发送缓冲区的队首位置;当在发送缓冲区中的情况时,如果告警消息积压,u继续以(n-m)条/s的速度向发送缓冲区队尾移动,直到u到达发送缓冲区队尾时,u处单位时间接收的告警信息为n,但当前上报处理能力为m,不能够保证每条告警均被发送,所以从发送缓冲区队尾处所取告警数据已不能够保证连续,此时将u重置于发送缓冲区队首处进行告警消息的实时上报。

如果u’在与u重合前,u’提前到达可恢复区队尾位置,则将u置于发送缓冲区队首处进行告警消息的实时上报。

当n<m,此时将u以(m-n)条/s的速度向队首移动,直到u与发送缓冲区队首重合后,保持u不变;这里当u对应的告警序号与补回前暂停时刻该用户告警流水号相同时,告警补发完成,继续上报实时告警。

发送单元203,用于将所述告警数据发送到所述客户端。

本发明实施例,接收客户端发送的告警数据回溯请求,根据预设的并发读取机制从告警队列中获取告警数据回溯请求对应的告警数据,将所述告警数据发送到所述客户端,使得不同的用户通过并发读取机制可以分别获取对应的告警数据,且通过在告警队列中设置消息恢复区,使得用户可以方便找回曾经的告警数据。

作为本发明的一个可选实施例,所述处理系统还包括:

标记单元,用于通过序号对告警数据进行标记。

在本发明实施例中,为了方便告警数据的管理和恢复,需要给告警数据统一生成序号,使得告警数据具备识别错序和序号定位能力。如以无符号整形来对告警数据进行编号,当达到最大值时,重新从1开始编号,当出现异常情况后,队列恢复后序号仍能够保持相同的基准值,且可以通过序号来判断是否存在告警数据遗漏。

本领域普通技术人员可以理解为上述实施例所包括的各个单元只是按照功能逻辑进行划分的,但并不局限于上述的划分,只要能够实现相应的功能即可;另外,各功能单元的具体名称也只是为了便于相互区分,并不用于限制本发明的保护范围。

本领域普通技术人员还可以理解,实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,所述的程序可以在存储于一计算机可读取存储介质中,所述的存储介质,包括rom/ram、磁盘、光盘等。

以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1