告警事件处理方法、系统、设备、存储介质及程序产品

技术领域

本申请属于计算机技术领域，具体涉及一种告警事件处理方法、系统、设备、存储介质及程序产品。

背景技术

网络运行过程中可能会出现异常而产生告警事件，如某个网元超负载运行而产生告警事件。产生告警事件后需要对告警事件进行处理来解除异常情况。

相关技术中提供了一些告警处理平台，在平台中预先配置一些告警处理规则。当产生告警事件时，确定告警事件匹配的告警处理规则。基于匹配的告警处理规则对该告警事件进行处理。

但基于预先配置的告警处理规则进行告警处理，很可能无法成功解除异常情况，准确性差，告警处理的效率低。

发明内容

本申请提出一种告警事件处理方法、系统、设备、存储介质及程序产品，可以解决相关技术中出现的告警处理准确性差的问题。

本申请第一方面实施例提出了一种告警事件处理方法，包括：

获取告警事件，确定所述告警事件的告警事件类型；

基于所述告警事件类型，从预先存储的告警事件类型与根因定位策略的第一映射关系中获取所述告警事件对应的根因定位策略，所述告警事件类型用于指示所述告警事件对应的网络异常类型，所述根因定位策略用于确定产生所述告警事件的根本异常原因，所述根本异常原因包括产生所述告警事件的具体网络异常节点和/或产生所述告警事件的异常节点的根本异常原因；

针对所述告警事件，执行所述根因定位策略，确定所述告警事件的根本异常原因；

基于所述根本异常原因对所述告警事件进行异常处理。

本申请第二方面实施例提出了一种告警事件处理系统，包括管理界面和后台处理系统；

所述管理界面，用于显示预设的配置显示界面，通过所述配置显示界面更新告警事件类型与根因定位策略的第一映射关系，以及告警事件类型、根本异常原因及异常处理策略的第二映射关系；所述告警事件类型用于指示告警事件对应的网络异常类型，所述根因定位策略为用于确定产生所述告警事件的根本异常原因，所述根本异常原因包括产生所述告警事件的具体网络异常节点和/或产生所述告警事件的异常节点的异常原因；

所述后台处理系统，用于存储所述第一映射关系和所述第二映射关系；获取告警事件，确定所述告警事件的告警事件类型；基于确定的所述告警事件类型，从存储的所述第一映射关系中获取所述告警事件对应的根因定位策略；针对所述告警事件，执行所述根因定位策略，确定所述告警事件的根本异常原因；以及，基于所述第二映射关系及所述告警事件的根本异常原因，对所述告警事件进行异常处理。

本申请第三方面的实施例提供了一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序以实现上述第一方面所述的方法。

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

本申请第五方面的实施例提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行以实现第一方面所述的方法。

本申请实施例中提供的技术方案，至少具有如下技术效果或优点：

在本申请实施例中，将定位告警事件的根本异常原因的过程转变成可传承、可维护、可持续迭代的根因定位策略的程序进行存档。基于告警事件的告警事件类型对应的根因定位策略自动定位引发告警事件的根本异常原因，进而基于该根本异常原因有针对性地采取相应的异常处理策略，实现基于其根本异常原因采取相应地异常处理措施，达到有针对性地异常处理，提高异常处理的成功率和效率，使得告警事件处理系统能够处理更为复杂的根本异常原因引发的告警事件。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变的明显，或通过本申请的实践了解到。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本申请一实施例所提供的一种告警事件处理方法的流程图；

图2示出了本申请一实施例所提供的集群可用率下跌对应的定位决策树的示意图；

图3示出了本申请一实施例所提供的一种告警事件处理系统的第一架构示意图；

图4示出了本申请一实施例所提供的一种告警事件处理系统的第二架构示意图；

图5示出了本申请一实施例所提供的一种告警处理系统的第三架构示意图；

图6示出了本申请一实施例所提供的一种告警处理系统的第四架构示意图；

图7示出了本申请一实施例所提供的一种告警处理系统的第五架构示意图；

图8示出了本申请一实施例所提供的一种告警处理系统的第六架构示意图；

图9示出了本申请一实施例所提供的一种告警处理系统的第七架构示意图；

图10示出了本申请一实施例所提供的一种告警处理系统的第八架构示意图；

图11示出了本申请一实施例所提供的一种告警处理系统的第九架构示意图；

图12示出了本申请一实施例所提供的一种告警处理系统的第十架构示意图；

图13示出了本申请一实施例所提供的一种告警处理系统的第十一架构示意图；

图14示出了本申请一实施例所提供的负载管理模块的原理示意图；

图15示出了本申请一实施例所提供的一种告警处理系统的第十二架构示意图；

图16示出了本申请一实施例所提供的异常定位模块基于maser-worker模式进行异常定位的示意图；

图17示出了本申请一实施例所提供的异常处理模块基于maser-worker模式进行异常处理的示意图；

图18示出了本申请一实施例所提供的一种电子设备的结构示意图；

图19示出了本申请一实施例所提供的一种存储介质的示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施方式。虽然附图中显示了本申请的示例性实施方式，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本申请所属领域技术人员所理解的通常意义。

网络运行过程中可能会出现异常而产生告警事件，例如在云服务系统运行过程中某个网元超负载运行而产生告警事件，或者某个网元的网络连接不稳定而产生告警事件等。相关技术中基于人工经验在告警处理平台预先配置一些告警处理规则。当产生告警事件时，确定告警事件匹配的告警处理规则。基于匹配的告警处理规则对该告警事件进行处理。

针对相关技术中的告警处理平台，本申请的发明人发现，基于人工经验配置的告警处理规则进行告警处理，有可能无法消除异常情况，导致告警处理失败。在这种情况下就需要人工对告警事件进行处理，导致告警事件处理的效率很低。本申请的发明人对此进行深入研究，发现相关技术中之所以告警处理容易失败，关键在于未分析产生告警事件的根本原因，没有从其根本原因出发进行有针对性地告警处理，从而导致告警处理易失败。

