CN108228322A - 一种分布式链路跟踪、分析方法及服务器、全局调度器 - Google Patents

Abstract

一种分布式链路跟踪、分析方法及服务器、全局调度器，在链路跟踪时，分布式集群中的服务器在处理用户请求的过程中产生事件，将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。在链路分析时，分布式集群中的全局调度器向服务器发送链路查询请求，服务器在本地搜索后返回与所述跟踪标识相关的事件的信息；全局调度器再基于接收到的事件的信息对所述用户请求进行链路分析。本申请采取本地存储、按需分析的方式，解决了传统方法存在的数据存储、分析和网络带宽的成本高以及扩展性问题。

Description

一种分布式链路跟踪、分析方法及服务器、全局调度器

技术领域

本发明涉及计算机技术，更具体地，涉及一种分布式链路跟踪、分析方法及服务器、全局调度器。

背景技术

跟踪(tracing)是计算机系统跟踪系统运行状况的一种技术，多用于调试、监控和跟踪目的。它类似记录日志，但性能更好，对目标系统干扰更低，覆盖更广，常用于记录更高频、更底层的事件。

在计算机科学的Tracing领域中，“事件”是指处理器运行到某指定代码点时，由于满足事先在该代码点设定的条件而触发一系列的操作，具有可识别性。比如用户事先在程序代码某处设定布尔变量，当处理器运行到这里，检测到该布尔变量为真时，就会触发事件，执行一系列事先安排的操作。这些操作通常是在日志中记录下这次事件的相关信息，比如事件名称、事件发生时刻、线程ID、事件携带的其他数据等。

“代码植入”(instrumentation)即术语“事件”中提到的由用户在应用程序的代码某处(由用户选择)植入一段逻辑(由用户设定)，通常是记录事件包含的各种信息。它有动态和静态之分，动态记录植入是指不需要在程序代码里事先加入用于tracing的代码，而是由操作系统内核或者特权进程在目标程序运行期间在用户指定的代码位置(比如函数的头、尾部)加入特殊指令集，达到运行用户设定代码逻辑的目的。静态植入是用户修改应用程序源码来加入用于tracing的代码逻辑。被植入的程序称为埋点的服务器程序(instrumented binary)。

有些事件是非独立、彼此有关系的。比如用户应用程序用TCP协议发数据包(事件A)，TCP数据段通过本地网卡传出去(事件B)，TCP检测到该数据段丢失进而重发这个数据段(事件C)。在整个过程中如果能在上述各个关键点记录下包含时间戳并携带有用信息的事件(A、B、C)，并且把这些有因果关系的事件从记录事件的总集合中挑选出来按照顺序(比如时间顺序)排列好，就能对用户数据包的发送延迟性给出定量的解释。上述挑选彼此有关系的事件并排序的过程叫做“事件关联”。

当代的互联网服务通常都是用大规模分布式集群来实现的，用户的一次请求很可能会散发到一个或多个集群去处理。集群中的各个服务器在这个请求的处理过程中可能承担不同的角色，最终协力完成请求，将结果返回给用户。为了更好的理解整个服务/系统、定位故障、优化性能，开发者/管理员一般会采用tracing技术来记录各个服务器上的操作的信息，然后对记录下来的信息进行汇总和分析。比如人们关心单个用户请求在其生命周期内各个处理阶段所花费的时间、资源等。服务器处理用户请求时，产生和记录相关信息的过程叫“链路跟踪”，之后对这些信息数据做分析的过程叫“链路分析”。

关于如何关联事件，业界有两种解决方案-黑盒跟踪和白盒跟踪。黑盒方案的优点是轻便，不修改应用程序代码，对应用方完全透明。它或者采用统计的方法从通讯消息包获得信息—因而是不精确的，或者根据收集到的各功能模块之间的交互消息根据消息之间内在的因果关系精确的跟踪。因此它的缺点是有可能在一定程度上不精确，另外在推断关联时有更大的资源消耗。采取黑盒方案的跟踪系统有vPath、BoarderPartrol、PreciseTracer等。白盒方案需要代码植入(instrumentation)，这是它的缺点。优点是推断关联比较简单，事件关联精确。采取白盒方案的跟踪系统有X-Trace、PinPoint、Magpie、Dapper、鹰眼等。

跟踪标识(traceID)是大多数白盒方案采取的一种简单的事件关联方法中所使用的一个全局标识符。跟踪系统对用户发送的每个请求都会生产一个traceID，该traceID会伴随着这个请求出现在所有处理阶段，并在各个事件触发时随着事件信息被记录保存下来。这样所有与某请求相关的事件就可以用这个traceID串联起来。

用户请求可以分为I型用户请求和II型用户请求。II型用户请求只会涉及集群里少数几台机器。比如分布式存储的写请求通常是写到3台服务器上；而分布式存储的读请求只需读一台服务器。不符合这个特征的用户请求为I型请求，比如搜索请求。一次搜索请求会牵涉到集群里几乎所有的服务器(如果绝大部分服务器上都有包含该搜索关键字的文档的话)。

分布式链路跟踪和分析系统需要记录下某次用户请求的服务过程中系统完成的所有操作的信息。举个例子，图1所示是一个和5台服务器相关的分布式请求服务过程。涉及的服务器包括：前端服务器A，中间层服务器B和C，及后端服务器D和E。当用户发起一个请求时，请求首先到达前端服务器A，服务器A发送两个远程过程调用协议(RPC:RemoteProcedure Call Protocol)消息到服务器B和C；服务器B会马上做出响应，但是服务器C需要和后端的服务器D和E交互之后再返回响应给服务器A，最后由服务器A响应最初的用户请求。对于这样一个请求服务过程，相关技术中的分布式链路跟踪、分析的实现，是服务器A为这个用户请求产生一个traceID，然后在各个服务器上每次操作时记录下包括traceID、时间戳的事件信息。有了traceID，就可以在后续对数据的分析中将各个和该用户请求相关的事件关联起来。

相关技术的分布式链路跟踪、分析系统的实现，如Google的Dapper、淘宝的鹰眼，都采用三阶段处理过程。第一阶段是各个服务器在请求服务过程到达预先埋好的代码路径点时，记录下来该请求和这个代码路径点相关的事件信息，一般是写入到本地文件中；第二阶段由守护进程或日志收集程序将这些信息数据从各个服务器上拉出来，通过网络传输到一个中央仓库中；第三阶段是从中央仓库中取数据进行后续的分析、查询、关联和计算。这一阶段又会在中央仓库和分析计算之间引入大数据库，比如京东、谷歌、淘宝的链路跟踪系统就在第三阶段分别使用了mysql、HBase、Infobright、HiStore等数据库。

