CN110888754A - 一种消息获得方法及装置 - Google Patents

Abstract

本发明实施例提供了一种消息获得方法及装置，上述方法包括：获得告警消息，其中，所述告警消息包括：引发生成所述告警消息的故障的类型；从所获得的告警消息中，确定告警消息组，其中，每一告警消息组包含的告警消息由提供同一服务的服务器生成；针对每一告警消息组，对该告警消息组中包括同一故障的类型的告警消息进行合并处理，得到提示服务器存在故障的告警消息，作为故障告警消息。应用本发明实施例提供的方案获得消息时，能够提高故障排除的效率。

Description

一种消息获得方法及装置

技术领域

本发明涉及数据监测技术领域，特别是涉及一种消息获得方法及装置。

背景技术

服务器发生故障时，会针对故障生成告警消息，这样运维人员可以根据告警消息确定发生故障的服务器，并排除所确定服务器发生的故障。

然而，当大量服务器同时发生相同类型的故障时，例如：每台服务器上硬件出现故障，例如：CPU、内存等出现故障。那么这些服务器可能会同时生成告警消息。由于发生故障的服务器数量众多，上述告警消息的数量也会较多，运维人员在面对数量众多的告警消息时，难以快速排除服务器发生的故障，从而导致故障排除效率低。

发明内容

本发明实施例的目的在于提供一种消息获得方法及装置，以提高故障排除效率。具体技术方案如下：

第一方面，本发明实施例提供了一种消息获得方法，所述方法包括：

获得告警消息，其中，所述告警消息包括：引发生成所述告警消息的故障的类型；

从所获得的告警消息中，确定告警消息组，其中，每一告警消息组包含的告警消息由提供同一服务的服务器生成；

针对每一告警消息组，对该告警消息组中包括同一故障的类型的告警消息进行合并处理，得到提示服务器存在故障的告警消息，作为故障告警消息。

本发明的一个实施例中，在所述得到提示服务器存在故障的告警消息，作为故障告警消息之后，还包括：

确定引发各个源服务出现各种源故障的服务，作为目的服务，其中，所述源故障为：故障告警消息包括的类型对应的故障，所述源服务为：生成故障告警消息的服务器提供的服务；

将各个故障告警消息中由提供目的服务的服务器生成的告警消息确定为最终告警消息。

本发明的一个实施例中，上述方法还包括：

针对每一目的服务，获得提供该目的服务的服务器的总数量和故障数量，并将所述总数量和故障数量添加至目的服务器生成的最终告警消息，其中，所述目的服务器为：提供该目的服务的服务器中生成了最终告警消息的服务器，所述故障数量为：目的服务器的数量。

本发明的一个实施例中，上述从所获得的告警消息中，确定告警消息组，包括：

确定生成所获得的告警消息的服务器的标识；

根据预设的服务器的标识与服务之间的对应关系，确定生成所获得的告警消息的服务器提供的服务；

针对每一所确定的服务，从所获得的告警消息中，确定由提供该服务的服务器生成的告警消息，得到包含所确定告警消息的告警消息组。

本发明的一个实施例中，上述方法还包括：

向告警接收用户使用的设备发送所述最终告警消息。

第二方面，本发明实施例提供了一种消息获得装置，所述装置包括：

告警消息获得模块，用于获得告警消息，其中，所述告警消息包括：引发生成所述告警消息的故障的类型；

告警消息组确定模块，用于从所获得的告警消息中，确定告警消息组，其中，每一告警消息组包含的告警消息由提供同一服务的服务器生成；

故障告警消息确定模块，用于针对每一告警消息组，对该告警消息组中包括同一故障的类型的告警消息进行合并处理，得到提示服务器存在故障的告警消息，作为故障告警消息。

本发明的一个实施例中，所述装置还包括：

目的服务确定模块，用于在所述故障告警消息确定模块得到所述故障告警消息之后，确定引发各个源服务出现各种源故障的服务，作为目的服务，其中，所述源故障为：故障告警消息包括的类型对应的故障，所述源服务为：生成故障告警消息的服务器提供的服务；

