CN116737765A - 业务告警信息处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开提供了一种业务告警信息处理方法、装置、电子设备及存储介质，该方法包括：根据业务告警信息的属性信息，确定业务告警信息所属的目标业务线；基于预先配置好的业务线与合并规则集合的对应关系，确定与目标业务线匹配的目标合并规则集合；基于目标合并规则集合以及业务告警信息的属性信息，生成针对业务告警信息的事件指纹，事件指纹用于表征业务告警信息的标识信息；判断在预设时间段内是否存在与事件指纹相同的目标告警事件，并在预设时间段内存在与事件指纹相同的目标告警事件的情况下，将业务告警信息合并到目标告警事件中。本申请实施例，有利于分析告警原因以及能够减少对维护人员的告警打扰次数。

Description

业务告警信息处理方法、装置、电子设备及存储介质

技术领域

本公开涉及互联网技术领域，具体而言，涉及一种业务告警信息处理方法、装置、电子设备和存储介质。

背景技术

随着互联网技术的发展，各类应用程序的出现为人们的生活提供了便利。为了保证用户在使用应用程序过程中的使用体验，需要对应用程序的运行进行监控，并在监控到运行出现异常状态时生成相应的业务告警信息，所述业务告警信息用于提示维护人员及时对该异常状态进行查看。

目前的告警方式通常在生成告警信息后直接将相应的业务告警信息发送到维护人员，导致维护人员在同一时间段内会收到大量的业务告警信息，进而引发业务告警信息遗漏或者不能及时对重要业务告警信息进行查看处理的情况。

发明内容

本公开实施例至少提供一种业务告警信息处理方法、装置、电子设备及存储介质，能够在保证在不遗漏业务告警信息的情况下，减少对维护人员的告警打扰次数。

本公开实施例提供了一种业务告警信息处理方法，包括：

根据业务告警信息的属性信息，确定所述业务告警信息所属的目标业务线；

基于预先配置好的业务线与合并规则集合的对应关系，确定与所述目标业务线匹配的目标合并规则集合；其中，每个合并规则集合包括至少一个合并规则，每个合并规则包括至少一个合并维度信息；

基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，所述事件指纹用于表征所述业务告警信息的标识信息；

判断在预设时间段内是否存在与所述事件指纹相同的目标告警事件，并在所述预设时间段内存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息合并到所述目标告警事件中。

本公开实施例中，在接收业务告警信息后，可以根据所述业务告警信息的属性信息，确定所述业务告警信息所属的目标业务线，并根据与该目标业务线匹配的合并规则集合，生成针对所述业务告警信息的事件指纹，并将预设时间段内具有相同事件指纹的业务告警信息合并到同一目标告警事件中，如此，将同一类业务告警信息进行合并，不仅有助于提升维护人员分析告警原因，还可以保证在不遗漏业务告警信息的情况下，减少对维护人员的告警打扰次数。此外，由于业务线与合并规则集合的对应关系是预先配置的，因此，可以为不同的业务线灵活配置相应的合并规则，以满足不同业务线的实际告警合并需求。

在一种可能的实施方式中，所述方法还包括：

在所述预设时间段内不存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息与所述事件指纹关联并存储。

本公开实施例中，在所述预设时间段内不存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息与所述事件指纹关联并存储，如此，可保证具有不同事件指纹的业务告警信息分开合并，进而有利于维护人员对不同目标告警事件下的业务告警信息进行区分，便于维护人员分析告警原因。

在一种可能的实施方式中，在所述合并规则集合中包括多个合并规则的情况下，各个合并规则所包括合并维度信息之间的交集小于预设范围。

本公开实施例中，在所述合并规则集合中包括多个合并规则的情况下，由于各个合并规则所包括合并维度信息之间的交集小于预设范围，进而可以避免将同一业务告警信息合并到不同的告警事件中。

在一种可能的实施方式中，所述基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，包括：

判断所述业务告警信息是否符合过滤条件，并在所述业务告警信息符合所述过滤条件的情况下，基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹；其中，所述过滤条件用于指示对预设类型的业务告警信息进行合并。