这种方法带来的一个问题是数据存储和网络带宽的成本高。每台服务器上的原始信息数据都要通过网络传输到中央仓库进行存储，这样当集群里的服务器数量很多且单台服务器的原始信息数据量也较大的时候，存储和网络带宽的成本就非常高(比如每日TB量级)，对中央仓库造成很大压力。这些网络传输也会对集群生产服务器有一些额外开销(overhead)。此外，扩展性也是问题，比如中央仓库必须随着集群内服务器的数量和整体QPS((服务器每秒处理多少请求))的增长而增加，所以中央仓库可能会成为一个瓶颈点。海量的数据存储到中央仓库以后还需要TB级别的大型数据库才能满足对这些数据的高效查询，这又引入大量的CPU资源。最后，人们一般更关心的是其中占比很小的异常请求的数据，通常只会查看这些异常请求的链路情况，这使得这种方案的性价比较低。

发明内容

有鉴于此，本发明提供了以下方案：

一种分布式链路跟踪方法，包括：

分布式集群中的服务器在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

所述服务器将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

一种分布式集群中的服务器，包括链路跟踪模块，其特征在于，所述链路跟踪模块包括：

事件产生单元，设置为：在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

事件存储单元，设置为：将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

一种分布式集群中的服务器，包括处理器和存储器，其特征在于，

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下链路跟踪处理：

在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

上述分布式链路跟踪方法和服务器将事件保存在本地，从而在链路分析过程中，可以在本地快速搜索事件，不需要将事件信息保存到数据仓库，也不需要建立大型数据。

有鉴于此，本发明还提供了以下方案：

一种分布式链路分析方法，包括：

分布式集群中的全局调度器需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；

所述全局调度器接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

所述全局调度器基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

一种分布式集群中的全局调度器，包括：

链路查询模块，设置为：在需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；及，接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

链路分析模块，设置为：基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

一种分布式集群中的全局调度器，包括处理器和存储器，其中：

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下链路分析处理：

在需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；

接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

上述分布式链路分析方法和全局调度器采取本地存储、按需分析的方式，去除了中央仓库和大型数据库，解决了传统的链路跟踪分析系统中数据存储、分析和网络带宽的成本高以及扩展性问题。

有鉴于此，本发明还提供了以下方案：

一种分布式链路分析方法，包括：

分布式集群中的服务器接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；

所述服务器根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；

所述服务器将搜索到的事件的信息返回给所述全局调度器。

一种分布式集群中的服务器，包括链路分析模块，所述链路分析模块包括：

第一查询接口单元，设置为：接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；及，将搜索到的事件的信息返回给所述全局调度器；

事件搜索单元，设置为：根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；其中，所述跟踪标识的产生时刻的信息携带在所述链路查询请求中。

一种分布式集群中的服务器，包括处理器和存储器，其中：

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下处理：

接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；

根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；

将搜索到的事件的信息返回给所述全局调度器。

上述链路分析方法和服务器通过搜索时间窗来搜索事件，可以大大缩小事件的搜索范围，加快链路分析进程。

附图说明

图1是分布式集群中一次分布式请求的服务过程的示例图；

图2是本发明实施例一分布式链路跟踪方法的流程图；

图3是本发明实施例一服务器中链路跟踪模块的单元结构图；

图4是本发明实施例二全局调度器侧分布式链路分析方法的流程图；

图5是本发明实施例二全局调度器的模块图；

图6是本发明实施例三服务器侧分布式链路分析方法的流程图；

图7是本发明实施例三服务器中链路分析模块的单元结构图；

图8是本发明示例二对I型请求的链路分析过程的整体示意图；

图9是本发明示例二服务器在本地搜索事件的示意图；

图10是本发明示例二的一种本地搜索处理的流程图；

图11是本发明示例二的一种本地搜索处理优化方案的流程图；

图12是本发明示例三对II型请求的链路分析过程的整体示意图；

图13是本发明示例三本地搜索处理和下游追踪处理的示意图；

图14是本发明示例三下游追踪处理的流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

文中，为了表述上的方便，在涉及事件信息包含的内容及对事件信息的保存时，本申请也将事件记录的事件信息称为“事件”。

文中，分布式集群为一个用户请求服务的过程中，为该用户请求产生跟踪标识的服务器称为该用户请求的源服务器。

本发明实施例采取本地存储、按需计算的方式来解决传统的分布式链路跟踪分析系统中数据存储、分析占用资源很多，性价比低以及扩展性不好等问题。

实施例一

本实施例涉及基于跟踪标识的白盒分布式链路跟踪分析系统，包括分布式集群中的全局调度器和服务器，服务器在处理用户请求的过程中产生的事件均保存在服务器本地，在进行链路分析时，才由全局调度器向服务器收集相应的事件信息以进行链路分析，不再建立数据仓库和用于链路跟踪分析的大型数据库。

本实施例涉及的是分布式链路跟踪方法及相应的服务器，分布式链路跟踪主要涉及事件的产生和保存，是分布式链路分析的基础。

本实施例的分布式链路跟踪方法如图2所示，包括：

步骤110，分布式集群中的服务器在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

对某个用户请求进行链路分析时，为了避免在整个存储目录下对事件进行搜索，服务器先确定一个搜索时间窗来缩小搜索范围是必要的，该搜索时间窗的起始时刻可设定为该用户请求的跟踪标识的产生时刻。本实施例中，源服务器将跟踪标识产生时刻的信息编码到产生的跟踪标识中，跟踪标识在链路分析中将被下发给服务器，服务器可以非常方便地从跟踪标识中获取搜索时间窗的起始时刻。在其他实施例中，跟踪标识中也可以不包含跟踪标识产生时刻的信息，例如，全局调度器可以先向源服务器查询得到跟踪标识的产生时刻的信息，然后携带在链路查询请求的其他信息单元中。

链路分析时使用的搜索时间窗的时长(时长＝结束时刻-起始时刻)可以设定为用户请求的最大生命周期如10分钟，所有用户请求的调用时长都不会超过这个时长。为了进一步缩小搜索范围，可以将搜索时间窗的时长设定为要进行链路分析的用户请求的调用时长。因而本实施例中，源服务器在用户请求完成时产生一个特殊的事件：应用程序编程接口(API：Application Programming Interface)事件并保存，该API事件包含用户请求的跟踪标识和调用时长信息。

特别地，本实施例中，源服务器将所述API事件中的超时API事件保存在超时API事件的专有目录下，所述超时API事件指用户请求的调用时长超过对应超时时长的API事件。不同用户请求(如读请求、写请求、查询请求等)对应的超时时长可能是不同的，但均小于系统为用户请求设定的最大生命周期。通常，超时API事件比API事件少至少一个数量级，而链路分析在大多数情况下是针对异常请求如超时请求发起的，因而在超时API事件的专有目录下搜索可以大大加快对超时请求的搜索速度。在搜索不到超时API事件时，说明用户请求的调用时长并没有超时，此时可以将该用户请求对应的超时时长作为该用户请求的调用时长返回给全局调度器。

在另一实施例中，将API事件(包括超时API事件)保存在API事件存储目录下，源服务器可以直接搜索API事件存储目录下的API事件来获取用户请求的调用时长。在又一实施例中，将除超时API事件外的其他API事件保存在API事件存储目录下，将超时API事件保存在超时API事件专有目录下(可以是API事件存储目录的子目录或独立的目录)，在搜索不到超时API事件时，再在API事件存储目录下搜索普通的API事件(即除超时API事件外的其他API事件)来获取用户请求的调用时长。上述API事件存储目录可以是事件存储目录下的子目录，也可以独立于事件存储目录。