最终告警消息确定模块，用于将各个故障告警消息中由提供目的服务的服务器生成的告警消息确定为最终告警消息。

本发明的一个实施例中，上述装置还包括：

数量添加模块，用于针对每一目的服务，获得提供该目的服务的服务器的总数量和故障数量，并将所述总数量和故障数量添加至目的服务器生成的最终告警消息，其中，所述目的服务器为：提供该目的服务的服务器中生成了最终告警消息的服务器，所述故障数量为：目的服务器的数量。

本发明的一个实施例中，上述告警消息组确定模块，包括：

服务器标识确定单元，用于确定生成所获得的告警消息的服务器的标识；

服务确定单元，用于根据预设的服务器的标识与服务之间的对应关系，确定生成所获得的告警消息的服务器提供的服务；

告警消息组确定单元，用于针对每一所确定的服务，从所获得的告警消息中，确定由提供该服务的服务器生成的告警消息，得到包含所确定告警消息的告警消息组。

本发明的一个实施例中，上述装置还包括：

消息发送模块，用于向告警接收用户使用的设备发送所述最终告警消息。

第三方面，本发明实施例提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现上述第一方面所述的方法步骤。

第四方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的方法步骤。

由以上可见，应用本发明实施例提供的方案获得消息时，根据所获得的告警消息，将提供同一服务的服务器生成的告警消息作为告警消息组，并针对每一告警消息组，将同一故障类型的告警消息进行合并处理，获得故障告警消息。可见，本发明实施例提供的方案中，所获得的告警消息是对提供同一服务的服务器生成的告警消息进行了合并处理后的告警消息，而现有技术中所获得的告警消息直接是各个服务器生成的告警消息，因此，本发明实施例提供的方案与现有技术相比，大大减少了最终获得的告警消息的数量，从而运维人员能够在较少的告警消息进行故障排除，免受相同告警消息的干扰，提高了故障排除效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种云存储系统中服务的框架图；

图2为本发明实施例提供的第一种消息获得方法的流程示意图；

图3为本发明实施例提供的第二种消息获得方法的流程示意图；

图4为本发明实施例提供的一种数据传输路径的示意图；

图5为本发明实施例提供的一种树形结构的示意图；

图6为本发明实施例提供的一种告警消息处理系统的示意图；

图7为本发明实施例提供的第一种消息获得装置的结构示意图；

图8为本发明实施例提供的第二种消息获得装置的结构示意图；

图9为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

首先，对本发明实施例中涉及到的概念进行说明。

1、服务：服务是由服务器提供的，因此可以将服务理解为服务器所实现的功能。例如：上述服务可以包括请求接入服务、请求处理服务、消息发送服务等等。具体的，可以将不同的服务封装成不同的组件，部署在服务器上，从而服务器能够为用户提供服务。

2、告警消息：当服务器所处的网络出现故障，或者服务器在对外提供服务的过程中出现故障时，生成的用于告知工作人员出现上述故障的消息。

然后，对本发明实施例的应用场景进行介绍。

本发明实施例的应用场景可以为：多台服务器联合为用户提供服务的场景。也就是说，本发明实施例的应用场景中包含的、用于对外提供服务的服务器数量较多。例如：上述场景可以为云存储系统对应的应用场景、云计算系统对应的应用场景等。

以云存储系统为例，参见图1，图1为本发明实施例提供的一种云存储系统中服务的框架图。图1中每个矩形框表示云存储系统中的服务，具体包括：请求接入服务、请求处理服务、元数据管理服务、数据存储服务、缓存服务、数据库服务、配置中心服务、消息队列服务、异步处理服务等。箭头表示数据传输方向，从图1中可以看出，请求接入服务接入请求，获得数据后，向请求处理服务发送数据，请求处理服务对数据进行处理后，可以向缓存服务、数据库服务、元数据管理服务、数据存储服务、配置中心服务、消息队列服务发送数据，消息队列服务对数据进行处理后，可以向异步处理服务发送数据。这些服务可以部署在多台服务器中，这样可以处理大量请求和海量数据。

