一种故障定位方法及装置与流程

本发明涉及计算机技术领域，特别是涉及一种故障定位方法及装置。

背景技术：

随着信息时代的到来，用户的需求越来越多样化，服务运营商为了满足用户的需求，开发了多种服务，这些开发出的服务之间相互配合，相互调用才能满足用户的需求。服务只有依托于服务器才能实现其功能，因此，可以将服务部署在至少一台服务器上。然而随着服务的数量不断地增加，服务器的数量也随之增加，但每一台服务器中运行的服务均有可能出现故障，而服务器中运行的服务的故障有可能导致响应用户的任务处理请求失败，因此，需要对故障进行定位，确定发生故障的服务所在的服务器，同时确定出现故障的原因，以便于维护人员根据出现故障的原因，及时对该服务器中出现故障的服务进行维修。

在现有技术中，可以通过日志对故障进行定位，具体的方法为：接收目标用户的故障报修请求；其中，所述故障报修请求包含目标用户的标识信息；基于该标识信息，在存储的各个服务器的日志中确认目标日志，其中，目标日志为服务器处理目标用户的任务处理请求时产生的；对获取的目标日志进行分析，确定出现故障的服务所在的服务器。通常情况下可以通过上述方式进行故障定位，但由于日志量数目繁多，逐一进行日志排查速度较慢，因此，难以在短时间内确定目标日志，从而导致故障定位的时间比较长。

技术实现要素：

本发明实施例的目的在于提供一种故障定位方法及装置，以实现快速地对故障进行定位。具体技术方案如下：

第一方面，为了达到上述目的，本发明实施例公开了一种故障定位方法，所述方法包括：

确定目标跟踪键，其中，所述目标跟踪键为用于跟踪响应目标服务请求的服务器的标识信息；

在本地存储的日志中确定记录有所述目标跟踪键的日志，并将所确定的日志确定为目标日志，其中，本地存储的每一日志均记录有服务器所响应服务请求对应的跟踪键；

根据所述目标日志中记载的告警信息，定位出现故障的服务所在的服务器。

可选的，所述目标跟踪键由预设数量个预设类型的数值组成。

可选的，所述确定目标跟踪键，包括：

接收针对目标服务请求失败的故障定位请求，其中，所述故障定位请求中携带所述目标服务请求的识别信息；

在本地存储的日志中查询记录有所述目标服务请求的识别信息的日志；

根据查询到的日志中记录的跟踪键，确定目标跟踪键。

可选的，所述确定目标跟踪键，包括：

检测本地存储的日志中是否存在包含预设标识的日志；

如果存在，根据包含所述预设标识的日志中记录的跟踪键，确定目标跟踪键。

可选的，所述根据所述目标日志中记载的告警信息，确定出现故障的服务所在的服务器，包括：

确定所述目标日志中记载的告警信息对应的告警时间；

将所述目标日志中告警时间最早的日志对应的服务器定位为出现故障的服务所在的服务器。

第二方面，为了达到上述目的，本发明实施例公开了一种故障定位装置，所述装置包括：

第一确定模块，用于确定目标跟踪键，其中，所述目标跟踪键为用于跟踪响应目标服务请求的服务器的标识信息；

第二确定模块，用于在本地存储的日志中确定记录有所述目标跟踪键的日志，并将所确定的日志确定为目标日志，其中，本地存储的每一日志均记录有服务器所响应服务请求对应的跟踪键；

定位模块，用于根据所述目标日志中记载的告警信息，定位出现故障的服务所在的服务器。

可选的，所述目标跟踪键由预设数量个预设类型的数值组成。

可选的，所述第一确定模块，包括：

接收子模块，用于接收针对目标服务请求失败的故障定位请求，其中，所述故障定位请求中携带所述目标服务请求的识别信息；

查询子模块，用于在本地存储的日志中查询记录有所述目标服务请求的识别信息的日志；

第一确定子模块，根据查询到的日志中记录的跟踪键，确定目标跟踪键。

可选的，所述第一确定模块，包括：

检测子模块，用于检测本地存储的日志中是否存在包含预设标识的日志；

第二确定子模块，用于在所述检测子模块的检测结果为存在的情况下，根据包含所述预设标识的日志中记录的跟踪键，确定目标跟踪键。

可选的，所述定位模块，包括：

第三确定子模块，用于确定所述目标日志中记载的告警信息对应的告警时间；