通过源服务器产生和存储API事件，在后续的链路分析过程中，全局调度器就可以向源服务器查询其保存的用户请求的调用时长信息，并用于精确确定对事件的搜索时间窗。

为了实现全局调度器向源服务器的查询，源服务器在产生跟踪标识时，可以将源服务器的地址信息编码到产生的跟踪标识中。所述服务器的地址信息可以是直接的地址信息如服务器的IP地址，也可以是间接的地址信息如服务器ID等可用来查找到服务器IP地址的信息。在其他实施例中，源服务器也可以通过其他方式如通过消息将其地址信息上报给全局调度器。

本实施例中，如果用户请求是分布式读请求或分布式写请求，对所述用户请求的处理只涉及到分布式集群中的少量服务器，后续的链路分析可以只针对少量服务器进行链路查询。为了识别该少量服务器，服务器在进行将用户请求向下一跳服务器发送的网络通讯处理时产生一个特殊的事件即通讯事件，所述通讯事件包含所述跟踪标识和所述用户请求被发送到的下一跳服务器的地址信息。在链路分析时，全局调度器可以只向源服务器(如前端服务器)发起查询，而源服务器根据通讯事件中保存的下一跳服务器的地址信息向处理所述用户请求的下一跳服务器发起查询，用户请求处理路径上的各个服务器均如此处理，就可以沿用户请求处理的路径逐跳完成链路查询。

步骤120，所述服务器将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

本实施例中，所述服务器按照事件产生时刻的先后顺序将事件依次保存在本地存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。因为采用顺序存储的方式，根据文件的创建时间和/或最后修改时间就可以确定文件中保存的事件的事件产生时刻所在的时间段。

本实施例还提供了一种分布式集群中的服务器，包括链路跟踪模块，如图3所示，所述链路跟踪模块包括：

事件产生单元10，设置为：在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

事件存储单元20，设置为：将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

本实施例中，所述链路跟踪模块还包括：标识产生单元，设置为：为用户请求产生跟踪标识时，将跟踪标识产生时刻的信息编码到所述跟踪标识中，或者将跟踪标识产生时刻的信息和本服务器的地址信息编码到所述跟踪标识中。

本实施例中，所述事件产生单元还设置为在所述用户请求完成时，产生应用程序编程接口API事件，所述API事件包含所述跟踪标识和所述用户请求的调用时长信息；所述事件存储单元还设置为保存所述API事件。

本实施例中，所述事件存储单元产生所述API事件之后，还包括：将所述API事件中的超时API事件保存在超时API事件的专有目录下，所述超时API事件指用户请求的调用时长超过超时时长的API事件。

本实施例中，所述事件产生单元还设置为进行将所述用户请求向下一跳服务器发送的网络通讯处理时产生一个通讯事件，所述通讯事件包含所述跟踪标识和所述用户请求被发送到的下一跳服务器的地址信息；所述用户请求是进行分布式读或分布式写的用户请求。

本实施例服务器中链路跟踪模块各单元执行的功能，还可以参见链路跟踪方法中的具体描述。

本实施例还提供了一种分布式集群中的服务器，包括处理器和存储器，其中，

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下链路跟踪处理：

在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

本实施例中，所述处理器执行的链路跟踪处理可以包括本实施例链路跟踪方法中的所有处理，这里不再重复说明。

本实施例分布式链路跟踪方法和服务器将产生的事件保存在本地，从而在链路分析过程中，可以在本地搜索事件，不需要将事件信息保存到数据仓库，也不需要建立大型数据。

实施例二

在实施例一中已经描述了分布式集群中服务器的链路跟踪方法，服务器将产生的事件保存在本地，不需要上传到数据仓库。本实施例的分布式链路分析方法中，由全局调度器向服务器进行链路查询，得到相关事件的信息后进行汇总分析。

本实施例分布式链路分析方法用于全局调度器，如图4所示，所述分布式链路分析方法包括：

步骤210，分布式集群中的全局调度器需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；

本实施例中，全局调度器对用户请求进行链路分析，可以根据用户指令来触发，也可以根据配置的条件自动触发，对此不做局限。

如上文所述，服务器在搜索一个用户请求相关的事件时要先确定一个搜索时间窗，所述搜索时间窗的起始时刻可设定为所述用户请求的跟踪标识的产生时刻，而时长可以设定为用户请求的最大生命周期信息或用户请求的调用时长。跟踪标识的产生时刻的信息可以包含在跟踪标识中。如果时长设定为用户请求的最大生命周期，该最大生命周期信息可以携带在所述链路查询请求中。当然也可以作为服务器的配置信息而无需携带在链路查询请求中。如果时长设定为用户请求的调用时长，则所述全局调度器可以向源服务器查询得到的所述用户请求的调用时长信息，并携带在所述链路查询请求中。

本实施例中，用户请求的类型不同时，全局调度器采用不同的链路查询方式：如果用户请求是搜索请求，全局调度器向所述分布式集群中的所有服务器发送所述链路查询请求；如果用户请求是分布式读请求或分布式写请求，全局调度器向所述用户请求的源服务器发送所述链路查询请求。

分布式集群可以提供不同的服务，如有的分布式集群提供读写服务，有些分布式集群提供搜索服务。因而分布式集群本身可以默认一种链路查询方式。对于可以同时提供多种类型服务的分布式集群，全局调度器可以根据用户请求类型采用相应的链路查询方式，或者根据指示处理方式的标志位采用相应的链路查询方式，例如，在跟踪标识中用1bit作为标志位，该标志位为“0”时表示应向分布式集群中的所有服务器发送链路查询请求，为“1”时表示只需向分布式集群中的源服务器发送链路查询请求。

步骤220，所述全局调度器接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

步骤230，所述全局调度器基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

在本实施例的分布式跟踪分析方法中，用户请求都具有一个唯一的跟踪标识，因而与所述跟踪标识相关的事件信息就是所述用户请求处理过程中产生的事件的信息。本实施例主要关注事件的信息采集过程，对于接收到事件信息后的分析处理方法不做任何局限。

本实施例还提供了一种分布式集群中的全局调度器，如图5所示，包括：

链路查询模块30，设置为：在需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；及，接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

链路分析模块40，设置为：基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

本实施例中，所述链路查询模块发送的链路查询请求还携带用户请求的最大生命周期信息，所述跟踪标识包含跟踪标识产生时刻的信息；或者，所述链路查询模块发送的链路查询请求还携带所述全局调度器向源服务器查询得到的所述用户请求的调用时长信息，所述跟踪标识包含跟踪标识产生时刻的信息。

本实施例中，所述用户请求是搜索请求，所述链路查询模块向所述分布式集群中的服务器发送链路查询请求，包括：向所述分布式集群中的所有服务器发送所述链路查询请求；或者，所述用户请求是分布式读请求或分布式写请求，所述链路查询模块向所述分布式集群中的服务器发送链路查询请求，包括：向所述分布式集群中所述用户请求的源服务器发送所述链路查询请求。

