CN109710439A - 故障处理方法和装置 - Google Patents

Abstract

本发明提出一种故障处理方法和装置，其中，方法包括：获取第一日志索引；若第一日志索引携带的故障标记指示存在故障，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引；根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文；根据第一日志原文和第二日志原文进行故障分析。该方法能够实现实时、准确地定位故障的原因，即提升分析结果的准确性和实时性，进而在进行故障处理时，可以提升故障处理的准确性和实时性。

Description

故障处理方法和装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种故障处理方法和装置。

背景技术

由于大规模分布式集群系统包含数量庞大的节点，服务请求调用链路复杂，并且在对服务请求进行处理的过程中，产生海量日志，因此，故障原因的定位过程异常复杂。然而，故障原因的快速准确定位，在加速止损过程中具有非常重要的作用。

相关技术中，针对某一个出现故障的日志进行故障分析。这种方式下，忽略了现有技术中对同一请求往往拆分为多个服务进行处理，从而分别生成相应日志的情况，导致无法将各个服务相关联进行故障分析，分析结果不够准确。并且，现有技术中，在采集日志时，无法同时实现对故障日志进行实时采集、对同一请求的所有故障日志进行全部采集以及仅采集故障日志，从而在进行故障处理时，无法准确、快速地分析出故障原因。

发明内容

本发明提出一种故障处理方法和装置，以实现实时、准确地定位故障的原因，即提升分析结果的准确性和实时性，进而在进行故障处理时，可以提升故障处理的准确性和实时性，用于解决现有技术中故障原因分析结果的准确性较低和实时性较差的技术问题。

本发明第一方面实施例提出了一种故障处理方法，包括：

获取第一日志索引；

若所述第一日志索引携带的故障标记指示存在故障，根据所述第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有所述服务请求标识的第二日志索引；

根据所述第一日志索引存储对应的第一日志原文，以及根据所述第二日志索引获取并存储对应的第二日志原文；

根据所述第一日志原文和所述第二日志原文进行故障分析。

本发明实施例的故障处理方法，通过获取第一日志索引，在第一日志索引携带的故障标记指示存在故障时，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引，之后，根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文，并根据第一日志原文和第二日志原文进行故障分析。由此，可以实现实时、准确地识别故障请求，根据同一服务请求的所有日志原文，进行故障处理和分析，即将同一服务请求下的各个服务相关联，根据同一服务请求的所有日志原文，进行关联分析，可以实现实时、准确地定位故障的原因，即提升分析结果的准确性和实时性，进而在进行故障处理时，可以提升故障处理的准确性和实时性。

本发明第二方面实施例提出了一种故障处理装置，包括：

获取模块，用于获取第一日志索引；

查询模块，用于若所述第一日志索引携带的故障标记指示存在故障，根据所述第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有所述服务请求标识的第二日志索引；

存储模块，用于根据所述第一日志索引存储对应的第一日志原文，以及根据所述第二日志索引获取并存储对应的第二日志原文；

分析模块，用于根据所述第一日志原文和所述第二日志原文进行故障分析。

本发明实施例的故障处理装置，通过获取第一日志索引，在第一日志索引携带的故障标记指示存在故障时，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引，之后，根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文，并根据第一日志原文和第二日志原文进行故障分析。由此，可以实现实时、准确地识别故障请求，根据同一服务请求的所有日志原文，进行故障处理和分析，即将同一服务请求下的各个服务相关联，根据同一服务请求的所有日志原文，进行关联分析，可以实现实时、准确地定位故障的原因，即提升分析结果的准确性和实时性，进而在进行故障处理时，可以提升故障处理的准确性和实时性。

为达上述目的，本发明第三方面实施例提出了一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如本申请第一方面实施例提出的故障处理方法。

为了实现上述目的，本发明第四方面实施例提出了一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请第一方面实施例提出的故障处理方法。

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

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明实施例一所提供的故障处理方法的流程示意图；

图2为本申请实施例的故障处理系统的结构示意图；

图3为本申请实施例中日志索引的格式示意图；

图4为本申请实施例中索引存储服务存储的逻辑关系图；

图5为本申请实施例中故障日志存储服务存储的逻辑关系图；

图6为本申请实施例二所提供的故障处理方法的流程示意图；

