CN114157553A - 一种数据处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种数据处理方法、装置、设备及存储介质，所述方法包括：获取所述数据处理系统包括的至少两个节点设备的告警信息；基于所述至少两个节点设备，确定至少一个异常子系统；针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。该方案可以清楚的展示出异常的子系统以及对应的告警信息，从而提高了故障定位的效率。

Description

一种数据处理方法、装置、设备及存储介质

技术领域

本申请涉及数据处理技术领域，涉及但不限于数据处理方法、装置、设备及存储介质。

背景技术

随着计算机技术的飞速发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性和实时性要求，也对技术提出了更高的要求。网络技术不断发展，网络系统(也可以称为数据处理系统)中的设备越来越多，各设备之间的关系也越来越复杂。在据处理系统中出现设备故障时，由于一个设备故障可能导致与其相关的其他设备也出现故障，所以在较复杂的数据处理系统中，如何定位故障尤其重要。

相关技术中，一般采用分布式监控(Zabbix)和开源监控(open-falcon)对系统进行监控，具体的，在每台被监控设备上部署一个代理(agent)进程，被监控设备通过agent采集告警信息，并通过Zabbix和open-falcon将告警信息上报给代理(proxy)，proxy再将告警信息上报给监控设备(server)进行汇总，然后就可以在监控设备的上展示以实例维度的告警信息。

但是，仅以设备为处理维罗列出每个被监控设备的告警信息，在告警较多的情况下，可能出现告警风暴，导致故障定位困难。

发明内容

本申请提供一种数据处理方法及装置、设备、存储介质，该方案可以清楚的展示出异常的子系统以及对应的告警信息，从而提高了故障定位的效率。

本申请的技术方案是这样实现的：

本申请提供了一种数据处理方法，所述方法应用于数据处理系统中的控制设备，所述数据处理系统还包括节点设备，所述方法包括：

获取所述数据处理系统包括的至少两个节点设备的告警信息；

基于所述至少两个节点设备，确定至少一个异常子系统；

针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；

针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。

本申请提供了一种数据处理装置，所述装置部署于数据处理系统中的控制设备，所述数据处理系统还包括节点设备，所述装置包括：

获取单元，用于获取所述数据处理系统包括的至少两个节点设备的告警信息；

确定单元，用于基于所述至少两个节点设备，确定至少一个异常子系统；

处理单元，用于针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；

展示单元，用于针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。

本申请还提供了一种电子设备，包括：存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述数据处理方法。

本申请还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述数据处理方法。

本申请所提供的数据处理方法、装置、设备及存储介质，包括：获取所述数据处理系统包括的至少两个节点设备的告警信息；基于所述至少两个节点设备，确定至少一个异常子系统；针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。本方案可以将以设备为维度的告警信息收敛至以系统为维度的告警信息；并以系统为维度进行对应展示，这样，可以根据展示的内容，清楚的得知哪个子系统异常，哪个子系统正常，提高了定位故障子系统的效率。

附图说明

图1为本申请实施例提供的数据处理系统的一种可选的结构示意图；

图2为本申请实施例提供的数据处理方法的一种可选的流程示意图；

图3为本申请实施例提供的数据处理方法的一种可选的流程示意图

图4为本申请实施例提供的数据处理方法的一种可选的流程示意图；

图5为本申请实施例提供的数据处理方法一种可选的流程示意图；

图6为本申请实施例提供的数据处理方法一种可选的流程示意图；

图7为本申请实施例提供的数据处理方法一种可选的流程示意图；

图8为本申请实施例提供的执行器的一种可选的结构示意图；

图9为本申请实施例提供的数据处理装置的一种可选的结构示意图；

图10为本申请实施例提供的电子设备的一种可选的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对申请的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅是为例区别不同的对象，不代表针对对象的特定排序，不具有先后顺序的限定。可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

本申请实施例可提供数据处理方法及装置、设备和存储介质。实际应用中，数据处理方法可由数据处理装置实现，数据处理装置中的各功能实体可以由控制设备的硬件资源，如处理器等计算资源、通信资源(如用于支持实现光缆、蜂窝等各种方式通信)协同实现。

本申请实施例提供的数据处理方法应用于数据处理系统，数据处理系统包括控制设备和节点设备。控制设备执行：获取所述数据处理系统包括的至少两个节点设备的告警信息；基于所述至少两个节点设备，确定至少一个异常子系统；针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。

作为一示例，数据处理系统10的结构可如图1所示，包括：控制设备101、节点设备102以及网络103。其中，控制设备101可以通过网络103与节点设备102通信。

控制设备101用于执行：获取所述数据处理系统包括的至少两个节点设备的告警信息；基于所述至少两个节点设备，确定至少一个异常子系统；针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。

节点设备102可以为服务器或路由器等硬件设备，或者还可以为虚拟机或容器等虚拟设备。

网络103用于控制设备101与节点设备102之间的通信。其中，网络103可以包括有限网络、无线网络等等。

需要说明的是，本申请实施例对于数据处理系统中的节点设备102的数量以及控制设备101的数量不作具体限定可以根据实际需求进行配置。在一示例中，控制设备101的数量可以为一个，节点设备102的数量可以为多个。其中，多个节点设备102属于不同的子系统。

下面，结合图1所示的数据处理系统的示意图，对本申请实施例提供的数据处理方法及装置、设备和存储介质的各实施例进行说明。

第一方面，本申请实施例提供一种数据处理方法，该方法应用于数据处理装置；其中，该数据处理装置可以部署于图1中的控制设备101。下面，对本申请实施例提供的数据处理过程进行说明。

图2示意了一种可选的一种数据处理方法的流程示意图，本申请实施例提供的数据处理方法，该方法可以包括但不限于图2所示的S201至S204。

S201、控制设备获取所述数据处理系统包括的至少两个节点设备的告警信息。

数据处理系统包括多个节点设备，该多个节点设备中的至少两个节点出现异常，控制设备获取该出现异常的至少两个节点设备的告警信息。

需要说明的是，出现异常的至少两个节点设备可以是数据处理系统包括的多个节点设备的部分或者全部。本申请实施例对存在告警信息的节点设备的具体数量不做具体限定，可以根据实际需求进行配置。

节点设备的告警信息用于表示节点设备异常，本申请实施例对节点设备的告警信息的具体内容不作限定，可以根据实际需求进行配置。