本实施例还提供了一种分布式集群中的全局调度器，包括处理器和存储器，其中：

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下链路分析处理：

在需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；

接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

本实施例中，全局调度器中的处理器执行的链路分析处理可以包括本实施例链路分析方法中的所有处理，这里不再重复说明。

本实施例分布式链路分析方法和全局调度器采取本地存储、按需分析的方式，去除了中央仓库和大型数据库，解决了传统的链路跟踪分析系统中数据存储、分析和网络带宽的成本高以及扩展性问题。

实施例三

本实施例涉及在分布式集群中服务器执行的链路分析方法，服务器在收到全局调度器发送的链路查询请求后，根据跟踪标识在本地搜索相关的事件，将搜索到的事件信息返回给全局调度器。为了加快搜索过程，可以使用搜索时间窗来缩小搜索范围。

本实施例分布式链路分析方法如图6所示，包括：

步骤310，分布式集群中的服务器接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；

步骤320，所述服务器根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；

本实施例中，所述跟踪标识的产生时刻的信息包含在所述链路查询请求携带的所述跟踪标识中。在其他实施例中，所述跟踪标识的产生时刻的信息也可以包含在所述链路查询请求携带的其他信息单元中。

本实施例中，所述事件按照事件产生时刻的先后顺序依次保存在文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。所述服务器根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，包括：在事件存储目录下，搜索事件产生时刻落入所述第一搜索时间窗的事件所在的第一目标文件，再在所述第一目标文件中搜索与所述跟踪标识相关的事件；其中，所述第一搜索时间窗的时长为所述用户请求的调用时长或者用户请求的最大生命周期。

本实施例中，所述服务器搜索所述第一目标文件，包括：根据事件存储目录下文件的创建时间和/或最后修改时间，确定文件中保存的事件的事件产生时刻所在的时间段；然后搜索所述时间段落入所述第一搜索时间窗的文件，搜索到的文件即所述第一目标文件。

在一个示例中，根据文件最后修改时间来确定文件中保存的事件的事件产生时刻所在的时间段，例如，一个文件的最后修改时间为t4，而该文件的前一文件的最后修改时间为t3，则该文件保存的事件的事件产生时刻所在的时间段可确定为[t3，t4]；又如，一个文件的创建时间为t5，最后修改时间为t6，则该文件保存的事件的事件产生时刻所在的时间段可确定为[t5，t6]；又如，一个文件的创建时间为t7，而该文件的后一文件的创建时间为t8，则该文件保存的事件的事件产生时刻所在的时间段可确定为[t7，t8]。

如果将所述用户请求的调用时长作为所述第一搜索时间窗的时长，全局调度器可以向源服务器查询得到所述用户请求的调用时长的信息并携带在全局调度器发送的链路查询请求中。

在调用时长的查询过程中，源服务器执行的处理包括：

所述用户请求的源服务器接收所述全局调度器的调用时长查询请求，所述调用时长查询请求携带所述跟踪标识；

本实施例中，所述源服务器在本地搜索与所述跟踪标识相关的超时API事件，从搜索到的超时API事件中获取所述调用时长的信息并返回给所述全局调度器。所述超时API事件指用户请求的调用时长超过对应超时时长的API事件，所述API事件包含用户请求的跟踪标识和调用时长的信息。

特别地，如果源服务器在本地没有搜索到与所述跟踪标识相关的超时API事件，可以到其他API事件的存储目录下继续搜索，也可以将所述用户请求对应的超时时长的信息作为所述调用时长的信息返回给全局调度器。将用户请求对应的超时时长作为调用时长，即可以节约继续搜索API事件的时间，同时返回给全局调度器的用户请求的调用时长也小于用户请求的最大生命周期，使得第一搜索时间窗较小。

在另一实施例中，所述源服务器将超时API事件和其他API事件保存在同一API事件存储目录下，收到调用时长查询请求后，在该API事件存储目录下搜索与所述跟踪标识相关的API事件，从搜索到的API事件中获取所述调用时长的信息并返回给所述全局调度器。

特别地，可以采用以下方式加速对API事件或超时API事件的搜索：先搜索事件产生时刻落入第二搜索时间窗的API事件或超时API事件所在的第二目标文件，再在所述第二目标文件中搜索与所述跟踪标识相关的API事件或超时API事件，其中，所述第二搜索时间窗的起始时刻为所述跟踪标识中包含的跟踪标识产生时刻，时长为用户请求的最大生命周期。对第二目标文件的搜索与对第一目标文件的搜索是类似的，也是根据API事件存储目录或超时API事件存储目录下文件的创建时间和/或最后修改时间，确定文件中保存的API事件的事件产生时刻所在的时间段；然后搜索所述时间段落入所述第二搜索时间窗的文件，搜索到的文件即所述第二目标文件。

步骤330，所述服务器将搜索到的事件的信息返回给所述全局调度器。

如果所述链路查询请求是对搜索请求的链路查询请求，全局调度器可以直接向分布式集群中的所有服务器发送链路查询请求，服务器在本地查询后，将查询结果返回给全局调度器即可。

如果所述链路查询请求是对用户的分布式读请求或分布式写请求的链路查询请求；除了将查询结果返回给全局调度器外，所述服务器还需要执行以下处理：

所述服务器查询本地存储的与所述跟踪标识相关的通讯事件，所述通讯事件包含所述用户请求被发送到的下一跳服务器的地址信息；

所述服务器如查询到所述通讯事件，根据其中的地址信息向所述下一跳服务器发送链路查询请求，携带所述用户请求的跟踪标识；

所述服务器接收所述下一跳服务器返回的与所述跟踪标识相关的事件的信息并返回给所述全局调度器。

在通讯事件存储目录下搜索与所述跟踪标识相关的通讯事件时，也可以使用搜索时间窗来加快搜索，该搜索时间窗的起始时刻为所述跟踪标识中包含的跟踪标识产生时刻，时长可设为用户请求的最大生命周期或者用户请求的调用时长。

本实施例还提供了一种分布式集群中的服务器，包括链路分析模块，如图7所示，所述链路分析模块包括：

第一查询接口单元50，设置为：接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；及，将搜索到的事件的信息返回给所述全局调度器；

事件搜索单元60，设置为：根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；其中，所述跟踪标识的产生时刻的信息携带在所述链路查询请求中。

本实施例中，所述事件按照事件产生时刻的先后顺序依次保存在文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。所述事件搜索单元根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，包括：在事件存储目录下，搜索事件产生时刻落入所述第一搜索时间窗的事件所在的第一目标文件，再在所述第一目标文件中搜索与所述跟踪标识相关的事件；其中，所述第一搜索时间窗的时长为所述用户请求的调用时长或者用户请求的最大生命周期。

本实施例中，所述事件搜索单元搜索所述第一目标文件，包括：根据事件存储目录下文件的创建时间和/或最后修改时间，确定文件中保存的事件的事件产生时刻所在的时间段，然后搜索所述时间段落入所述第一搜索时间窗的文件，搜索到的文件即所述第一目标文件。