基于此，本申请的发明人提出一种告警事件处理方法，该方法应用于云网络系统的告警事件处理系统，能够自动定位告警事件的根本异常原因，基于其根本异常原因对告警事件进行异常处理，提高告警事件处理的成功率及效率。

参见图1，本申请的告警事件处理方法具体包括以下步骤：

步骤101：获取告警事件，确定该告警事件的告警事件类型。

本申请实施例的执行主体为告警事件处理系统，其基于网络运行过程中产生的网络数据确定是否产生告警事件，以及对告警事件进行处理。该网络数据可以包括网元数据、服务数据和通过埋点技术采集的探测数据等。网元数据可以包括网络中网元的负载量、系统占用率、数据传输速率等。服务数据可以包括单位时间内的用户访问量、请求响应时长、数据丢包率等。探测数据可以包括按键点击率、页面浏览量、网元启动次数、在线用户数等。

接收到网络数据后，对网络数据进行预处理，预处理包括对网络数据进行清洗、去重等操作。在本申请实施例中，系统中预先存储有预设异常规则，该预设异常规则用于规定异常网络数据所需满足的条件，如该预设异常规则可以规定负载量大于一定负载阈值的网元数据为异常网络数据，或者规定请求响应时长大于一定时长阈值的服务数据为异常网络数据，等等。

上述清洗操作指去除网络数据中不满足预设异常规则的数据，留下满足预设异常规则的异常网络数据。去重操作指将异常网络数据中重复的数据只保留一份，删除其他的重复数据。经过预处理后，还基于最终得到的异常网络数据，生成告警事件处理系统支持的数据格式的告警事件。

网络中还存在一些第三方的告警平台，这些告警平台可以直接将本地生成的告警事件发送给本申请的告警事件处理系统。告警事件处理系统接收第三方的告警平台发送的告警事件，若该告警事件的数据格式不是本告警事件处理系统支持的数据格式，则将该告警事件的数据格式转换为告警事件处理系统支持的数据格式。告警事件处理系统接收到告警事件，并确认告警事件的数据格式为告警事件处理系统支持的数据格式之后，定位该告警事件的根本异常原因。

告警事件处理系统还可以对获得的告警事件进行限流、去重等操作，避免短时间内多次触发相同的告警事件处理，或短时间内同一网元触发多次告警事件处理等。

告警事件中包括告警事件的告警事件类型及异常网络数据，告警事件类型用于指示告警事件对应的网络异常类型，如集群可用率下跌、负载过大、系统占用率过高、数据传输速率下跌等。

告警事件处理系统还可以存储告警事件，具体可以将得到的告警事件存储在日志服务节点中。日志服务节点采用SLS（LogService，日志服务）作为告警事件的存储载体，使告警事件处理的全过程的信息持久化，并使告警事件处理的所有相关信息具有可回放的功能。告警事件处理的全过程包括告警事件接入、定位根本异常原因及最终的异常处理过程。

通过本步骤的操作获得告警事件及其告警事件类型后，通过步骤102的操作来定位该告警事件的根本异常原因。

步骤102：基于告警事件类型，从预先存储的告警事件类型与根因定位策略的第一映射关系中获取该告警事件对应的根因定位策略。

本申请实施例预先在告警事件处理系统中存储了告警事件类型与根因定位策略之间的第一映射关系。其中，根因定位策略用于确定产生告警事件的根本异常原因，根本异常原因包括产生告警事件的具体网络异常节点和/或产生告警事件的异常节点的异常原因。根因定位策略是将人工定位根本异常原因的过程进行总结，并编程为可配置、可展示、可执行的程序进行存档，该程序的形式可以为脚本程序或定位决策树等。

告警事件处理系统可以显示预设的配置显示界面，通过该预设的配置显示界面对上述第一映射关系进行更新，并存储更新后的该第一映射关系。

提供预设的配置显示界面，方便用户自主配置告警事件类型与根因定位策略的第一映射关系，能够灵活地修改或者新增第一映射关系，更新第一映射关系后能够立即生效，无需对告警事件处理系统本身做任何程序上的修改，节省了研发成本。

在本申请的一些实施例中，告警事件处理系统可以对日志服务节点进行实时检测，检测到日志服务节点中存在待处理的告警事件，即从日志服务节点中获取告警事件，基于存储的第一映射关系，确定当前告警事件的根本异常原因。具体地，从告警事件中获取告警事件的告警事件类型。基于该告警事件类型，从告警事件类型与根因定位策略的第一映射关系中获取该告警事件对应的根因定位策略。

步骤103：针对该告警事件，执行获取的根因定位策略，确定该告警事件的根本异常原因。

根因定位策略为用于确定告警事件的根本异常原因的可执行程序。获取到该告警事件对应的根因定位策略，针对该告警事件执行该根因定位策略，即可得到该告警事件的根本异常原因。

图2示出了根因定位策略为定位决策树的一个具体实例，如图2所示，告警事件的告警事件类型为集群可用率下跌，对该告警事件执行图2所示的定位决策树。具体地，先判断该告警事件是由设备异常还是用户侧异常导致的。如果是设备异常导致的，则进一步判断是该设备的进程异常还是CPU（CentralProcessing Unit，计算机处理器）使用率高导致的，如果是进程异常导致的，则确定该告警事件的根本异常原因为该设备的进程异常。如果是CPU使用率高导致的，则进一步判断是集群整体CPU使用率高，还是单个CPU使用率高。如果是集群整体CPU使用率高，则确定该告警事件的根本异常原因为流量源分析异常。如果是单个CPU使用率高，则确定该告警事件的根本异常原因为单实例切流异常。若判定集群可用率下跌是因为用户侧异常，则判断是单用户异常，还是多用户异常。如果是单用户异常，则确定该告警事件的根本异常原因即为单用户异常。如果是多用户异常，进一步判断是实例被中止造成的异常，还是因为新增实例产生的异常。如果是实例被中止造成的异常，则确定根本异常原因为误报。如果判断是新增实例导致的异常，则确定根本异常原因为实例配置异常。