接下来在对本发明实施例的执行主体进行说明。

本发明实施例的执行主体可以有以下两种情况：

第一种情况，本发明实施例的执行主体可以为具有管理作用的服务器，为便于描述称为管理服务器。在这种情况下，上述管理服务器可以是与提供服务的服务器相独立的服务器，还可以是某一台提供服务的服务器。

第二种情况，本发明实施例的执行主体可以为客户端。上述客户端可以为运维人员使用的电子设备，例如：电子设备可以为手机、电脑等。

下面通过具体实施例对本发明实施例提供的消息获得方法及装置进行详细说明。

参见图2，图2为本发明实施例提供的第一种消息获得方法的流程示意图，上述方法包括S201-S203。

S201：获得告警消息。

上述告警消息可以是由提供服务的服务器生成的。当服务器处于故障状态时，根据所发生的故障类型，可以生成对应的告警消息。例如：当发生故障的类型为CPU故障时，可以生成表示CPU发生故障的告警消息。因此，上述告警消息可以包括：引发生成告警消息的故障的类型。

具体的，服务器生成告警消息时，可以检测服务器是否处于故障状态，若为是，则生成与发生故障的故障类型对应的告警消息。在检测服务器是否处于故障状态时，可以通过对运行时的状态数据进行监测，例如，上述状态数据可以是CPU占用率、内存占用率等。监测方式可以为周期性监测、定时监测等。当监测到的状态数据处于预设的正常范围内时，可以视为服务器处于正常状态。反之，当监测到的状态数据不位于预设的正常范围内时，可以视为当前服务器处于故障状态。例如：假设上述状态数据为CPU占用率，且预设的CPU占用率正常范围为0％～60％。当监测到CPU占用率为30％时，由于位于0％～60％之间，因此当前服务器处于正常状态。当监测到CPU占用率为70％时，由于不位于0％～60％之间，因此当前服务器处于故障状态。

上述告警消息还可以是由本发明实施例的执行主体生成的。具体的，当网络链路发生故障、网络发生拥塞等网络状况较差的情况时，会导致服务器无法正常运行，那么本发明实施例的执行主体无法获得服务器的任何消息，在这种情况下，也可以生成告警消息。

具体的，获得上述告警消息时，可以按照预设的告警消息采集方式，采集服务器的告警消息，从而获得告警消息。还可以定时或者周期性向提供服务的服务器发送告警消息获得请求，获得告警消息。还可以监测上述提供服务的服务器的网络状况，当网络发生故障时，生成告警消息。

S202：从所获得的告警消息中，确定告警消息组。

上述告警消息组为告警消息的集合、且包含的告警消息由提供同一服务的服务器生成。

在确定告警消息组时，可以在所获得的告警消息中，确定提供同一服务的服务器，并获得提供同一服务的服务器生成的告警消息，将提供同一服务的服务器生成的告警消息作为告警消息组。

例如：假设有3个服务，分别为服务A、服务B、服务C，30台服务器，分别为(服务器1，服务器2……服务器30)，其中各个服务与各个服务器的对应关系如下表1所示。

表1

服务	服务器
		服务A	(服务器1，服务器2，……服务器10)
服务B	(服务器11，服务器12，……服务器20)
		服务C	(服务器21，服务器22，……服务器30)

所获得的告警消息是由服务器1、服务器2、服务器11、服务器12、服务器21、服务器22生成的。由于服务器1和服务器2提供同一个服务A，服务器11和服务器12提供同一个服务B，服务器21和服务器22提供同一个服务C。

这样，可以形成三个告警消息组，分别是服务器1和服务器2生成的告警消息组成的告警消息组1，服务器11和服务器12生成的告警消息组成的告警消息组2，分别是服务器21和服务器22生成的告警消息组成的告警消息组3。

S203：针对每一告警消息组，对该告警消息组中包括同一故障的类型的告警消息进行合并处理，得到提示服务器存在故障的告警消息，作为故障告警消息。

