异常数据的报警处理方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机应用技术领域，尤其涉及一种异常数据的报警处理方法、装置、电子设备及存储介质。

背景技术

随着互联网技术的蓬勃发展，互联网产品、服务层出不穷，用户通常倾向于选择服务稳定、高质量的产品与服务。数据监控报警是保障产品质量、提高服务稳定性的重要手段，即以数据为依托，制定监控规则，检测到触发规则的异常数据之后发送报警通知。

相关技术中，传统报警服务检测到异常数据后会立即发送报警通知，从而容易导致报警通知量大，相关负责人员对报警通知的重视度降低，进而制约了监控效果。

发明内容

本公开提供一种异常数据的报警处理方法、装置、电子设备、存储介质及计算机程序产品，以至少解决相关技术中，检测到异常数据后立即发送报警通知的传统报警服务，容易导致报警通知量大，相关负责人员对报警通知的重视度降低，进而制约了监控效果的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种异常数据的报警处理方法，包括：获取源异常数据的报警消息；根据所述报警消息，建立所述报警消息的生命周期；如果在所述生命周期之中检测到与所述源异常数据相关的关联异常数据，则对所述源异常数据和所述关联异常数据进行监控；以及当所述源异常数据恢复时，关闭所述报警消息，并结束所述生命周期。

可选地，在本公开第一方面实施例一种可能的实现方式中，所述对所述源异常数据和所述关联异常数据进行监控，包括：

将所述关联异常数据添加至异常数据维护表；

对所述异常数据维护表之中的每个关联异常数据建立监控；以及

当所述关联异常数据对应的处理时间达到第一预设时间时，则推送所述关联异常数据的处理提醒消息。

可选地，在本公开第一方面实施例另一种可能的实现方式中，所述获取源异常数据的报警消息，包括：

接收异常数据；以及

如果所述异常数据不位于波动范围之内，且未存在与所述异常数据相关的上游异常数据，则将所述异常数据确定为所述源异常数据，并发送所述报警消息。

可选地，在本公开第一方面实施例再一种可能的实现方式中，所述源异常数据为所述关联异常数据的上游异常数据。

可选地，在本公开第一方面实施例又一种可能的实现方式中，所述在所述生命周期之中检测到与所述源异常数据相关的关联异常数据，包括：

获取所述源异常数据的配置参数；

获取在所述生命周期之中检测到的新异常数据的配置参数；

如果根据预设配置表、所述源异常数据的配置参数及所述新异常数据的配置参数，确定所述源异常数据为所述新异常数据的上游异常数据，则将所述新异常数据确定为所述源异常数据的关联异常数据。

可选地，在本公开第一方面实施例又一种可能的实现方式中，所述方法，还包括：

如果所述异常数据维护表之中无关联异常数据，且在第二预设时间内未再收到异常数据，则关闭所述异常数据维护表。

根据本公开实施例的第二方面，提供一种异常数据的报警处理装置，包括：获取模块，被配置为执行获取源异常数据的报警消息的步骤；建立模块，被配置为执行根据所述报警消息，建立所述报警消息的生命周期的步骤；监控模块，被配置为执行在所述生命周期之中检测到与所述源异常数据相关的关联异常数据时，对所述源异常数据和所述关联异常数据进行监控的步骤；以及第一关闭模块，被配置为执行当所述源异常数据恢复时，关闭所述报警消息，并结束所述生命周期的步骤。

可选地，在本公开第二方面实施例一种可能的实现方式中，所述监控模块，包括：

添加单元，被配置为执行将所述关联异常数据添加至异常数据维护表的步骤；

监控单元，被配置为执行对所述异常数据维护表之中的每个关联异常数据建立监控的步骤；以及

推送单元，被配置为执行当所述关联异常数据对应的处理时间达到第一预设时间时，则推送所述关联异常数据的处理提醒消息的步骤。

可选地，在本公开第二方面实施例另一种可能的实现方式中，所述获取模块，包括：