本申请将定位告警事件的根本异常原因的过程转变成可传承、可维护、可持续迭代的程序进行存档，使得告警事件处理系统能够处理更为复杂的根本异常原因引发的告警事件。且确定告警事件的根本异常原因，实现基于其根本异常原因采取相应地异常处理措施，达到有针对性地异常处理，提高异常处理的成功率和效率。

在本申请的一些实施例中，告警事件处理系统还可以显示处理进度界面，通过该处理进度界面显示确定根本异常原因的确定进度。

告警事件处理系统显示的首页或前文所述的预设的配置显示界面中可以提供用于查询告警事件的处理进度的链接。当检测到该链接触发的查询请求时显示处理进度界面。或者，该处理进度界面也可以为上述预设的配置显示界面中的部分显示区域。在显示该配置显示界面时，可以在该配置显示界面上的一块区域中显示告警事件的处理进度。在对告警事件定位根本异常原因的过程中，在上述处理进度界面中展示确定根本异常原因的确定进度。该确定进度可以通过进度条的形式展示，也可以通过显示该告警事件对应的根因定位策略的程序执行过程来展示。

通过进度处理界面能够准确清晰地呈现确定告警事件的根本异常原因的进度，能够使根本异常原因的定位更加直观。

确定出告警事件的根本异常原因后，还需要对该告警事件进行更新。在一种实现方式中，日志服务节点中可以分别通过两个队列来存储未定位原因的告警事件和已定位原因的告警事件。在这种情况下，得到告警事件的根本异常原因后，可以将该告警事件与其根本异常原因封装为新的告警事件，将该新的告警事件存储到日志服务节点中用于存储已定位原因的告警事件队列中，以便后续从已定位原因的告警事件队列中取告警事件进行异常处理。

在另一种实现方式中，在告警事件中设置事件状态的字段来区分已定位原因和未定位原因两种状态。日志服务节点中通过一个队列来存储所有告警事件。在这种实现方式中，确定出当前告警事件的根本异常原因后，修改该告警事件的事件状态为已定位原因，将根本异常原因及修改状态后的告警事件封装为新的告警事件。将新的告警事件存储到日志服务节点中的队列中，以便后续异常处理模块从该队列中取告警事件进行异常处理。

步骤104：基于根本异常原因对告警事件进行异常处理。

本申请实施例预先在告警事件处理系统中存储了事件类型、根本异常原因与异常处理策略之间的第二映射关系。异常处理策略为直接针对告警事件的根本异常原因的直接修正方式，异常处理策略包括自动化处理策略或人工处理策略。

本申请也可以通过预设的配置显示界面更新上述第二映射关系，并存储更新后的第二映射关系。方便用户自主配置事件类型、根本异常原因与异常处理策略的第二映射关系，能够灵活地修改或者新增第二映射关系，更新第二映射关系后能够立即生效，无需对告警事件处理系统本身做任何程序上的修改，节省了研发成本。

通过步骤103确定出告警事件的根本异常原因后，对该告警事件进行异常处理。具体地，从日志服务节点的相应队列中获取已定位原因的告警事件，从该告警事件中提取出告警事件类型及根本异常原因。根据根本异常原因及告警事件中的告警事件类型，从第二映射关系中，获取对应的异常处理策略。对该告警事件执行获取的异常处理策略。

若该异常处理策略为人工处理策略，则该人工处理策略中包含相应地人工处理接口的信息，基于该信息将该告警事件推送给相应地维护人员的终端或人工处理平台进行处理，并接收返回的处理结果。若该异常处理策略为自动化处理策略，则可以由告警事件处理系统执行该自动化处理策略，或者，自动化处理策略中也可以包含相应地自动化处理平台的信息，将该告警事件及异常处理策略发送给相应地自动化处理平台进行处理，接收该自动化处理平台返回的处理结果。

通过上述方式对告警事件进行异常处理的过程中，告警事件处理系统也可以显示异常处理的处理进度。具体可以通过前面提及的处理进度界面来显示异常处理策略的处理进度，若告警事件的异常处理策略为自动化处理策略，则该处理进度可以包括异常处理策略的程序执行过程以及处理结果，或者该处理进度可以包括执行异常处理策略的自动化处理平台的相关信息以及该平台返回的处理结果。若告警事件的异常处理策略为人工处理策略，则该处理进度可以包括人工处理平台或相关维护人员的相关信息以及返回的处理结果。其中，平台的相关信息可以为平台的名称、地址等信息。

为了便于更好的理解告警事件处理的整个过程，下面结合图2所示的根因定位策略的执行逻辑，以表格的形式举例说明告警事件的告警事件类型、定位出的根本异常原因及异常处理策略之间的对应关系。如表1所示，在告警事件的告警事件类型为集群可用率下跌时，执行图2所示的根因定位策略，若定位出的根本异常原因为某实例被中止而导致的误报，则对应的异常处理策略可以为自动恢复被中止的该实例，从而消除误报的该告警事件。若定位出的根本异常原因为新增的某实例的配置异常，则异常处理策略可以为人工修改配置异常的实例的配置信息，具体执行该异常处理策略时可以将该告警事件推送给相关的运维人员，提醒运维人员修改新增的该实例的配置信息。

表1

对于负载过大、系统占用率过高、数据传输速率下跌等告警事件类型，同样地执行告警事件类型对应的根因定位策略，确定出导致告警事件产生的根本异常原因，然后基于告警事件类型和根本异常原因，确定出对应的异常处理策略。针对告警事件执行该异常处理策略，来消除产生该告警事件的根本异常原因。

相对于相关技术中产生告警事件就执行与告警事件相匹配的预设处理策略，本申请实施例是先定位出告警事件的根本异常原因，然后执行该根本异常原因对应的异常处理策略，异常处理的成功率更高。

例如，某个网元因同一用户短时间访问量激增导致超负载运行而产生告警事件。相关技术中会直接为该网元分配更多的资源，而分配更多的资源并不能从根本上解决问题，在用户访问量很大时无法成功解除告警，即便能够解除，随着用户访问量增多该网元仍会超负载而告警。而本申请实施例中对于该网元产生的告警事件，首先定位引发该告警事件的根本异常原因，确定出其是因为用户访问量激增导致的，进而采取限制该用户的访问流量的处理策略，达到从根本上解决问题的效果，限制该异常用户的访问流量之后，该网元的访问量会明显回落，从而使该网元不会出现超负载运行的情况。