在一种可能的实施方式中，节点设备的告警信息可以包括至少一个第一告警级别、与至少一个第一告警级别一一对应的第一告警数量。例如，节点设备的告警信息可以包括：紧急(Critical)告警、与紧急告警对应的数量1；主要(Major)告警、与主要告警对应的数量2；以及次要(Minor)告警、与次要告警对应的数量3。其中，与紧急告警对应的数量1表征发生紧急告警的次数为1；与主要告警对应的数量2表征发生主要告警的次数为2；与次要告警对应的数量3表征发生次要告警的次数为3。

在一种可能的实施方式中，节点设备的告警信息还可以包括：与至少一个第一告警级别一一对应的告警类型，与至少一个第一告警级别一一对应的告警时间、与至少一个第一告警级别一一对应的告警日志等等。

S201的实施可以包括：控制设备接收至少两个节点设备上报的告警日志，控制设备针对至少两个节点中的每个节点设备，对节点设备的告警日志进行处理，得到节点设备的告警信息。

S202、控制设备基于所述至少两个节点设备，确定至少一个异常子系统。

控制设备将存在告警信息的至少两个节点设备所属的异常子系统，确定为该至少一个异常子系统。其中，至少两个节点设备可以属于一个异常子系统，也可以属于多个异常子系统。

S203、控制设备针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息。

其中，第一处理包括：将异常子系统包括的至少一个节点设备的告警信息，收敛为异常子系统的告警信息。

子系统的告警信息用于表示子系统异常，本申请实施例对子系统的告警信息的具体内容不作限定，可以根据实际需求进行配置。

在一种可能的实施方式中，子系统的告警信息可以包括至少一个第二告警级别、与至少一个第二告警级别一一对应的第二告警数量。例如，子系统的告警信息可以包括：紧急(Critical)告警、与紧急告警对应的数量4；主要(Major)告警、与主要告警对应的数量5；次要(Minor)告警、与次要告警对应的数量6。

在一种可能的实施方式中，子系统的告警信息还可以包括：与至少一个第二告警级别一一对应的告警类型，与至少一个第二告警级别一一对应的告警时间、与至少一个第二告警级别一一对应的节点设备等等。

控制设备针对至少一个异常子系统中的每个异常的子系统执行第一处理，将该异常子系统包括的至少一个节点设备的告警信息，收敛为异常子系统的告警信息；从而得到至少一个异常子系统的告警信息。

S204、控制设备针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。

本申请实施例对对应展示异常子系统以及异常子系统的告警信息的方式不作具体限定，可以根据实际需求进行配置。

在一种可能的实施方式中，可以通过图的方式进行展示。对应的，S204的实施可以包括：在图中展示数据处理系统中的至少一个异常子系统，并在每个异常子系统的对应位置展示该异常子系统的告警信息。其中，在该种实施方式中，可以通过在系统原有图(例如流程图，结构图)的基础上进行展示，也可以是通过新建一个图进行展示。

在另一种可能的实施方式中，可以通过文字的方式进行展示。对应的，S204的实施可以包括：通过文字的方式对应展示数据处理系统中的至少一个异常子系统，以及异常子系统的告警信息。

本申请实施例提供的数据处理方案包括：获取所述数据处理系统包括的至少两个节点设备的告警信息；基于所述至少两个节点设备，确定至少一个异常子系统；针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。本方案可以将以设备为维度的告警信息收敛至以子系统为维度的告警信息；并以子系统为维度进行对应展示，这样，可以根据展示的内容，清楚的得到哪个子系统异常，哪个子系统正常，提高了定位故障子系统的效率。

下面，对S201控制设备获取所述数据处理系统包括的至少两个节点设备的告警信息的过程进行说明。其中，控制设备获取每个节点设备的告警信息的过程类似，现以一个节点设备为例，对该过程进行说明。该过程可以包括但不限于下述S2011至S2013。

S2011、控制设备对所述节点设备上报的告警日志进行处理，得到表征告警提示的关键字字段。

控制设备对告警日志中的信息按照切割规范进行切割，得到多个切割后的字段，在多个切割后的字段中确定关键字字段，并提取各信息关键字字段的内容(告警提示)。

需要说明的是，切割规则需要与具体的日志规范对应。例如：一个日志规范以空格为间隔对各信息(例如包括告警设备、告警时间、告警级别)进行区分，则切割规则为以空格为界限进行切割，得到告警设备、告警时间以及告警级别。

S2012、控制设备基于所述关键字字段表征的告警提示，确定针对所述节点设备的M个第一告警级别，以及与所述M个第一告警级别一一对应的M个第一告警数量。

其中，M大于或等于1。

控制设备将各告警提示按照日志中出现的数量按照从大到小的顺序进行排序，确定出排名前K的告警提示，根据告警提示确定对应告警级别，得到M个第一告警级别；统计每个第一告警级别对应的第一告警的数量。

其中，K大于或等于M。即一个告警级别可以对应一个或者多个类型的告警提示。例如，告警提示“JDBC异常”对应重要告警；告警提示“内存异常”也对应重要告警。

S2013、控制设备基于所述M个第一告警级别，以及所述M个第一告警级数量，更新针对所述节点设备的第一告警字典，得到所述节点设备的告警信息。

其中，N大于或等于M。

第一告警字典包括N个第一告警级别，以及与N个第一告警级别一一对应的N个第一预设告警数量。

本申请实施例对第一告警字典的表达形式不做具体限定，可以根据实际需求进行配置。示例性的，第一告警字典可以配置为：{‘minor’：0；‘major’：0；‘critical’：0}。

示例性的，得到的节点设备(IP为8.8.8.8的容器)的告警信息包括：{‘minor’：0，‘major’：1，‘critical’：0}。对应的，M个第一告警级别为‘major’，与M个第一告警级数量为1。

控制设备基于M个第一告警级别，以及与M个第一告警级别一一对应的第一告警级数量，更新针对节点设备的第一告警字典，得到节点设备的告警信息。

这样，由于针对节点设备的第一告警字典的形式是预先设置的，在获得设备的告警信息时，只需根据具体告警内容更新告警字典，实现简单、清楚。

下面，对S203中，控制设备将将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息的过程进行说明。该过程可以包括但不限于下述S2031至S2033。

S2031、控制设备获得所述异常子系统包括的至少一个节点设备的告警信息。