本实施例中，所述链路分析模块还可以包括：

调用时长存储单元，设置为：保存应用程序编程接口API事件或超时API事件，所述API事件包含用户请求的跟踪标识和调用时长的信息，所述超时API事件指用户请求的调用时长超过对应超时时长的API事件；

调用时长搜索单元，设置为：接收所述全局调度器发送的调用时长查询请求，在本地搜索与所述调用时长查询请求中携带的跟踪标识相关的API事件或超时API事件，从搜索到的API事件或超时API事件中获取用户请求的调用时长的信息并返回给所述全局调度器。

本实施例中，所述调用时长搜索单元在本地搜索与所述跟踪标识相关的超时API事件，之后还包括：如没有搜索到，将所述用户请求对应的超时时长的信息作为所述调用时长的信息返回给全局调度器。

本实施例中，所述调用时长搜索单元在本地搜索与所述跟踪标识相关的API事件或超时API事件，包括：先搜索事件产生时刻落入第二搜索时间窗的API事件或超时API事件所在的第二目标文件，再在所述第二目标文件中搜索与所述跟踪标识相关的API事件或超时API事件，所述第二搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长为用户请求的最大生命周期。

本实施例中，所述链路查询请求是对用户的分布式读请求或分布式写请求的链路查询请求。所述链路分析模块还包括第二查询接口单元，所述第二查询接口单元包括：

地址获取子单元，设置为：收到所述链路查询请求后，在本地查询与所述跟踪标识相关的通讯事件，从中获取所述用户请求被发送到的下一跳服务器的地址信息；

链路查询子单元，设置为：根据所述地址信息向所述下一跳服务器发送链路查询请求，携带所述用户请求的跟踪标识；

信息传送子单元，设置为：接收所述下一跳服务器返回的与所述跟踪标识相关的事件的信息并返回给所述全局调度器。

本实施例还提供了一种分布式集群中的服务器，包括处理器和存储器，其中，

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下处理：

接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；

根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；

将搜索到的事件的信息返回给所述全局调度器。

本实施例中，服务器中的处理器执行的链路分析处理可以包括本实施例链路分析方法中的所有处理，这里不再重复说明。

本实施例链路分析方法和服务器通过搜索时间窗大大缩小了事件的搜索范围，加快链路分析进程。

上述实施例采用的分布式链路跟踪和分析方法放弃了中央仓库和大型数据库，原始信息数据始终保存在本地服务器上。只有当用户真正需要查询某次用户请求的链路情况时，才会对此用户请求的相关事件进行查询、分析。因此绝大部分时候，绝大部分用户请求的数据如事件都只存储在本服务器上不参与网络传输。另外，上述实施例围绕事件本身是时间有序的这个特性，设计了一些优化方案，在单机一万QPS(即服务器每秒处理10000个请求)的压力下对一次请求的链路分析可以在秒级完成，而且这个时间不随目标集群的规模增大而增加，适合做在线查询分析。无论是从存储角度还是计算角度来看，扩展性都不是问题。

下面再通过几个实际应用中的示例对本发明进行说明。

示例一

本示例涉及链路跟踪，主要关注事件的产生和保存。

本示例的分布式链路跟踪分析系统包括一个全局调度器(可以分布在1或几台机器上)和服务器(本申请中指为用户提供服务的生产服务器)。

本示例涉及I类请求(如搜索请求)和II类请求(如分布式读请求和分布式写请求)共同的链路跟踪方法。

本示例在链路跟踪过程中，将事件保存在本地时，遵照以下规则：各个事件产生本身是时间有序的，服务器会按照事件产生时刻的先后顺序将事件存储在事件存储目录下的文件中。每个文件的最大尺寸可以固定比如设定为2M字节。当文件尺寸超过这个限制后会转到同一文件组的下一个文件保存。例如，文件可以轮转(rotate)方式产生，在文件名中包含序号且序号依次递增，产生的文件数达到设定的最大数量后覆盖最初产生的文件。因为事件按产生时间的先后顺序在文件中依次保存，一个文件的属性“最后修改时间”就能反映出该文件保存的最后一个事件的事件产生时刻(有的文件中只记录一个修改时间(modifytime)，该修改时间就是文件的最后修改时间)。结合规则a)，前一个文件的最后修改时刻可以作为该文件的创建时刻。同样，一个文件的“创建时间”可以反映出该文件保存的第一个事件的事件产生时刻，而下一个文件的“创建时间”可以作为该文件的最后修改时间。

本示例中，通讯事件保存在通讯事件的专有目录下，超时API事件保存在超时API事件的专用目录下，独立于其他事件的存储目录(但可以是其他事件存储目录的子目录)，这样可以加快对这两类特殊事件的搜索。但本发明不局限于此。

本示例中，源服务器需要执行以下处理：

a)源服务器(如图1的前端服务器A里)产生traceID时将traceID产生时刻编码入traceID。这样在链路分析时，服务器能够从traceID中解码出它的产生时刻。

b)源服务器在用户请求完成的时候，产生一个API事件，该API事件记录的信息中包含跟踪标识和用户请求的调用时长。API事件是一个特殊的事件。本示例中，源服务器将API事件中的超时API事件查找出来并保存在一个专有目录下(即该存储目录下只保存超时API事件)，超时API事件指用户请求的调用时长超过对应超时时长(即为该类用户请求设定的超时时长)的API事件。

c)如果使用用户请求的调用时长来缩小搜索时间窗，源服务器产生traceID时将本服务器的IP地址编码入traceID，链路分析时，全局调度器可以从traceID能从中解码出源服务器的IP地址，向源服务器发起对用户请求调用时长的查询。

本示例对II类请求的链路跟踪方法的特殊要求如下：

a)无论是否使用用户请求的调用时长来缩小搜索时间窗，源服务器产生traceID时均将本服务器的IP地址编码入traceID，之后全局调度器能从中解码出产生该traceID的服务器IP地址，向源服务器发起链路查询。

b)服务器进行将用户请求向下一跳服务发送的网络通讯处理时，产生一个通讯事件，该通讯事件包含用户请求被发送到的下一跳服务器的IP地址，可以将此类事件单独存至通讯事件存储目录中。

示例二

本示例涉及I型请求如搜索请求的链路分析过程，相关的链路跟踪过程采用的是示例一的方案，本示例主要关注链路分析中事件的信息采集。

本示例链路分析过程的总体过程请参见图8，包括：

(1)用户需要查看某一用户请求(以下简称为请求)的链路情况，向全局调度器发送链路查看请求，携带该请求的traceID；

(2)全局调度器向分布式集群中所有生产服务器发送链路查询请求，携带该traceID；每台服务器上的分析器(相当于实施例中的链路分析模块)收到后，从本地存储目录中搜索与该traceID相关的所有事件，如果搜索到，就将搜索到的事件的信息发回全局调度器；

(3)全局调度器汇集该traceID相关的所有事件的信息，对其进行链路分析处理，并将最终链路分析结果发回给用户。