由于告警消息组中包含的告警消息可以携带有故障的类型，那么可以确定同一故障的类型的告警消息。在对上述同一故障的类型的告警消息进行合并处理时，可以是按照预设的故障告警消息的格式对告警消息进行合并。例如：上述预设的故障告警消息的格式可以为[告警时间，故障类型，告警服务]，可以将同一故障的类型的告警消息合并为一条格式为[告警时间，故障类型，告警服务]的故障告警消息。

由以上可见，应用本实施例提供的方案获得消息时，根据所获得的告警消息，将提供同一服务的服务器生成的告警消息作为告警消息组，并针对每一告警消息组，将同一故障类型的告警消息进行合并处理，获得故障告警消息。可见，本实施例提供的方案中，所获得的告警消息是对提供同一服务的服务器生成的告警消息进行了合并处理后的告警消息，而现有技术中所获得的告警消息直接是各个服务器生成的告警消息，因此，本实施例提供的方案与现有技术相比，大大减少了最终获得的告警消息的数量，从而运维人员能够在较少的告警消息进行故障排除，免受相同告警消息的干扰，提高了故障排除效率。

本发明的一个实施例中，参见图3，提供了第二种消息获得方法的流程示意图，在上述S203确定故障告警消息之后，还可以包括S204-S205。

S204：确定引发各个源服务出现各种源故障的服务，作为目的服务。

上述源故障为：故障告警消息包括的类型对应的故障，上述故障告警消息为S203中确定的故障告警消息。根据各个故障告警消息包括的故障的类型，可以确定源故障，例如：故障告警消息1包括的故障的类型为CPU故障，故障告警消息2包括的故障的类型为内存故障，那么可以确定源故障为CPU故障、内存故障。

上述源服务为：生成上述故障告警消息的服务器提供的服务。

具体的，在对数据进行处理时，数据按照预设的数据传输路径进行传输，上述预设的数据传输路径上的各个节点表示为各个服务。

例如：参见图4，图4为本发明实施例提供的一种数据传输路径的示意图，各个矩形框表示各个服务，这些服务分别为请求接入服务、请求处理服务、元数据管理服务，箭头方向表示数据传输方向，数据按照箭头的方向在各个服务之间进行传输。

若元数据管理服务发生故障时，由于请求接入服务、请求处理服务无法请求到元数据管理服务所提供的服务，导致请求接入服务和请求处理服务也被认为发生故障，这种情况下可以认为元数据管理服务导致了请求接入服务和请求处理服务出现故障，那么请求接入服务、请求处理服务为源服务，元数据管理服务为目的服务。

另外，若请求处理服务发生故障时，由于请求接入服务无法请求到请求处理服务所提供的服务，导致请求接入服务被认为发生故障。但是由于请求处理服务出现故障，而元数据管理服务不会向请求处理服务请求服务，所以请求处理服务出现的故障不会对元数据管理服务产生影响。这种情况，可以认为请求处理服务导致了请求接入服务出现故障，但是不会导致元数据管理服务出现故障，那么请求接入服务为源服务，而请求处理服务为目的服务。

S205：将各个故障告警消息中由提供目的服务的服务器生成的告警消息确定为最终告警消息。

在确定目的服务后，可以根据预设的服务与服务器的标识之间的对应关系，确定提供目的服务的服务器的标识。根据所确定的服务器的标识，将所确定的服务器的标识对应的服务器生成的告警消息确定为最终告警消息。

由以上可见，应用本实施例提供的方案获得消息时，由于确定了目的服务后，仅将提供目的服务的服务器生成的告警消息作为最终告警消息，进一步减少了告警消息数量。这样运维人员面对的告警消息数量也会进一步减少，进而能够更加快速的定位出引发源服务故障的目的服务，提高了故障排除的效率。

本发明的一个实施例中，在上述S202从所获得的告警消息中，确定告警消息组，可以包括以下步骤A1-A3。

步骤A1：确定生成所获得的告警消息的服务器的标识。

具体的，在确定上述服务器的标识时，可以有以下几种情况：