本公开实施例中，在对业务告警信息进行合并之前，需要先对所述业务告警信息是否符合过滤条件进行判断，进而只将符合过滤条件的业务告警信息进行合并，如此，可以将一些不符合过滤条件的业务告警信息进行过滤，有助于提升合并的效率。

在一种可能的实施方式中，所述方法还包括：

获取所述用户为不同的业务线配置的合并规则集合，并基于规则引擎生成所述业务线与合并规则集合的对应关系。

本公开实施例中，通过规则引擎不仅可以实现为不同的业务线配置合并规则集合的需求，还便于用户对合并规则的设定。

在一种可能的实施方式中，所述合并维度信息包括以下至少一种：

告警来源信息、告警类别信息、应用服务标识信息、告警级别信息、告警名称信息及应用链路信息。

本公开实施例中，由于合并维度信息包括告警来源信息、告警类别信息、应用服务标识信息、告警级别信息、告警名称信息及应用链路信息中的至少一种，进而可以根据具体需求从不同的角度为各个业务线位置相应的合并规则。

在一种可能的实施方式中，在所述预设时间段到达后，将所述目标告警事件发送至目标用户，所述目标告警事件携带聚合标识，所述聚合标识用于表征所述目标告警事件聚合的具有相同事件指纹的业务告警信息的数量。

本公开实施例中，在所述预设时间段到达后，可以将目标告警事件对应的多个业务告警信息统一发送至目标用户，如此不仅可以提醒维护人员及时对业务告警信息进行查看，还可以减少对维护人员的告警打扰次数。

本公开实施例提供了一种业务告警信息处理装置，包括：

告警信息接收模块，用于在接收到业务告警信息的情况下，针对每个业务告警信息，根据所述业务告警信息的属性信息确定所述业务告警信息所属的目标业务线；

合并规则确定模块，用于基于预先配置好的业务线与合并规则集合的对应关系，确定与所述目标业务线匹配的目标合并规则集合；其中，每个合并规则集合包括至少一个合并规则，每个合并规则包括至少一个合并维度信息；

事件指纹生成模块，用于基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，所述事件指纹用于表征所述业务告警信息的标识信息；

告警信息合并模块，用于基于所述事件指纹，判断在预设时间段内是否存在与所述事件指纹相同的目标告警事件，并在所述预设时间段内存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息合并到所述目标告警事件中。

在一种可能的实施方式中，所述业务告警信息合并模块还用于：

在所述预设时间段内不存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息与所述事件指纹关联并存储。

在一种可能的实施方式中，在所述合并规则集合中包括多个合并规则的情况下，各个合并规则所包括合并维度信息之间的交集小于预设范围。

在一种可能的实施方式中，所述事件指纹生成模块具体用于：

判断所述业务告警信息是否符合过滤条件，并在所述业务告警信息符合所述过滤条件的情况下，基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹；其中，所述过滤条件用于指示对预设类型的业务告警信息进行合并。

在一种可能的实施方式中，所述装置还包括：

合并规则设置模块，用于获取所述用户为不同的业务线配置的合并规则集合，并基于规则引擎生成所述业务线与合并规则集合的对应关系。

在一种可能的实施方式中，所述合并维度信息包括以下至少一种：

告警来源信息、告警类别信息、应用服务标识信息、告警级别信息、告警名称信息及应用链路信息。

在一种可能的实施方式中，所述业务告警信息合并模块还用于：

在所述预设时间段到达后，将所述目标告警事件发送至目标用户，所述目标告警事件携带聚合标识，所述聚合标识用于表征所述目标告警事件聚合的具有相同事件指纹的业务告警信息的数量。

本公开实施例提供了一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述任一实施方式中所述的业务告警信息处理方法。

本公开实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述任一实施方式中所述的业务告警信息处理方法。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开一些实施例所提供的一种业务告警信息处理方法的流程图；

图2示出了本公开一些实施例所提供的一种业务告警信息处理过程的示意图；

图3示出了本公开一些实施例所提供的业务告警信息处理装置的结构示意图；

图4示出了本公开一些实施例所提供的另一种业务告警信息处理装置的结构示意图；

图5示出了本公开一些实施例所提供的电子设备的示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

本文中术语“和/或”，仅仅是描述一种关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

