一种故障定位方法、装置、设备及介质与流程

[0001]
本公开涉及日志处理技术领域，尤其涉及一种故障定位方法、装置、设备及介质。


背景技术：

[0002]
随着互联网和云计算等技术的快速发展，业务系统中的数据越来越多。在业务系统中，日志是非常重要的组成部分，其在问题回溯、系统故障定位和系统性能优化等方面至关重要。
[0003]
由于业务系统时刻都在生成大量的日志，给故障定位带来较大的困难，故障定位一般是通过人工发起全系统的日志查询实现的，由于需要人工参与，可能会造成效率较低的问题。


技术实现要素：

[0004]
为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种故障定位方法、装置、设备及介质。
[0005]
本公开实施例提供了一种故障定位方法，所述方法包括：
[0006]
接收故障关键词；
[0007]
将携带有所述故障关键词的日志查询请求下发至边缘节点设备，其中，所述边缘节点设备的数量为至少两个；
[0008]
接收各所述边缘节点设备基于所述故障关键词确定的初始日志查询结果，并对所述初始日志查询结果进行处理，得到目标日志查询结果；
[0009]
基于所述目标日志查询结果确定故障原因。
[0010]
可选的，所述接收故障关键词，包括：
[0011]
接收故障告警设备在故障数量达到告警数量阈值时发送的故障关键词，其中，所述故障关键词包括节点信息和/或域名信息。
[0012]
可选的，所述将携带有所述故障关键词的日志查询请求下发至边缘节点设备，包括：
[0013]
将携带有所述故障关键词的日志查询请求下发至每个边缘节点对应的边缘节点设备，其中，所述边缘节点的数量为至少两个，一个所述边缘节点包括至少一个边缘节点设备。
[0014]
可选的，所述对所述初始日志查询结果进行处理，得到目标日志查询结果，包括：
[0015]
基于匹配关键词和匹配次数对所述初始日志查询结果进行汇总和排序，得到目标日志查询结果。
[0016]
可选的，所述初始日志查询结果和所述目标日志查询结果均包括不同数据维度的结果，所述数据维度的数量为至少两个。
[0017]
可选的，所述基于所述目标日志查询结果确定故障原因，包括：
[0018]
对所述目标日志查询结果中不同数据维度的结果进行交叉分析；
[0019]
将设定数量的数据维度的结果中排序为首位的结果确定为故障原因。
[0020]
可选的，所述数据维度包括上游层级、http服务器、错误原因、域名、统一资源定位器和设备ip地址。
[0021]
本公开实施例还提供了一种故障定位装置，所述装置包括：
[0022]
关键词接收模块，用于接收故障关键词；
[0023]
查询请求下发模块，用于将携带有所述故障关键词的日志查询请求下发至边缘节点设备，其中，所述边缘节点设备的数量为至少两个；
[0024]
日志处理模块，用于接收各所述边缘节点设备基于所述故障关键词确定的初始日志查询结果，并对所述初始日志查询结果进行处理，得到目标日志查询结果；
[0025]
故障定位模块，用于基于所述目标日志查询结果确定故障原因。
[0026]
可选的，所述关键词接收模块具体用于：
[0027]
接收故障告警设备在故障数量达到告警数量阈值时发送的故障关键词，其中，所述故障关键词包括节点信息和/或域名信息。
[0028]
可选的，所述查询请求下发模块具体用于：
[0029]
将携带有所述故障关键词的日志查询请求下发至每个边缘节点对应的边缘节点设备，其中，所述边缘节点的数量为至少两个，一个所述边缘节点包括至少一个边缘节点设备。
[0030]
可选的，所述日志处理模块具体用于：
[0031]
基于匹配关键词和匹配次数对所述初始日志查询结果进行汇总和排序，得到目标日志查询结果。
[0032]
可选的，所述初始日志查询结果和所述目标日志查询结果均包括不同数据维度的结果，所述数据维度的数量为至少两个。
[0033]
可选的，所述故障定位模块具体用于：
[0034]
对所述目标日志查询结果中不同数据维度的结果进行交叉分析；
[0035]
将设定数量的数据维度的结果中排序为首位的结果确定为故障原因。
[0036]
可选的，所述数据维度包括上游层级、http服务器、错误原因、域名、统一资源定位器和设备ip地址。
[0037]
本公开实施例还提供了一种电子设备，所述电子设备包括：处理器；用于存储所述处理器可执行指令的存储器；所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现如本公开实施例提供的故障定位方法。
[0038]
本公开实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行如本公开实施例提供的故障定位方法。
[0039]
本公开实施例提供的技术方案与现有技术相比具有如下优点：本公开实施例提供的故障定位方案，接收故障关键词，将携带有所述故障关键词的日志查询请求下发至边缘节点设备，其中，所述边缘节点设备的数量为至少两个，接收各所述边缘节点设备基于所述故障关键词确定的初始日志查询结果，并对所述初始日志查询结果进行处理，得到目标日志查询结果，基于所述目标日志查询结果确定故障原因。采用上述技术方案，当中央平台接收到故障关键词时，可以自动下发查询任务给每个边缘节点设备，并对边缘节点设备返回的结果处理之后得到最终结果，进而基于最终结果确定故障原因，实现了全自动的故障定
位，并且各边缘节点设备分别分析得到查询结果之后上报给中央数据平台进行处理，保证了较高的查询效率。
附图说明
[0040]
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
[0041]
为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
[0042]
图1为本公开实施例提供的一种故障定位方法的流程示意图；
[0043]
图2为本公开实施例提供的一种故障定位系统的示意图；
[0044]
图3为本公开实施例提供的另一种故障定位方法的流程示意图；
[0045]
图4为本公开实施例提供的一种故障定位的示意图；
[0046]
图5为本公开实施例提供的第一种数据维度的结果示意图；
[0047]
图6为本公开实施例提供的第二种数据维度的结果示意图；
[0048]
图7为本公开实施例提供的第三种数据维度的结果示意图；
[0049]
图8为本公开实施例提供的第四种数据维度的结果示意图；
[0050]
图9为本公开实施例提供的一种故障定位装置的结构示意图；
[0051]
图10为本公开实施例提供的一种电子设备的结构示意图。
具体实施方式
[0052]
为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
[0053]
在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
[0054]
目前，对日志的分析和查询一般是由各节点机器统一上报至中央大数据平台并由中央大数据平台统一做处理，单次查询全网日志耗时较长。多维度计算可以由kibana日志分析平台来完成，但是需要临时拼凑命令，运算耗时较长，查询的数据量较大时可能会导致中央大数据平台崩溃。中央大数据平台可以elasticsearch(es)集群为例。部分厂家还使用spark系统把多维度的数据实时计算出来，但随着数据量的增加，很难再向下细化到设备、统一资源定位器(uniform resource locator，url)、用户代理(user agent，ua)等层面，每向下细化一个维度，都将面临着巨大的数据量级翻倍。普通运维人员分析日志需要登录到服务器，通过sed-awk、perl等工具现场拼凑命令去执行，多维度分析很难通过一行命令、一次查询来完成，多次分析总耗时平均在20分钟以上，效率极差。
[0055]
上述日志分析和查询的方式具有以下缺点：查询时效性差，不能做到实时出数据，不能做到实时运算数据；分析的数据维度有限，扩展性不佳；由于原始日志字段较多，搜索结果命中的越多，需要传递的数据就越大，效率越差。并且，故障定位一般是通过人工发起
全系统的日志查询实现的，由于需要人工参与，可能会造成效率较低的问题。为了解决上述缺陷，本公开实施例中提供了一种故障定位方法。
[0056]
图1为本公开实施例提供的一种故障定位方法的流程示意图，该方法可以由故障定位装置执行，其中该装置可以采用软件和/或硬件实现，一般可集成在电子设备中。如图1所示，该方法包括：
[0057]
步骤101、接收故障关键词。
[0058]
其中，故障关键词可以理解为与故障相关的任意信息，本公开实施例对故障关键词的具体类型不作限定，例如故障关键词可以包括节点信息和/或域名信息等信息。
[0059]
具体的，接收故障关键词，可以包括：接收故障告警设备在故障数量达到告警数量阈值时发送的故障关键词，其中，故障关键词包括节点信息和/或域名信息。故障告警设备可以为用于对故障进行检测的设备，具体设备型号或类型不限。故障告警设备可以检测故障信息，当故障信息的数量大于或等于预先设置的告警数量阈值时，则可以发送故障告警关键词给日志分析系统中的中央平台，中央平台即可接收到该故障告警关键词，以进行后续的故障定位。
[0060]
步骤102、将携带有故障关键词的日志查询请求下发至边缘节点设备，其中，边缘节点设备的数量为至少两个。
[0061]
边缘节点设备为中央平台下属服务集群中各边缘节点包括的具体日志分析设备。
[0062]
中央平台接收到故障关键词之后，可以下发日志查询请求给下属各边缘节点设备。具体的，将携带有故障关键词的日志查询请求下发至边缘节点设备，可以包括：将携带有故障关键词的日志查询请求下发至每个边缘节点对应的边缘节点设备，其中，边缘节点的数量为至少两个，一个边缘节点包括至少一个边缘节点设备。
[0063]
示例性的，图2为本公开实施例提供的一种故障定位系统的示意图，如图2所示，该故障定位系统即为日志分析系统，可以包括中央平台和下属服务集群，服务集群中可以包括多个边缘节点，如图中的边缘节点1、边缘节点2，
…
，边缘节点n，每个边缘节点中可以包括多个设备，边缘节点的数量和每个边缘节点中包括的设备数量本公开实施例中不做限定，可以根据实际情况进行设定。中央平台可以将日志查询请求的任务下发给服务集群中每个边缘节点的设备，以使设备执行该日志查询请求。
[0064]
步骤103、接收各边缘节点设备基于故障关键词确定的初始日志查询结果，并对初始日志查询结果进行处理，得到目标日志查询结果。
[0065]
其中，初始日志查询结果为边缘节点设备执行日志查询并统计分析之后的查询结果，目标日志查询结果为中央节点对多个初始日志查询结果进行二次处理之后的结果。
[0066]
各边缘节点设备接收到日志查询请求之后，可以按照故障关键词在本机的日志进行匹配，得到包括匹配关键词和匹配次数等统计信息的初始日志查询结果，并将初始日志查询结果上报给中央平台。中央平台接收到多个初始日志查询结果之后，可以通过二次处理，得到最终的目标日志查询结果。具体的，对初始日志查询结果进行处理，得到目标日志查询结果，可以包括：基于匹配关键词和匹配次数对初始日志查询结果进行汇总和排序，得到目标日志查询结果。中央平台可以将同一匹配关键词的匹配次数进行汇总，之后对汇总的结果进行排序，可以得到目标日志查询结果。
[0067]
步骤104、基于目标日志查询结果确定故障原因。
[0068]
初始日志查询结果和目标日志查询结果均包括不同数据维度的结果，数据维度的数量为至少两个。也即，初始日志查询结果和目标日志查询结果均为多个数据维度的日志查询统计结果。本公开实施例中的数据维度可以包括上游层级(upstream)、http服务器(http server)、错误原因(error reason)、域名(domain)、统一资源定位器和设备ip地址等维度，数据维度可以根据实际情况进行设定。
[0069]
本公开实施例中，基于目标日志查询结果确定故障原因，可以包括：对所述目标日志查询结果中不同数据维度的结果进行交叉分析；将设定数量的数据维度的结果中排序为首位的结果确定为故障原因。其中，设定数量可以为超过总数的一半的任意一个数量，具体可以根据实际情况设定。交叉分析可以理解为分析至少两个变量之间相互关系的一种基本数据分析方式，例如，可以将两个数据维度的结果设置为行变量和列变量建立交叉表格，两个变量在交叉表格中的交叉点即为变量值，通过变量值体现两个数据维度的结果之间的关系。通过交叉分析目标日志查询结果中的各个数据维度的结果，如果多个数据维度中排在首位的结果所对应的故障原因相同，则该故障原因可以为最终确定的故障原因。
[0070]
本公开实施例提供的故障定位方案，接收故障关键词，将携带有故障关键词的日志查询请求下发至边缘节点设备，其中，边缘节点设备的数量为至少两个，接收各边缘节点设备基于故障关键词确定的初始日志查询结果，并对初始日志查询结果进行处理，得到目标日志查询结果，基于目标日志查询结果确定故障原因。采用上述技术方案，当中央平台接收到故障关键词时，可以自动下发查询任务给每个边缘节点设备，并对边缘节点设备返回的结果处理之后得到最终结果，进而基于最终结果确定故障原因，实现了全自动的故障定位，并且各边缘节点设备分别分析得到查询结果之后上报给中央数据平台进行处理，保证了较高的查询效率。
[0071]
图3为本公开实施例提供的另一种故障定位方法的流程示意图，本实施例在上述实施例的基础上，进一步优化了上述故障定位方法。如图3所示，该方法包括：
[0072]
步骤201、接收故障关键词。
[0073]
示例性的，图4为本公开实施例提供的一种故障定位的示意图，如图4所示，故障告警设备基于故障信息可以发送故障关键词给中央平台，具体当故障信息中域名和节点均已知，或者域名未知但节点已知时，可以直接将节点或节点加域名作为故障关键词发送至中央平台；当故障信息中域名已知但节点未知时，可以采用快速定位工具先定位节点，之后将节点加域名作为故障关键词发送至中央平台，中央平台可以基于该故障关键词进行后续的故障定位。可以理解的是，故障关键词也可以为域名或其他的信息，图中仅为示例。
[0074]
步骤202、将携带有故障关键词的日志查询请求下发至边缘节点设备。
[0075]
其中，边缘节点设备的数量为至少两个。将携带有故障关键词的日志查询请求下发至每个边缘节点对应的边缘节点设备，其中，边缘节点的数量为至少两个，一个边缘节点包括至少一个边缘节点设备。
[0076]
步骤203、接收各边缘节点设备基于故障关键词确定的初始日志查询结果。
[0077]
步骤204、基于匹配关键词和匹配次数对初始日志查询结果进行汇总和排序，得到目标日志查询结果。
[0078]
步骤205、基于目标日志查询结果确定故障原因。
[0079]
可选的，基于目标日志查询结果确定故障原因之后，可以基于该故障原因执行对
应的故障检查操作。示例性的，参见图4，故障原因可以包括图中的设备问题、链路问题、源站问题等等，确定故障原因之后，可以针对该故障原因执行对应的操作，如图4，对于设备问题，可以执行暂停设备的操作；对于链路问题，可以执行暂停节点的操作；对于源站问题，可以执行发送通知给技术人员的操作。图中的故障原因和对应的操作仅为示例。
[0080]
本公开实施例提供的故障定位方法，由于原始日志存储在每台业务服务器(即边缘节点设备)上，可以充分发挥边缘节点设备数量多的优势，发挥每台机器的cpu性能，由每台机器单独计算本机日志，并将清洗后的结果各自上报给中央平台，再由中央平台做汇聚，减少日志的二次传递，节省日志存储空间；本公开实施例可以实现实时全网日志查询，每个边缘节点设备针对关键词做匹配，并累加匹配的次数，之后可以直接进行多个数据维度的计算，得到初始日志查询结果；然后将初始日志查询结果连同主机名一起上报给中央平台，中央平台汇聚各设备初始日志查询结果统一展示，并实现故障定位，同时用户可以根据匹配情况对相关主机进行细查。本公开实施例的方法可以提升搜索效率，使每次查询时间由查询日志的范围决定，最大可以支持单次查询60分钟的日志，例如查询1分钟的日志耗时约1秒钟。并且系统可以由go语言编写，可维护性较高，易部署，可随时拓展增加新需求，新维度，并几乎不影响运算效率。
[0081]
此外，本公开实施例还可以执行日志的实时分析，具体过程与上述日志查询过程类似，可以先由边缘节点设备各自计算出本机数据各项指标的排序在前20的结果，并通过json数据结构上报给中央平台，中央平台拿到所有边缘节点设备的上报数据后统一汇聚出排序在前10的结果，通过类似预赛决赛的模式实现日志的实时分析，各机器运算和上报的行为相互独立，互不干扰。
[0082]
在进行日志的实时分析时，还可以针对日志的字段筛选出需要进行多数据维度统计的字段，并计划对这些字段的数据进行加总或取平均处理，最终汇聚出不同数据维度的排序在前10的结果，从而发现异常数据。例如，某个边缘节点的某台设备故障，那么在设备主机名维度的汇总中将看到错误数据均来自这台故障设备。计算时将针对每一条日志都进行不同数据维度的相应的聚合操作。为提升效率，系统可以采用go语言开发，利用go语言的高并发特点，并通过gzip函数直接读取压缩过的tar文件，使得计算效率较java或python都有大幅提升。
[0083]
接下来通过一个具体的示例来说明上述日志的实时分析过程。示例性的，图5为本公开实施例提供的第一种数据维度的结果示意图，对应的数据维度为状态码，展示了状态码为“5xx”的统计排序结果，从图5中可看出504状态码占比最高，并且回源状态码中也是504的数量最多，基本可判断为回源出现504。图6为本公开实施例提供的第二种数据维度的结果示意图，对应的数据维度为域名，在图6中域名排序结果中可看到域名均为“*.a3.com.cn”，说明504均来自同一客户业务。图7为本公开实施例提供的第三种数据维度的结果示意图，对应的数据维度为错误原因，从图7中可以看到报错原因为回源异常。图8为本公开实施例提供的第四种数据维度的结果示意图，对应的数据维度为上游层级，如图8所示，在上一级的ip地址的维度可以看到错误占比最高的ip地址也被定位到是客户源站，并且出错域名中并没有其他客户的域名，所以可快速定位到报错为客户源站自身问题。可以理解的是，图中出现的域名、ip地址和客户源站等均为示意。
[0084]
本公开实施例中的故障定位方法，主要用于解决快速排障，快速定位故障根因，不
仅仅单纯实现实时日志统计的工作，可以按需计算，当故障发生并到达告警阈值后，可自动发起查询任务，并拿到故障根因结论，根据最终结果的多维度的排序可判断出故障根因。当不需要计算时系统不工作，可有效节省服务器资源。
[0085]
本公开实施例提供的故障定位方案，接收故障关键词，将携带有故障关键词的日志查询请求下发至边缘节点设备，其中，边缘节点设备的数量为至少两个，接收各边缘节点设备基于故障关键词确定的初始日志查询结果，基于匹配关键词和匹配次数对初始日志查询结果进行汇总和排序，得到目标日志查询结果，基于目标日志查询结果确定故障原因。采用上述技术方案，当中央平台接收到故障关键词时，可以自动下发查询任务给每个边缘节点设备，并对边缘节点设备返回的结果处理之后得到最终结果，进而基于最终结果确定故障原因，实现了全自动的故障定位，并且各边缘节点设备分别分析得到查询结果之后上报给中央数据平台进行处理，保证了较高的查询效率。
[0086]
图9为本公开实施例提供的一种故障定位装置的结构示意图，该装置可由软件和/或硬件实现，一般可集成在电子设备中。如图9所示，该装置包括：
[0087]
关键词接收模块301，用于接收故障关键词；
[0088]
查询请求下发模块302，用于将携带有所述故障关键词的日志查询请求下发至边缘节点设备，其中，所述边缘节点设备的数量为至少两个；
[0089]
日志处理模块303，用于接收各所述边缘节点设备基于所述故障关键词确定的初始日志查询结果，并对所述初始日志查询结果进行处理，得到目标日志查询结果；
[0090]
故障定位模块304，用于基于所述目标日志查询结果确定故障原因。
[0091]
本公开实施例提供的故障定位装置，通过各模块间的配合，接收故障关键词，将携带有所述故障关键词的日志查询请求下发至边缘节点设备，其中，所述边缘节点设备的数量为至少两个，接收各所述边缘节点设备基于所述故障关键词确定的初始日志查询结果，并对所述初始日志查询结果进行处理，得到目标日志查询结果，基于所述目标日志查询结果确定故障原因。采用上述技术方案，当中央平台接收到故障关键词时，可以自动下发查询任务给每个边缘节点设备，并对边缘节点设备返回的结果处理之后得到最终结果，进而基于最终结果确定故障原因，实现了全自动的故障定位，并且各边缘节点设备分别分析得到查询结果之后上报给中央数据平台进行处理，保证了较高的查询效率。
[0092]
可选的，所述关键词接收模块301具体用于：
[0093]
接收故障告警设备在故障数量达到告警数量阈值时发送的故障关键词，其中，所述故障关键词包括节点信息和/或域名信息。
[0094]
可选的，所述查询请求下发模块302具体用于：
[0095]
将携带有所述故障关键词的日志查询请求下发至每个边缘节点对应的边缘节点设备，其中，所述边缘节点的数量为至少两个，一个所述边缘节点包括至少一个边缘节点设备。
[0096]
可选的，所述日志处理模块303具体用于：
[0097]
基于匹配关键词和匹配次数对所述初始日志查询结果进行汇总和排序，得到目标日志查询结果。
[0098]
可选的，所述初始日志查询结果和所述目标日志查询结果均包括不同数据维度的结果，所述数据维度的数量为至少两个。
[0099]
可选的，所述故障定位模块304具体用于：
[0100]
对所述目标日志查询结果中不同数据维度的结果进行交叉分析；
[0101]
将设定数量的数据维度的结果中排序为首位的结果确定为故障原因。
[0102]
可选的，所述数据维度包括上游层级、http服务器、错误原因、域名、统一资源定位器和设备ip地址。
[0103]
本公开实施例所提供的故障定位装置可执行本发明任意实施例所提供的故障定位方法，具备执行方法相应的功能模块和有益效果。
[0104]
图10为本公开实施例提供的一种电子设备的结构示意图。如图10所示，电子设备400包括一个或多个处理器401和存储器402。
[0105]
处理器401可以是中央处理单元(cpu)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备400中的其他组件以执行期望的功能。
[0106]
存储器402可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(ram)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(rom)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器401可以运行所述程序指令，以实现上文所述的本公开的实施例的故障定位方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如输入信号、信号分量、噪声分量等各种内容。
[0107]
在一个示例中，电子设备400还可以包括：输入装置403和输出装置404，这些组件通过总线系统和/或其他形式的连接机构(未示出)互连。
[0108]
此外，该输入装置403还可以包括例如键盘、鼠标等等。
[0109]
该输出装置404可以向外部输出各种信息，包括确定出的距离信息、方向信息等。该输出装置404可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。
[0110]
当然，为了简化，图10中仅示出了该电子设备400中与本公开有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备400还可以包括任何其他适当的组件。
[0111]
除了上述方法和设备以外，本公开的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本公开实施例所提供的故障定位方法。
[0112]
所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如java、c++等，还包括常规的过程式程序设计语言，诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。
[0113]
此外，本公开的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本公开实施例所提供的故障定位方法。
[0114]
所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
[0115]
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0116]
以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。