图8中集群生产服务器中“埋点的服务器程序”用于完成事件产生和存储功能，相当于实施例中的链路跟踪模块。

具体到服务器中的分析器，如图9所示，分析器在本地事件存储目录下搜索服务器是否产生过和该traceID相关的事件。如果搜索到，返回搜索结果给全局控制器。

本示例对搜索采用了以下优化方案。

本方案搜索traceID相关的事件时并不对整个事件存储目录进行搜索。每台服务器的整个存储目录可能存储了几天的数据，用户请求一般都是有超时时间的，而这个超时时间一般都不大。各类请求的超时时间不一样，但都小于等于用户请求的最大生命周期，假定为10分钟。服务器可以从traceID中解码出traceID产生时刻，因此可以搜索从traceID时刻起的10分钟时间范围的数据，从traceID时刻起的10分钟时间范围，即使用的搜索时间窗，这里称为第一搜索时间窗。

因为在链路跟踪过程中存储事件时是按照时间顺序存储在文件中，当一个文件尺寸达到设定的最大尺寸(如用户限制的尺寸)时就转存到下一个文件保存新事件，所以每一文件的属性“最后修改时间”就能反映该文件最后一个事件的事件产生时刻。换句话说，每一文件都可以从自己以及前一个文件的最后修改时间推断出该文件中保存的所有事件所在的时间段。这样就不用去整个目录搜索，而只从所述时间段落入第一搜索时间窗的文件集合里搜索包含该traceID的事件就可以了。该优化使得只要单机QPS固定，搜索的最大耗时不会随着事件存储目录下事件数量的增长而增加。

服务器中的分析器(相当于链路分析模块)的处理流程(请参见图10)包括：

分析器从traceID的编码中解析出该traceID产生的时间戳:t

在本地事件存储目录中遍历找出所有modify time在[t,t+10分钟]范围的文件组成的集合：S

如果集合S非空，则在集合的文件中去搜索和traceID相关的事件，搜索到的事件集合记为E；如果集合S为空，直接返回空结果；

如果集合E非空，将集合E中的事件的信息返回给全局调度器；如果集合E为空，返回空结果。

上述搜索过程还可以优化，以进一步加速超时请求的链路分析。超时请求是用户很感兴趣的一类请求。上一方案是以用户请求的最大生命周期10分钟作为第一搜索时间窗的时长，即会搜索本服务器的事件存储目录下从traceID发生的时刻起10分钟内的数据中是否有包含该traceID的事件。但不是所有种类的请求(写请求、读请求等)都是10分钟超时的，本优化方案就是要找到用户请求真正的超时时间—它一般比10分钟小很多。源服务器只要在API事件包含的调用时长超过对应的超时时长后，产生一个超时API事件并存到另外一个专有目录里。正常情况下，超时请求的数量比正常请求的数量要少很多，所以超时API事件存储目录至少比普通事件存储目录还要小至少一个数量级。

本优化方案先通过源服务器在本地超时API事件集合里搜索包含该traceID的超时API事件，从搜索到的超时API事件中取得该请求的调用时长，如果搜不到，可以再搜索其他API事件集合取得该请求的调用时长，如果搜不到，或者将该请求对应的超时时长作为该请求的调用时长；之后，就可以用该请求的调用时长来代替原来的10分钟作为各个服务器搜索事件的第一搜索时间窗的时长了。

超时请求优化过的过程(其与全局调度器与源服务器的交互请参见图11)包括：

全局调度器解析traceID，得到产生它的源服务器的IP地址，发送请求的traceID给该服务器以查询请求的调用时长，然后等待分析器返回该请求的调用时长t1；

源服务器上的分析器从收到的traceID的编码中解析出该traceID产生的时间戳：t；

源服务器上的分析器在本地超时API事件存储目录中所有创建到最后修改的时间段在[t,t+10分钟]范围的文件组成的集合中，搜索是否有文件包含该traceID的超时API事件，文件从创建到最后修改的时间段也即文件中保存的事件的事件产生时刻所在的时间段，可以根据文件(或文件及其相邻文件)的最后修改时间和/或创建时间确定；

如果找到，源服务器上的分析器取出该请求的调用时长(duration)t1发送给全局调度器，如果没找到，将该请求对应的超时时长作为t1发送给全局调度器；

全局调度器尝试等待源服务器上的分析器发来的t1，如果在合理等待时间内收到t1，则设置x＝t1，否则设置x＝10分钟。将x作为分析器程序中的y，和traceID一起发送给所有服务器(包括源服务器)上的分析器；

所有服务器上的分析器收到全局调度器发送过来的traceID和对应的y值后，从本地事件存储目录中找到所有创建到最后修改的时间段在[t,t+y]时间范围内的文件集合：S；

如果集合S非空，则在集合的文件中去搜索和traceID相关的事件，搜索到的事件集合记为E；如果集合S为空，直接返回空结果；

如果集合E非空，将集合E中的事件的信息返回给全局调度器；如果集合E为空，返回空结果。

示例三

本示例涉及II型请求如分布式写请求或分布式读请求的链路分析过程，相关的链路跟踪过程采用的是示例一与II型请求相关的方案，本示例主要关注链路分析中事件信息的采集。

整体过程

因为traceID内嵌了产生它的源服务器的IP地址，所以全局调度器对给定traceID能解码出对应的源服务器的IP地址，将traceID发送给源服务器。源服务器上的分析器一边执行I型请求中描述的处理过程，搜索本地和traceID相关联的事件，一边寻找该traceID被自己发送给了哪些服务器(下一跳服务器)，向这些服务器发送链路查询请求，携带该traceID。这些服务器上的分析器也依此操作，直至最后一跳服务器。

II型请求和I型请求的区别在于它牵涉的服务器很少，所以这么一种链式的追踪方案可以使得只有真正处理过相关请求的几台服务器才参与链路分析的过程，集群中绝大部分服务器都不受打扰，这可将链路分析对生产服务器的干扰降到最低。

本示例对II型请求的链路分析流程如图12所示，包括：

(1)用户要查看某一请求的链路情况，向全局调度器发送对该请求的链路查看请求，携带该请求的traceID；

(2)全局调度器解析出产生该traceID的源服务器的IP地址，向源服务器发送链路查询请求，携带该traceID。

(3)源服务器上的分析器收到该traceID后，一边按照I型请求的处理过程搜索和traceID相关联的事件，一边从通讯事件中查找该traceID被发送到的下一跳服务器的IP地址，向下一跳服务器发送链路查询请求，携带该traceID。这样链式处理，直至最后一跳服务器。

(4)所有收到链路查询请求的服务器上的分析器将搜索到的和该traceID相关的事件的信息发回给全局调度器；

(5)全局调度器汇集所有的事件，分析处理后，将链路分析处理的结果发给用户。

本示例服务器上分析器除了要实施示例一中对I型请求的两段式处理过程外，还要执行一个查找下游服务器和向之发送traceID的追踪过程，如图13所示，针对II型请求的分析器本地搜索处理和下游追踪处理包括：

本地处理过程：和示例二相同；