经研究发现，目前的业务告警信息的处理方式通常在生成告警信息后直接将相应的业务告警信息发送到维护人员，导致维护人员在同一时间段内会频繁的收到的业务告警信息，进而引发业务告警信息遗漏或者不能及时对重要业务告警信息进行查看处理的情况。

基于上述研究，本公开提供了一种业务告警信息处理方法，可以根据业务告警信息的属性信息，确定所述业务告警信息所属的目标业务线；然后基于预先配置好的业务线与合并规则集合的对应关系，确定与所述目标业务线匹配的目标合并规则集合；其中，每个合并规则集合包括至少一个合并规则，每个合并规则包括至少一个合并维度信息；接着基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，所述事件指纹用于表征所述业务告警信息的标识信息；最后基于所述事件指纹，判断在预设时间段内是否存在与所述事件指纹相同的目标告警事件，并在所述预设时间段内存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息合并到所述目标告警事件中。

本公开实施例中，可以根据所述业务告警信息的属性信息，确定所述业务告警信息所属的目标业务线，并根据与该目标业务线匹配的合并规则集合，生成针对所述业务告警信息的事件指纹，并将预设时间段内具有相同事件指纹的业务告警信息合并到同一目标告警事件中，如此，可以将同一类业务告警信息进行合并，有助于维护人员分析告警原因，同时，还可以在保证在不遗漏业务告警信息的情况下，减少对维护人员的告警打扰次数。

此外，由于业务线与合并规则集合的对应关系是预先配置的，因此，可以为不同的业务线灵活配置相应的合并规则，以满足不同业务线的实际告警合并需求。

为便于对本实施例进行理解，首先对本公开实施例所提供的业务告警信息处理方法的执行主体进行详细介绍。本公开实施例所提供的业务告警信息处理方法的执行主体为电子设备。该电子设备可以为终端设备或者服务器。其中，该终端设备可以为移动设备、用户终端、终端、手持设备、计算设备、车载设备、可穿戴设备等。该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云存储、大数据和人工智能平台等基础云计算服务的云服务器。

其他实施方式中，该业务告警信息处理方法还可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

下面结合附图对本申请实施例所提供的业务告警信息处理方法进行详细说明。参见图1所示，为本公开实施例提供的一种业务告警信息处理方法的流程图，该业务告警信息处理方法包括以下S101～S104：

S101，根据业务告警信息的属性信息，确定所述业务告警信息所属的目标业务线。

其中，业务告警信息是指各个应用程序在运行过程中某项性能指标不符合预设指标要求时而生成的信息。具体地，针对每个的应用程序可以根据实际需求对不同的性能指标设置对应的指标要求，进而可以在某个性能的性能指标不符合预设指标要求时而生成相应的业务告警信息。

其中，应用程序包括但不限于短视频类应用程序、直播类应用程序、新闻类应用程序、交互类应用程序以及购物类应用程序等。

示例性地，可以通过监控平台来对应用程序的运行过程进行监测，并在应用程序的某项性能指标不符合预设的指标要求时生成相应的业务告警信息。作为一种示例，可以针对应用程序的不同服务功能分别设置不同的监控平台，比如，可以通过监控平台1对应用程序的前端服务功能进行监测，通过监控平台2对应用程序的后端服务功能进行监测。当然，也可以通过智能监控平台，来实现对应用程序的前端及后端服务同时进行监测。

因此，在实际应用中，可以根据实际需求为需要监测的应用程序配置相应的监控平台，进而针对同一应用程序，在接收到业务告警信息时，不仅可以获悉该业务告警信息来自于哪个监控平台，还可以基于预设的合并规则对自于不同监控平台的业务告警信息进行合并，以减少对维护人员的打扰。

可以理解，为了将不同的业务告警信息进行区分，在生成相应业务告警信息时可以基于告警ID(Identity Document，身份标识)生成用于表征不同类别业务告警信息。具体地，可以预先为每个需要监测的性能设置相应的告警ID，比如，针对接口调用超时类性能，可以为其设置告警ID1，针对运行卡顿的性能，可以为其告警ID2，进而在监控平台监测到当前运行的应用程序的接口在调用过程中出现超时(比如超过500ms)的情况下，可以生成携带告警ID1的业务告警信息，如此，在接收到业务告警信息后，根据该业务告警信息所携带的告警ID即可识别出当前业务告警信息的类别信息。