图7为本申请实施例中日志索引推送过程示意图；

图8为本申请实施例中日志收集过程示意图一；

图9为本申请实施例三所提供的故障处理方法的流程示意图；

图10为本申请实施例中日志收集过程示意图二；

图11为本发明实施例四所提供故障处理装置的结构示意图；

图12为本发明实施例五所提供故障处理装置的结构示意图；

图13示出了适于用来实现本申请实施方式的示例性计算机设备的框图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

本申请主要针对现有技术中故障原因分析结果的准确性较低和实时性较差的技术问题，提出一种故障处理方法。

本申请实施例的故障处理方法，通过获取第一日志索引，在第一日志索引携带的故障标记指示存在故障时，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引，之后，根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文，并根据第一日志原文和第二日志原文进行故障分析。由此，可以实现实时、准确地识别故障请求，根据同一服务请求的所有日志原文，进行故障处理和分析，即将同一服务请求下的各个服务相关联，根据同一服务请求的所有日志原文，进行关联分析，可以实现实时、准确地定位故障的原因，即提升分析结果的准确性和实时性，进而在进行故障处理时，可以提升故障处理的准确性和实时性。

下面参考附图描述本发明实施例的故障处理方法和装置。

图1为本发明实施例一所提供的故障处理方法的流程示意图。

本申请实施例以该故障处理方法被配置于故障处理装置中来举例说明，该故障处理装置可以应用于任一计算机设备中，以使该计算机设备可以执行故障处理功能。

其中，计算机设备可以为个人电脑(PersonalComputer，简称PC)、云端设备、移动设备等，移动设备例如可以为手机、平板电脑、个人数字助理、穿戴式设备、车载设备等具有各种操作系统、触摸屏和/或显示屏的硬件设备。

如图1所示，该故障处理方法可以包括以下步骤：

步骤101，获取第一日志索引。

本申请实施例中，第一日志索引是根据第一日志原文生成的。

具体地，业务端可以响应服务请求，并进行业务处理，生成相应的日志原文，因此，本申请中，故障处理装置可以实时地从第一业务端，读取第一日志原文，并根据第一日志原文，生成第一日志索引。其中，第一日志索引至少包括以下内容：服务请求标识(trace_id)、故障标记(failure)、第一业务端的网络地址(IP)、日志文件的文件标识(inode)、第一日志原文在日志文件中的偏移量(offset)、和/或、第一日志原文长度(length)。

作为一种示例，参见图2，图2为本申请实施例的故障处理系统的结构示意图。其中，故障处理系统可以包括：索引构建服务、索引存储服务、索引转发服务、故障日志存储服务、日志收集中心服务。

其中，索引构建服务可以部署在各业务端上，用于检测业务日志的滚动，将识别到的日志原文，实时地转换为日志索引，如果服务请求在某一业务端上产生故障，则该业务端生成的日志原文中将记录对应的故障字段(故障信息)，索引构建服务可以识别出该故障字段(故障信息)，并在日志索引中标记出来，即日志索引中携带故障标记。在索引构建服务生成日志索引后，可以将日志索引发送至索引转发服务。

例如，参见图3，针对各业务端生成的日志文件，索引构建服务可以对日志文件中的每行日志原文，生成对应的日志索引。其中，日志索引中包含服务请求的唯一标识trace_id，该标识是由服务最顶层模块生成，并随用户请求依次传递到下游各个相关模块，由各个相关模块打印到日志原文，最后由索引构建服务识别、提取、并存储到日志索引中。在示例中，trace_id为2。例如，参见图3，假设第一日志原文为日志文件中的第三行，则第一日志索引携带的服务请求标识trace_id为2，故障标记failure为0，即第一日志索引携带的故障标记指示不存在故障，第一业务端的网络地址ip为1.1.1.1，文件标识inode为1，第一日志原文在日志文件中的偏移量offset为44，第一日志原文长度length为22。

步骤102，若第一日志索引携带的故障标记指示存在故障，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引。