其中，节点设备的告警信息包括M个第一告警级别，以及与M个第一告警级别一一对应的M个第一告警数量。

控制设备根据异常子系统包括的节点设备的标识，获取异常子系统包括的节点设备的告警信息。其中，异常子系统可以包括一个或多个节点设备。

S2032、控制设备基于所述至少一个节点设备中每个所述节点设备的M个第一告警级别，以及所述M个第一告警数量，确定针对所述异常子系统的P个第二告警级别，以及与所述P个第二告警级别一一对应的P个第二告警数量。

其中，P大于或等于M。

控制设备将至少一个节点设备中每个节点设备的M个第一告警级别的并集确定为P个第二告警级别；针对P个第二告警级别中的每个第二告警级别，控制设备将至少一个节点设备中每个节点设备中，与该第二告警级别具有相同内容的第一告警级别的第一告警数量之和作为与该第二告警级别对应的第二告数量。

S2033、控制设备基于所述P个第二告警级别，以及所述P个第二告警数量，更新针对所述异常子系统的第二告警字典，得到所述异常子系统的告警信息。

其中，Q大于或等于P。

第二告警字典包括Q个第二告警级别，以及与Q个第二告警级别一一对应的第二预设告警数量。

本申请实施例对第二告警字典的表达形式不做具体限定，可以根据实际需求进行配置。示例性的，第二告警字典可以配置为：{‘minor’：0；‘major’：0；‘critical’：0}。

例如，异常子系统1包括两个节点设备，分别为节点设备1和节点设备2。其中，节点设备1的告警信息包括{‘minor’：0，‘major’：1，‘critical’：0}；节点设备2的告警信息包括{‘minor’：0，‘major’：1，‘critical’：1}；收敛后的异常子系统1的告警信息包括：{‘minor’：0，‘major’：2，‘critical’：1}。

这样，由于针对子系统的第二告警字典的形式是预先设置的，在获得设备的告警信息时，只需根据各节点设备的告警字典中的内容更新第二告警字典，即更新子系统的告警级别，以及每个告警级别下的告警数量，实现简单、清楚。

下面，对S204控制设备针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息的过程进行说明。该过程可以包括但不限于下述实施方式A1或实施方式A2。

实施方式A1、通过图的形式进行展示；

实施方式A2、通过文字的形式进行展示。

实施方式A1可以包括但不限于下述S2041至S2043。

S2041、控制设备获得交易流程图；所述交易流程图中展示了所述至少一个异常子系统。

在一种可能的实施方式中，S2041可以实施为：控制设备采用graphviz画图的方式，对交易过程涉及的系统流程进行绘制，得到交易流程图。

在另一种可能的实施方式中，交易的流程图是预先绘制好并存储在固定位置的，S2041可以实施为：控制设备的存储交易流程图的固定位置获取交易流程图。

S2042、控制设备在所述交易流程图中，针对所述至少一个异常子系统中的每个异常子系统，确定所述异常子系统在所述交易流程图中所属的子系统节点。

控制设备对至少一个异常子系统中的每个异常子系统，根据交易流程图中的各子系统的节点标识，确定异常子系统在交易流程图中所属的子系统节点。

S2043、控制设备对应所述子系统节点展示所述异常子系统的告警信息。

本申请实施例对控制设备对应子系统节点展示异常子系统的告警信息的具体方式不作具体限定，可以根据实际需求进行配置。例如，可以在子系统节点的预设位置(左侧、右侧、上侧、下侧等等)展示异常子系统的告警信息。

实施方式A2可以包括：通过文字的方式对应展示数据处理系统中的至少一个异常子系统，以及异常子系统的告警信息。

采用实施方式A1，通过图的形式进行展示异常子系统的告警信息，不仅可以清楚各异常子系统的告警信息，还可以清楚异常子系统与系统中的其他子系统之间的逻辑关系。

采用通过文字的形式进行展示，由于文字信息的数据量小，且兼容性好，所以易于实现。

本申请实施例提供的数据处理方法，在确定异常子系统后，还可以对异常子系统进行进一步的处理。其中，对每个异常子系统的处理过程类似，现以一个异常子系统为例进行说明。

如图3所示，该过程可以包括但不限于下述S205至S207。

S205、控制设备确定所述异常子系统中满足第一条件的节点设备为待处理节点设备。

在一种可能的实施方式中，若异常子系统中，只有一个节点设备存在异常，即只有一个节点设备存在告警信息，则将该一个节点设备确定为待处理节点设备。

在另一种可能的实施方式中，一个异常子系统中多个节点设备存在异常，即多个节点设备存在告警信息，则将该多个节点设备均确定为待处理节点设备。

S206、控制设备判断所述待处理节点设备是否故障。

本申请实施例对判断待处理节点设备是否故障的方式不做具体限定，可以根据实际需求进行配置。

S207、控制设备在所述待处理节点设备故障的情况下，向所述待处理节点设备发送第一指令，以使所述待处理节点设备在所述第一指令的指示下执行对应操作。

其中，对应的操作可以包括：做内存，线程，进程的dump，重启，隔离，自动扩容等等。

这样在节点设备故障的情况下，可以自动执行对应的操作，提高了故障情况下的处理效率。

下面，对S205控制设备确定所述异常子系统中满足第一条件的节点设备为待处理节点设备的过程进行说明。该过程可以包括但不限于下述S2051和S2052。

S2051、控制设备确定所述异常子系统中每个所述节点设备的告警分数。

示例性的，控制设备可以通过下述公式(1)确定节点设备的告警分数。

F＝Q(minor)×f1+Q(major)×f2+Q(critical)×f3公式(1)；

其中，F表示节点设备的告警分数；Q(minor)表示minor告警级别对应的第一告警数量；Q(major)表示major告警级别对应的第一告警数量；Q(critical)表示critical告警级别对应的第一告警数量；f1表示minor告警级别对应的告警分数；f2表示major告警级别对应的告警分数；f3表示critical告警级别对应的告警分数。

在一示例中，f1可以为1分，f2可以为2分，f3可以为4分。

S2052、若第一节点设备的告警分数大于或等于第一分数阈值，且第二节点设备的告警分数小于或等于第二分数阈值，则控制设备确定所述第一节点设备为所述待处理节点设备。

其中，第一分数阈值大于第二分数阈值。

第一节点设备为异常子系统中的任一节点设备，第二节点设备为异常子系统中除第一节点设备之外的节点设备。