基于上述内容可知，所述业务告警信息的属性信息可以包括告警来源信息、告警类别信息以及应用服务标识信息。其中，所述告警来源信息用于指示所述业务告警信息来自于哪个监控平台；所述告警类别信息用于指示所述业务告警信息所属的类别；所述应用服务标识信息用于指示所述业务告警信息对应的应用程序。

除此之外，所述业务告警信息的属性信息还可以包括告警级别信息、业务告警信息名称信息以及应用链路信息中的至少一种。其中，所述告警级别信息用于指示所述业务告警信息的告警严重程度，比如，可以根据实际需求预先设置不同的等级(一级、二级、三级等)，进而可以在生成业务告警信息时根据告警严重程度生成对应的告警等级信息；所述应用链路信息用于指示所述业务告警信息对应的链路调用信息，该链路调用信息是指所述业务告警信息对应的应用程序所包括的多个子服务之间的调用信息。

示例性地，在接收到业务告警信息后，可以基于业务告警信息所携带的应用服务标识信息确定所述业务告警信息所属的目标业务线。其中，不用的应用程序对应不同的业务线，例如，对于X应用程序，可以对应Y业务线；对于M应用程序，可以对应N业务线。此外，针对同一个应用程序，不同的应用功能可以分别对应的同一业务线下的不同子业务线。比如，针对X应用程序，X应用程序的应用功能1对应一级Y业务线，X应用程序的应用功能2对应二级Y业务线。当然，其他实施例中，也可以多个应用功能对应一个子业务线，具体可以根据实际需求而设定，在此不做具体限定。

S102，基于预先配置好的业务线与合并规则集合的对应关系，确定与所述目标业务线匹配的目标合并规则集合；其中，每个合并规则集合包括至少一个合并规则，每个合并规则包括至少一个合并维度信息。

可以理解，在对业务告警信息进行合并之前，需要预先设置业务线与合并规则集合之间的对应关系，该业务线与合并规则集合之间的对应关系可以如下表1所示：

表1

业务线1	合并规则集合1
		业务线2	合并规则集合2
业务线n	合并规则集合n

如此，在确定所述业务告警信息所属的目标业务线之后，即可基于预先配置好的业务线与合并规则集合的对应关系，确定与所述目标业务线匹配的目标合并规则集合。例如，若目标业务线为业务线1，则根据该对应关系，即可将合并规则集合1确定为目标规则集合。

具体地，根据实际需求每个合并规则集合中可以包括至少一个合并规则，且每个合并规则包括至少一个合并维度信息。示例性地，合并规则集合1可以包括合并规则1a以及合并规则1b等。其中，合并维度信息与前述的业务告警信息的属性信息类似，可以包括告警来源信息、告警类别信息、应用服务标识信息、告警级别信息、告警名称信息及应用链路信息中的至少一种。

示例性地，合并规则1a可以包括告警类别信息；合并规则1b可以包括告警来源信息以及应用服务标识信息；合并规则2a可以包括告警来源信息、应用服务标识信息以及告警级别信息；合并规则3a可以包括应用链路信息；合并规则4a可以包括告警名称信息等。

可以理解，以上合并规则所包括的合并维度信息仅仅是举例示意，本申请实施例对此不做限定。其他实施例中，合并规则可以是任意的合并维度信息组合。

在一些实施例中，在基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹时，还可以先判断所述业务告警信息是否符合过滤条件，并在所述业务告警信息符合所述过滤条件的情况下，再基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹；其中，所述过滤条件用于指示对预设类型的业务告警信息进行合并。比如，在业务告警信息的告警类别包括不同类别的情况下，可以对某一告警类别的业务告警信息进行合并。如此，可以将一些不符合过滤条件的业务告警信息进行过滤，进而提升合并的效率。

需要说明的是，该过滤条件可以根据用户的实际需求而设定。