接收单元，被配置为执行接收异常数据的步骤；以及

第一确定单元，被配置为执行在所述异常数据不位于波动范围之内，且未存在与所述异常数据相关的上游异常数据时，将所述异常数据确定为所述源异常数据，并发送所述报警消息的步骤。

可选地，在本公开第二方面实施例再一种可能的实现方式中，所述源异常数据为所述关联异常数据的上游异常数据。

可选地，在本公开第二方面实施例又一种可能的实现方式中，所述监控模块，包括：

第一获取单元，被配置为执行获取所述源异常数据的配置参数的步骤；

第二获取单元，被配置为执行获取在所述生命周期之中检测到的新异常数据的配置参数的步骤；

第二确定单元，被配置为执行在根据预设配置表、所述源异常数据的配置参数及所述新异常数据的配置参数，确定所述源异常数据为所述新异常数据的上游异常数据时，将所述新异常数据确定为所述源异常数据的关联异常数据的步骤。

可选地，在本公开第二方面实施例又一种可能的实现方式中，所述装置，还包括：

第二关闭模块，被配置为执行在所述异常数据维护表之中无关联异常数据，且在第二预设时间内未再收到异常数据时，关闭所述异常数据维护表的步骤。

根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现如前所述的异常数据的报警处理方法。

根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如前所述的异常数据的报警处理方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，该计算机程序由电子设备的处理器执行时，使得电子设备能够执行如前所述的异常数据的报警处理方法。

本公开的实施例提供的技术方案至少带来以下有益效果：通过在获取到源异常数据的报警消息时，建立与该报警消息对应的生命周期，并在生命周期内检测到与源异常数据相关的关联异常数据时，仅对关联异常数据进行记录以便于分析，而不发送报警通知，直至源数据恢复，结束生命周期。由此，对于在源异常数据对应的生命周期内获取到的关联异常数据，仅进行监控，而不发送报警消息，从而大大减少了报警通知量，提升了异常数据的监控效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种异常数据的报警处理方法的流程图。

图2为根据一示例性实施例示出的一种生命周期模式的示意图。

图3是根据一示例性实施例示出的另一种异常数据的报警处理方法的流程图。

图4是根据一示例性实施例示出的再一种异常数据的报警处理方法的流程图。

图5是根据一示例性实施例示出的一种异常数据的报警处理装置框图。

图6是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种异常数据的报警处理方法的流程图，如图1所示，该异常数据的报警处理方法用于电子设备中，包括以下步骤。

在步骤101中，获取源异常数据的报警消息。

需要说明的是，本公开实施例的异常数据的报警处理方法可以由本公开实施例的异常数据的报警处理装置执行，本公开实施例的异常数据的报警处理装置可以配置在任意电子设备中，以执行本公开实施例的异常数据的报警处理方法。本公开实施例的异常数据的报警处理方法可以应用在对任意的互联网产品的异常报警的监控场景中，从而本公开实施例的异常数据的报警处理装置可以配置在任意的互联网产品的服务器中，以对互联网产品的异常报警进行监控，即本公开实施例的异常数据的报警处理方法的执行主体可以为服务器。

其中，源异常数据，可以是指数据值符合预设的监控规则，且不与当前存在的生命周期对应的其他源异常数据相关的数据。也就是说，源异常数据是指报警原因与当前存在的各生命周期的报警原因均不相同的异常数据。

在本公开实施例中，可以根据实际的监控需求，在执行主体服务器中设定并存储预设的监控规则，从而服务器可以依据预设的监控规则，确定数据值符合预设的监控规则的异常数据。在获取到异常数据之后，若当前不存在尚未结束的生命周期，则可以将当前获取到的异常数据确定为源异常数据，并生成该源异常数据的报警消息；若当前存在尚未结束的生命周期，则可以进一步判断当前获取到的异常数据是否与当前存在的生命周期对应的源异常数据是否相关，若不相关，则可以确定当前获取到的异常数据可以提示新的故障类型，即与当前存在的生命周期对应的源异常数据的报警原因不同，从而可以将当前获取到的异常数据确定为源异常数据，并生成该源异常数据的报警消息，以避免漏报必要的报警消息。