若第一节点设备的告警分数大于或等于第一分数阈值，且第二节点设备的告警分数小于或等于第二分数阈值，则控制设备确定第一节点设备为待处理节点设备；若不存在满足条件的第一节点设备，则确定不存在待处理节点设备。

通过计算节点设备的告警分数的方式确定一个节点设备是否为待处理节点设备，具有实现简单、易于实现的特点。

下面，对S206控制设备判断所述待处理节点设备是否故障的过程进行说明。该过程可以包括但不限于下述S2061至S2063。

S2061、控制设备获得所述待处理节点设备的至少一个指标。

至少一个指标可以包括但不限于下述至少一项：时延、成功率以及交易量。

S2062、控制设备针对所述至少一个指标中的每个所述指标，计算所述指标与所述指标的参考值之间的第一距离，得到所述指标的判断结果。

其中，若该指标与该指标之间的第一距离大于或等于第一距离阈值，则确定该指标的判断结果为异常；若该指标与该指标之间的第一距离小于第一距离阈值，则确定该指标的判断结果为正常。

本申请实施例对第一距离阈值的具体取值不作限定，可以根据实际需求进行配置。

在一种可能的实施方式中，针对至少一个指标中的所有指标建立一个孤立森林判断器，通过运行该孤立森林判断器，得到每个所有指标的判断结果。

在另一种可能的实施方式中，针对至少一个指标中的每个指标，建立一个孤立森林判断器，通过运行与指标对应的孤立森林判断器，得到该指标的判断结果。

S2062可以实施为：控制设备针对至少一个指标中的每个指标，计算该指标与该指标的参考值之间的第一距离，得到该指标的判断结果。

本申请实施例对指标的参考值的躯体取值不作限定，可以根据实际需求进行配置。例如，指标的参考值可以根据指标的历史数据来确定，也可以根据经验值来确定。

本申请实施例对得到判断结果的具体方式不作限定，可以根据实际需求进行配置，在一种可能的实施方式中，可以根据孤立森林判断器得到指标的判断结果。

示例性的，控制设备将至少一个指标的每个指标输入至孤立森林判断器，运行孤立森林判断器，输出第一值或第二值，若输出第一值，则表征得到针对该指标的判断结果为异常，若输出第二值，则表征得到针对该指标的判断结果为正常。

S2063、若针对所述至少一个指标中的每个所述指标的判断结果均正常，则控制设备确定所述待处理节点设备未故障；否则，确定所述待处理节点设备故障。

通过孤立森林判断器的方式判断待处理节点设备是否故障，实现简单，处理效率高。

可选的，在S2063之后，若判断结果为异常，本申请实施例提供的数据处理方法还可以对判断结果进行修正，以提高判断的准确性，该修正过程可以包括但不限于下述实施方式B1和实施方式B2。

实施方式B1、通过各指标的基准值进行修正；

实施方式B2、通过各指标的正常范围进行修正。

实施方式B1可以包括：在指标包括时延的情况下，若待处理节点设备的时延小于或等于时延基准值，则控制设备修改针对所述时延的判断结果为正常。

在指标包括成功率的情况下，若待处理节点设备的成功率大于或等于成功率基准值，则修改针对成功率的判断结果为正常。

本申请实施例对时延基准值、成功率基准值的具体取值不作限定，可以根据实际需求进行配置。

在一示例中，可以根据历史数据或者经验值来确定时延基准值、成功率基准值。

采用实施方式B1通过各指标的基准值进行修正，可以根据各指标的具体特点，对判断节点进行修正，具有准确率高，灵活度高的特点。

实施方式B2可以包括：控制设备基于历史正常指标数据确定指标的正常范围；控制设备判断待处理节点设备的指标是否属于正常范围；若待处理节点设备的指标属于正常范围，则控制设备修改判断结果为正常。

本申请实施例对与正常范围的确定方式不作具体限定，可以根据实际需求进行配置。

在一示例中，可以根据历史数据确定指标的正常范围。

针对每个指标，控制设备均确定每个指标的正常范围。

采用实施方式B2通过各指标的正常范围进行修正，由于指标的正常范围是根据历史指标的正常数据确定的，所以适应性强。

下面，以节点设备是实例设备(也可以称为实例或者被监控设备)，控制设备是监控设备为例，对本申请实施例提供的数据处理方法进行说明。

为了便于理解下述实施例，对部分技术术语做简单解释。

转存(dump)，可以用于保存相关环境信息，生产dump文件。例如，可以用于转存内存、线程、进程等信息。

孤立森林算法，用于异常点的检测。

黄金指标，指影响系统可靠性的指标。例如，黄金指标可以包括：成功率、时延以及交易量等等。

Sklearn Python，指一个与机器学习相关的库。

Graphviz，指一种画图的工具。

相关技术中，一般采用Zabbix和open-falcon对系统进行监控，具体的，在每台被监控设备(实例)上部署一个代理(agent)进程，被监控设备通过agent采集告警信息，并通过Zabbix和open-falcon将告警信息上报给代理(proxy)，proxy再将告警信息上报给监控设备(server)进行汇总，然后就可以在监控设备的上展示以实例维度的告警信息。

监控设备针对各被监控设备的告警信息，采用单一算法(比如标准差，决策树，差分整合移动平均自回归模型(Autoregressive Integrated Moving Average model，ARIMA)，长短期记忆人工神经网络(Long Short-Term Memory，LSTM)等算法)或者多种算法叠加的方式(比如用集成学习，组成一个投票器，采用少数服从多数的原则)对指标进行检查，从而确定故障设备。

但是实际中：第一点，一个系统一般是包括多个子系统的，监控设备不清楚各子系统之间的逻辑关系，无法对各子系统的告警信息的进行汇总、统计，只是一一列出所有告警信息，这样，很容易产生告警风暴，影响运维工程师的判断。

第二点，即使采用单一算法或者多种算法叠加的方式进行异常点检查，在没有进一步的修正的情况下，很容易造成误判，损耗大量的精力。

第三点，对于确定的故障设备，仅仅只是起到了通知的作用，没有对一些简单的故障，比如单实例故障，进行自动化处理，影响系统的可用率。

本申请实施例提供的检测方法，可以克服上述的第一点至第三点的问题。如图4所示，具体可以包括但不限于下述阶段1至阶段3。