定位子模块，用于将所述目标日志中告警时间最早的日志对应的服务器定位为出现故障的服务所在的服务器。

本发明实施例提供的故障定位方法及装置，通过跟踪键快速地确定目标日志，根据目标日志中的告警信息，可以定位出现故障的服务所在的服务器，相较于现有技术，确定目标日志的时间比较短，能够快速地对故障进行定位。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种故障定位方法的流程示意图；

图2为本发明实施例中跟踪键在服务之间传递的示意图；

图3为本发明实施例中采用flume收集日志的示意图；

图4为本发明实施例提供的一种故障定位装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明实施例提供的一种故障定位方法的流程示意图，方法包括：

s101：确定目标跟踪键，其中，所述目标跟踪键为用于跟踪响应目标服务请求的服务器的标识信息。

具体的，目标跟踪键可以由预设数量个预设类型的数值组成。

在本发明实施例中，跟踪键(traceid)是数值型时，可以使得跟踪键占用的空间比较固定，生成比较容易，具体的，可以采用随机算法生成。预设数量可以为一个或多个，具体可以根据在第一段时间内，服务请求的数量确定。预设类型可以为整型、长整型等等，示例性的，跟踪键可以由两个长整型的数值组成，一个长整型的值空间为2⁶⁴，两个长整型的值空间为2¹²⁸，则两个跟踪键相同的概率为1/2¹²⁸，两个跟踪键相同的概率极小，确保了根据跟踪键确定的日志准确性。

在实际应用中，服务请求由多个服务响应，服务之间相互配合才能完成对服务请求的处理。跟踪键可以是第一个对服务请求进行处理的服务所在的服务器生成的，生成的跟踪键作为服务调用的额外参数，每次调用都将该跟踪键作为参数传递给新的服务。示例性，跟踪键在服务之间传递的示意图可以如图2所示，web(worldwideweb，全球广域网)service(服务)生成跟踪键1，并将该跟踪键1传递给http(hypertexttransferprotocol，超文本传输协议)service和rpc(remoteprocedurecallprotocol，远程过程调用协议)service，httpservice将跟踪键1传递给db(database，数据库)service，rpcservice将跟踪键1传递给hbaseservice。其中，hbase是一个分布式的、面向列的开源数据库。

跟踪键在服务之间传递可以理解为一个服务中的服务器响应该服务请求，然后将跟踪键连同其他的参数传递给下一个服务中的服务器。当然，跟踪键也可以是公共组件库生成的，在公共组件库中设置跟踪键变量，针对一个服务请求生成一个跟踪键，且随着服务请求在不同的服务中处理，跟踪键也会随不同服务的组件中传递。跟踪键在公共组件库中传递，与现有技术中的其他参数在公共组件库中的传递方法相同，在这里不进行赘述。

第一种跟踪键传递方法实现比较简单，但需要额外传递跟踪键。第二种跟踪键传递方法对用户透明，且是自动传递的，但需要公共组件库中所有公共组件的支持。需要说明的是，公共组件库是由公共组件组成的库，公共组件是可以被外层的组件或程序调用的组件。

在本发明实施例中，可以通过以下方式确定目标跟踪键：

第一步：接收针对目标服务请求失败的故障定位请求，其中，所述故障定位请求中携带所述目标服务请求的识别信息。

在本发明实施例中，服务器出现故障会导致服务请求处理失败，则将会有相应的故障定位请求。该故障定位请求可以是用户发送的，也可以是其他系统发送的，还可以是出现故障的服务所在的服务器发送的等等，在这里并不进行限定。故障定位请求携带了目标服务请求的标识信息，示例性的，该标识信息可以包含发送目标服务请求的时间、所使用的ip(internetprotocol，网络之间互连的协议)地址等等用来确定目标服务请求的信息。

第二步：在本地存储的日志中查询记录有所述目标服务请求的识别信息的日志。

在本发明实施例中，每个服务所在的每一服务器均可以打印日志，打印日志就是生成日志并将日志保存起来。在一个服务器打印日志的时候，将记录有该服务器所响应服务请求对应的跟踪键也打印进去。示例性的，服务请求1对应的跟踪键为跟踪键1，则服务器1打印针对服务请求1对应的日志，同时将跟踪键1打印到该日志中。