第一种情况：当告警消息中携带有生成该告警消息服务器的标识时，那么在获得告警消息后，可以根据告警消息携带的服务器的标识，确定服务器的标识。

第二种情况：可以根据预先存储的消息获得的通道与服务器的标识之间的对应关系，可以确定生成告警消息的服务器的标识。

步骤A2：根据预设的服务器的标识与服务之间的对应关系，确定生成所获得的告警消息的服务器提供的服务。

上述预设的服务器的标识与服务之间的对应关系可以为一个服务与多台服务器的标识之间的对应关系。

例如：假设有30台服务器，这30台服务器的标识分别为：1，2，3……30，前10台服务器提供请求接入服务，中间10台服务器提供请求处理服务，最后10台服务器提供元数据管理服务，那么上述对应关系可以如下表2所示。

表2

服务名称	服务器的标识
		请求接入服务	1，2，3……10
请求处理服务	11，12，13……20
		元数据管理服务	21，22，23……30

上述对应关系还可以是一个服务与一台服务器之间的对应关系。

例如：假设有3台服务器，这3台服务器的标识分别为：1，2，3，第一台服务器提供请求接入服务，第二台服务器提供请求处理服务，第三台服务器提供元数据管理服务，那么请求接入服务与1之间存在对应关系，请求处理服务与2之间存在对应关系，元数据管理服务与3之间存在对应关系。

本发明的一个实施例中，上述服务器的标识与服务之间的对应关系可以用树形结构来表示。

参见图5，图5为本发明实施例提供的一种树形结构的示意图，其中，服务a、服务b、服务c表示三种服务的标识，服务器a1、服务器a2、服务器a3、服务器b1、服务器b2、服务器b3、服务器c1、服务器c2、服务器c3均表示服务器的标识，“应用”表示由各个服务形成的业务。由图5可以看出，服务器的标识与服务之间的对应关系包括：

服务a对应于服务器a1、服务器a2、服务器a3；服务b对应于服务器b1、服务器b2、服务器b3；服务c对应于服务器c1、服务器c2、服务器c3。

在上述描述的基础上，根据步骤A1中所确定的服务器标识、预设的服务器的标识与服务之间的对应关系，可以确定生成所获得的告警消息的服务器提供的服务。

步骤A3：针对每一所确定的服务，从所获得的告警消息中，确定由提供该服务的服务器生成的告警消息，得到包含所确定告警消息的告警消息组。

具体的，从所获得的告警消息中，确定由提供每一服务的服务器生成的告警消息时，可以按照预设的服务器的标识与服务之间的对应关系，获得提供同一服务的服务器生成的告警消息。

例如，假设有10台服务器，这10台服务器的标识分别为服务器1，服务器2，……服务器10，预设的服务器的标识与服务之间的对应关系如下表3所示。

表3

服务	服务器的标识
		请求接入服务	服务器1，服务器2，……，服务器5
请求处理服务	服务器6，服务器7，……，服务器10

根据上述表3，可以将服务器1、服务器2、……、服务器5生成的告警消息，作为提供请求接入服务的服务器生成的告警消息，并得到包含这些告警消息的告警消息组。将服务器6、服务器7、……、服务器10生成的告警消息，作为提供请求处理服务的服务器生成的告警消息，并得到包含这些告警消息的告警消息组。

这样，根据预设的服务器的标识与服务之间的对应关系，可以快速获得提供同一服务的服务器生成的告警消息，从而提高了获得告警消息组的效率。

本发明的一个实施例中，在上述S105中确定最终告警消息后，可以针对每一目的服务，获得提供该目的服务的服务器的总数量和故障数量，并将总数量和故障数量添加至目的服务器生成的最终告警消息。

上述目的服务器为：提供该目的服务的服务器中生成了最终告警消息的服务器，也就是提供目的服务的服务器中发生故障的服务器，上述故障数量为：目的服务器的数量。具体的，可以对生成最终告警消息的服务器数量进行统计，获得故障数量。