本申请实施例中，第二日志索引是根据第二日志原文生成的，第二日志原文是第二业务端响应服务请求进行业务处理生成的。其中，第二日志索引至少包括以下内容：服务请求标识(trace_id)、故障标记(failure)、第二业务端的网络地址(IP)、日志文件的文件标识(inode)、第二日志原文在日志文件中的偏移量(offset)、和/或、第二日志原文长度(length)。需要说明的是，第二日志索引是在生成第一日志索引之前，已存在的日志索引，第二日志索引中的故障标记可以指示存在故障，或者指示不存在故障，对此不作限制。

本申请实施例中，可以判断第一日志索引携带的故障标记是否存在故障，若第一日志索引携带的故障标记指示不存在故障，则可以不对第一日志原文进行故障分析，降低计算资源的开销，并且，可以实现仅对故障标记指示存在故障的日志原文进行故障分析，提升故障处理的实时性，以及节省计算的工作量。而若第一日志索引携带的故障标记指示存在故障，则可以根据第一日志索引携带的服务请求标识(trace_id)，在已获取到的日志索引中，查询具有服务请求标识(trace_id)的第二日志索引。

步骤103，根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文。

本申请实施例中，可以根据第二日志索引携带的第二业务端的网络地址(IP)，访问对应的第二业务端，在第二业务端存储的日志文件中，查询符合第二日志索引携带的文件标识(inode)的日志文件，并根据第二日志索引携带的偏移量(offset)，读取日志文件，得到第二日志原文。

在获取到第二日志原文后，可以根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引存储对应的第二日志原文，即将第一日志索引和第一日志原文进行对应存储，以及将第二日志索引和第二日志原文进行对应存储。由此，根据日志索引，即可定位相应的日志原文，而无需通过扫描整个日志文件来定位相应的日志原文，可以有效节省工作量，并提升处理效率。

需要说明的是，现有技术中，在采集日志时，无法同时实现对故障日志进行实时采集，对同一服务请求的所有故障日志进行全部采集，从而后续在进行故障分析时，无法准确、快速地分析出故障原因。

而本申请实施例中，将第一日志索引和第一日志原文进行对应存储，以及将第二日志索引和第二日志原文进行对应存储，可以实现对故障标记指示存在故障的日志原文进行实时采集，并且可以对同一服务请求的所有日志原文进行全部收集，从而后续步骤中在进行故障处理时，可以准确、快速地分析出故障原因，以提升故障处理的实时性和准确性。

步骤104，根据第一日志原文和第二日志原文进行故障分析。

本申请实施例中，在获取第一日志原文和第二日志原文后，可以根据第一日志原文和第二日志原文，进行故障分析。由此，可以实现根据同一请求的所有日志原文，进行故障分析和处理，即将同一服务请求下的各个服务相关联，进行故障分析和处理，可以准确定位故障的原因，即提升分析结果的准确性，进而在进行故障处理时，可以提升故障处理结果的准确性。

本申请实施例的故障处理方法，通过获取第一日志索引，在第一日志索引携带的故障标记指示存在故障时，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引，之后，根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文，并根据第一日志原文和第二日志原文进行故障分析。由此，可以实现实时、准确地识别故障请求，根据同一服务请求的所有日志原文，进行故障处理和分析，即将同一服务请求下的各个服务相关联，根据同一服务请求的所有日志原文，进行关联分析，可以实现实时、准确地定位故障的原因，即提升分析结果的准确性和实时性，进而在进行故障处理时，可以提升故障处理的准确性和实时性。

需要说明的是，现有技术中，主要通过以下几种方式，采集日志：

第一种，将日志原文无修改地推送至旁路分布式文件系统(Hadoop DistributedFile System，简称HDFS)进行存储。但是这种方式，无法仅对故障标记指示存在故障的日志原文和对应的日志索引进行存储，并且，由于推送任务是批量执行的，无法实现实时采集；

第二种，对日志原文进行抽样采集，以实现实时采集。但是这种方式，无法对所有的日志文件进行采集；

第三种，对日志文件进行采集，在确定存在故障后，根据服务请求标识和日志文件中记录的服务调度关系，递归地扫描出存在故障的日志原文。但是这种方式，消耗大量业务端的磁盘IO、吞吐低，在发生大规模故障时，受限于吞吐，无法实现实时地对同一服务请求的所有日志原文进行全部收集。