本发明实施例提供的故障定位方法可以应用于elasticsearch。elasticsearch是一个基于lucene(全文搜索引擎)的搜索服务器，不仅是一款提供存储，查询，检索的优秀的开源搜索引擎，还可以提供即时查询。在实际应用中，可以将每个服务所部署的服务器上的日志都收集起来存储在elasticsearch。

在本发明实施例中，可以利用日志收集工具进行日志的收集，日志收集工具可以为flume、logstash等等。flume是cloudera提供的一个高可用的，高可靠的，分布式的海量日志收集、聚合和传输的系统。示例性的，采用flume收集日志的示意图可以如图3所示，可以将flume部署到每一服务中，每个服务中部署的flume进行日志的收集，并将收集的日志存储到elasticsearch。logstash是一款轻量级的日志收集处理框架，可以方便的把分散的、多样化的日志收集起来，并进行自定义的处理，然后将收集到的日志传输到指定的位置。

第三步：根据查询到的日志中记录的跟踪键，确定目标跟踪键。

在本发明实施例中，查询到的日志中不仅包含了目标服务请求的识别信息，还包含了跟踪键，可以将该跟踪键确定为目标跟踪键。

在本发明实施例中，还可以通过以下方式确定目标跟踪键：

第一步：检测本地存储的日志中是否存在包含预设标识的日志。

在实际应用中，elasticsearch存储所接收的日志，然后，检测本地存储的日志中是否存在包含预设标识的日志，这里所说的预设标识可以是告警的标识信息，示例性的，可以是error(错误)。如果日志中包含了预设标识，说明该日志对应的服务器中运行的服务可能出现故障，或者是与该服务器处理同一服务请求的其他服务器中运行的服务出现故障。

第二步：根据包含所述预设标识的日志中记录的跟踪键，确定目标跟踪键。

如果检测到多个日志中包含有预设标识，且这些日志对针对一个服务请求，则可以直接将包含有预设标识的日志中记录的跟踪键，确定为目标跟踪键。

如果检测到多个日志中包含有预设标识，且这些日志对针对不同的服务请求产生的，则可以通过以下两种方法在检测到的包含有预设标识的日志中确定目标跟踪键：

第一种：可以将检测到的包含有预设标识的日志中，包含有同一个跟踪键的日志分为一类。将其中一类日志中的跟踪键确定为目标跟踪键，再根据该目标跟踪键确定目标日志，进而定位出现故障的服务器。然后，在跟踪键没有被确定为目标跟踪键的其他类日志中，选择一类日志，将选择的日志中的跟踪键确定为目标跟踪键。重复执行确定目标日志，进而定位出现故障的服务器的步骤，直至每一类包含有预设标识的日志中跟踪键均确定为目标跟踪键。

第二种：可以将检测到的包含有预设标识的日志中，包含有同一个跟踪键的日志分为一类，分别将每一类日志中的跟踪键确定为目标跟踪键，针对每一类日志中确定的跟踪键，分别执行根据目标跟踪键确定目标日志，进而定位出现故障的服务器的步骤。

第一种方法是串行地确定目标跟踪键，第二种方法是并行地确定目标跟踪键，在实际应用中，可以选择其中的一种方法确定目标跟踪键。

s102：在本地存储的日志中确定记录有所述目标跟踪键的日志，并将所确定的日志确定为目标日志，其中，本地存储的每一日志均记录有服务器所响应服务请求对应的跟踪键。

需要说明的是，在本地存储的日志中，确定记录有目标跟踪键的所有日志。示例性的，日志1、日志2、日志3和日志4都记录有目标跟踪键，则将日志1、日志2、日志3和日志4确定为目标日志。

本领域内技术人员可以理解的是，任何一台服务器在运行过程中均可以针对其运行状态生成日志，这些日志中可以包括：服务器所处理请求的标识、运行状态记录、处理请求是否成功的标识等等；另外，服务的正常运行是依托于硬件设备的，一个服务的正常运行可能会依托于一台服务器，也可能依托于多台服务器；基于上述两方面情况，可以得知服务请求是由服务所依托的服务器具体响应的，那么这些服务器可以在响应服务请求的过程中生成日志。

具体的，跟踪键与服务请求是相对应的，所以在生成日志的同时可以在日志内容中记录跟踪键，这样每一条日志可以清楚、直观的与各个服务请求相对应。综合上述情况，能够实现采用跟踪键对响应该跟踪键对应的服务请求的服务器进行跟踪，使得可以根据跟踪键，一次性获取服务器针对该服务请求产生的日志，这样就根据获取的日志定位故障，实现一站式定位故障，方便快捷。