在获得提供目的服务的服务器的总数量时，可以根据预设的服务与服务器的标识之间的对应关系，确定与目的服务对应的服务器的标识，从而可以统计提供目的服务的服务器的总数量。

本发明的一个实施例中，上述最终告警消息的格式可以为：

[告警时间、故障类型、目的服务、故障数量/总数量、是否影响其他服务：是/否、源服务]。

例如，假设，告警时间为：2019-09-16 10:12:23，故障类型为：机器磁盘故障，目的服务为：元数据管理服务，故障数量为：3，总数量为：79，是否影响其他服务：是，受影响的服务列表：请求处理服务、请求接入服务。

则上述最终告警消息为：

[2019-09-16 10:12:23、机器磁盘故障、元数据管理服务、3/79、是、请求处理服务和请求接入服务]。

这样将总数量和故障数量添加至最终告警消息，能够使得运维人员根据获得的最终告警消息充分掌握当前故障情况，提高了故障排除效率。

本发明的一个实施例中，在确定最终告警消息后，还可以向告警接收用户使用的设备发送最终告警消息。

上述告警接收用户可以为运维人员等，上述告警接收用户使用的设备可以是运维人员使用的手机、平板电脑等。

具体的，发送最终告警消息的形式可以包括邮件、短信、电话等形式。

这样将最终告警消息发送至告警接收用户使用的设备，能够使得告警接收用户可以及时了解到服务器所发生的故障，进而针对最终告警消息快速进行故障排除，提高了故障排除效率。

本发明的一个实施例中，告警接收用户在接收到最终告警消息后，可以针对最终告警消息进行信息查询。具体的，接收到查询请求后，可以查询上述查询请求所请求的信息，向告警接收用户发送查询到的信息。

具体的，上述查询请求可以是用于查询最终告警消息的详细信息的请求。这种情况下，上述详细信息可以包括：故障发生时间、发生故障的服务器的IP地址等信息。

另外，上述查询请求还可以是用于查询生成上述最终告警消息的服务器的历史故障信息的请求。这种情况下，上述详细信息可以包括生成最终告警消息的服务器的历史故障信息等。

这样告警接收用户可以根据查询到的信息，了解服务器所发生故障的具体情况和/或历史情况，进而有针对性的对故障进行有效排除，提高了故障排除的效率。

具体的，在本发明实施例的执行主体为上述管理服务器时，该管理服务器和各个提供服务的服务器可以组成告警消息处理系统。

下面结合图6通过具体实例对上述告警消息处理系统进行详细说明。

参见图6，图6为本发明实施例提供的一种告警消息处理系统的示意图。图6中告警消息处理系统包括：服务器1、服务器2、……、服务器n-1、服务器n和管理服务器，其中，上述管理服务器未在图6中示出。

另外，从功能模块的角度，上述告警消息处理系统可以被划分为多个功能模块：告警消息采集模块、告警消息收集模块、告警消息前置处理模块，告警消息后置处理模块，告警消息发送模块以及告警消息查询模块等。

其中，告警消息采集模块位于服务器1、服务器2、……、服务器n-1、服务器n中，告警消息收集模块、告警消息前置处理模块，告警消息后置处理模块，告警消息查询模块以及告警消息发送模块位于上述管理服务器中。

上述各个模块的功能如下表4所示，各个模块按照表4中所示的功能相互配合工作，进而实现告警消息处理。

表4

与上述消息获得方法相对应，本发明实施例还提供了一种消息获得装置。

参见图7，图7为本发明实施例提供的一种消息获得装置的结构示意图，上述装置包括：

告警消息获得模块701，用于获得告警消息，其中，所述告警消息包括：引发生成所述告警消息的故障的类型。

告警消息组确定模块702，用于从所获得的告警消息中，确定告警消息组，其中，每一告警消息组包含的告警消息由提供同一服务的服务器生成。

故障告警消息确定模块703，用于针对每一告警消息组，对该告警消息组中包括同一故障的类型的告警消息进行合并处理，得到提示服务器存在故障的告警消息，作为故障告警消息。