阶段1、收集告警信息，绘制告警链路图。

阶段2、针对异常子系统，确定异常子系统中的第一实例，进行异常的检测，确定第一实例是否故障。

对于第一实例，也可以称为单实例故障的实例，相当于上述待处理节点设备，由于根据告警信息无法最终确认该实例是否真的故障，所以需要进行再次判断，本申请可以根据孤立森林判断器、人为经验以及历史数据等进行二次检查，增加故障识别的正确率。

阶段3、将第一实例的检测结果发送到对应的执行器，通过执行器针对该第一实例，执行对应的操作。

行对应的操作可以包括：状态的保存、流量的隔离、重启等。

总体来说，一方面通过收集的各实例的告警信息对告警信息进行收敛，得到子系统的告警信息，并展示子系统的告警信息，另一方面通过收集的各实例的告警信息以及各实例的指标信息，对第一实例进行异常检测，如果确定第一实例为故障实例，则通过调用执行器，对故障实例进行相应的操作。

下面，对阶段1收集告警信息，绘制告警链路图的过程进行详细说明。

当一个子系统出现问题时，非常容易出现告警风暴，导致监控系统被刷屏，这样，很难找到故障设备。

所以，本申请先对告警信息进行收敛和汇总，并对收敛后的告警信息，采用python3+graphviz的方式绘制告警链路图。这样，可以清楚的看出哪个子系统出现了告警。

阶段1具体可以包括但不限于下述步骤A1至步骤A5。

步骤A1、收集各实例的告警信息。

示例性的，收集各实例在最近两个小时一直存在的告警信息。

告警的等级可以包括：通知(Info)告警、警告(Warning)告警、次要(Minor)告警、主要(Major)告警和紧急(Critical)告警。其中，Info告警和Warning告警的告警级别较低，所以，本申请对Info告警和Warning告警不做处理，只针对Minor告警、Major告警和Critical告警进行处理。

具体的，监控设备对告警日志中的信息进行切割，提取各信息中的关键字(告警类型)，并将各告警类型按照日志中出现的数量从大到小进行排序，确定出排名前三的告警类型，获取这三个告警类型的告警级别。

需要说明的是，切割时的切割规则需要与具体的日志规范对应。例如：一个日志规范以空格为间隔对各信息(例如包括告警设备、告警时间、告警级别、告警类型)进行区分，则切割规则为以空格为界限进行切割，得到告警设备、告警时间、告警级别以及告警类型对应的信息。

以实例为维度，创建一个实例的字典A，并初始化次数。

例如，字典A：{‘minor’：0；‘major’：0；‘critical’：0}。

示例1：实例1(ip为8.8.8.8的容器)的告警统计：{‘minor’：0，‘major’：1，‘critical’：0}。对应的，关键字：(‘JDBC异常’：1)；其中，JDBC异常表示数据库异常，1表示异常数量为1。

实例2(ip为7.7.7.7的虚拟机)的告警统计：{‘minor’：0，‘major’：1，‘critical’：0}。对应的，关键字：(‘JDBC异常’：1)。

步骤A2、对各实例的告警信息采用规定的计数方法进行统计，得到每个子系统的告警信息。

以子系统为维度，组成一个全局的字典B，全量拉取子系统中所有实例的告警，并循环遍历。比如子系统A的实例1出现了major的告警，则通过字段匹配到子系统A，在实例1的二级字典上，找到major，并在上面加1，同时在二级字典的“总”的上面加1。遍历子系统A中的所有实例的告警，得到子系统A的告警。

基于示例1，示例2：子system_A：{总数量：2；实例1：‘minor’：0，‘major’：1，‘critical’：0；实例2：‘minor’：0，‘major’：1，‘critical’：0}。对应的，关键字‘JDBC异常’。

基于示例1，示例3：子system_A：{总数量：2；实例1：1，实例2：1}。对应的，关键字‘JDBC异常’。

步骤A3、获得交易的流程图。

每个交易的流程图，是需要根据交易的调用交易过程中各子系统之间的逻辑关系进行编写的。

如图5所示，该交易的流程包括：请求从四层的虚拟服务器(Linux VirtualServer Linux，LVS)子系统作为负载均衡子系统，到7层的代理服务(Nginx)子系统，再到内部的应用程序接口(Application Programming Interface，API)网关层的服务于前端的后端(Backend For Frontend，BFF)子系统，BFF子系统再将请求转发给UM接口子系统，UM接口子系统将请求发送至ACL子系统或者白名单子系统(whitelist)。

可以理解的，当一个子系统出现故障时，可能会导致一大堆的子系统产生告警，导致告警风暴。所以，需要从流程图中，快速的定位到相应的故障原因。

示例性的，流程图可以采用graphviz画图的方式进行绘制。

步骤A4、在该流程图中展示各子系统的告警信息，得到告警链路图。

根据子系统名，在该流程图中展示各子系统的告警信息，得到告警链路图。

针对存在多个关键链路，对应多个关键链路的流程图的情况，还可以将多个链路的流程图一起进行以下处理：

一个核心子系统，可能有多条链路对应的流程图。

每条关键链路都有一个或多个核心子系统，当上下游系统出现问题时，核心子系统也会出现问题，产生告警。比如在图5中，UM就是一个核心子系统。

其中，关键链路可以是以大功能为维度的链路。比如登录链路，授权链路，短信发送链路等等。

具体包括：子步骤1、将所有的核心子系统作为一个字典的key，当该条链路的核心子系统都出现告警时，选择此链路，进入子步骤2。

子步骤2、在执行子步骤1后，可能得到多条链路，将这一条或多条链路中出现的非核心子系统去匹配告警，当某个非核心子系统存在告警时，则选择此链路，如果非核心子系统出现在多条链路中，则匹配到多条链路。将根据告警汇总成字典得到的子系统的告警汇总结果(相当于异常子系统的告警信息)，写在对应子系统的后面，再生成如图6所示的告警链路图。

步骤A5、将告警链路图发送至告警群。

通过Graphviz将生成图片，用python读取图片，同时将图片转化成基于64个可打印字符来表示二进制数据(base64)格式的信息，调用机器人的消息接口将告警发到告警群。

下面，对阶段2针对第一实例，进行异常的检测，确定第一实例是否故障。阶段2具体可以包括但不限于下述步骤B1至步骤B4。

步骤B1、确定第一实例。