可选地，可以基于规则引擎以及脚本文件来实现对业务线与合并规则集合的对应关系以及过滤条件的自定义设定。具体地，可以通过脚本文件获取所述用户为不同的业务线配置的合并规则集合，并基于规则引擎生成所述业务线与合并规则集合的对应关系。

其中，规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

S103，基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，所述事件指纹用于表征所述业务告警信息的标识信息。

在获取到与所述目标业务线匹配的目标合并规则集合后，即可基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，其中，所述事件指纹用于将不同的业务告警信息进行合并。

示例性地，以合并规则集合中包括一个合并规则【告警级别信息(一级)+链路调用信息】为例，对事件指纹确定过程进行说明。在接收到针对目标应用程序A-内容的业务告警信息时，通过所述业务告警信息的属性信息中的应用服务标识信息，可以确定所述业务告警信息属于业务线1的二级业务线，进而根据预设的业务线与合并规则集合对应关系可以获取到与该业务线1的二级业务线匹配的目标合并规则集合【告警级别信息(一级)+链路调用信息】。因此，在所述业务告警信息的告警级别信息为一级的情况下，可以通过应用服务标识信息获取到与所述目标应用程序A对应的链路调用信息，假设该链路调用信息的ID为“1234567”，那么所确定的事件指纹则为“目标应用程序A-内容/一级/1234567”。

需要说明的是，在所述合并规则集合中包括多个(两个以上)合并规则的情况下，为了避免将同一个业务告警信息合并到不同的告警事件中，各个合并规则所包括合并维度信息之间的交集小于预设范围，也即，同一个合并规则集合中的不同合并规则之间应具有一定的互斥性。

比如，若同一个规则合并集合中的一个合并规则包括告警来源信息以及应用服务标识信息，而另一个合并规则包括告警来源信息、应用服务标识信息以及告警级别信息，也即，该两个合并集合中的交集包括了两个合并维度信息“警来源信息”以及“应用服务标识信息”，因此，该业务告警信息可能会被合并到不同的两个告警事件中。

S104，判断在预设时间段内是否存在与所述事件指纹相同的目标告警事件，并在所述预设时间段内存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息合并到所述目标告警事件中。

示例性地，在得到所述业务告警信息对对应的事件指纹后，即可判断在预设时间段内(如10分钟)是否存在与所述事件指纹相同的目标告警事件，并在所述预设时间段内存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息合并到所述目标告警事件中，如此，不仅有利于维护人员对告警原因进行分析，还可以减少对维护人员的告警打扰次数，并且通过同一告警事件可以同时看到多个业务告警信息，并不会遗漏相关业务告警信息。其中，告警事件用于表征具有相同事件指纹的业务告警信息的集合，目标告警事件为多个告警事件中的一个。

其中，预设时间段可以根据实际需求而设置，比如，该预设时间段可以为10分钟、15分钟，也可以是小时级别，具体不做限定。

下面以具体的示例对基于事件指纹对业务告警信息进行合并的过程进行说明。

例如，针对目标应用程序A-内容的业务，需求为将来自监控平台1的级别为一级的业务告警信息按照【告警级别信息+链路调用信息】进行合并。

具体地，在接收到针对目标应用程序A-内容的业务告警信息时，与上述事件指纹的确定过程类似，可以确定当前业务告警信息的事件指纹为“目标应用程序A-内容/监控平台1/一级/12345”，如此，可以将10分钟(预设时间段)内与该事件指纹相同的业务告警信息合并到同一目标告警事件下。

例如，以告警级别相同的两个业务告警信息为例进行说明，若该目标应用程序A包括a、b、c、d、e五个子服务，且具有相应的调用关系，若第一时刻接收到业务告警信息1，且业务告警信息1为针对a子服务的告警，a属于以上链路，链路ID为12345，第二时刻接收业务告警信息2，业务告警信息2为e子服务的告警，由于e属于以上链路，链路ID也为12345，进而可以将业务告警信息2与业务告警信息1合并到同一目标告警事件下。

参见图2所示，为本公开实施例提供的一种业务告警信息处理方法的过程示意图，与图1中的流程图中所指示的过程不同的是，在所述预设时间段内不存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息与所述事件指纹关联并存储。

