本申请涉及计算机软件
技术领域:
,尤其涉及一种消息推送风暴抑制方法。
背景技术:
:广电运营商的fttx(fiber-to-the-x,光纤接入)网络上连接有众多的网络设备,这些网络设备通过网络管理系统进行管理,网络管理系统的一台服务器可管理几十万台网络设备。服务器对网络设备进行周期性查询,获取设备参数值和网络设备主动上报的trap报文,进而得出网络设备的当前状态,当网络设备的当前状态为非正常的告警状态时,服务器生成相应的告警消息,以提醒网络管理员和系统运维人员及时处理,将网络设备或网络恢复正常。相关技术中,采用与网络管理系统通信连接的客户端接收服务器的告警消息,客户端为搭载监控app的通信终端,服务器上生成的告警消息,推送到通信终端的监控app中,供网络管理员和系统运维人员进行查看并处理。然而,当一个片区(街道/小区/一栋楼)发生断电、断网、断光时会造成大量网络设备断网,网络管理系统根据大量网络设备掉线,在短时间生成较多告警消息并推送至通信终端,造成推送风暴。推送风暴带来许多问题,比如监控app短时间内不能及时接收大量的告警消息,出现严重卡顿甚至导致通信终端死机;重要的告警消息会湮没在海量消息中,推送的内容不能被网络管理员和系统运维人员及时看到并处理。技术实现要素:本申请提供了一种消息推送风暴抑制方法,以解决消息推送风暴问题。本申请提供了一种消息推送风暴抑制方法,该方法包括:获取第一预设周期内服务器的全部待推送消息;分别判断每条所述待推送消息是否符合预设过滤规则;如果所述待推送消息不符合预设过滤规则,将所述待推送消息标记为滤后消息;判断所述滤后消息的总数量是否大于推送阈值;如果滤后消息的总数量大于推送阈值,将全部所述滤后消息按照预设聚合原则进行聚合,得到聚合消息;将所述聚合消息推送到客户端。可选地,将全部所述滤后消息按照预设聚合原则进行聚合,得到聚合消息,包括:提取每条所述滤后消息的归类信息,根据所述归类信息得到消息摘要,所述归类信息包括告警等级或设备类型;将全部所述滤后消息合并为一条聚合消息,将所述消息摘要标注为所述聚合消息的标题。可选地,获取第一预设周期内服务器的全部待推送消息,之前还包括:获取客户端发送的消息配置信息,根据所述消息配置信息确定预设过滤规则。可选地,所述方法还包括:所述客户端在接收到所述聚合消息时,发出第一提醒信号,所述第一提醒信号根据所述消息配置信息进行设置。可选地,所述方法还包括:如果所述待推送消息符合预设过滤规则,将所述待推送消息按照所述消息配置信息归类存储到服务器的消息数据库中。可选地,所述方法还包括:如果滤后消息的总数量没有大于推送阈值,将全部所述滤后消息推送到客户端;所述客户端在接收到所述滤后消息时,发出第二提醒信号,所述第二提醒信号根据所述消息配置信息进行设置。可选地,所述聚合消息和滤后消息均设置有确认选项,所述方法还包括:所述客户端每隔第二预设周期,根据所述确认选项的处理状态,判断是否存在未确认消息;如果存在未确认消息,根据所述未确认消息为所述聚合消息,生成第一提醒信号进行提醒,和/或根据所述未确认消息为所述滤后消息,生成第二提醒信号进行提醒。可选地,分别判断每条所述待推送消息是否符合预设过滤规则,包括:判断所述待推送消息是否符合多个预设过滤规则中的任意一种预设过滤规则,其中,多个所述预设过滤规则包括管理范围过滤准则、设备类型过滤准则、信号参数类型过滤准则、设备恢复过滤准则和告警等级过滤准则。本申请提供的消息推送风暴抑制方法的有益效果包括:本申请实施例提供的消息推送风暴抑制方法,通过将符合预设过滤原则的待推送消息过滤掉,只推送用户关注的消息,避免了对用户进行打扰,并且,避免了重要的消息被湮没在普通的消息中而造成严重后果;根据一定周期内的待推送消息的数量超过推送阈值,将多条待推送消息进行聚合,得到聚合消息,将聚合消息推送到客户端,避免短时间内大量待推送消息直接推送给客户端导致客户端出现卡顿甚至崩溃的现象,提升了客户端的稳定性;通过将聚合消息和普通的滤后消息采用不同的提醒方式进行提醒,有利于用户快速判断接收到的消息为聚合消息或滤后消息,提升了用户体验;进一步的,每隔一定周期进行消息提醒,有利于提醒用户及时进行消息处理,保障网络管理系统的稳定运行。附图说明为了更清楚地说明本申请的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。图1为本申请实施例提供的一种消息推送风暴抑制方法的结构示意图;图2为本申请实施例提供的一种消息聚合方法的流程示意图。具体实施方式为了使本
技术领域:
的人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。参见图1,为本申请实施例提供的一种消息推送风暴抑制方法的流程示意图,如图1所示,本申请实施例提供的消息推送风暴抑制方法,包括以下步骤:步骤s101:获取客户端发送的消息配置信息,根据消息配置信息确定预设过滤规则。客户端为与服务器通信连接的通信终端,如智能手机,客户端上搭载有监控app,通过监控app设置消息配置信息,以及接收服务器推送的告警消息。客户端的用户可为网络管理员和系统运维人员,本申请实施例以系统运维人员进行示例性描述。消息配置信息可用于确定预设过滤原则、推送阈值、推送提醒信号、推送周期和提醒周期。服务器端的待推送消息,如果符合预设过滤原则,将不推送至监控app,不符合过滤原则的待推送消息,将推送至监控app。消息配置信息的配置内容如下:管理范围:根据片区分组划分管理范围,比如上海嘉定区的系统运维人员,可配置只接收嘉定区网络设备的推送消息,其他片区的推送消息都配置为不向系统运维人员的监控app推送。设备类型:接收光发射机、光放大器、光开关、光接收机等设备类型中的一种或几种设备类型的告警消息,设备类型的设置使得告警消息能够显示设备类型。参数类型:接收电压、电流、光信号、rf信号等参数类型中的一种或几种参数类型的告警消息,参数类型的设置使得告警消息能够显示参数类型。发生和恢复:配置只接收发生设备异常的消息,设备恢复的消息配置为不向系统运维人员的监控app推送。告警等级:设备的推送消息按严重等级划分,比如,本申请实施例中,配置的严重等级为紧急、重要、一般、提示,配置严重等级为一般、提示的告警消息不向系统运维人员的监控app推送。告警等级可根据电压、电流、光信号、rf信号参数类型等进行划分。本申请实施例中,消息配置信息配置管理范围为特定片区以外,和/或告警等级为一般、提示的告警消息为符合预设过滤原则,即能够推送至监控app的告警消息为特定片区内,且告警等级为紧急或重要的消息;配置推送周期为10秒,每隔10秒推送一次消息;配置推送阈值为2,超过2条消息则将消息聚合推送;配置推送提醒信号包括第一提醒信号和第二提醒信号,其中,监控app接收到没有聚合的告警消息时,发出第二提醒信号进行提醒,监控app接收到聚合消息时,发出第一提醒信号进行提醒;配置提醒周期为10分钟,如果有系统运维人员未处理的推送消息,每隔10分钟提醒一次,根据未处理的告警消息为没有聚合的告警消息或聚合消息,通过相应的提醒信号进行提醒。步骤s102:获取第一预设周期内服务器的全部待推送消息。第一预设周期即推送周期,每隔10秒获取一次服务器收到的待推送消息。例如,在一个10秒周期内,得到了10条待推送消息。步骤s103:分别判断每条待推送消息是否符合预设过滤规则。根据步骤s101设置的预设过滤准则,判断步骤s102内的每一条待推送消息是否符合多个预设过滤规则中的任意一种预设过滤规则,其中,多个预设过滤规则包括管理范围过滤准则、设备类型过滤准则、信号参数类型过滤准则、设备恢复过滤准则和告警等级过滤准则。管理范围过滤原则,即如果是指定片区外设备的推送消息,则被过滤掉;设备类型过滤准则,即如果是指定设备类型外设备的推送消息,则被过滤掉;信号参数类型过滤准则,即如果是指定信号参数类型外的其他信号参数类型的推送消息,则被过滤掉;设备恢复过滤准则,即如果是设备恢复的推送消息,则被过滤掉;告警等级过滤准则,即如果是告警等级为一般的推送消息,则被过滤掉。只要符合上述任一条预设过滤原则,就被过滤掉。例如,这10条待推送消息均属于管理范围内的推送消息,如表1:表1表1中,告警等级为一般的待推送消息符合预设过滤规则。步骤s104:如果待推送消息不符合预设过滤规则,将待推送消息标记为滤后消息。不符合预设过滤原则的待推送消息标记为滤后消息,将全部待推送消息判断完毕后,就可以累计得出滤后消息的总数量。表1中,不符合预设过滤规则的待推送消息如表2:表2表2中,滤后消息的总数量为5。步骤s105:如果待推送消息符合预设过滤规则,将待推送消息按照消息配置信息归类存储到服务器的消息数据库中。未推送到客户端的待推送消息,可按照消息配置信息中的设备类型、参数类型、告警等级归类存储到服务器的消息数据库中,便于系统运维人员登录服务器按类别查询。本实施例中,系统运维人员可利用客户端的监控app登录服务器,查看表1被过滤掉的5条告警等级为一般的待推送消息的内容。步骤s106:判断滤后消息的总数量是否大于推送阈值。判断滤后消息的总数量是否大于2。步骤s107:如果滤后消息的总数量大于推送阈值,将全部滤后消息按照预设聚合原则进行聚合,得到聚合消息。表2中,滤后消息的总数量为5,大于推送阈值2,则将这5条消息进行聚合。预设聚合原则的聚合方法可参见图2,为本申请实施例提供的一种消息聚合方法的流程示意图,如图2所示,本申请实施例提供的消息聚合方法,包括以下步骤:步骤s7001:提取每条滤后消息的归类信息,根据归类信息得到消息摘要,归类信息包括告警等级或设备类型。提取这5条滤后消息的归类信息,归类信息包括告警等级或设备类型,以告警等级为例,分别提取这5条滤后消息的告警等级,并进行统计,得到告警等级为致命的2条滤后消息,告警等级为严重的3条滤后消息。步骤s7002:将全部滤后消息合并为一条聚合消息,将消息摘要标注为聚合消息的标题。聚合消息的标题参见表3:表3共5条推送消息,其中致命2条、严重3条步骤s7001-s7002仅为一种示例性聚合方法,还可采用其他方法进行消息聚合,例如,根据设备类型进行消息聚合,得到的聚合消息摘要为:共5台设备发生异常,其中2台为光发射机、3条为光接收机异常;根据滤后消息的总数量进行消息聚合,得到的聚合消息摘要为:共10条推送消息,异常设备ip:10.68.36.6,…,10.68.36.99。步骤s108:将聚合消息推送到客户端。将表3中的聚合消息推送给监控app,系统运维人员点开该聚合消息,可查看这5条消息的内容。步骤s109:客户端在接收到聚合消息时,发出第一提醒信号,第一提醒信号根据消息配置信息进行设置。步骤s110:如果滤后消息的总数量没有大于推送阈值,将全部滤后消息推送到客户端。如果步骤s106中的滤后消息的总数量为0-2条,则将全部滤后消息推送到客户端的监控app。步骤s111:客户端在接收到滤后消息时,发出第二提醒信号,第二提醒信号根据消息配置信息进行设置。第一提醒信号和第二提醒信号用不同的方式进行提醒,例如,可以设置第一提醒信号为通信终端进行高频铃声或高音量提醒,设置第二提醒信号为通信终端进行低频铃声或低音量提醒。在监控app内,可进一步设置服务器直接推送的滤后消息为黄色字体,聚合消息的标题为红色字体,便于系统运维人员查看。聚合消息和滤后消息均设置有确认选项,以便判断系统运维人员是否对聚合消息或滤后消息进行处理。步骤s112:客户端每隔第二预设周期,根据确认选项的处理状态,判断是否存在未确认消息。当系统运维人员查看一条消息时,点击确认选项,则将该消息标记为已确认的处理状态,系统运维人员不点击确认选项,则该消息为未确认的处理状态。第二预设周期可设置为10分钟,每隔10分钟清点一下是否有未确认的消息。步骤s113:如果存在未确认消息,根据未确认消息为聚合消息,生成第一提醒信号进行提醒,和/或根据未确认消息为滤后消息,生成第二提醒信号进行提醒。由于每隔10秒钟推送一次消息,因此,当系统运维人员一段时间内未进行消息处理时,可能会有多条未确认消息,如果有聚合消息,就通过第一提醒信号进行提醒,如果有滤后消息,就通过第二提醒信号进行提醒,如果既有聚合消息,也有滤后消息,就依次通过第一提醒信号和第二提醒信号进行提醒。由上述实施例可见,本申请实施例提供的消息推送风暴抑制方法,通过将符合预设过滤原则的待推送消息过滤掉,只推送用户关注的消息,避免了对用户进行打扰,并且,避免了重要的消息被湮没在普通的消息中而造成严重后果;根据一定周期内的待推送消息的数量超过推送阈值,将多条待推送消息进行聚合,得到聚合消息,将聚合消息推送到客户端,避免短时间内大量待推送消息直接推送给客户端导致客户端出现卡顿甚至崩溃的现象,提升了客户端的稳定性;通过将聚合消息和普通的滤后消息采用不同的提醒方式进行提醒,有利于用户快速判断接收到的消息为聚合消息或滤后消息,提升了用户体验;进一步的,每隔一定周期进行消息提醒,有利于提醒用户及时进行消息处理,保障网络管理系统的稳定运行。由于以上实施方式均是在其他方式之上引用结合进行说明,不同实施例之间均具有相同的部分,本说明书中各个实施例之间相同、相似的部分互相参见即可。在此不再详细阐述。需要说明的是,在本说明书中,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或暗示这些实体或操作之间存在任何这种实际的关系或顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的电路结构、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种电路结构、物品或者设备所固有的要素。在没有更多限制的情况下,有语句“包括一个……”限定的要素,并不排除在包括所述要素的电路结构、物品或者设备中还存在另外的相同要素。本领域技术人员在考虑说明书及实践这里发明的公开后,将容易想到本申请的其他实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本
技术领域:
中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由权利要求的内容指出。以上所述的本申请实施方式并不构成对本申请保护范围的限定。当前第1页12