在一些实施例中，对定位出根本异常原因的告警事件进行处理，并得到异常处理结果后，还将处理结果封装到该告警事件中。至此该告警事件中至少包括告警事件类型、异常网络数据、根本异常原因及异常处理结果。告警事件处理系统存储该告警事件的事件日志，该事件日志包括该告警事件。或者，在另一些实施例中，告警事件处理系统也可以不将根本异常原因和/或异常处理结果封装到该告警事件中，而是将该告警事件、根本异常原因和异常处理结果均存储在事件日志中。

告警事件处理系统对外部系统提供事件查询接口，外部系统可以通过该查询接口发送事件查询请求给告警事件处理系统。告警事件处理系统接收到外部系统的事件查询请求后，发送该事件查询请求所对应的告警事件的事件日志给外部系统。或者，告警事件处理系统还可以主动将告警事件的事件日志推送给外部系统。

向外部系统提供事件查询接口，或者推送告警事件的事件日志给外部系统，使得外部系统能够方便地获知告警事件的处理过程以及异常处理结果。

在本申请实施例中，为了使告警事件处理系统能够应对告警事件数量的变化，还可以对告警事件处理系统进行负载检测，在检测到负载过高时对告警事件处理系统进行扩容处理。具体地，告警事件处理系统还可以通过负载管理界面，设置或更新告警事件处理系统的超负荷条件及系统扩容策略，并存储该超负荷条件及系统扩容策略。

其中，超负荷条件包括以下条件中的至少之一：定位告警事件的根本异常原因的耗时大于第一预设时长；对定位出根本异常原因的告警事件进行异常处理的耗时大于第二预设时长；从告警事件产生到对该告警事件处理完成的耗时大于第三预设时长；告警事件处理系统的内存使用率大于预设使用率；告警事件接入告警事件处理系统的平均请求耗时大于第四预设时长；待处理的告警事件的队列长度大于预设长度等。

系统扩容策略包括以下策略中的至少之一：增加线程数；增加用于进行异常定位的服务节点数；增加用于进行异常处理的服务节点数；增加用于接入告警事件的服务节点数；为告警事件的根因定位和/或异常处理多分配计算资源或存储资源等。

通过负载管理界面与用户交互，能够使用户自定义地配置超负荷条件及系统扩容策略，使得告警事件处理系统的负载管理更加灵活和个性化。

在运行过程中采集告警事件处理系统的负载数据，该负载数据包括定位告警事件的根本异常原因的耗时、对定位出根本异常原因的告警事件进行异常处理的耗时、从告警事件产生到对该告警事件处理完成的耗时、告警系统的内存使用率、告警事件接入告警事件处理系统的平均请求耗时、待处理的告警事件的队列长度等多个数据中的至少之一。

告警事件处理系统基于采集的负载数据，根据上述超负荷条件，判断当前告警事件处理系统是否超负荷。若判定出告警事件处理系统超负荷，则基于负载数据和系统扩容策略，执行对应的系统扩容策略。

例如，若判定出定位告警事件的根本异常原因的耗时大于第一预设时长，则增加用于定位根本异常原因的服务节点数目。若判定出告警事件处理系统的内存使用率大于预设使用率，则为告警事件处理系统分配更多的存储资源。

通过上述负载检测及系统调整方式，实现了告警事件处理系统自动化负载检测及扩容调整的闭环调控能力，能够减少新增告警事件很多导致系统服务不可用的情况发生，使整个告警事件处理系统实现了自运维能力。

在本申请实施例中，将定位告警事件的根本异常原因的过程转变成可传承、可维护、可持续迭代的根因定位策略的程序进行存档。基于告警事件的告警事件类型对应的根因定位策略自动定位引发告警事件的根本异常原因，进而基于该根本异常原因有针对性地采取相应的异常处理策略，实现基于其根本异常原因采取相应地异常处理措施，达到有针对性地异常处理，提高异常处理的成功率和效率，使得告警事件处理系统能够处理更为复杂的根本异常原因引发的告警事件。

本申请的一些实施例提供了一种告警事件处理系统，该系统用于执行上述任一实施例提供的告警事件处理方法。图3示出了该告警事件处理系统的一种示意图，如图3所示，该告警事件处理系统包括管理界面和后台处理系统。

其中，管理界面，用于显示预设的配置显示界面，通过配置显示界面更新告警事件类型与根因定位策略的第一映射关系，以及告警事件类型、根本异常原因及异常处理策略的第二映射关系；告警事件类型用于指示告警事件对应的网络异常类型，根因定位策略为用于确定产生告警事件的根本异常原因，根本异常原因包括产生告警事件的具体网络异常节点和/或产生告警事件的异常节点的根本异常原因。

后台处理系统，用于存储第一映射关系和第二映射关系；获取告警事件，确定告警事件的告警事件类型；基于确定的告警事件类型，从存储的第一映射关系中获取告警事件对应的根因定位策略；针对告警事件，执行根因定位策略，确定告警事件的根本异常原因；以及，基于第二映射关系及告警事件的根本异常原因，对告警事件进行异常处理。

通过配置显示界面实现定位策略和异常处理策略的自定义配置，提高策略维护的便捷性。基于告警事件的告警事件类型对应的根因定位策略自动定位引发告警事件的根本异常原因，进而基于该根本异常原因有针对性地采取相应的异常处理策略，提高异常处理的成功率和效率。

如图4所示，上述后台处理系统包括获取模块、异常定位模块和异常处理模块。其中，获取模块用于获得告警事件，将告警事件传输给异常定位模块。异常定位模块用于定位告警事件的根本异常原因，将定位出的根本异常原因及告警事件传输给异常处理模块。异常处理模块用于基于告警事件的根本异常原因进行异常处理。