作为一种可能的实现方式，服务器在生成源异常数据的报警消息之后，可以将报警消息发送至客户端，以提醒用户服务出现异常，及时进行维护和处理。其中，用户可以是互联网产品的维护人员、开发人员等，客户端可以是维护人员、开发人员使用的对互联网产品进行维护的应用程序，或者电脑、手机等终端设备等。

在步骤102中，根据报警消息，建立报警消息的生命周期。

在本公开实施例中，服务器在生成报警消息之后，可以根据报警消息的产生时刻，建立该报警消息的生命周期，并将该报警消息的产生时刻，确定为该报警消息的生命周期对应的起始时刻。

在步骤103中，如果在生命周期之中检测到与源异常数据相关的关联异常数据，则对源异常数据和关联异常数据进行监控。

在本公开实施例中，建立报警消息的生命周期之后，若在生命周期未结束时，检测到新的异常数据，则可以首先判断新的异常数据是否与该生命周期对应的源异常数据相关，若是，则可以确定新的异常数据所指示的故障类型与源异常数据指示的故障类型相同或相关，从而可以将新的异常数据确定为关联异常数据。由于关联异常数据与源异常数据可能是由相同的故障引发的，从而可以仅生成一次报警消息，以降低报警消息的数量，并且不会导致漏报必要的报警信息。在确定出与源异常数据相关的关联异常数据之后，可以记录关联异常数据，便于后续对故障进行归因、关联、分析等。

在本公开实施例中，获取到与源异常数据相关的关联异常数据之后，可以对各关联异常数据进行监控，以记录源异常数据与关联异常数据在生命周期内的数据值。

作为一种可能的实现方式，可以预设对源异常数据和关联异常数据进行监控的频率，即可以以预设的频率获取源异常数据与各关联异常数据的数据值并记录，以监控源异常数据与关联异常数据在生命周期内的变化趋势等状态，进而在生命周期未结束时，根据源异常数据与关联异常数据的状态对报警消息进行跟进，以使报警消息可以得到及时处理。

在步骤104中，当源异常数据恢复时，关闭报警消息，并结束生命周期。

在本公开实施例中，当源异常数据恢复正常值时，即当源异常数据的数据值不再符合预设的监控规则时，可以确定触发报警消息的故障已经消除，从而可以关闭报警消息，并结束该报警消息的生命周期。从而实现了在报警消息的生命周期内，对于相关联的异常数据仅进行一次报警，大大降低了报警消息的数量；并且，在报警消息的生命周期结束后，不会对之后获取到的异常数据的报警产生影响，从而避免了在本次故障解决之后，再次产生相同的故障时，不会漏报报警消息。

作为一种可能的实现方式，可以通过人工的方式对报警消息进行处理，因此，可以在获取到客户端发送的报警消息结束指令时，确定报警消息已经被处理，从而可以确定源异常数据恢复，进而可以关闭报警消息，并结束生命周期。

作为另一种可能的实现方式，服务器还可以根据对源异常数据和关联异常数据的监控数据，确定源异常数据是否已经恢复至正常范围，并在检测到源异常数据已经恢复至正常范围时，确定源异常数据恢复，从而可以自动关闭报警消息，并结束生命周期。