计算每个实例的故障分数，将满足预设条件的实例确定为第一实例。

例如，在minor级别的告警为分，major级别的告警为2分，critical级别的告警为4分的情况下，一个实例分数＝minor告警的次数×1+major告警的次数×2+critical告警的次数×4。

预设条件为：一个系统中一个实例的分数大于或等于4分，其他的实例的分数小于或等于1分，则确定分数大于或等于4分的实例为第一实例。

步骤B2、基于孤立森林判断器确定第一实例是否异常。

首先，获取第一实例的黄金指标，对指标进行分类，得到所以实例的交易量、时延以及成功率等等。

对于每种指标，都训练一套相应的孤立森林判断器模型。

孤立森林判断器的判断前提是所有的异常都是少数的。

孤立森林判断器的原理为根据数学的方式找到少数的异常点。

下面，以一个指标(时延)为例，对得到孤立森林判断器的过程进行说明。

孤立森林判断器的输入数据类型：连续的业务指标数据

训练方式：无监督学习，代入数据就可以得到结果。但是为了调整模型参数，需要有一些打好标签的数据，进行验证。

异常定义：容易被孤立的点，就是分布比较稀疏，离密度较高的群体较远的点。

做法：Python3+sklearn的库。

具体的训练过程可以包括：

获取训练数据(1个月的时延指标数据)，选择出80％的数据作为训练集，20％的数据作为测试数据，对每一个数据打标签，是正常还是异常。例如，时延0.3ms，正常；时延2ms，异常。

通过model＝Isolation Forest(n_estimators，max_samples)，利用Sklearn的Isolation Forest函数建立一个孤立森林判断器模型(model)，将80％的数据X作为训练集，代入model.fit(X)训练函数进行训练，得到初步训练好的孤立森林判断器。

用训练集训练好模型后，则用带有结果的测试集(20％的数据)进行评估，得到初步训练好的孤立森林判断器的模型分数。

例如，可以通过下述公式(2)，计算孤立森林判断器的模型分数。

其中，第一数量为判断结果为异常且正确的数量；第二数量为判断结果为正常且正确的数量；正常分数和异常分数均为50。

打乱训练数据的顺序，在确保正常和异常的数目保持一致比如都是10000个正常，10个异常的情况下，修改n_estimators(子树的数量)、max_depth(树的最大生长深度)的参数，其他的参数选择默认，从而得到多组孤立森林判断器的模型，最后得出一个分数数组。

其中，选择这两个参数的原因，是因为这两个参数对模型影响最大。n_estimators，选择的范围是(3-23)，而max_depth选择(5-25)。先固定max_depth为5，然后遍历n_estimators，然后固定n_estimators为3，遍历max_depth。

最后选取分数最高的模型，作为使用的模型。

其中，训练数据，为二维数组，比如成功率的数据为[[0.88]，[0.90]，[0.88]，[0.99]]，而对应数据的结果标签，则是一个一维数组，它和数据按照顺序对应，[-1，1，1，-1]，其中-1表示异常，1表示正常。如0.88对应-1，则为不正常的数据。

简单来说，通过model＝Isolation Forest(n_estimators，max_samples)，利用Sklearn的Isolation Forest函数建立一个孤立森林判断器模型(model)，将80％的数据X作为训练集，代入model.fit(X)训练函数进行训练，然后用20％的数据Y代入model.predict(Y)预测函数进行预测，然后将预测结果和标记的结果做比较，选择出模型分数最高的两个参数，保存。

当前时间点的第一实例的异常点检查：

1、保存训练阶段得到的n_estimators，max_samples参数，并将此参数代入Isolation Forest函数，建立好孤立森林判断器模型。

2、将最近两天的数据，按照上述结构，生产一个二维数组，并代入模型的训练函数model.fit函数中，训练好对应的孤立森林判断器模型。

3、将当前时间点的第一实例的数据，也建成一个二维数组，代入模型的建立好孤立森林判断器模型或者也可以称为预测函数(model.predict)，运行孤立森林判断器模型，得到一个判断结果。

4、若判断结果为-1，表示异常；若判断结果为1，表示正常。

步骤B3、基于经验信息确定第一实例是否故障。

也可以将B3过程称为异常修正的过程，即对孤立森林判断器的判断结果进行修正。

异常的修正原因：当出现大多数异常，小部分正常的情况时，会导致正常的实例被判断为异常，此时需要对异常进行二次修正。

解决问题：当指标是多数异常，少数正常，会存在误判的情况。即会判断正常的指标为异常，进而导致误操作。

具体的修正过程可以包括：

对于时延指标，由于时延越低，异常的可能性越低，所以当孤立森林判断指标A是异常的，但是其时延比其他实例指标的平均值低时，则修改结果，判断指标A为正常。

对于成功率，由于成功率越高，异常的可能性越地，假设孤立森林判断指标B是异常的，但是其成功率比其他指标的均值的成功率高，则修改结果，判断实例B为正常实例。

步骤B4、基于历史数据确定第一实例是否故障。

也可以将B4过程称为历史数据校验过程，即对B3的修正结果进行校验。

校验的目的：减少无用的操作和告警。

假设有实例A的指标C异常，进入校验，选择最近一周的历史数据，看有没有异常的数值。

一次判断：如果历史已经有异常数据了，判断指标C是否在比历史异常值更加的严重，比如指标B成功率是80％，而历史上，95％就是异常点，那么80％一定是异常点。

二次判断：去除最高的5个点，去除最低的5个点，然后计算最大值，最小值，假设异常的点在最大最小值之间，则将异常改成正常。

总体来说，如图7所示，异常检测分为三步，第一步是用孤立森林判断器做一个初步的判断，第二步是在第一步的基础上，根据已有的经验规则，对判断的结果进行修正，第三步是在第二步的基础上，根据历史的数据对判断的结果进行再次确认。

下面，对阶段3将第一实例的检测结果发送到对应的执行器，通过执行器针对该第一实例，执行对应的操作的过程进行说明。

在第一实例的检测结果是异常的情况下，将第一实例的检测结果发送至第一实例所属的被监控设备，通过在被监控设备上部署的执行器，执行对应的操作。

操作包括：做内存，线程，进程的dump，重启，隔离，自动扩容等等。

设定操作规则表：对于成功率异常引起的故障，则进行dump、隔离的操作。对于时延异常引起的故障，则进行dump、隔离操作。对于交易量异常引起的故障，则发出告警。