对于获取模块，如图5所示，获取模块可以包括告警生成单元和告警接入单元。其中，告警生成单元用于接收网络运行过程中产生的网络数据，从网络数据中筛选出异常网络数据，对异常网络数据进行去重处理；基于去重处理的异常网络数据生成告警事件；将生成的告警事件传输给告警接入单元。

上述网络数据可以包括网元数据、服务数据和通过埋点技术采集的探测数据等。网元数据可以包括网络中网元的负载量、系统占用率、数据传输速率等。服务数据可以包括单位时间内的用户访问量、请求响应时长、数据丢包率等。探测数据可以包括按键点击率、页面浏览量、网元启动次数、在线用户数等。

通过告警生成单元接收到网络数据后，对网络数据进行预处理，预处理包括对网络数据进行清洗、去重等操作。在本申请实施例中，告警生成单元中预先存储有预设异常规则，该预设异常规则用于规定异常网络数据所需满足的条件，如该预设异常规则可以规定负载量大于一定负载阈值的网元数据为异常网络数据，或者规定请求响应时长大于一定时长阈值的服务数据为异常网络数据，等等。

上述清洗操作指去除网络数据中不满足预设异常规则的数据，留下满足预设异常规则的异常网络数据。去重操作指将异常网络数据中重复的数据只保留一份，删除其他的重复数据。

经过上述预处理后，告警生成单元还基于最终得到的异常网络数据，生成告警事件处理系统支持的数据格式的告警事件，将生成的告警事件传输给告警接入单元。

网络中还存在一些第三方的告警平台，这些告警平台可以直接将本地生成的告警事件发送给本申请的告警处理系统。可以由上述告警接入单元接收第三方的告警平台发送的告警事件，若该告警事件的数据格式不是本告警处理系统支持的数据格式，则将该告警事件的数据格式标准化为告警处理系统支持的统一的数据格式。告警接入单元从告警生成单元和/或第三方告警平台接收到告警事件，并确认告警事件的数据格式为告警处理系统支持的数据格式之后，可以将告警事件传输给后台处理系统中的存储模块进行存储，或者传输给异常定位模块处理。

上述告警接入单元中还可以对获得的告警事件进行限流、去重等操作，避免短时间内多次触发相同的告警事件处理，或短时间内同一网元触发多次告警事件处理等。

告警事件中包括告警事件的告警事件类型及异常网络数据，告警事件类型用于指示告警事件的网络异常类型，如集群可用率下跌、负载过大、系统占用率过高、数据传输速率下跌等。

在本申请的另一些实施例中，如图6所示，该后台处理系统中还可以包括存储模块，告警接入单元可以将告警事件传输给存储模块进行存储。如图7所示，存储模块中具体可以包括日志服务节点，将得到的告警事件存储在日志服务节点中。异常定位模块从该日志服务节点中提取告警事件进行处理。

其中，日志服务节点采用SLS作为告警事件的存储载体，使告警事件处理的全过程的信息持久化，并使告警事件处理的所有相关信息具有可回放的功能。告警事件处理的全过程包括告警事件接入、定位根本异常原因及最终的异常处理过程。

上述存储模块还可以包括事件注册单元，如图7所示。上述第一映射关系可以存储在该事件注册单元中。如图7所示，告警事件处理系统包括配置显示界面，通过该配置显示界面更新上述第一映射关系，并将更新的第一映射关系存储在事件注册单元中。当告警事件处理系统检测到配置显示界面触发的配置请求时，从该配置显示界面接收用户提交的第一映射关系，存储该第一映射关系。具体将接收到的第一映射关系存储到上述事件注册单元中。

通过配置显示界面，方便用户自主配置告警事件类型与根因定位策略的第一映射关系，能够灵活地修改或者新增第一映射关系，更新第一映射关系后能够立即生效，无需对告警事件处理系统本身做任何程序上的修改，节省了研发成本。

在本申请的一些实施例中，异常定位模块可以对存储模块中的日志服务节点进行实时检测，检测到日志服务节点中存在待处理的告警事件，即从日志服务节点中获取告警事件来定位原因。异常定位模块可以包括一个或多个用于定位根本异常原因的微服务，包括多个微服务的场景中这些微服务可以部署在一台或多台服务器上。或者，异常定位模块也可以包括一个或多个用于定位根本异常原因的服务器，在每个服务器上通过创建一个或多个线程来执行定位告警事件的根本异常原因的操作。

异常定位模块还从存储模块中的事件注册单元中获取告警事件类型与根因定位策略的第一映射关系。异常定位模块从日志服务节点中获取告警事件与从事件注册单元中获取第一映射关系的操作，可以同步进行，也可以以任何顺序先后进行。异常定位模块基于获得的第一映射关系，确定当前告警事件的根本异常原因。

本申请将定位告警事件的根本异常原因的过程转变成可传承、可维护、可持续迭代的程序进行存档。通过独立的异常定位模块来确定告警事件的根本异常原因，使得整体的告警事件处理系统能够处理更为复杂的根本异常原因引发的告警事件。且确定告警事件的根本异常原因，从而可以基于其根本异常原因采取相应地异常处理措施，达到有针对性地异常处理，提高异常处理的成功率和效率。

在本申请的一些实施例中，告警事件处理系统还可以显示处理进度界面，通过该处理进度界面显示确定根本异常原因的确定进度。

告警事件处理系统的首页或上述的配置显示界面中可以提供用于查询告警事件的处理进度的链接。当检测到该链接触发的查询请求时显示处理进度界面。或者，该处理进度界面也可以为上述配置显示界面中的部分显示区域。在显示配置显示界面时，可以在该配置显示界面上的一块区域中显示告警事件的处理进度。在通过异常定位模块对告警事件定位根本异常原因的过程中，在上述处理进度界面中展示确定根本异常原因的确定进度。

通过进度处理界面能够准确清晰地呈现确定告警事件的根本异常原因的确定进度，能够使根本异常原因的定位更加直观。