举例来说，如图2所示，为根据一示例性实施例示出的一种生命周期模式的示意图。其中，100为生命周期1，200为生命周期2，300为生命周期3；110为生命周期1对应的源异常数据，120为源异常数据110的关联异常数据；210生命周期2对应的源异常数据，220、230、240为源异常数据210的关联异常数据；310为生命周期3对应的源异常数据，320、330为源异常数据310的关联异常数据。在传统报警模式中，在获取到各异常数据110、120、210、220、230、240、310、320、330时，都会产生报警消息，而生命周期报警模式中，仅会在获取到源异常数据110、源异常数据210、源异常数据310时，产生报警消息，从而大大降低了报警消息的数量。由图2中可以看出，生命周期1的结束方式为数据恢复，即服务器根据对源异常数据110及关联异常数据120的监控数据，确定源异常数据110恢复正常时，可以自动结束生命周期1；而生命周期2和生命周期3的结束方式为人为结束，即服务器可以在获取到客户端发送的生命周期2和生命周期3对应的报警消息结束指令时，结束生命周期2和生命周期3。

本公开的实施例提供的异常数据的报警处理方法，通过在获取到源异常数据的报警消息时，建立与该报警消息对应的生命周期，并在生命周期内检测到与源异常数据相关的关联异常数据时，仅对关联异常数据进行记录以便于分析，而不发送报警通知，直至源数据恢复，结束生命周期。由此，对于在源异常数据对应的生命周期内获取到的关联异常数据，仅进行监控，而不发送报警消息，从而大大减少了报警通知量，提升了异常数据的监控效果。

在本公开一种可能的实现形式中，可以预设各类数据的正常值所在的波动范围，以根据预设的波动范围，确定异常数据。

图3是根据一示例性实施例示出的另一种异常数据的报警处理方法的流程图，如图3所示，该异常数据的报警处理方法用于电子设备中，包括以下步骤。

在步骤401中，接收异常数据。

在步骤402中，如果异常数据不位于波动范围之内，且未存在与异常数据相关的上游异常数据，则将异常数据确定为源异常数据，并发送报警消息。

需要说明的是，如果一个数据A异常会导致数据B产生异常，则数据B可以为数据A的上游异常数据。在本公开实施例中，各数据对应的上游数据可以根据实际业务需要进行配置；对于包含关系严格规范的数据，也可以对存储数据的数据源和数据维度进行分析，以自动确定各数据对应的上游数据。

举例来说，网络接口数据为包含关系严格规范的数据，其中，影响网络接口成功率的数据维度可以有很多，如域名、内容分发网络、网络类型、地域、机房信息等，从而可以将网络接口成功率配置为域名、内容分发网络、网络类型、地域、机房信息等数据的上游数据。

在本公开实施例中，服务器可以以预设的频率采集系统中各数据的数据值，若在当前时刻获取的某个数据的数据值没有位于波动范围之内，则可以将该数据确定为异常数据。

作为一种可能的实现方式，可以将波动范围预设为[-x,3x]，其中，x为数据的7天数据均值，即在数据的数据值较7天数据均值浮动超过200％，则可以确定该数据在当前时刻为异常数据；或者，还可以利用开源时序序列预估工具(如fbprophet)，预估数据的波动范围，进而在数据值偏离预估的波动范围的上下界100％时，确定该数据在当前时刻为异常数据。

在本公开实施例中，当前时刻获取到异常数据之后，可以进一步确定当前时刻是否存在未结束的生命周期，若不存在，则可以将该异常数据确定为源异常数据，并生成该源异常数据的报警消息并发送至客户端；若存在未结束的生命周期，则可以进一步判断当前时刻所在的生命周期中，是否包含与该异常数据相关的上游异常数据，若不存在，则可以将该异常数据确定为源异常数据，并发送报警消息。

举例来说，如图2所示，在获取到源异常数据110、210、310的时刻，可以确定当前不存在未结束的生命周期，从而可以在获取到数据110、210、310时，分别将110、210、310确定为源异常数据，并发送报警消息；而在获取到异常数据120的时刻，存在未结束的生命周期100，并且源异常数据110为异常数据120的上游异常数据，从而可以确定异常数据120不是源异常数据。

需要说明的是，确定数据是否为异常数据的监控规则，可以包括但不限于以上列举的情形。实际使用时，可以根据实际需要及具体的业务场景，确定合适的监控规则，本公开实施例对此不做限定。