承接上述实施例，若在确定事件指纹为“目标应用程序A-内容/监控平台1/一级/12345”后，在预设时间段内不存在与该事件指纹相同的事件，则可以将所述业务告警信息与所述事件指纹关联并存储，如此，预设之间段内当前时刻之后的业务告警信息的事件指纹与该事件指纹相同，则可以与该业务告警信息进行合并。

本公开实施例中，在所述预设时间段内不存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息与所述事件指纹关联并存储，如此，可保证具有不同事件指纹的业务告警信息分开合并，进而有利于维护人员对不同告警事件下的业务告警信息进行区分，便于维护人员分析告警原因。

在一些实施例中，在所述预设时间段到达后，可以将所述目标告警事件发送至目标用户，其中，所述目标告警事件携带聚合标识，所述聚合标识用于表征所述目标告警事件聚合的具有相同事件指纹的业务告警信息的数量，如此，可以不仅可以将预设时间段内的业务告警信息发送到目标用户，以提醒目标用户及时对业务告警信息进行查看，还可以降低对目标用户的打扰次数。此外，通过聚合标识可以直观的使得目标用户看到该目标告警事件下所聚合的业务告警信息的数量。

本公开实施例中，所述目标用户为对应用程序进行维护的维护人员。

可以理解，在一些实施例中，还可以确定每个告警事件下的各个业务告警信息的潜在告警原因，并将所述潜在告警原因送至所述目标用户，如此，可以进一步便于所述目标用户对所述业务告警信息的告警原因进行分析。例如，可以针对每个业务告警信息确定多个潜在告警原因以供所述目标用户选择，并将所述目标用户的选择结果进行记录和保存。

可选的，所述方法还包括，在所述目标用户未对所述业务告警信息进行处理的情况下，向所述目标用户发送提示信息，以提醒所述目标用户对所述业务告警信息进行处理，并将处理结果进行记录和统计分析。

例如，在目标用户对某一业务告警信息进行处理后，可以对处理的业务告警信息进行标记，如此，可以根据所述目标用户的标记信息确定所述业务告警信息已被处理，并在确定所述目标用户未对接收到的告警信息进行处理的情况下，生成提示信息以对目标用户进行提醒，该提示信息可以通过短信、即时交互软件的交互信息或者邮件的形式实现。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一技术构思，本公开实施例中还提供了与业务告警信息处理方法对应的业务告警信息处理装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述业务告警信息处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图3所示，为本公开实施例提供的一种业务告警信息处理装置300的示意图，所述装置包括：

告警信息接收模块301，用于根据业务告警信息的属性信息，确定所述业务告警信息所属的目标业务线；

合并规则确定模块302，用于基于预先配置好的业务线与合并规则集合的对应关系，确定与所述目标业务线匹配的目标合并规则集合；其中，每个合并规则集合包括至少一个合并规则，每个合并规则包括至少一个合并维度信息；

事件指纹生成模块303，用于基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，所述事件指纹用于表征所述业务告警信息的标识信息；

告警信息合并模块304，用于基于所述事件指纹，判断在预设时间段内是否存在与所述事件指纹相同的目标告警事件，并在所述预设时间段内存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息合并到所述目标告警事件中。

在一种可能的实施方式中，所述业务告警信息合并模块304还用于：

在所述预设时间段内不存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息与所述事件指纹关联并存储。

在一种可能的实施方式中，在所述合并规则集合中包括多个合并规则的情况下，各个合并规则所包括合并维度信息之间的交集小于预设范围。

在一种可能的实施方式中，所述事件指纹生成模块303具体用于：

判断所述业务告警信息是否符合过滤条件，并在所述业务告警信息符合所述过滤条件的情况下，基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹；其中，所述过滤条件用于指示对预设类型的业务告警信息进行合并。

参见图4所示，在一种可能的实施方式中，所述装置还包括：

合并规则设置模块305，用于获取所述用户为不同的业务线配置的合并规则集合，并基于规则引擎生成所述业务线与合并规则集合的对应关系。

在一种可能的实施方式中，所述合并维度信息包括以下至少一种：

告警来源信息、告警类别信息、应用服务标识信息、告警级别信息、告警名称信息及应用链路信息。

在一种可能的实施方式中，所述业务告警信息合并模块304还用于：