对于异常定位模块，如图8所示，异常定位模块包括定位计算单元，定位计算单元从存储模块中的日志服务节点中获取告警事件，以及从存储模块中的事件注册单元中获取告警事件类型与根因定位策略的第一映射关系。定位计算单元基于该告警事件的告警事件类型从第一映射关系中获取对应的根因定位策略，执行该根因定位策略得到该告警事件的根本异常原因。

异常定位模块和存储模块可以部署在不同的服务器中，在这种情况下定位计算单元根据需要从事件注册单元中获取第一映射关系，因此异常定位模块无需存储第一映射关系，节省异常定位模块的存储资源。

如图9所示，异常定位模块还可以包括故障模型系统，每当存储模块中的事件注册单元中存入更新的告警事件类型与根因定位策略的第一映射关系时，都将更新的第一映射关系发送给异常定位模块，将更新的第一映射关系存储到故障模型系统中。当定位计算单元获取到告警事件后，从故障模型系统中获取该告警事件对应的根因定位策略，然后对该告警事件执行该根因定位策略得到根本异常原因。

事件注册单元将更新的第一映射关系发送给异常定位模块，并存储到故障模型系统中之后，事件注册单元就可以将更新的第一映射关系删除，以节省事件注册单元的存储资源。

定位计算单元确定出告警事件的根本异常原因后，还需要对该告警事件进行更新。在一种实现方式中，日志服务节点中可以分别通过两个队列来存储未定位原因的告警事件和已定位原因的告警事件。定位计算单元得到告警事件的根本异常原因后，可以将该告警事件与其根本异常原因封装为新的告警事件，将该新的告警事件传输给日志服务节点。日志服务节点将定位计算单元传过来的告警事件存储在已定位原因的告警事件队列中，以便后续异常处理模块从已定位原因的告警事件队列中取告警事件进行异常处理。

在另一种实现方式中，在告警事件中设置事件状态的字段来区分已定位原因和未定位原因两种状态。日志服务节点中通过一个队列来存储所有告警事件。定位计算单元确定出当前告警事件的根本异常原因后，修改该告警事件的事件状态为已定位原因，将根本异常原因及修改状态后的告警事件封装为新的告警事件。将新的告警事件传输给日志服务节点，日志服务节点将该新的告警事件存储在队列中，以便后续异常处理模块从该队列中取告警事件进行异常处理。

在本申请实施例中，异常处理模块包括自动化处理单元和人工处理单元，如图10所示。异常定位模块确定出告警事件的根本异常原因后，由异常处理模块对该告警事件进行异常处理。具体地，异常处理模块从日志服务节点的相应队列中获取已定位原因的告警事件，从该告警事件中提取出告警事件类型及根本异常原因。异常处理模块从事件注册单元中获取第二映射关系。根据根本异常原因及告警事件中的告警事件类型，从第二映射关系中，获取对应的异常处理策略。对该告警事件执行获取的异常处理策略。

若该异常处理策略为人工处理策略，则通过人工处理单元将所述告警事件推送给维护人员。若该异常处理策略为自动化处理策略，则可以由异常处理模块中的自动化处理单元执行该自动化处理策略，或者，也可以通过自动化处理单元执行该异常处理策略。

过上述方式对告警事件进行异常处理的过程中，也可以显示异常处理策略的处理进度。具体可以通过前面提及的处理进度界面来显示异常处理策略的处理进度，若告警事件的异常处理策略为自动化处理策略，则该处理进度可以包括异常处理策略的程序执行过程以及异常处理结果，或者该处理进度可以包括执行异常处理策略的自动化处理平台的相关信息以及该平台返回的异常处理结果。若告警事件的异常处理策略为人工处理策略，则该处理进度可以包括人工处理平台或运维人员的相关信息以及返回的异常处理结果。

在一些实施例中，异常处理模块对定位出根本异常原因的告警事件进行处理，并得到异常处理结果后，还将异常处理结果封装到该告警事件中。至此该告警事件中至少包括告警事件类型、异常网络数据、根本异常原因及异常处理结果，将封装后的告警事件存储在事件日志中。或者，在另一些实施例中，异常处理模块也可以不将异常处理结果封装到该告警事件中，而是将该告警事件和异常处理结果均存储在事件日志中。

如图11所示，该告警事件处理系统还可以包括日志管理模块，上述事件日志均存储在日志管理模块中。该日志管理模块可以包括事件中心和通知中心，该事件中心用于生成并存储告警事件对应的事件日志。对于未处理完成的告警事件，可以在定位出根本异常原因或完成异常处理后更新事件中心中存储的该告警事件的事件日志。例如，对于尚未定位的告警事件，可以将该告警事件的事件日志存储在事件中心中，当异常定位模块定位出该告警事件的根本异常原因并将根本异常原因封装在该告警事件中后，可以更新事件中心中存储的对应的事件日志中的该告警事件。

上述通知中心用于接收外部系统的事件查询请求，从事件中心获取查询请求对应的事件日志，发送查询的事件日志给外部系统；或者，将事件日志推送给外部系统。通知中心为外部系统提供通知服务或订阅服务，外部系统可以包括外部的网络管理平台、大数据分析平台或第三方网络系统等。通知中心在接收到外部系统发送的事件查询请求后从事件中心获取对应的事件日志，将该事件日志返回给外部系统。或者通知中心基于订阅服务将事件日志推送给外部系统。

在本申请的一些实施例中，为了提高告警事件处理的时效性，在该后台处理系统中还设置有流式引擎模块，如图12所示，该流式引擎模块与存储模块、异常定位模块及异常处理模块都进行数据交互。该流式引擎模块，用于从存储模块获取告警事件，若告警事件为未定位原因的事件，则将告警事件传输给后台处理系统包括的异常定位模块。若告警事件为已定位原因的事件，则将告警事件传输给后台处理系统包括的异常处理模块。

上述流式引擎模块负责告警事件在整个后台处理系统中的流转、调度，提高告警事件处理的时效性、完整性及一致性。如图12所示，该流式引擎模块包括调度引擎算子，该流式引擎模块是基于flink开发的流计算任务，flink是一个框架和分布式处理引擎，用于对无限制和有限制的数据流进行有状态的计算。具体地，基于flink的UDF（UserDefinedFunction，用户自定义）功能开发的调度引擎算子。该调度引擎算子会实时消费存储模块中日志服务节点存储的告警事件，告警事件在整个后台处理系统各处理模块之间流转的实时性得到很大提升。