因此，现有技术中，无法同时实现对故障标记指示存在故障的日志原文进行实时采集，对同一服务请求的所有日志原文进行全部收集，仅对故障标记指示存在故障的日志原文进行采集，从而在进行故障处理时，无法准确、快速地分析出故障原因。

而本申请实施例的故障处理方法，可以实现仅对故障标记指示存在故障的日志原文和对应的日志索引进行存储，降低存储资源和计算资源的开销。并且，本申请中，可以实现对故障标记指示存在故障的日志原文进行实时采集，对同一服务请求的所有日志原文进行全部采集，从而在进行故障处理时，可以准确、快速地分析出故障原因。下面结合图2，对上述过程进行详细说明。

如图2所示，索引构建服务，用于检测业务日志的滚动，将识别到的日志原文，实时地转换为日志索引，同时，还可以接收日志收集中心服务发送的日志索引，根据日志索引查询对应的日志原文并返回。

索引存储服务，用于按照服务请求粒度，存储每个服务请求下的日志索引。索引存储服务可以为一个key-value数据库，同一个key下可以存储多个value，其中，key为服务请求标识trace_id，value为日志索引，同一个key下存储的为同一服务请求的所有日志原文对应的日志索引。通过调用append方法，在一个key下写入value。其存储的逻辑关系图可以如图4所示，将日志索引(location)和服务请求标识(trace_id)进行对应存储。

具体地，索引存储服务可以接收索引转发服务发送的第一日志索引和第二日志索引，并通过调用append方法，将第一日志索引和第二日志索引存储至服务请求标识(trace_id)所对应的索引集合中。并且，索引存储服务可以接收日志收集中心服务或者索引转发服务发送的服务请求标识(trace_id)，根据服务请求标识(trace_id)，查询获取该服务请求标识(trace_id)对应的全部日志索引，即获取服务请求标识(trace_id)对应的key下的所有value值。

索引转发服务，用于接收索引构建服务离散发送的日志索引，将日志索引推送至索引存储服务，同时，从索引存储服务中查询日志索引携带的故障标记是否存在故障，若是，则将该日志索引服务请求标识(trace_id)，推送至日志收集中心服务。

故障日志存储服务，用于按照服务请求粒度，存储故障标记存在故障的日志索引中携带的服务请求，本申请中记为故障请求下的所有日志原文。故障日志存储服务可以为一个key-value数据库，同一个key下可以存储多个value，其中，key为故障请求标识trace_id，value为故障标记存在故障的日志索引及其日志原文，同一个key下存储的为故障请求下的所有日志原文以及对应的日志索引。通过调用append方法，在一个key下写入value。其存储的逻辑关系图可以如图5所示，将日志索引(location)和对应的日志原文，与服务请求标识(trace_id)进行对应存储。

由此，可以实现仅对故障标记指示存在故障的日志原文和对应的日志索引进行存储，降低存储资源和计算资源的开销。并且，本申请中，可以实现对故障标记指示存在故障的日志原文进行实时采集，对同一服务请求的所有日志原文进行全部收集，从而在进行故障分析和处理时，可以准确、快速地分析出故障原因。

故障日志存储服务，还可以接收日志收集中心服务发送的服务请求trace_id，返回该服务请求标识trace_id对应的全部日志索引。

日志收集中心服务，用于根据接收的故障请求标识trace_id和日志索引，收集对应的日志原文。

具体地，日志收集中心服务可以根据故障请求标识trace_id，从索引存储服务中获取该故障请求下全部的日志索引location，记为集合S1；而后根据根据故障请求标识trace_id，从故障日志存储服务中获取该故障请下全部的日志索引location，即为集合S2；将S2和S1作差，得到集合L；对于L中的每个日志索引，从相应的索引构建服务获取其对应的日志原文，并将这些日志原文记为D；将L和D发送至故障日志存储服务进行存储。

下面结合图2至图6，对实施例一提出的故障处理方法进行详细说明。

图6为本申请实施例二所提供的故障处理方法的流程示意图。

如图6所示，该故障处理方法可以包括以下步骤：

步骤201，从第一业务端读取第一日志原文；其中，第一日志原文，是第一业务端响应服务请求进行业务处理生成的。