本公开实施例通过预设各数据所处的正常波动范围及各数据间的关联关系，确定源异常数据，以可靠确定发送报警消息的时机，避免遗漏报警或重复报警，在降低报警量的同时，进一步提升报警的可靠性和重视程度。并且，通过根据数据之间相互影响的因果关系，确定源异常数据的关联异常数据，以便于对报警原因进行归因、关联分析，以便于对故障进行修复。

在步骤403中，根据报警消息，建立报警消息的生命周期。

上述步骤403的具体实现过程及原理，可以参照上述实施例的详细描述，此处不再赘述。

在步骤404中，获取源异常数据的配置参数。

在本公开实施例中，异常数据的配置参数，可以是指异常数据的名称。比如，获取到的源异常数据为：“网络接口成功率：X”，从而可以将网络接口成功率确定为源异常数据的配置参数。

在步骤405中，获取在生命周期之中检测到的新异常数据的配置参数。

在本公开实施例中，若在源异常数据对应的生命周期未结束时，又检测到新的异常数据，则可以从检测到的新异常数据中提取新异常数据的名称，作为新异常数据的配置参数。比如，在网络接口成功率对应的生命周期中，检测到新异常数据：“域名：Y”，从而可以确定新异常数据的配置参数为“域名”。

在步骤406中，如果根据预设配置表、源异常数据的配置参数及新异常数据的配置参数，确定源异常数据为新异常数据的上游异常数据，则将新异常数据确定为源异常数据的关联异常数据。

在本公开实施例中，配置各数据的上游数据时，可以将配置完成的信息存储在预设配置表中，从而通过查询预设配置表，确定新异常数据是否与源异常数据相关。具体的，预设配置表中可以存储各数据的配置参数对应的上游数据的配置参数，从而可以在获取到源异常数据的配置参数与新异常数据的配置参数之后，根据预设配置表，确定源异常数据的配置参数是否为新异常数据的配置参数的上游配置参数；若是，则可以确定源异常数据为新异常数据的上游异常数据；若确定源异常数据的配置参数不是新异常数据的配置参数的上游配置参数，则可以确定源异常数据不是新异常数据的上游异常数据，即新异常数据与源异常数据不相关，从而可以将新异常数据确定为新的源异常数据，并发送与新的源异常数据对应的报警消息，以及建立与新的源异常数据对应的生命周期。

在本公开实施例中，由于一个异常数据若存在上游异常数据，则该上游异常数据存在异常很可能是该异常数据导致的，即该异常数据与其对应的上游异常数据存在关联。从而在确定源异常数据为新异常数据的上游异常数据时，可以确定源异常数据存在异常很可能是新异常数据导致的，即源异常数据与新异常数据可以指示相同的故障，从而可以将新异常数据确定为源异常数据的关联异常数据。

本公开实施例通过根据预设配置表确定异常数据是否与源异常数据关联，从而提升了关联异常数据确定的效率，进而提升了异常数据监控的效率。

在步骤407中，对源异常数据和关联异常数据进行监控。

在步骤408中，当源异常数据恢复时，关闭报警消息，并结束生命周期。

上述步骤407-408的具体实现过程及原理，可以参照上述实施例的详细描述，此处不再赘述。

本公开的实施例提供的异常数据的报警处理方法，通过预设各数据的波动范围和上游数据维度，以在数据的数据值不位于波动范围，且不存在相关的上游异常数据时，将该数据确定为源异常数据，并发送报警消息及建立生命周期，进而通过预设配置表预设各数据的上游数据维度，从而可以根据预设配置表确定新异常数据是否为源异常数据的关联异常数据。由此，对于在源异常数据对应的生命周期内获取到的关联异常数据，仅进行监控，而不发送报警消息，并配置各数据对应的上游数据维度，以便于对数据间的关联进行分析，从而大大减少了报警通知量，进一步提升了对报警原因进行归因分析的准确性，便于对故障进行修复。