由以上可见，应用本实施例提供的方案获得消息时，根据所获得的告警消息，将提供同一服务的服务器生成的告警消息作为告警消息组，并针对每一告警消息组，将同一故障类型的告警消息进行合并处理，获得故障告警消息。可见，本实施例提供的方案中，所获得的告警消息是对提供同一服务的服务器生成的告警消息进行了合并处理后的告警消息，而现有技术中所获得的告警消息直接是各个服务器生成的告警消息，因此，本实施例提供的方案与现有技术相比，大大减少了最终获得的告警消息的数量，从而运维人员能够在较少的告警消息进行故障排除，免受相同告警消息的干扰，提高了故障排除效率。

本发明的一个实施例中，参见图8，图8为本发明实施例提供的第二种消息获得装置的结构示意图，在所述故障告警消息确定模块703之后，还包括：

目的服务确定模块704，用于在故障告警消息确定模块703得到所述故障告警消息之后，确定引发各个源服务出现各种源故障的服务，作为目的服务，其中，所述源故障为：故障告警消息包括的类型对应的故障，所述源服务为：生成故障告警消息的服务器提供的服务。

最终告警消息确定模块705，用于将各个故障告警消息中由提供目的服务的服务器生成的告警消息确定为最终告警消息。

由以上可见，应用本实施例提供的方案获得消息时，由于确定了目的服务后，仅将提供目的服务的服务器生成的告警消息作为最终告警消息，进一步减少了告警消息数量。这样运维人员面对的告警消息数量也会进一步减少，进而能够更加快速的定位出引发源服务故障的目的服务，提高了故障排除的效率。

本发明的一个实施例中，上述装置还包括：

数量添加模块，用于针对每一目的服务，获得提供该目的服务的服务器的总数量和故障数量，并将所述总数量和故障数量添加至目的服务器生成的最终告警消息，其中，所述目的服务器为：提供该目的服务的服务器中生成了最终告警消息的服务器，所述故障数量为：目的服务器的数量。

这样，将总数量和故障数量添加至最终告警消息，能够使得运维人员根据获得的最终告警消息充分掌握当前故障情况，提高了故障排除效率。

本发明的一个实施例中，上述告警消息组确定模块702，包括：

服务器标识确定单元，用于确定生成所获得的告警消息的服务器的标识；

服务确定单元，用于根据预设的服务器的标识与服务之间的对应关系，确定生成所获得的告警消息的服务器提供的服务。

告警消息组确定单元，用于针对每一所确定的服务，从所获得的告警消息中，确定由提供该服务的服务器生成的告警消息，得到包含所确定告警消息的告警消息组。

这样，根据预设的服务器的标识与服务之间的对应关系，可以快速获得提供同一服务的服务器生成的告警消息，从而提高了获得告警消息组的效率。

本发明的一个实施例中，上述装置还包括：

消息发送模块，用于向告警接收用户使用的设备发送所述最终告警消息。

这样将最终告警消息发送至告警接收用户使用的设备，能够使得告警接收用户可以及时了解到服务器所发生的故障，进而针对最终告警消息快速进行故障排除，提高了故障排除效率。

与上述消息获得方法相对应，本发明实施例还提供了一种电子设备。

本发明实施例还提供了一种电子设备，如图9所示，包括处理器901、通信接口902、存储器903和通信总线904，其中，处理器901，通信接口902，存储器903通过通信总线904完成相互间的通信，

存储器903，用于存放计算机程序；

处理器901，用于执行存储器903上所存放的程序时，实现本发明实施例提供的消息获得方法。

上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现本发明实施例提供的消息获得方法。

在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行时实现本发明实施例提供的消息获得方法。

由以上可见，应用上述实施例提供的方案获得消息时，根据所获得的告警消息，将提供同一服务的服务器生成的告警消息作为告警消息组，并针对每一告警消息组，将同一故障类型的告警消息进行合并处理，获得故障告警消息。可见，本实施例提供的方案中，所获得的告警消息是对提供同一服务的服务器生成的告警消息进行了合并处理后的告警消息，而现有技术中所获得的告警消息直接是各个服务器生成的告警消息，因此，本实施例提供的方案与现有技术相比，大大减少了最终获得的告警消息的数量，从而运维人员能够在较少的告警消息进行故障排除，免受相同告警消息的干扰，提高了故障排除效率。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备、计算机可读存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