该调度引擎算子，用于实时从日志服务节点获取告警事件，以及从事件注册单元获取第一映射关系和第二映射关系；若获取的告警事件未定位根因，则将告警事件传输给后台处理系统包括的异常定位模块，以及将第一映射关系或告警事件对应的根因定位策略传输给异常定位模块；若告警事件已定位根因，则将告警事件传输给后台处理系统包括的异常处理模块，以及将第二映射关系或告警事件及其根本异常原因对应的异常处理策略传输给异常处理模块；

该调度引擎算子从日志服务节点获取到告警事件后，首先从该告警事件中解析出事件状态，若该事件状态为未定位原因，则该调度引擎算子将该告警事件传输给异常定位模块。若该事件状态为已定位原因，则该调度引擎算子将该告警事件传输给异常处理模块。

对于根因定位策略的调度，一种实现方式中，该调度引擎算子在从日志服务节点中获得告警事件并确认为未定位原因的事件时，该调度引擎算子从该告警事件中解析出该告警事件的告警事件类型，基于该告警事件类型从存储模块的事件注册单元中获取该告警事件类型对应的根因定位策略，然后将该根因定位策略和该告警事件一起发送给异常定位模块。在这种实现方式中，异常定位模块无需存储告警事件类型与根因定位策略的第一映射关系，有助于节省异常定位模块所占用的存储资源。

另一种实现方式中，该调度引擎算子从日志服务节点中获取到未定位原因的告警事件时将该告警事件发送给异常定位模块。调度引擎算子周期性地检测事件注册单元中是否存在更新的告警事件类型与根因定位策略的第一映射关系，检测到存在更新的第一映射关系时，将该第一映射关系发送给异常定位模块的故障模型系统存储。在该实现方式方式中异常定位模块存储该第一映射关系后事件注册单元即可删除该第一映射关系，有助于节省事件注册单元的存储资源。

相似地，对于异常处理策略的调度，一种实现方式中，该调度引擎算子在从日志服务节点中获得告警事件并确认为已定位原因的事件时，该调度引擎算子从该告警事件中解析出该告警事件的告警事件类型及根本异常原因，基于该告警事件类型及根本异常原因从存储模块的事件注册单元中获取该告警事件类型及根本异常原因对应的异常处理策略，然后将该异常处理策略和该告警事件一起发送给异常处理模块。在这种实现方式中，异常处理模块无需存储告警事件类型、根本异常原因与异常处理策略的第二映射关系，有助于节省异常处理模块所占用的存储资源。

另一种实现方式中，该调度引擎算子从日志服务节点中获取到已定位原因的告警事件时将该告警事件发送给异常处理模块。调度引擎算子周期性地检测事件注册单元中是否存在更新的告警事件类型、根本异常原因与异常处理策略的第二映射关系，检测到存在更新的第二映射关系时，将该第二映射关系发送给异常处理模块存储。在该实现方式方式中异常处理模块存储该第二映射关系后事件注册单元即可删除该第二映射关系，有助于节省事件注册单元的存储资源。

该调度引擎算子，还用于接收异常处理模块发送的已定位根因的告警事件，将已定位根因的告警事件传输给日志服务节点存储；已定位根因的告警事件中封装有该告警事件的根本异常原因。

异常定位模块定位出告警事件的根本异常原因，并将该根本异常原因封装到该告警事件中后，还将该告警事件返回给流式引擎模块，由调度引擎算子将该告警事件存储到存储模块中的日志服务节点中。异常处理模块获得告警事件的异常处理结果后并将该异常处理结果封装到该告警事件中后，也将该告警事件返回给流式引擎模块，由调度引擎算子将该告警事件存储到日志服务节点中。

该流式引擎算子还将告警事件的事件日志发送给日志管理模块中的事件中心存储，以及在告警事件定位出根本异常原因或获得异常处理结果时向日志管理模块中的通知中心发送事件更新的通知，以便通知中心能够及时将更新后的告警事件的事件日志推送给使用订阅服务的外部系统。

在本申请实施例中，管理界面，还用于显示负载管理界面，该负载管理界面用于设置或更新告警事件处理系统的超负荷条件以及系统扩容策略。如图13所示该后台处理系统还可以包括负载管理模块，负载管理模块用于检测后台处理系统中各模块的负载情况，并在出现负载过高的情况进行扩容调整。如图13所示该负载管理模块包括负载检测单元和计算调整单元。负载检测单元，用于采集后台处理系统的负载数据。计算调整单元，用于从后台处理系统的存储模块获取存储的超负荷条件和系统扩容策略；基于负载数据，根据超负荷条件，判断当前告警事件处理系统是否超负荷；当告警事件处理系统超负荷时，基于负载数据和系统扩容策略，执行对应的系统扩容策略。

其中，负载检测单元可以包括服务集群检测子单元、流式引擎检测子单元和接入集群检测子单元。

服务集群检测子单元用于采集异常定位模块及异常处理模块的负载数据，该负载数据包括定位告警事件的根本异常原因的耗时、对定位出根本异常原因的告警事件进行异常处理的耗时等。服务集群检测子单元将采集的负载数据发送给计算调整单元，计算调整单元判断异常定位模块和/或异常处理模块是否满足预先配置的超负荷条件，如果是，则基于该判定结果及预先配置的系统扩容策略进行相应地扩容处理。例如，若异常定位模块定位根本异常原因的耗时过长，则增加异常定位模块的服务节点数目。

流式引擎检测子单元用于采集流式引擎模块的负载数据，该负载数据包括从告警事件产生到对该告警事件处理完成的耗时、待处理的告警事件的队列长度等。将该负载数据发送给计算调整单元，计算调整单元判断流式引擎模块是否满足超负荷条件，如果是，则基于判断结果及系统扩容策略，进行相应地扩容处理。例如，若待处告警事件接入告警事件处理系统的平均请求耗时过长，则为流式引擎模块分配更多的计算资源或创建更多的线程。