需要说明的是，隔离的时候，需要保证子系统中2/3的实例处于可用状态。

下面，对执行器的处理过程进行说明。

其中，通过go语言写成一个agent，部署在被监控设备(例如虚拟机或者容器)上，做一个客户端的进程(减少业务代码的逻辑)，而如果是容器，如图8所示，则用边车(sidecar)的方式：在一个任务(pod)内，启动一个agent容器，这个容器可以被称为sidecar容器。

其中，执行器的作用如下：

收集实例的日志的报错信息。

收集实例的日志的业务指标。

收集对应的基础信息各种指标信息(内存、CPU等信息)，然后将基础信息进行汇总上报。

接收各种指令，从而对子系统进行特定的操作。比如隔离、重启进程、对内存、线程、进程打dump。

比如接收到的指令是隔离，则对该实例的内存、线程、进程打dump，然后隔离。

比如接收到的指令是内存过高：则对该实例的内存、线程、进程打dump，然后重启。

收集到指标信息时，对指标进行特定的处理，比如某个系统的某个实例出现大量的故障时，就要对其进行隔离。当某个实例的业务指标出现异常时，也可以对其进行隔离。

成功率异常，时延异常，直接进行dump操作，然后进行隔离，隔离后需要分析是否资源不够，进行自动的扩缩容。

本申请实施例提供的数据处理方法具有以下有益效果：

1、通过流程图结合告警字典，生成告警链路图，形象的展现了子系统的告警级别次数、告警内容、子系统的上下游情况，从而可以协助快速定位到故障点。

2、由告警初步找到异常的实例，代入到我们的异常点检测，一方面，根据告警筛选出异常的实例，然后用算法进行再次判断。通过有针对性的提供异常实例，不用将所有的实例的数据都代入算法，减少算法的运算量，节约成本；另一方面，利用异常的修正和历史数据的检验，提高了算法的准确性。

3、通过改造监控的agent，增加指令执行功能，使得像保存实例环境，流量隔离更加的准确，快速。

为实现上述数据处理方法，本申请实施例的一种数据处理装置，下面结合图9所示的数据处理装置的结构示意图进行说明。

如图9所示，数据处理装置90包括：获取单元901、确定单元902、处理单元903和展示单元904。其中：

获取单元901，用于获取所述数据处理系统包括的至少两个节点设备的告警信息；

确定单元902，用于基于所述至少两个节点设备，确定至少一个异常子系统；

处理单元903，用于针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；

展示单元904，用于针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。

在一些实施例中，获取单元901还用于：

针对所述至少两个节点设备中的每个所述节点设备执行以下处理：

对所述节点设备上报的告警日志进行处理，得到表征告警提示的关键字字段；

基于所述关键字字段表征的告警提示，确定针对所述节点设备的M个第一告警级别，以及与所述M个第一告警级别一一对应的M个第一告警数量；所述M大于或等于1；

基于所述M个第一告警级别，以及所述M个第一告警级数量，更新针对所述节点设备的第一告警字典，得到所述节点设备的告警信息；所述第一告警字典包括N个第一告警级别，以及与所述N个第一告警级别一一对应的N个第一预设告警数量；所述N大于或等于M。

在一些实施例中，处理单元903，还用于：

获得所述异常子系统包括的至少一个节点设备的告警信息，所述节点设备的告警信息包括M个第一告警级别，以及与所述M个第一告警级别一一对应的M个第一告警数量；

基于所述至少一个节点设备中每个所述节点设备的M个第一告警级别，以及所述M个第一告警数量，确定针对所述异常子系统的P个第二告警级别，以及与所述P个第二告警级别一一对应的P个第二告警数量；所述P大于或等于所述M；

基于所述P个第二告警级别，以及所述P个第二告警数量，更新针对所述异常子系统的第二告警字典，得到所述异常子系统的告警信息；所述第二告警字典包括Q个第二告警级别，以及与所述Q个第二告警级别一一对应的第二预设告警数量；所述Q大于或等于所述P。

在一些实施例中，展示单元904还用于：

获得交易流程图；所述交易流程图中展示了所述至少一个异常子系统；

在所述交易流程图中，针对所述至少一个异常子系统中的每个异常子系统，确定所述异常子系统在所述交易流程图中所属的子系统节点；

对应所述子系统节点展示所述异常子系统的告警信息。

在一些实施例中，数据处理装置90还包括执行单元，执行单元用于：针对所述至少一个异常子系统中的每个所述异常子系统执行以下处理：

确定所述异常子系统中满足第一条件的节点设备为待处理节点设备；

判断所述待处理节点设备是否故障；

在所述待处理节点设备故障的情况下，向所述待处理节点设备发送第一指令，以使所述待处理节点设备在所述第一指令的指示下执行对应操作。

在一些实施例中，执行单元还用于：

确定所述异常子系统中每个所述节点设备的告警分数；

若第一节点设备的告警分数大于或等于第一分数阈值，且第二节点设备的告警分数小于或等于第二分数阈值，则确定所述第一节点设备为所述待处理节点设备；所述第一分数阈值大于所述第二分数阈值；所述第一节点设备为所述异常子系统中的任一节点设备，所述第二节点设备为所述异常子系统中除所述第一节点设备之外的节点设备。

在一些实施例中，执行单元还用于：

获得所述待处理节点设备的至少一个指标；

针对所述至少一个指标中的每个所述指标，计算所述指标与所述指标的参考值之间的第一距离，得到所述指标的判断结果；其中，若所述第一距离大于或等于第一距离阈值，则确定所述判断结果为异常；若所述第一距离小于所述第一距离阈值，则确定所述判断结果为正常；

若针对所述至少一个指标中的每个所述指标的判断结果均正常，则确定所述待处理节点设备未故障；否则，确定所述待处理节点设备故障。

在一些实施例中，若所述判断结果为异常的情况下，执行单元还用于：

在所述指标包括时延的情况下，若所述待处理节点设备的时延小于或等于时延基准值，则修改针对所述时延的判断结果为正常；

在所述指标包括成功率的情况下，若所述待处理节点设备的成功率大于或等于成功率基准值，则修改针对所述成功率的判断结果为正常。

在一些实施例中，若所述指标的判断结果为异常，执行单元还用于：

基于历史正常指标数据确定指标的正常范围；