本申请实施例中，业务端可以响应服务请求，并进行业务处理，生成相应的日志原文，因此，本申请中，故障处理装置可以实时地从第一业务端，读取第一日志原文。

步骤202，根据第一日志原文中记录的故障信息，生成第一日志索引的故障标记。

本申请实施例中，第一业务端上部署有索引构建服务，可以通过索引构建服务根据第一日志原文，生成第一日志索引。

具体地，如果服务请求在第一业务端上产生故障，则该第一业务端生成的第一日志原文中将记录对应的故障信息，索引构建服务可以识别出该故障信息，并在第一日志索引中标记出来，即第一日志索引中携带故障标记。因此，本申请中，可以根据第一日志原文中记录的故障信息，生成第一日志索引的故障标记。

例如，参见图3，假设第一日志原文为日志文件中的第四行，则索引构建服务根据第一日志原文中记录的故障信息，生成第一日志索引的故障标记failure为1。

步骤203，根据第一日志原文中记录的服务请求标识，生成第一日志索引的服务请求标识。

仍以上述例子示例，由于第一日志原文中记录的服务请求标识trace_id为2，索引构建服务生成的第一日志索引中的服务请求标识trace_id为2。

步骤204，判断第一日志索引携带的故障标记是否指示存在故障，若是，则根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引。

例如，参见图4，由于索引存储服务将同一服务请求的所有日志原文对应的日志索引(location)和该服务请求标识(trace_id)进行对应存储，因此，在确定第一日志索引中携带的服务请求标识后，可以由索引存储服务在已获取到的日志索引中，根据服务请求标识，查询具有服务请求标识的第二日志索引。

步骤205，根据第二日志索引携带的网络地址，访问对应的第二业务端。

步骤206，在第二业务端存储的日志文件中，查询符合第二日志索引携带的文件标识的日志文件。

步骤207，根据第二日志索引携带的偏移量，读取日志文件得到第二日志原文。

本申请实施例中，第二日志索引是根据第二日志原文生成的，第二日志原文是第二业务端响应服务请求进行业务处理生成的。因此，本申请中，在确定第二日志索引后，可以根据第二日志索引携带的第二业务端的网络地址(IP)，访问对应的第二业务端，在第二业务端存储的日志文件中，查询符合第二日志索引携带的文件标识(inode)的日志文件，并根据第二日志索引携带的偏移量(offset)，读取日志文件，得到第二日志原文。

步骤208，根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引存储对应的第二日志原文。

例如，参见图5，可以由故障日志存储服务，将第一日志原文和第一日志索引进行对应存储，以及将第二日志索引和第二日志原文进行对应存储。

步骤209，根据第一日志原文和第二日志原文进行故障分析。

步骤208至209的执行过程可以参见上述实施例中步骤103至104的执行过程，此处不做赘述。

作为一种示例，参见图7，第一业务端和第二业务端共同响应一个服务请求，该服务请求的标识为trace_id，第一服务端和第二服务端在处理完该服务请求后，分别生成一行日志：第一日志原文(log1)和第二日志原文(log2)。

索引构建服务根据log2生成对应的第二日志索引location2，并同时将location2和trace_id发送至索引转发服务。

假设故障产生在第一业务端，导致log1中记录有故障信息，索引构建服务在确定log1中记录故障信息后，可以根据log1中记录的故障信息，生成第一日志索引location1的故障标记，并根据log1中记录的trace_id，生成location1的服务请求标识trace_id，而后同时将location1和trace_id发送至索引转发服务。

索引转发服务将trace_id和location1写入索引存储服务，索引存储服务将location1添加至trace_id对应的location集合中。当索引存储服务确定location1的故障标记指示存在故障，则将trace_id标记为故障，索引转发服务从索引存储服务查询该trace_id是故障的，索引转发服务将查询到的故障的trace_id推送给日志收集中心服务。

如图8所示，日志收集中心服务根据故障的trace_id从索引存储服务查询该trace_id对应的全部location——location1和location2，并从故障日志存储服务查询该trace_id对应的全部日志索引location，确定故障日志存储服务中并未存在该trace_id对应的location，此时，日志收集中心服务可以请求索引构建服务，获取location1和location2对应的日志原文log1和log2，日志收集中心服务将trace_id、location1、location2、log1和log2写入故障日志存储服务。