在所述预设时间段到达后，将所述目标告警事件发送至目标用户，其中，所述目标告警事件携带聚合标识，所述聚合标识用于表征所述目标告警事件聚合的具有相同事件指纹的业务告警信息的数量。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

基于同一技术构思，本公开实施例还提供了一种电子设备。参照图5所示，为本公开实施例提供的电子设备500的结构示意图，包括处理器501、存储器502、和总线503。其中，存储器502用于存储执行指令，包括内存5021和外部存储器5022；这里的内存5021也称内存储器，用于暂时存放处理器501中的运算数据，以及与硬盘等外部存储器5022交换的数据，处理器501通过内存5021与外部存储器5022进行数据交换。

本申请实施例中，存储器502具体用于存储执行本申请方案的应用程序代码，并由处理器501来控制执行。也即，当电子设备500运行时，处理器501与存储器502之间通过总线503通信，使得处理器501执行存储器502中存储的应用程序代码，进而执行前述任一实施例中所述的方法。

其中，存储器502可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read－Only Memory，PROM)，可擦除只读存储器(Erasable Programmable Read－Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read－Only Memory，EEPROM)等。

处理器501可能是一种集成电路芯片，具有信号的处理能力。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备500的具体限定。在本申请另一些实施例中，电子设备500可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中的业务告警信息处理方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例还提供一种计算机程序产品，该计算机程序产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中的业务告警信息处理方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.一种业务告警信息处理方法，其特征在于，包括：

根据业务告警信息的属性信息，确定所述业务告警信息所属的目标业务线；

基于预先配置好的业务线与合并规则集合的对应关系，确定与所述目标业务线匹配的目标合并规则集合；其中，每个合并规则集合包括至少一个合并规则，每个合并规则包括至少一个合并维度信息；

基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，所述事件指纹用于表征所述业务告警信息的标识信息；

判断在预设时间段内是否存在与所述事件指纹相同的目标告警事件，并在所述预设时间段内存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息合并到所述目标告警事件中。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述预设时间段内不存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息与所述事件指纹关联并存储。

3.根据权利要求1所述的方法，其特征在于，在所述合并规则集合中包括多个合并规则的情况下，各个合并规则所包括合并维度信息之间的交集小于预设范围。

4.根据权利要求1所述的方法，其特征在于，所述基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，包括：

判断所述业务告警信息是否符合过滤条件，并在所述业务告警信息符合所述过滤条件的情况下，基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹；其中，所述过滤条件用于指示对预设类型的业务告警信息进行合并。

5.根据权利要求1-4中任一项所述的方法，其特征在于，所述方法还包括：

获取所述用户为不同的业务线配置的合并规则集合，并基于规则引擎生成所述业务线与合并规则集合的对应关系。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述合并维度信息包括以下至少一种：

告警来源信息、告警类别信息、应用服务标识信息、告警级别信息、告警名称信息及应用链路信息。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述方法还包括：

在所述预设时间段到达后，将所述目标告警事件发送至目标用户；其中，所述目标告警事件携带聚合标识，所述聚合标识用于表征所述目标告警事件聚合的具有相同事件指纹的业务告警信息的数量。

8.一种业务告警信息处理装置，其特征在于，包括：

告警信息接收模块，用于根据业务告警信息的属性信息确定所述业务告警信息所属的目标业务线；

合并规则确定模块，用于基于预先配置好的业务线与合并规则集合的对应关系，确定与所述目标业务线匹配的目标合并规则集合；其中，每个合并规则集合包括至少一个合并规则，每个合并规则包括至少一个合并维度信息；

事件指纹生成模块，用于基于所述目标合并规则集合以及所述业务告警信息的属性信息，生成针对所述业务告警信息的事件指纹，所述事件指纹用于表征所述业务告警信息的标识信息；

告警信息合并模块，用于基于所述事件指纹判断在预设时间段内是否存在与所述事件指纹相同的目标告警事件，并在所述预设时间段内存在与所述事件指纹相同的目标告警事件的情况下，将所述业务告警信息合并到所述目标告警事件中。

9.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1-7任一所述的业务告警信息处理方法。

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1-7任一所述的业务告警信息处理方法。