在在本公开一种可能的实现形式中，还可以将与源异常数据相关的关联异常数据添加至异常数据维护表中，以对关联异常数据的变化进行记录，便于后续对故障进行归因、关联、分析等，提升异常数据监控的可靠性。

图4是根据一示例性实施例示出的再一种异常数据的报警处理方法的流程图，如图4所示，该异常数据的报警处理方法用于电子设备中，包括以下步骤。

在步骤501中，获取源异常数据的报警消息。

在步骤502中，根据报警消息，建立报警消息的生命周期。

上述步骤501-502的具体实现过程及原理，可以参照上述实施例的详细描述，此处不再赘述。

在步骤503中，如果在生命周期之中检测到与源异常数据相关的关联异常数据，则将关联异常数据添加至异常数据维护表。

在本公开实施例中，建立报警消息的生命周期之后，若在生命周期未结束时，检测到新的异常数据，则可以首先判断新的异常数据是否与该生命周期对应的源异常数据相关，若是，则可以确定新的异常数据所指示的故障类型与源异常数据指示的故障类型相同或相关，从而可以将新的异常数据确定为关联异常数据。由于关联异常数据与源异常数据可能是由相同的故障引发的，从而可以仅生成一次报警消息，以降低报警消息的数量，并且不会导致漏报必要的报警信息。在确定出与源异常数据相关的关联异常数据之后，可以建立异常数据维护表，并将关联异常数据添加至异常数维护表中，以对关联异常数据的实时变化进行记录，便于后续对故障进行归因、关联、分析等。

进一步的，为节约运算资源，还可以在异常数据维护表为空时，关闭异常数据维护表。即在本公开实施例一种可能的实现形式中，上述方法，还可以包括：

如果异常数据维护表之中无关联异常数据，且在第二预设时间内未再收到异常数据，则关闭异常数据维护表。

在本公开实施例中，若异常数据维护表中不存在关联异常数据，即异常数据维护表为空，且长时间未接收到异常数据，则可以确定当前时间段可能不存在异常数据，从而可以关闭异常数据维护表，以节约运算资源；并在接收到异常数据时，再重新建立异常数据维护表。

作为一种可能的实现方式，可以根据实际需要确定第二预设时间，从而可以在异常数据维护表为空，且未接收到异常数据的时长达到第二预设时间时，确定未接收到异常数据的时间较长，从而可以关闭异常数据维护表。

在步骤504中，对源异常数据和异常数据维护表之中的每个关联异常数据进行监控。

在本公开实施例中，获取到与源异常数据相关的关联异常数据之后，可以对各关联异常数据进行监控，以记录源异常数据与关联异常数据在生命周期内的数据值。

作为一种可能的实现方式，可以预设对源异常数据和关联异常数据进行监控的频率，即可以以预设的频率获取源异常数据与异常数据维护表中的各关联异常数据的数据值，并记录在异常数据维护表中，以监控源异常数据与关联异常数据在生命周期内的变化趋势等状态，进而在生命周期未结束时，根据源异常数据与关联异常数据的状态对报警消息进行跟进，以使报警消息可以得到及时处理。

在步骤505中，当关联异常数据对应的处理时间达到第一预设时间时，则推送关联异常数据的处理提醒消息。

其中，关联异常数据对应的处理时间，可以是指将关联异常数据添加至异常数据维护表中的时长。

在本公开实施例中，对异常数据维护表中的每个关联异常数据进行监控之后，还可以根据在各个时刻获取的关联异常数据的数据值，判断关联异常数据是否已经恢复正常。若将关联异常数据添加至异常数据维护表中的时长(即关联异常数据对应的处理时间)已经达到第一预设时间，关联异常数据还没有恢复正常，则可以向用户的客户端发送该关联异常数据对应的处理提醒消息，以提醒用户及时对报警消息进行处理，避免用户在处理报警消息时产生遗漏。