以上整个过程全部是实时触发，并且日志收集中心服务获取到的trace_id全部是故障请求的trace_id，根据location，以不扫描日志文件的方式，可以直接定位并获取到相应的日志原文，可以节省工作量，并提升处理效率。并且，通过和故障日志存储服务中的location集合进行比较，保证了只收集未存在于故障日志存储服务的故障日志，避免了日志原文的重复获取，保证了故障日志存储服务中只存储故障请求的日志原文，从而在进行故障处理时，可以提升故障处理的实时性，并且，将同一服务请求下的各个服务相关联，进行故障分析和处理，可以准确定位故障的原因，即提升分析结果的准确性，进而在进行故障处理时，可以提升故障处理的准确性和实时性，从而实现及时止损。

作为一种可能的实现方式，在获取到第一日志索引后，还可以获取与第一日志索引具有相同服务请求标识的第三日志索引，并获取第三日志索引对应的第三日志原文，从而根据第一日志原文，第二日志原文以及第三日志原文，对服务请求标识指示的服务请求进行故障分析，以提升分析结果的准确性。下面结合图9，对上述过程进行详细说明。

图9为本申请实施例三所提供的故障处理方法的流程示意图。

如图9所示，该故障处理方法可以包括以下步骤：

步骤301，获取第一日志索引。

步骤302，若第一日志索引携带的故障标记指示存在故障，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引。

步骤303，根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文。

步骤301至303的执行过程可以参见上述实施例中步骤101至103的执行过程，在此不做赘述。

步骤304，存储服务请求标识与第一日志索引和第二日志索引之间的对应关系。

例如，参见图3，可以由索引存储服务，存储服务请求标识trace_id与第一日志索引location1和第二日志索引location2之间的对应关系。

步骤305，根据第一日志索引携带的服务请求标识，对第一日志索引之后获取到的日志索引进行识别，以得到具有服务请求标识的第三日志索引。

本申请实施例中，在确定第一日志索引location1携带的故障标记指示存在故障时，可以获取与第一日志索引具有相同服务请求标识的第三日志索引。具体地，可以对第一日志索引之后获取到的日志索引进行识别，以得到具有服务请求标识的第三日志索引。其中，第三日志索引location3是根据第三日志原文生成的，第三日志原文是第三客户端响应服务请求进行业务处理生成的。

例如，参见图4，由于索引存储服务将同一服务请求的所有日志原文对应的日志索引(location)和该服务请求标识(trace_id)进行对应存储，因此，在确定第一日志索引中携带的服务请求标识后，可以由索引存储服务在已获取到的日志索引中，根据服务请求标识，查询具有服务请求标识的第三日志索引。

需要说明的是，本申请仅以步骤305在步骤303之后执行示例，实际应用时，为了提升故障处理的实时性，步骤305可以在步骤301之后执行，即步骤305可以与步骤302并列执行，对此不作限制。

步骤306，根据服务请求标识与第三日志索引是否具有对应关系，确定是否已存储第三日志原文，若是，执行步骤308，若否，执行步骤307。

步骤307，根据第三日志索引，获取并存储对应的第三日志原文。

本申请实施例中，在服务请求标识trace_id与第三日志索引location3之间不具有对应关系时，表明之前未对第三日志原文进行存储，此时，可以根据第三日志索引，获取并存储对应的第三日志原文。

具体地，可以根据第三日志索引携带的第三业务端的网络地址(IP)，访问对应的第三业务端，在第三业务端存储的日志文件中，查询符合第三日志索引携带的文件标识(inode)的日志文件，并根据第三日志索引携带的偏移量(offset)，读取日志文件，得到第三日志原文。在获取到第三日志原文后，可以根据第三日志索引，存储对应的第三日志原文，即将第三日志索引和第三日志原文进行对应存储。例如，参见图5，可以由故障日志存储服务，将第三日志索引和第三日志原文进行对应存储。

步骤308，根据存储的第一日志原文，第二日志原文以及第三日志原文，对服务请求标识指示的服务请求进行故障分析。