Claims (12)

1.一种消息获得方法，其特征在于，所述方法包括：

获得告警消息，其中，所述告警消息包括：引发生成所述告警消息的故障的类型；

从所获得的告警消息中，确定告警消息组，其中，每一告警消息组包含的告警消息由提供同一服务的服务器生成；

针对每一告警消息组，对该告警消息组中包括同一故障的类型的告警消息进行合并处理，得到提示服务器存在故障的告警消息，作为故障告警消息。

2.根据权利要求1所述的方法，其特征在于，在所述得到提示服务器存在故障的告警消息，作为故障告警消息之后，所述方法还包括：

确定引发各个源服务出现各种源故障的服务，作为目的服务，其中，所述源故障为：故障告警消息包括的类型对应的故障，所述源服务为：生成故障告警消息的服务器提供的服务；

将各个故障告警消息中由提供目的服务的服务器生成的告警消息确定为最终告警消息。

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

针对每一目的服务，获得提供该目的服务的服务器的总数量和故障数量，并将所述总数量和故障数量添加至目的服务器生成的最终告警消息，其中，所述目的服务器为：提供该目的服务的服务器中生成了最终告警消息的服务器，所述故障数量为：目的服务器的数量。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述从所获得的告警消息中，确定告警消息组，包括：

确定生成所获得的告警消息的服务器的标识；

根据预设的服务器的标识与服务之间的对应关系，确定生成所获得的告警消息的服务器提供的服务；

针对每一所确定的服务，从所获得的告警消息中，确定由提供该服务的服务器生成的告警消息，得到包含所确定告警消息的告警消息组。

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

向告警接收用户使用的设备发送所述最终告警消息。

6.一种消息获得装置，其特征在于，所述装置包括：

告警消息获得模块，用于获得告警消息，其中，所述告警消息包括：引发生成所述告警消息的故障的类型；

告警消息组确定模块，用于从所获得的告警消息中，确定告警消息组，其中，每一告警消息组包含的告警消息由提供同一服务的服务器生成；

故障告警消息确定模块，用于针对每一告警消息组，对该告警消息组中包括同一故障的类型的告警消息进行合并处理，得到提示服务器存在故障的告警消息，作为故障告警消息。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

目的服务确定模块，用于在所述故障告警消息确定模块得到所述故障告警消息之后，确定引发各个源服务出现各种源故障的服务，作为目的服务，其中，所述源故障为：故障告警消息包括的类型对应的故障，所述源服务为：生成故障告警消息的服务器提供的服务；

最终告警消息确定模块，用于将各个故障告警消息中由提供目的服务的服务器生成的告警消息确定为最终告警消息。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

数量添加模块，用于针对每一目的服务，获得提供该目的服务的服务器的总数量和故障数量，并将所述总数量和故障数量添加至目的服务器生成的最终告警消息，其中，所述目的服务器为：提供该目的服务的服务器中生成了最终告警消息的服务器，所述故障数量为：目的服务器的数量。

9.根据权利要求6-8任一项所述的装置，其特征在于，所述告警消息组确定模块，包括：

服务器标识确定单元，用于确定生成所获得的告警消息的服务器的标识；

服务确定单元，用于根据预设的服务器的标识与服务之间的对应关系，确定生成所获得的告警消息的服务器提供的服务；

告警消息组确定单元，用于针对每一所确定的服务，从所获得的告警消息中，确定由提供该服务的服务器生成的告警消息，得到包含所确定告警消息的告警消息组。

10.根据权利要求7或8所述的装置，其特征在于，所述装置还包括：

消息发送模块，用于向告警接收用户使用的设备发送所述最终告警消息。

11.一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现权利要求1-5任一所述的方法步骤。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-5任一所述的方法步骤。

Images