作为一种可能的实现方式，可以根据预设的监控恢复策略，确定关联异常数据是否恢复正常。比如，预设的监控恢复策略可以为“数据至恢复至波动范围的时长达到第三预设时间”，从而可以在关联异常数据对应的处理时间达到第一预设时间时，判断关联异常数据的数据值恢复至波动范围的时长是否达到第三预设时间，若是，则可以确定关联异常数据恢复正常；或者，预设的监控恢复策略还可以为“数据对应的连续N个数据值恢复至波动范围”，从而可以在关联异常数据对应的处理时间达到第一预设时间时，判断关联异常数据是否存在N个连续的监测值恢复至波动范围，若是，则可以确定关联异常数据恢复正常。

需要说明的是，预设的监控恢复策略可以包括但不限于以上列举的情形。实际使用时，可以根据实际需要及具体的业务场景预设，本公开实施例对此不做限定。

在步骤506中，当源异常数据恢复时，关闭报警消息，并结束生命周期。

需要说明的是，在确定源异常数据是否恢复时，可以按照步骤505中描述的确定关联异常数据是否恢复正常的监控恢复策略，确定源异常数据是否恢复，此处不再赘述。

上述步骤506的具体实现过程及原理，可以参照上述实施例的详细描述，此处不再赘述。

本公开的实施例提供的异常数据的报警处理方法，通过在获取到源异常数据的报警消息时，建立与该报警消息对应的生命周期，并在生命周期内检测到与源异常数据相关的关联异常数据时，将关联异常数据添加至异常数据维护表中，并对关联异常数据的实时变化进行记录以便于分析，而不发送报警通知，进而在关联异常数据长时间未被处理时，向用户发送处理提醒消息，直至源数据恢复，结束生命周期。由此，对于在源异常数据对应的生命周期内获取到的关联异常数据，仅记录至异常数据维护表中进行监控，而不发送报警消息，从而大大减少了报警通知量，提升了对报警原因进行归因分析的准确性，而且通过及时跟进异常数据的状态，提醒用户及时处理报警消息，避免了报警消息处理遗漏。

图5是根据一示例性实施例示出的一种异常数据的报警处理装置框图。参照图5，该装置60包括获取模块61、建立模块62、监控模块63及第一关闭模块64。

该获取模块61，被配置为执行获取源异常数据的报警消息的步骤；

该建立模块62，被配置为执行根据报警消息，建立报警消息的生命周期的步骤；

该监控模块63，被配置为执行在生命周期之中检测到与源异常数据相关的关联异常数据时，对源异常数据和关联异常数据进行监控的步骤；以及

该第一关闭模块64，被配置为执行当源异常数据恢复时，关闭报警消息，并结束生命周期的步骤。

在实际使用时，本公开实施例提供的异常数据的报警处理装置，可以被配置在任意电子设备中，以执行前述异常数据的报警处理方法。

本公开的实施例提供的异常数据的报警处理装置，通过在获取到源异常数据的报警消息时，建立与该报警消息对应的生命周期，并在生命周期内检测到与源异常数据相关的关联异常数据时，仅对关联异常数据进行记录以便于分析，而不发送报警通知，直至源数据恢复，结束生命周期。由此，对于在源异常数据对应的生命周期内获取到的关联异常数据，仅进行监控，而不发送报警消息，从而大大减少了报警通知量，提升了异常数据的监控效果。

在本公开一种可能的实现形式中，上述监控模块63，包括：

添加单元，被配置为执行将关联异常数据添加至异常数据维护表的步骤；

监控单元，被配置为执行对异常数据维护表之中的每个关联异常数据建立监控的步骤；以及

推送单元，被配置为执行当关联异常数据对应的处理时间达到第一预设时间时，则推送关联异常数据的处理提醒消息的步骤。

进一步的，在本公开另一种可能的实现形式中，上述获取模块61，包括：

接收单元，被配置为执行接收异常数据的步骤；以及

第一确定单元，被配置为执行在异常数据不位于波动范围之内，且未存在与异常数据相关的上游异常数据时，将异常数据确定为源异常数据，并发送报警消息的步骤。