本申请实施例中，在服务请求标识trace_id与第三日志索引location3之间具有对应关系时，表明之前已对第三日志原文进行存储，此时，为了重复存储第三日志原文，可以直接根据存储的第一日志原文，第二日志原文以及第三日志原文，对服务请求标识指示的服务请求进行故障分析，以提升分析结果的准确性。

作为一种示例，参见图7，第一业务端、第二业务端和第三业务端共同响应一个服务请求，该服务请求的标识为trace_id，第一业务端、第二业务端和第三业务端在处理完该服务请求后，分别生成一行日志：第一日志原文(log1)、第二日志原文(log2)和第三日志原文(log3)。

第三业务端中部署有索引构建服务，索引构建服务根据log3可以生成对应的第三日志索引location3而后同时将location3和服务请求标识trace_id发送至索引转发服务。

索引转发服务将location3和trace_id写入索引存储服务，并且从索引存储服务中查询该trace_id是故障的，索引转发服务将故障的trace_id推送给日志收集中心服务。

日志收集中心服务根据故障的trace_id从索引存储服务查询该trace_id对应的全部索引location——location1、location2和location3，并从如图8所示的故障日志存储服务查询该trace_id对应的全部日志索引location——location1和location2，确定故障日志存储服务中并未存在location3。此时，如图10所示，日志收集中心服务可以将trace_id、location3和log3写入故障日志存储服务。

由此，可以将同一服务请求下的各个服务相关联，根据同一服务请求的所有日志原文，进行关联分析，可以实现实时、准确定位故障的原因，即提升分析结果的准确性和实时性，进而在进行故障处理时，可以提升故障处理的准确性和实时性。

为了实现上述实施例，本发明还提出一种故障处理装置。

图11为本发明实施例四所提供故障处理装置的结构示意图。

如图11所示，该故障处理装置包括：获取模块101、查询模块102、存储模块103，以及分析模块104。

其中，获取模块101，用于获取第一日志索引。

查询模块102，用于若第一日志索引携带的故障标记指示存在故障，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引。

存储模块103，用于根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文。

分析模块104，用于根据第一日志原文和第二日志原文进行故障分析。

进一步地，在本发明实施例的一种可能的实现方式中，参见图12，在图11所示实施例的基础上，该故障处理装置还可以包括：

识别模块105，用于在获取第一日志索引之后，根据服务请求标识，对第一日志索引之后获取到的日志索引进行识别，以得到具有服务请求标识的第三日志索引。

获取模块101，还用于：根据第三日志索引，获取并存储对应的第三日志原文。

分析模块104，具体用于：根据存储的第一日志原文，第二日志原文以及第三日志原文，对服务请求标识指示的服务请求进行故障分析。

存储模块103，还用于：存储服务请求标识与第一日志索引和第二日志索引之间的对应关系。

确定模块106，用于当获取到携带服务请求标识的第三日志索引时，根据服务请求标识与第三日志索引是否具有对应关系，确定是否已存储第三日志原文。

作为一种可能的实现方式，获取模块101，具体用于：从第一业务端读取第一日志原文；其中，第一日志原文，是第一业务端响应服务请求进行业务处理生成的；根据第一日志原文中记录的故障信息，生成第一日志索引的故障标记；根据第一日志原文中记录的服务请求标识，生成第一日志索引的服务请求标识。

作为一种可能的实现方式，存储模块103，具体用于：根据第二日志索引携带的网络地址，访问对应的第二业务端；在第二业务端存储的日志文件中，查询符合第二日志索引携带的文件标识的日志文件；根据第二日志索引携带的偏移量，读取日志文件得到第二日志原文。

需要说明的是，前述对故障处理方法实施例的解释说明也适用于该实施例的故障处理装置，此处不再赘述。

本发明实施例的故障处理装置，通过获取第一日志索引，在第一日志索引携带的故障标记指示存在故障时，根据第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有服务请求标识的第二日志索引，之后，根据第一日志索引存储对应的第一日志原文，以及根据第二日志索引获取并存储对应的第二日志原文，并根据第一日志原文和第二日志原文进行故障分析。由此，可以实现实时、准确地识别故障请求，根据同一服务请求的所有日志原文，进行故障处理和分析，即将同一服务请求下的各个服务相关联，根据同一服务请求的所有日志原文，进行关联分析，可以实现实时、准确地定位故障的原因，即提升分析结果的准确性和实时性，进而在进行故障处理时，可以提升故障处理的准确性和实时性。