下游追踪过程：在进行本地搜索处理的同时，分析器查找通讯事件存储目录(可以与其他事件在同一目录，也可以是一个专有目录)是否包含traceID相关的通讯事件，有则找到所有下一跳服务器的IP地址，并向其发送链路查询请求，携带该traceID；否则直接返回。

II型请求的本地搜索处理，除了有和I型请求同样的优点外，因为只牵涉到几台服务器即只有这几台服务器上的分析器，而集群里绝大多数服务器上的分析器都不会涉及，所以能极大的减少集群的CPU、磁盘IO资源。所以此方案在这类请求上有更大的优势。

因为II型请求和I型请求的本地搜索处理过程一样，只需要具体看一下下游追踪的流程：

本示例中，下游追踪过程是搜索通讯事件存储目录，所以优化的方案和效果也和示例二相同，如图14所示，包括：

(1)从traceID的编码中解析出该traceID产生的时间戳:t

(2)在本地通讯事件存储目录中遍历找出所有创建到最后修改的时间段落入[t,t+10分钟]的文件组成的集合：S

(3)如果集合S非空，则在集合的文件中去搜索和该traceID相关的通讯事件，通讯事件集合记为E；否则直接返回空结果

(4)如果集合E非空，记录集合E里各个通讯事件包含的下一跳服务器的IP地址，向其发送链路查询请求，携带该traceID；否则直接返回空结果；

(5)结束下游追踪过程。

上述实施例和示例实现了完全本地化存储和计算，去除了经典分布式链路跟踪分析系统中的中央仓库和大型数据库。此外至少还有以下特点：

产生超时API事件，用于优化搜索超时请求的过程

增加包含目标服务IP的通讯事件，用于优化II型请求的搜索过程，只有真正处理过该请求的几台服务器才参与链路分析的过程，集群中绝大部分服务器都不受打扰。将链路分析对生产服务器的干扰降到最低

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (34)

1.一种分布式链路跟踪方法，包括：

分布式集群中的服务器在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

所述服务器将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

2.如权利要求1所述的方法，其特征在于：

所述跟踪标识中包含跟踪标识产生时刻的信息；或者

所述跟踪标识中包含跟踪标识产生时刻的信息和源服务器的地址信息。

3.如权利要求1或2所述的方法，其特征在于：

所述方法还包括：

所述用户请求的源服务器在所述用户请求完成时，产生应用程序编程接口API事件并保存，所述API事件包含所述跟踪标识和所述用户请求的调用时长信息。

4.如权利要求3所述的方法，其特征在于：

所述源服务器产生所述API事件之后，还包括：将所述API事件中的超时API事件保存在超时API事件的专有目录下，所述超时API事件指用户请求的调用时长超过对应超时时长的API事件。

5.如权利要求1或2或4所述的方法，其特征在于：

所述用户请求是分布式读请求或分布式写请求；

所述方法还包括：所述服务器进行将所述用户请求向下一跳服务器发送的网络通讯处理时产生一个通讯事件，所述通讯事件包含所述跟踪标识和所述用户请求被发送到的下一跳服务器的地址信息。

6.一种分布式集群中的服务器，包括链路跟踪模块，其特征在于，所述链路跟踪模块包括：

事件产生单元，设置为：在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

事件存储单元，设置为：将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

7.如权利要求6所述的服务器，其特征在于：

所述链路跟踪模块还包括：标识产生单元，设置为：为用户请求产生跟踪标识时，将跟踪标识产生时刻的信息编码到所述跟踪标识中，或者将跟踪标识产生时刻的信息和本服务器的地址信息编码到所述跟踪标识中。

8.如权利要求6或7所述的服务器，其特征在于：

所述事件产生单元还设置为在所述用户请求完成时，产生应用程序编程接口API事件，所述API事件包含所述跟踪标识和所述用户请求的调用时长信息；

所述事件存储单元还设置为保存所述API事件。

9.如权利要求8所述的服务器，其特征在于：

所述事件存储单元产生所述API事件之后，还包括：将所述API事件中的超时API事件保存在超时API事件的专有目录下，所述超时API事件指用户请求的调用时长超过超时时长的API事件。

10.如权利要求6或7或9所述的服务器，其特征在于：

所述事件产生单元还设置为进行将所述用户请求向下一跳服务器发送的网络通讯处理时产生一个通讯事件，所述通讯事件包含所述跟踪标识和所述用户请求被发送到的下一跳服务器的地址信息；所述用户请求是进行分布式读或分布式写的用户请求。

11.一种分布式集群中的服务器，包括处理器和存储器，其特征在于，

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下链路跟踪处理：

在处理用户请求的过程中产生事件，所述事件中包含跟踪标识的信息；

将所述事件按照事件产生时刻的先后顺序依次保存在本地事件存储目录下的文件中，在一个文件达到设定的最大尺寸后转用下一文件保存。

12.一种分布式链路分析方法，包括：

分布式集群中的全局调度器需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；

所述全局调度器接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

所述全局调度器基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

13.如权利要求12所述的方法，其特征在于：

所述跟踪标识包含跟踪标识产生时刻的信息，所述链路查询请求还携带用户请求的最大生命周期信息；或者

所述跟踪标识包含跟踪标识产生时刻的信息，所述链路查询请求还携带所述全局调度器向源服务器查询得到的所述用户请求的调用时长信息。

14.如权利要求12或13所述的方法，其特征在于：

所述用户请求是搜索请求；所述全局调度器向所述分布式集群中的服务器发送链路查询请求，包括：向所述分布式集群中的所有服务器发送所述链路查询请求；或者

所述用户请求是分布式读请求或分布式写请求，所述全局调度器向所述分布式集群中的服务器发送链路查询请求，包括：向所述用户请求的源服务器发送所述链路查询请求。

15.一种分布式集群中的全局调度器，其特征在于，包括：

链路查询模块，设置为：在需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；及，接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

链路分析模块，设置为：基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

16.如权利要求15所述的全局调度器，其特征在于：

所述链路查询模块发送的链路查询请求还携带用户请求的最大生命周期信息，所述跟踪标识包含跟踪标识产生时刻的信息；或者

所述链路查询模块发送的链路查询请求还携带所述全局调度器向源服务器查询得到的所述用户请求的调用时长信息，所述跟踪标识包含跟踪标识产生时刻的信息。

17.如权利要求15或16所述的全局调度器，其特征在于：

所述用户请求是搜索请求，所述链路查询模块向所述分布式集群中的服务器发送链路查询请求，包括：向所述分布式集群中的所有服务器发送所述链路查询请求；或者

所述用户请求是分布式读请求或分布式写请求，所述链路查询模块向所述分布式集群中的服务器发送链路查询请求，包括：向所述分布式集群中所述用户请求的源服务器发送所述链路查询请求。

18.一种分布式集群中的全局调度器，包括处理器和存储器，其特征在于，

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下链路分析处理：

在需要对用户请求进行链路分析时，向所述分布式集群中的服务器发送链路查询请求，携带所述用户请求的跟踪标识；