判断所述待处理节点设备的指标是否属于所述正常范围；

若所述待处理节点设备的指标属于所述正常范围，则修改所述指标的判断结果为正常。

需要说明的是，本申请实施例提供的数据处理装置包括所包括的各单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU，Central Processing Unit)、微处理器(MPU，Micro ProcessorUnit)、数字信号处理器(DSP，Digital Signal Processor)或现场可编程门阵列(FPGA，Field-Programmable Gate Array)等。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的数据处理方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

为实现上述数据处理方法，本申请实施例提供一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述实施例中提供的数据处理方法中的步骤。

下面结合图10所示的电子设备100，对电子设备的结构图进行说明。

在一示例中，电子设备100可以为上述电子设备。如图10所示，所述电子设备100包括：一个处理器1001、至少一个通信总线1002、用户接口1003、至少一个外部通信接口1004和存储器1005。其中，通信总线1002配置为实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏，外部通信接口1004可以包括标准的有线接口和无线接口。

存储器1005配置为存储由处理器1001可执行的指令和应用，还可以缓存待处理器1001以及电子设备中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory，RAM)实现。

第四方面，本申请实施例提供一种存储介质，也就是计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的数据处理方法中的步骤。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

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

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

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

Claims (11)

1.一种数据处理方法，其特征在于，所述方法应用于数据处理系统中的控制设备，所述数据处理系统还包括节点设备，所述方法包括：

获取所述数据处理系统包括的至少两个节点设备的告警信息；

基于所述至少两个节点设备，确定至少一个异常子系统；

针对所述至少一个异常子系统中的每个所述异常子系统执行第一处理，以得到所述至少一个异常子系统的告警信息；所述第一处理包括：将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息；

针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息。

2.根据权利要求1所述的方法，其特征在于，所述获取所述数据处理系统包括的至少两个节点设备的告警信息，包括：

针对所述至少两个节点设备中的每个所述节点设备执行以下处理：

对所述节点设备上报的告警日志进行处理，得到表征告警提示的关键字字段；

基于所述关键字字段表征的告警提示，确定针对所述节点设备的M个第一告警级别，以及与所述M个第一告警级别一一对应的M个第一告警数量；所述M大于或等于1；

基于所述M个第一告警级别，以及所述M个第一告警级数量，更新针对所述节点设备的第一告警字典，得到所述节点设备的告警信息；所述第一告警字典包括N个第一告警级别，以及与所述N个第一告警级别一一对应的N个第一预设告警数量；所述N大于或等于M。

3.根据权利要求1所述的方法，其特征在于，所述将所述异常子系统包括的至少一个节点设备的告警信息，收敛为所述异常子系统的告警信息，包括：

获得所述异常子系统包括的至少一个节点设备的告警信息，所述节点设备的告警信息包括M个第一告警级别，以及与所述M个第一告警级别一一对应的M个第一告警数量；

基于所述至少一个节点设备中每个所述节点设备的M个第一告警级别，以及所述M个第一告警数量，确定针对所述异常子系统的P个第二告警级别，以及与所述P个第二告警级别一一对应的P个第二告警数量；所述P大于或等于所述M；

基于所述P个第二告警级别，以及所述P个第二告警数量，更新针对所述异常子系统的第二告警字典，得到所述异常子系统的告警信息；所述第二告警字典包括Q个第二告警级别，以及与所述Q个第二告警级别一一对应的第二预设告警数量；所述Q大于或等于所述P。

4.根据权利要求1所述的方法，其特征在于，所述针对所述至少一个异常子系统中的每个异常子系统，对应展示所述异常子系统的告警信息，包括：

获得交易流程图；所述交易流程图中展示了所述至少一个异常子系统；

在所述交易流程图中，针对所述至少一个异常子系统中的每个异常子系统，确定所述异常子系统在所述交易流程图中所属的子系统节点；

对应所述子系统节点展示所述异常子系统的告警信息。

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

针对所述至少一个异常子系统中的每个所述异常子系统执行以下处理：

确定所述异常子系统中满足第一条件的节点设备为待处理节点设备；

判断所述待处理节点设备是否故障；

在所述待处理节点设备故障的情况下，向所述待处理节点设备发送第一指令，以使所述待处理节点设备在所述第一指令的指示下执行对应操作。

6.根据权利要求5所述的方法，其特征在于，所述确定所述异常子系统中满足第一条件的节点设备为待处理节点设备，包括：

确定所述异常子系统中每个所述节点设备的告警分数；

若第一节点设备的告警分数大于或等于第一分数阈值，且第二节点设备的告警分数小于或等于第二分数阈值，则确定所述第一节点设备为所述待处理节点设备；所述第一分数阈值大于所述第二分数阈值；所述第一节点设备为所述异常子系统中的任一节点设备，所述第二节点设备为所述异常子系统中除所述第一节点设备之外的节点设备。

7.根据权利要求5所述的方法，其特征在于，所述判断所述待处理节点设备是否故障，包括：

获得所述待处理节点设备的至少一个指标；

针对所述至少一个指标中的每个所述指标，计算所述指标与所述指标的参考值之间的第一距离，得到所述指标的判断结果；其中，若所述第一距离大于或等于第一距离阈值，则确定所述判断结果为异常；若所述第一距离小于所述第一距离阈值，则确定所述判断结果为正常；

若针对所述至少一个指标中的每个所述指标的判断结果均正常，则确定所述待处理节点设备未故障；否则，确定所述待处理节点设备故障。

8.根据权利要求7所述的方法，其特征在于，若所述指标的判断结果为异常，所述方法还包括，包括：

在所述指标包括时延的情况下，若所述待处理节点设备的时延小于或等于时延基准值，则修改针对所述时延的判断结果为正常；

在所述指标包括成功率的情况下，若所述待处理节点设备的成功率大于或等于成功率基准值，则修改针对所述成功率的判断结果为正常。

9.根据权利要求7所述的方法，其特征在于，若所述指标的判断结果为异常，所述方法还包括：

基于历史正常指标数据确定指标的正常范围；

判断所述待处理节点设备的指标是否属于所述正常范围；

若所述待处理节点设备的指标属于所述正常范围，则修改所述指标的判断结果为正常。

10.一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1至9任一项所述的数据处理方法。

11.一种存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时，实现权利要求1至9任一项所述的数据处理方法。

Images