为了实现上述实施例，本发明还提出一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如本申请上述实施例提出的故障处理方法。

为了实现上述实施例，本发明还提出一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请上述实施例提出的故障处理方法。

图13示出了适于用来实现本申请实施方式的示例性计算机设备的框图。图13显示的计算机设备12仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图13所示，计算机设备12以通用计算设备的形式表现。计算机设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。

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

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

存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(Random Access Memory；以下简称：RAM)30和/或高速缓存存储器32。计算机设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图13未显示，通常称为“硬盘驱动器”)。尽管图13中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如：光盘只读存储器(Compact Disc Read OnlyMemory；以下简称：CD-ROM)、数字多功能只读光盘(Digital Video Disc Read OnlyMemory；以下简称：DVD-ROM)或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本申请各实施例的功能。

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

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

处理单元16通过运行存储在系统存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现前述实施例中提及的故障处理方法。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种故障处理方法，其特征在于，所述方法包括以下步骤：

获取第一日志索引；

若所述第一日志索引携带的故障标记指示存在故障，根据所述第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有所述服务请求标识的第二日志索引；

根据所述第一日志索引存储对应的第一日志原文，以及根据所述第二日志索引获取并存储对应的第二日志原文；

根据所述第一日志原文和所述第二日志原文进行故障分析。

2.根据权利要求1所述的故障处理方法，其特征在于，所述获取第一日志索引之后，还包括：

根据所述服务请求标识，对所述第一日志索引之后获取到的日志索引进行识别，以得到具有所述服务请求标识的第三日志索引；

根据所述第三日志索引，获取并存储对应的第三日志原文。

3.根据权利要求2所述的故障处理方法，其特征在于，所述进行故障分析，包括：

根据存储的第一日志原文，第二日志原文以及第三日志原文，对所述服务请求标识指示的服务请求进行故障分析。

4.根据权利要求2所述的故障处理方法，其特征在于，所述根据所述第三日志索引，获取并存储对应的第三日志原文之前，还包括：

存储所述服务请求标识与所述第一日志索引和所述第二日志索引之间的对应关系；

当获取到携带所述服务请求标识的所述第三日志索引时，根据所述服务请求标识与所述第三日志索引是否具有所述对应关系，确定是否已存储所述第三日志原文。

5.根据权利要求1-4任一项所述的故障处理方法，其特征在于，所述获取第一日志索引包括：

从第一业务端读取所述第一日志原文；其中，所述第一日志原文，是所述第一业务端响应服务请求进行业务处理生成的；

根据所述第一日志原文中记录的故障信息，生成所述第一日志索引的故障标记；

根据所述第一日志原文中记录的所述服务请求标识，生成所述第一日志索引的服务请求标识。

6.根据权利要求5所述的故障处理方法，其特征在于，所述根据所述第二日志索引获取并存储对应的第二日志原文，包括：

根据所述第二日志索引携带的网络地址，访问对应的第二业务端；

在所述第二业务端存储的日志文件中，查询符合所述第二日志索引携带的文件标识的日志文件；

根据所述第二日志索引携带的偏移量，读取所述日志文件得到所述第二日志原文。

7.一种故障处理装置，其特征在于，所述装置包括：

获取模块，用于获取第一日志索引；

查询模块，用于若所述第一日志索引携带的故障标记指示存在故障，根据所述第一日志索引携带的服务请求标识，在已获取到的日志索引中，查询具有所述服务请求标识的第二日志索引；

存储模块，用于根据所述第一日志索引存储对应的第一日志原文，以及根据所述第二日志索引获取并存储对应的第二日志原文；

分析模块，用于根据所述第一日志原文和所述第二日志原文进行故障分析。

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

识别模块，用于根据所述服务请求标识，对所述第一日志索引之后获取到的日志索引进行识别，以得到具有所述服务请求标识的第三日志索引；

所述获取模块，还用于：根据所述第三日志索引，获取并存储对应的第三日志原文。

9.一种计算机设备，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如权利要求1-6中任一所述的故障处理方法。

10.一种非临时性计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-6中任一所述的故障处理方法。