进一步的，在本公开再一种可能的实现形式中，上述源异常数据为关联异常数据的上游异常数据。

进一步的，在本公开又一种可能的实现形式中，上述监控模块63，包括：

第一获取单元，被配置为执行获取源异常数据的配置参数的步骤；

第二获取单元，被配置为执行获取在生命周期之中检测到的新异常数据的配置参数的步骤；

第二确定单元，被配置为执行在根据预设配置表、源异常数据的配置参数及新异常数据的配置参数，确定源异常数据为新异常数据的上游异常数据时，将新异常数据确定为源异常数据的关联异常数据的步骤。

进一步的，在本公开又一种可能的实现形式中，上述异常数据的报警处理装置60，还包括：

第二关闭模块，被配置为执行在异常数据维护表之中无关联异常数据，且在第二预设时间内未再收到异常数据时，关闭异常数据维护表的步骤。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

本公开的实施例提供的异常数据的报警处理装置，通过预设各数据的波动范围和上游数据维度，以在数据的数据值不位于波动范围，且不存在相关的上游异常数据时，将该数据确定为源异常数据，并发送报警消息及建立生命周期，进而通过预设配置表预设各数据的上游数据维度，从而可以根据预设配置表确定新异常数据是否为源异常数据的关联异常数据。由此，对于在源异常数据对应的生命周期内获取到的关联异常数据，仅进行监控，而不发送报警消息，并配置各数据对应的上游数据维度，以便于对数据间的关联进行分析，从而大大减少了报警通知量，进一步提升了对报警原因进行归因分析的准确性，便于对故障进行修复。

图6是根据一示例性实施例示出的一种用于信息查询的电子设备700的框图。

如图6所示，上述电子设备700包括：

存储器710及处理器720，连接不同组件(包括存储器710和处理器720)的总线730，存储器710存储有计算机程序，当处理器720执行所述程序时实现本公开实施例所述的异常数据的报警处理方法。

总线730表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。

电子设备700典型地包括多种电子设备可读介质。这些介质可以是任何能够被电子设备700访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

存储器710还可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)740和/或高速缓存存储器750。电子设备700可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统760可以用于读写不可移动的、非易失性磁介质(图6未显示，通常称为“硬盘驱动器”)。尽管图6中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线730相连。存储器710可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本公开各实施例的功能。

具有一组(至少一个)程序模块770的程序/实用工具780，可以存储在例如存储器710中，这样的程序模块770包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块770通常执行本公开所描述的实施例中的功能和/或方法。

电子设备700也可以与一个或多个外部设备790(例如键盘、指向设备、显示器791等)通信，还可与一个或者多个使得用户能与该电子设备700交互的设备通信，和/或与使得该电子设备700能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口792进行。并且，电子设备700还可以通过网络适配器793与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器793通过总线730与电子设备700的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备700使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

处理器720通过运行存储在存储器710中的程序，从而执行各种功能应用以及数据处理。

需要说明的是，本实施例的电子设备的实施过程和技术原理参见前述对本公开实施例的异常数据的报警处理方法的解释说明，此处不再赘述。

本公开实施例提供的电子设备，可以执行如前所述的异常数据的报警处理方法，通过在获取到源异常数据的报警消息时，建立与该报警消息对应的生命周期，并在生命周期内检测到与源异常数据相关的关联异常数据时，仅对关联异常数据进行记录以便于分析，而不发送报警通知，直至源数据恢复，结束生命周期。由此，对于在源异常数据对应的生命周期内获取到的关联异常数据，仅进行监控，而不发送报警消息，从而大大减少了报警通知量，提升了异常数据的监控效果。

为了实现上述实施例，本公开还提出一种存储介质。

其中，该存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如前所述的异常数据的报警处理方法。

为了实现上述实施例，本公开还提供一种计算机程序产品，该计算机程序由电子设备的处理器执行时，使得电子设备能够执行如前所述的异常数据的报警处理方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。