接收所述服务器在本地搜索后返回的与所述跟踪标识相关的事件的信息；

基于接收到的与所述跟踪标识相关的事件的信息，对所述用户请求进行链路分析。

19.一种分布式链路分析方法，包括：

分布式集群中的服务器接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；

所述服务器根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；

所述服务器将搜索到的事件的信息返回给所述全局调度器。

20.如权利要求19所述的方法，其特征在于：

所述跟踪标识的产生时刻的信息包含在所述链路查询请求携带的所述跟踪标识中。

21.如权利要求19所述的方法，其特征在于：

所述事件按照事件产生时刻的先后顺序依次保存在文件中，在一个文件达到设定的最大尺寸后转用下一文件保存；

所述服务器根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，包括：在事件存储目录下，搜索事件产生时刻落入所述第一搜索时间窗的事件所在的第一目标文件，再在所述第一目标文件中搜索与所述跟踪标识相关的事件；其中，所述第一搜索时间窗的时长为所述用户请求的调用时长或者用户请求的最大生命周期。

22.如权利要求21所述的方法，其特征在于：

所述服务器搜索所述第一目标文件，包括：根据事件存储目录下文件的创建时间和/或最后修改时间，确定文件中保存的事件的事件产生时刻所在的时间段，然后搜索所述时间段落入所述第一搜索时间窗的文件，搜索到的文件即所述第一目标文件。

23.如权利要求21所述的方法，其特征在于：

所述第一搜索时间窗的时长为所述用户请求的调用时长；

所述方法还包括：

所述用户请求的源服务器接收所述全局调度器的调用时长查询请求，所述调用时长查询请求携带所述跟踪标识；

所述源服务器在本地搜索与所述跟踪标识相关的应用程序编程接口API事件或超时API事件，从搜索到的API事件或超时API事件中获取所述调用时长的信息并返回给所述全局调度器；

其中，所述API事件包含用户请求的跟踪标识和调用时长的信息，所述超时API事件指用户请求的调用时长超过对应超时时长的API事件。

24.如权利要求23所述的方法，其特征在于：

所述源服务器在本地搜索与所述跟踪标识相关的超时API事件，之后还包括：如没有搜索到，将所述用户请求对应的超时时长的信息作为所述调用时长的信息返回给全局调度器。

25.如权利要求23或24所述的方法，其特征在于：

所述源服务器在本地搜索与所述跟踪标识相关的API事件或超时API事件，包括：先搜索事件产生时刻落入第二搜索时间窗的API事件或超时API事件所在的第二目标文件，再在所述第二目标文件中搜索与所述跟踪标识相关的API事件或超时API事件，所述第二搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长为用户请求的最大生命周期。

26.如权利要求19-24中任一所述的方法，其特征在于：

所述链路查询请求是对用户的分布式读请求或分布式写请求的链路查询请求；

所述服务器收到所述链路查询请求后，还包括：

所述服务器查询本地存储的与所述跟踪标识相关的通讯事件，所述通讯事件包含所述用户请求被发送到的下一跳服务器的地址信息；

所述服务器如查询到所述通讯事件，根据其中的地址信息向所述下一跳服务器发送链路查询请求，携带所述用户请求的跟踪标识；

所述服务器接收所述下一跳服务器返回的与所述跟踪标识相关的事件的信息并返回给所述全局调度器。

27.一种分布式集群中的服务器，包括链路分析模块，其特征在于，所述链路分析模块包括：

第一查询接口单元，设置为：接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；及，将搜索到的事件的信息返回给所述全局调度器；

事件搜索单元，设置为：根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；其中，所述跟踪标识的产生时刻的信息携带在所述链路查询请求中。

28.如权利要求27所述的服务器，其特征在于：

所述事件按照事件产生时刻的先后顺序依次保存在文件中，在一个文件达到设定的最大尺寸后转用下一文件保存；

所述事件搜索单元根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，包括：在事件存储目录下，搜索事件产生时刻落入所述第一搜索时间窗的事件所在的第一目标文件，再在所述第一目标文件中搜索与所述跟踪标识相关的事件；其中，所述第一搜索时间窗的时长为所述用户请求的调用时长或者用户请求的最大生命周期。

29.如权利要求28所述的服务器，其特征在于：

所述事件搜索单元搜索所述第一目标文件，包括：根据事件存储目录下文件的创建时间和/或最后修改时间，确定文件中保存的事件的事件产生时刻所在的时间段，然后搜索所述时间段落入所述第一搜索时间窗的文件，搜索到的文件即所述第一目标文件。

30.如权利要求28所述的服务器，其特征在于：

所述链路分析模块还包括：

调用时长存储单元，设置为：保存应用程序编程接口API事件或超时API事件，所述API事件包含用户请求的跟踪标识和调用时长的信息，所述超时API事件指用户请求的调用时长超过对应超时时长的API事件；

调用时长搜索单元，设置为：接收所述全局调度器发送的调用时长查询请求，在本地搜索与所述调用时长查询请求中携带的跟踪标识相关的API事件或超时API事件，从搜索到的API事件或超时API事件中获取用户请求的调用时长的信息并返回给所述全局调度器。

31.如权利要求30所述的服务器，其特征在于：

所述调用时长搜索单元在本地搜索与所述跟踪标识相关的超时API事件，之后还包括：如没有搜索到，将所述用户请求对应的超时时长的信息作为所述调用时长的信息返回给全局调度器。

32.如权利要求30或31所述的服务器，其特征在于：

所述调用时长搜索单元在本地搜索与所述跟踪标识相关的API事件或超时API事件，包括：先搜索事件产生时刻落入第二搜索时间窗的API事件或超时API事件所在的第二目标文件，再在所述第二目标文件中搜索与所述跟踪标识相关的API事件或超时API事件，所述第二搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长为用户请求的最大生命周期。

33.如权利要求27-31中任一所述的服务器，其特征在于：

所述链路查询请求是对用户的分布式读请求或分布式写请求的链路查询请求；

所述链路分析模块还包括第二查询接口单元，所述第二查询接口单元包括：

地址获取子单元，设置为：收到所述链路查询请求后，在本地查询与所述跟踪标识相关的通讯事件，从中获取所述用户请求被发送到的下一跳服务器的地址信息；

链路查询子单元，设置为：根据所述地址信息向所述下一跳服务器发送链路查询请求，携带所述用户请求的跟踪标识；

信息传送子单元，设置为：接收所述下一跳服务器返回的与所述跟踪标识相关的事件的信息并返回给所述全局调度器。

34.一种分布式集群中的服务器，包括处理器和存储器，其特征在于，

所述存储器，设置为：保存程序代码；

所述处理器，设置为：读取所述程序代码并执行以下处理：

接收全局调度器发送的链路查询请求，所述链路查询请求中携带用户请求的跟踪标识；

根据第一搜索时间窗在本地搜索与所述跟踪标识相关的事件，所述第一搜索时间窗的起始时刻为所述跟踪标识的产生时刻，时长小于或等于用户请求的最大生命周期；

将搜索到的事件的信息返回给所述全局调度器。