接入集群检测子单元用于采集获取模块的负载数据，该负载数据包括事件接入接口的平均请求耗时。将该负载数据发送给计算调整单元，计算调整单元判断获取模块是否满足超负荷条件，如果是，则基于判断结果及系统扩容策略，进行相应地扩容处理。例如，若事件接入接口的平均请求耗时过长，则增加告警接入模块的服务节点数目。

图14示出了负载管理模块的工作原理图，如图4所示，通过管理界面将超负荷条件和系统扩容策略配置给计算调整单元，服务集群检测子单元对异常定位模块和异常处理模块进行检测，采集事件处理速率、事件队列长度等负载数据。流式引擎检测子单元对于流式引擎模块进行检测，采集事件滞留时长、事件消费延迟、内存使用率等负载数据。接入集群检测子单元对获取模块进行检测，采集事件处理速率、事件队列长度等负载数据。上述各检测子单元将采集的数据传输给计算调整单元。计算调整单元基于接收到的数据以及预先配置的超负荷条件和系统扩容策略判断需要进行扩容调整的目标模块，并对目标模块执行相应的扩容操作。

为了更加直观地展示本申请的告警事件处理系统的架构，如图15所示，在图13的基础上，从实现功能角度对管理界面进行了细化。如图15所示管理界面可以用于配置根因定位策略、异常处理策略、超负荷条件、系统扩容策略，还可以用于显示告警事件的处理进度。

在本申请实施例中，异常定位模块可以是基于分布式master-woker模式的计算框架来实现事件的实时消费定位逻辑。如图16所示，该分布式master-woker模式包括中心master、agent-master和worker三个处理单元，中心master接收到不同的告警事件，并获取到告警事件对应的根因定位策略后，将告警事件及其对应的根因定位策略分发到不同Agent-Master的队列中，进入执行定位任务的流程。

Agent-Master主要负责接收请求、分发任务、上报结果等，实时消费对队列里面的告警事件及根因定位策略来获取定位任务，然后将定位任务分发给Worker进行执行，并上报Worker执行的结果。Agent-Master也可以周期性地将告警事件定位根本异常原因的结果传输给日志管理模块存储。Agent-Master还将封装了根本异常原因的告警事件传输给日志服务节点存储，后续异常处理模块再从日志服务节点中获取已定位原因的告警事件进行异常处理。

Worker负责执行具体的定位任务，执行传入的告警事件对应的根因定位策略，并将得到的结果上报给Agent-Master。

如图17所示，异常处理模块也可以是基于分布式master-woker模式的计算框架来实现事件的异常处理逻辑。中心master接收到已定位原因的告警事件，并获取到告警事件的根本异常原因对应的异常处理策略，将告警事件及其对应的异常处理策略分发给Agent-Master的队列中。

Agent-Master主要负责接收请求、分发任务、上报结果等，实时消费对队列里面的告警事件及异常处理策略，然后将异常处理任务分发给Worker进行执行，并上报Worker执行的结果。Agent-Master也可以周期性地将告警事件的异常处理结果传输给日志管理模块存储。

Worker负责执行具体的异常处理任务，判断该告警事件对应的异常处理策略，如果是自动化处理策略，则转发给相应的自动化处理平台。如果是人工处理策略，则转发给相应的人工处理平台。

本申请实施例中，将定位告警事件的根本异常原因的过程转变成可传承、可维护、可持续迭代的定位策略的程序进行存档。通过管理界面将根因定位策略配置到事件注册单元中，异常定位模块基于告警事件的告警事件类型对应的根因定位策略自动定位引发告警事件的根本异常原因，异常处理模块基于该根本异常原因有针对性地采取相应的异常处理策略，实现基于其根本异常原因采取相应地异常处理措施，达到有针对性地异常处理，提高异常处理的成功率和效率，使得告警事件处理系统能够处理更为复杂的根本异常原因引发的告警事件。还可以通过流式引擎模块实现告警事件在各个模块之间的流转调度，提高告警事件处理的实时性，实现告警事件全流程的自动化处理。

本申请实施方式还提供一种电子设备，以执行上述告警事件处理方法。请参考图18，其示出了本申请的一些实施方式所提供的一种电子设备的示意图。如图18所示，电子设备4包括：处理器400，存储器401，总线402和通信接口403，所述处理器400、通信接口403和存储器401通过总线402连接；所述存储器401中存储有可在所述处理器400上运行的计算机程序，所述处理器400运行所述计算机程序时执行本申请前述任一实施方式所提供的告警事件处理方法。

其中，存储器401可能包含高速随机存取存储器（RAM：RandomAccess Memory），也可能还包括非不稳定的存储器（non-volatile memory），例如至少一个磁盘存储器。通过至少一个通信接口403（可以是有线或者无线）实现该装置网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。

总线402可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。其中，存储器401用于存储程序，所述处理器400在接收到执行指令后，执行所述程序，前述本申请实施例任一实施方式揭示的所述告警事件处理方法可以应用于处理器400中，或者由处理器400实现。

处理器400可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器400中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器400可以是通用处理器，包括处理器(Central ProcessingUnit，简称CPU)、网络处理器(NetworkProcessor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器401，处理器400读取存储器401中的信息，结合其硬件完成上述方法的步骤。

本申请实施例提供的电子设备与本申请实施例提供的告警事件处理方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施方式还提供一种与前述实施方式所提供的告警事件处理方法对应的计算机可读存储介质，请参考图19，其示出的计算机可读存储介质为光盘50，其上存储有计算机程序（即程序产品），所述计算机程序在被处理器运行时，会执行前述任意实施方式所提供的告警事件处理方法。

需要说明的是，所述计算机可读存储介质的例子还可以包括，但不限于相变内存(PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

本申请实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行以实现权上述任一实施例所述的告警事件处理方法。

本申请的上述实施例提供的计算机可读存储介质、计算机程序产品均与本申请实施例提供的告警事件处理方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。

需要说明的是：

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下示意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。