s103：根据所述目标日志中记载的告警信息，定位出现故障的服务所在的服务器。

在本发明实施例中，一个服务器中运行的服务出现故障，则该服务器的日志中会出现告警信息，与该服务器一起响应同一服务请求的服务器的日志中也可能会出现告警信息。示例性的，服务器1、服务器2、服务器3和服务器4依次响应服务请求a，如果服务器3中运行的服务出现故障，则服务器3针对服务请求a产生的日志出现告警信息，服务器1和服务器2针对服务请求a产生的日志也会出现告警信息。对目标日志中的告警信息进行分析，可以定位出现故障的服务所在的服务器。

在本发明的一个优选的实施例中，根据所述目标日志中记载的告警信息，确定出现故障的服务所在的服务器，包括：

确定所述目标日志中记载的告警信息对应的告警时间；

将所述目标日志中告警时间最早的日志对应的服务器定位为出现故障的服务所在的服务器。

这里所说的告警时间为告警信息产生的时间，每一个告警时间对应一个告警信息。一个服务器出现故障，响应的服务请求的日志中记载告警信息，而且响应该服务请求的其他服务器针对该服务请求的日志中也会记载告警信息。因此，可以将目标日志中告警时间最早的日志对应的服务器确定为出现故障的服务器。示例性的，告警时间可以是告警时间戳，确定目标日志中每一日志的告警时间戳，对所确定的告警时间戳按照告警时间戳的先后进行排序，将排在最前面的告警时间戳对应的服务器，定位为出现故障的服务所在的服务器。

在本发明实施例中，目标日志中不仅记载了告警时间，还记载了出现故障的原因，维护人员可以根据出现故障的原因，确定服务器中的服务具体是哪里出现问题，进而解决该问题，使得该服务器中的服务能够正常运行，能够对服务请求进行处理。

应用本发明实施例，通过跟踪键快速地确定目标日志，根据目标日志中的告警信息，可以定位出现故障的服务所在的服务器，相较于现有技术，确定目标日志的时间比较短，能够快速地对故障进行定位。

与图1所示的方法实施例相对应，图4为本发明实施例提供的一种故障定位装置的结构示意图，装置包括第一确定模块201、第二确定模块202和定位模块203，其中，

第一确定模块201，用于确定目标跟踪键，其中，所述目标跟踪键为用于跟踪响应目标服务请求的服务器的标识信息；

第二确定模块202，用于在本地存储的日志中确定记录有所述目标跟踪键的日志，并将所确定的日志确定为目标日志，其中，本地存储的每一日志均记录有服务器所响应服务请求对应的跟踪键；

定位模块203，用于根据所述目标日志中记载的告警信息，定位出现故障的服务所在的服务器。

具体的，所述目标跟踪键由预设数量个预设类型的数值组成。

具体的，所述第一确定模块201，可以包括接收子模块、查询子模块和第一确定子模块(图中未示出)。

接收子模块，用于接收针对目标服务请求失败的故障定位请求，其中，所述故障定位请求中携带所述目标服务请求的识别信息；

查询子模块，用于在本地存储的日志中查询记录有所述目标服务请求的识别信息的日志；

第一确定子模块，根据查询到的日志中记录的跟踪键，确定目标跟踪键。

具体的，所述第一确定模块201，可以包括检测子模块和第二确定子模块(图中未示出)。

检测子模块，用于检测本地存储的日志中是否存在包含预设标识的日志；

第二确定子模块，用于在所述检测子模块的检测结果为存在的情况下，根据包含所述预设标识的日志中记录的跟踪键，确定目标跟踪键。

具体的，定位模块203，可以包括第三确定子模块和定位子模块(图中未示出)。

第三确定子模块，用于确定所述目标日志中记载的告警信息对应的告警时间；

定位子模块，用于将所述目标日志中告警时间最早的日志对应的服务器定位为出现故障的服务所在的服务器。

应用本发明实施例，通过跟踪键快速地确定目标日志，根据目标日志中的告警信息，可以定位出现故障的服务所在的服务器，相较于现有技术，确定目标日志的时间比较短，能够快速地对故障进行定位。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。