| 发布日期：2024-11-19 14:54 点击次数：152 |
分散式软件系统正粗糙应用于互联网、金融、政府、工业等社会的各个领域中， 对东说念主们的糊口有着要紧的影响.若何提高系统运维效用， 保险分散式软件系统不时提供可靠厚实的办事， 成为学术界和工业界共同温和的问题.由于分散式软件系统具有以下特色:(1)节点限制浩瀚.分散式软件系统被部署在大批的物理或假造节点中; (2)系统结构与组件依赖关系复杂.系统组件宽广且开始各类， 可能由不同团队使用不同编程谈话开导并集成了第三方或者开源软件代码女同， 组件之间互相依赖; (3)限制与结构不时更新.为高慢不断增长的业务量与新需求， 分散式软件系统时时会在限制与结构上不时更新与升级， 使得分散式软件系统的限制愈加浩瀚， 结构愈加复杂.同期， 分散式软件系统存在大批并发的办事苦求， 请务实行的逻辑复杂， 即使是单个办事苦求也会经过分散在大批节点上的不同组件的处理.这些特色导致了分散式软件系统的步履难以领会， 请务实行的畸形难以检测与定位， 分散式软件系统的性能瓶颈难以分析与优化， 给分散式软件系统中的故障会诊、性能调优、系统率悟等一系列运维任务带来了严峻的挑战.
图 1以Hadoop系统为例， 展示了一个办事苦求在分散式软件系统中的处理过程.Hadoop被部署在由千千万万台办事器组成的大限制集群中， 对内或对外提供不同类型的办事(如HDFS的文献存取办事， YARN的资源调治办事， MapReduce的分散式计议办事等)， 办事之间互相依赖， 不同的办事由不同的组件提供， 每个组件有一个或多个分散在不同的物理/假造的计议节点上的实例， 用户对Hadoop提供的办事进行调用(即进行办事苦求)， 整个的组件/办事/节点共同配合反映用户的办事苦求.在这种典型的分散式软件系统场景中， 传统的以组件/节点/程度/线程为中心的系统监控与跟踪方法只可揭示分散式软件系统局部的状态与步履， 或者提供全局的粗粒度的统计数据， 无法准确描绘分散式软件系统中因办事苦求产生的一系列步履与状态变化， 难以救济分散式软件系统中的各项运维任务.因此， 分散式软件系统蹙迫需要一种对系统运行步履进行举座、精确、细粒度描绘的本事， 高慢分散式软件系统的故障会诊、性能调优、系统率悟、资源审计等一系列运维经管任务的需求.基于此， 分散式跟踪本事应时而生.分散式跟踪(distributed tracing)是指在办事苦求参加分散式软件系统到系统完成对苦求的反映这段时代内， 将系统中因处理该苦求产生的因果相干的事件(即苦求事件)相干联， 生成苦求在系统中的实行旅途的过程， 也被称为以责任流为中心的跟踪(workflow-centric tracing)/端到端跟踪(end-to-end tracing)/因果跟踪(causal tracing)/分散式调用跟踪/全链路跟踪[1-3].
Fig. 1 The request processing in a distributed system (Hadoop)
图 1 分散式软件系统中的办事苦求处理(以Hadoop为例)
分散式跟踪本事产生的请务实行旅途随机精确地描绘分散式软件系统举座的实行逻辑.基于生成的请务实行旅途， 开导与运维东说念主员随机高效、精确地发现、定位分散式软件系统的故障并进行根因分析， 准确地发现、分析并领会分散式软件系统中的性能瓶颈， 在空匮本事文档的要求下不错领会分散式软件系统的部署结构和运功绩态， 对系统资源进行细粒度的经管与审计， 这对提高分散式软件系统的运维效用具有要紧的议论意旨.
分散式跟踪本事早期与针对单点圭表的跟踪本事， 如strace、ptrace、DTrace[4]， 与分散式软件系统中的办事依赖发现[5]密切相干， 但针对单点圭表的跟踪本事只温和一个节点或统一程度/线程的事件之间的时序关系， 而办事依赖发现则只温和办事或组件之间的交互.早期对分散式软件系统的跟踪主要使用strace、ptrace、GDB等， 关联词， 跟着分散式软件系统的急速发展与应用， 传统的单点调试与跟踪器具无法冒失限制越来越大、结构越来越复杂、苦求并发度越来越高的分散式软件系统， 分散式跟踪本事安靖成为一个单独的议论热门， 得回了学术界与工业界的大批温和， 在工业界的应用中考据了其巨大的生意价值[6].图 2给出了自2001年以来学术界在分散式跟踪领域所发表的学术论文的数目、发表源卓越发表年限.从图 2不错看出， 自2001年来， 学术界均有厚实数目的分散式跟踪领域的议论后果发表在计议机领域顶级、要紧的会议与期刊中， 且近6年来的论文发表数目有彰着的加多， 成为分散式系统率域一个要紧的议论热门.天然分散式跟踪本事在议论与应用方面都取得了巨大的进展， 但面前的分散式跟踪本事仍存在着一定的局限性， 使得分散式跟踪本事无法透顶地施展其巨大价值， 如面前的分散式跟踪本事或者需要侵入分散式软件系统的源代码， 或者依赖于特定的中间件与特定的邻接库， 或者在生成的请务实行旅途的准确性与完好性上有所缺失.因此， 分散式跟踪本事在若何低支拨、低侵入地生成苦求跟踪数据， 若何从苦求跟踪数据中构建完好、准确的请务实行旅途仍然面对着很大的挑战.本文从跟踪数据获取、苦求事件索求、因果关系判断及苦求旅途默示这4个方面综述了分散式跟踪本事的近况， 然后先容了连年来基于分散式跟踪本事的应用议论责任， 终末对分散式跟踪领域以前值得温和的问题和议论目的进行了探讨.
Fig. 2 The distribution for the number and the year of the published papers
图 2 论文发表数目、出处及发表年份分散
本文第1节对分散式跟踪相干的见地进行文告.第2节给出议论框架并对分散式跟踪领域已有的议论责任进行详备的先容与分析， 并回归其优污点.第3节展示学术界基于分散式跟踪本事的应用议论.第4节对分散式跟踪本事以前的议论目的进行预计.
1 问题形色假定分散式软件系统在一段时代内处理n个办事苦求R={r1， r2， r3， …， rn}， 产生的事件的集结为E={e1， e2， e3， …， em}， m≥n， 其中， ri为分散式软件系统处理的一个苦求， ei为一个分散式跟踪系统所不雅察到或产生的事件.
事件:由于不同的分散式跟踪本事其所针对的运维任务不同且其地点的软件堆栈也不同， 是以在不同的分散式跟踪议论责任中， 其事件的粒度(granularity)可能是不同的， 常见的事件粒度有内核事件、系统调用事件、库调用事件、方法调用事件、RPC(remote procedure call)事件、日记音信、组件及办事等.
因果关系:事件之间的因果关系泛泛被界说为Lamport[7]忽视的事件之间的Happen-before关系.Happen- before关系界说事件a→b， 即事件a为事件b的因， 事件b为a的果， 当且仅当:(1)若a与b在统一程度(可扩张至子程度及线程之中)中， a先于b发生; (2)若a是一个音信的发送事件， 而b是此音信的禁受事件.相干责任对Happen-before关系进行了拓展， 如Yong[1]在Happen-before因果关系的基础上拓展出因程度/线程同步导致的事件之间的因果关系及因读写统一内存地址或音信队伍等产生读取与写入事件之间的依赖关系， 文献[8]将Log片断之间的因果关系辩别为Happen-before、Mutual exclusion和Pipeline这3类.若事件粒度为方法调用事件， 因果关系则泛泛指的是方法之间调用与被调用的关系[9].若事件粒度在组件及办事级别， 因果关系则泛泛指的是组件之间的调用关系[10， 11]， 或办事之间的依赖关系[12].期望状态下， 分散式跟踪本事应该随机识别整个事件之间的因果关系.
请务实行旅途:获取事件集结E， 将E辩别为n+1个子集结E1， E2， …， En+1， 判断每个子集结Ej中事件之间因果关系并对每一个苦求构建请务实行旅途.其中， 当i≠j时， Ei⌒Ej=∅， 且E1∪E2∪E3∪…∪En+1=E， 其中， En+1为分散式软件系统自身产生的与办事苦求无关的事件集结; 每个子集结Ej={ej 1， ej 2， ej 3， …， ej 0}， o为集结中事件的个数， 集结中的每个事件ej i∈E， 且ej i是分散式软件系统因处理苦求rj过程中产生的事件; 对每个子集结Ej， 分散式跟踪生成该集结中事件之间的因果关系集结Cj={cj 1， cj 2， cj 3， …， ej p}， p为集结中因果关系的个数， 其中， 每个因果关系cj t默示Ej中的两个事件ej i与ej k存在因果关系即ej i→ej k; 对每一个苦求rj， 分散式跟踪系统凭证其事件集结Ej与其因果关系集结Cj构建请务实行旅途.
2 分散式跟踪本事相干议论责任 2.1 本事框架分散式跟踪本事的典型框架如图 3所示， 由4个关节本事组成:(1)跟踪数据获取; (2)苦求事件索求; (3)事件因果关系判断; (4)请务实行旅途默示.
Fig. 3 The research framework of distributed tracing technique
图 3 分散式跟踪本事框架
(1) 跟踪数据获取.在系统运行时获取构建请务实行旅途所需的跟踪数据.跟踪数据包括事件自己与扶植构建请务实行旅途的其他数据.举例， 当请务实行旅途中的事件为方法调用时， 请务实行旅途为一个苦求的方法调用树， 跟踪数据包含每个方法调用事件、苦求ID、每个方法调用事件的父事件ID、每个方法调用的时代戳与实行时代等.跟踪数据获取主要有两个本事目的:①代码侵入; ②数据采集.前者通过在软件堆栈的不同头绪修改代码成立跟踪点生成跟踪数据， 后者期骗系统运行时产生的日记与内核事件手脚跟踪数据.
(2) 苦求事件索求.从整个事件中将与某一苦求相干的事件索求或荫庇出来.举例， 当苦求旅途中的事件粒度为方法时， 苦求事件索求的是系统为处理该苦求所调用的整个方法的事件集结.苦求事件索求主要有3个本事目的:①基于苦求标识; ②基于统计算计; ③基于因果关系判断.基于苦求标识的苦求事件索求方法期骗苦求的全局ID或者局部ID判断事件是否属于统一个苦求， 基于统计算计的事件索求方法摄取统计学方法算计事件是否属于统一个苦求， 基于因果关系判断的事件索求方法凭证事件之间的因果关系不断地将事件团结， 互相团结的事件属于统一苦求.
(3) 因果关系判断.对属于某一苦求或整个的事件进行因果关系判定， 若两个事件存在因果关系(A为因， B为果)， 则事件A是事件B发生的前提.举例， 当请务实行旅途中的事件粒度为方法时， 该本事判断属于统一苦求的纵情两个方法调用事件之间的调用关系.因果关系判断主要有两种方法:①基于章程; ②基于统计分析.前者期骗跟踪数据中所含有的父子事件ID、时代戳、对统一数据的读写关系等判断事件之间的因果关系.后者摄取统计学方法， 从历史或者全局的跟踪数据中， 算计事件之间的因果关系.
(4) 请务实行旅途默示.对苦求的事件及事件之间的因果关系进行默示.举例， 当请务实行旅途中的事件粒度为方法时， 请务实行旅途不错默示为一个苦求的方法调用序列或者方法调用树.请务实行旅途主要有3种默示模子:①序列模子; ②树模子; ③有向图模子.
2.2 跟踪数据获取跟踪数据包括两部分:(1)组成请务实行旅途的事件， 如内核事件、方法调用事件等; (2)扶植构建请务实行旅途的其他数据， 如时代戳、苦求ID等.凭证是否不错截至所获取的跟踪数据的内容， 将跟踪数据获取本事分为基于代码侵入的跟踪数据获取和基于数据采集的跟踪数据获取.前者摄取侵入软件堆栈的不同头绪的样式主动获取构建请务实行旅途所需要的跟踪数据， 后者则采集分散式软件系统在运行过程中产生的预界说的数据.
2.2.1 基于代码侵入的跟踪数据获取本事此类本当事人要议论若何以较少的代码修改、较低的系统支拨及较强的通用性侵入软件堆栈的不同头绪， 成立跟踪点， 在分散式系统软件中传播苦求的高下文， 已毕跟踪数据的获取.各本事的主要区别在于侵入软件堆栈的头绪、侵入的方法、跟踪点的成立及苦求高下文的传播机制.按照侵入软件堆栈头绪的不同， 咱们不错将基于代码侵入的跟踪数据获取本事更具体地辩别为以下4类.
(1) 侵入分散式软件系统.此类方法需要东说念主工修改分散式软件系统的源代码， 添加救济分散式跟踪功能的代码， 产生苦求的标识符并截至苦求的标识符在分散式软件系统中的传播， 生成跟踪数据.文献[3]在分散式存储系统Ursa Minor中， 成立了200个跟踪点， 加多了250 000行代码用于产生跟踪数据.其跟踪数据由时代戳、苦求的全局ID——breadcrumb、程度ID和线程ID所组成的头部以及代表不共事件的负载所组成.其中， 苦求的全局ID在蚁合音信之间的传播通过修改Ursa Minor的RPC通讯来已毕， 在节点内则通过东说念主工修改Ursa Minor的代码进行传播; 负载字段则包含磁盘、CPU、内存等资源使用数据.文献[13]则在文献[3]的基础上加多了部分跟踪点， 用于记载多线程编程酿成的并行与同步操作.雷同的需侵入分散式软件系统代码获取跟踪数据的议论责任还包括文献[14-16].
(2) 侵入特定的运行时环境.此类方法需要东说念主工修改分散式软件系统运行时环境的代码或者期骗运行时环境的一些性情(如， 面向切面编程AOP)及特定的器具进行半自动化的侵入.这种方法常见于跟踪运行在JAVA或者.NET平台之上的分散式软件系统.文献[17， 18]侵入JavaBeans、JSP和JSP tags的已毕代码， 在苦求参加J2EE系统时， 自动地为苦求分拨全局独一的ID.该苦求ID在蚁合音信之间的传播是通过在HTTP公约的头中添加苦求ID， 在节点之内则是通过将苦求ID存放在Thread Local Storage中， 随截至流而传播.文献[19， 20]虽莫得侵入JVM已毕， 但依赖于Java平台救济面向切面编程(AOP)的性情， 动态地成立跟踪点， 生成跟踪数据.但其苦求ID在蚁合音信之间的传播是通过东说念主工修改分散式软件系统的RPC(remote procedure call)公约代码， 在跨程度/线程交互部分苦求ID的传播通过使用AspectJ进步履态已毕， 在线程之内的苦求ID传播与文献[18]沟通， 是通过Thread Local Storage来已毕.文献[21， 22]则适用于运行在.NET平台上的分散式软件系统的跟踪， 其详尽期骗Windows系统中的Event Tracing for Windows、.NET profiling API、Detours等不同器具生成包含内核事件、RPC调用、系统调用、蚁合交互等不同头绪的跟踪数据.文献[23]侵入Node.js的运行时环境， 成立跟踪点， 动态地产生客户端与分散式软件系统的跟踪数据.
(3) 侵入大众邻接库.此类方法需要东说念主工修改分散式软件系统所依赖的大众邻接库， 如RPC库、线程库来已毕自动或半自动地对基于此类大众邻接库的分散式软件系统的跟踪.此类方法多见于大型企业中， 不同的分散式软件系统依赖于被粗糙调用的企业里面的通用邻接库.文献[9]通过对谷歌里面的基础RPC库、线程截至库和经由截至库(线程池及异措施用)进行少许的代码修改(1 000行的C++代码修改与800行的Java代码修改)， 成立跟踪点， 已毕了对基于这些大众邻接库的分散式软件系统的跟踪数据的生成.文献[24]则是基于Facebook里面的大众邻接库的产陌生散式软件系统的跟踪数据.而业界着名的开源分散式跟踪系统zipkin[25]与opentracing[26]摄取了与文献[9]相似的机制， 提供了多种谈话的常见的大众邻接库以救济分散式跟踪.文献[27， 28]通过修改蚁合邻接库向各式蚁合公约的头部添加苦求ID跋文录蚁合音信手脚跟踪数据.文献[29]在分散式软件系统每次进行系统调用及调用扫尾时刻别记载系统调用称号实时代戳手脚苦求跟踪数据.
(4) 侵入操作系统内核接口.此类方法在假造机层或者系统调用的API上进行系统调用的防止与删改来已毕自动地对运行在此类操作系统上的分散式软件系统进行跟踪.文献[30， 31]在假造机经管软件(VMM)层防止系统调用生成跟踪数据， 包括socket的标识符、TCP四元组(srcIP， srcPort， destIP， destPort)及线程ID这些扶植生成请务实行旅途的数据.而文献[1， 32， 33]则通过LD_PRELOAD机制防止UNIX-like系统中的系统调用在libc库中的API， 当分散式系统进行系统调用时， 通过防止与删改系统调用的样式生成跟踪数据.文献[34]基于ptrace防止系统调用事件， 并将系统调用事件和其他开始的日记数据一说念手脚跟踪数据.文献[35]则只是处理TCP蚁合通讯系统调用事件， 记载下分散式软件系统每次蚁合通讯的TCP四元组数据.
2.2.2 基于数据采集的跟踪数据获取本事此类本当事人要采集分散式软件系统运行时产生的预界说的数据手脚跟踪数据.这类预界说的数据主要有两种， 一种是分散式软件系统运行所产生的在开导阶段预界说的日记， 另一种是操作系统层面预界说的内核事件日记.
(1) 采集分散式软件系统日记.分散式软件系统的日记由开导东说念主员在开导时依据个东说念主训诫主不雅成立， 不同的分散式软件系统的日记体式泛泛有所区别， 其自己是为了便捷开导东说念主员进行系统功能调试， 而非为了跟踪分散式系统中的苦求， 其内容、数目、体式与结构泛泛无法变嫌.因此需要使用不同的方法对采集到的日记进行预处理， 并从中索求苦求的全局ID、局部ID及日记之间的关联关系等用于构建请务实行旅途.文献[2， 8， 36-44]均期骗分散式软件系统在运行时产生的系统日记手脚跟踪数据， 从中构建请务实行旅途.
(2) 采集操作系统内核事件日记.关于操作系统级别的内核事件， 不同的事件类型， 其体式也会有所区别， 比拟于分散式软件系统的日记， 内核事件更为底层， 空匮表层应用的信息， 且难以领会， 需要大批的巨匠常识对每一种类型的内核事件进行解读.因其不包含表层应用的信息， 故其变量也不存在苦求的全局ID.文献[45-47]平直采集运行分散式软件系统的操作系统产生的内核日记手脚苦求跟踪数据， 构建请务实行旅途.
2.2.3 不同跟踪数据获取本事的对比分析表 1回归了不同跟踪数据获取本事的优污点.基于代码侵入的跟踪数据获取本事具有跟踪内容可自界说、可活泼成立跟踪点的优点， 即产生什么类型的数据以及在什么位置产生跟踪数据乃至于产生的跟踪数据的内容是什么都不错进行截至.其污点则在于需要东说念主工修改相应软件堆栈的代码， 且会引入一定的罕见的系统支拨.侵入分散式软件系统的方法适用于分散式软件系统的源代码可控且对源码比较了解， 且不需要洽商后续通用性的情况; 侵入运行时环境的方法和侵入大众邻接库的方法适用于需要洽商分散式跟踪本事的通用性， 且被跟踪的分散式软件系统具有沟通的运行时环境或大众邻接库的情况; 侵入操作系统内核接口的方法适用于对分散式软件系统的运行环境具有绝对的截至(Root权限)， 且需要分散式跟踪本事具有较高的通用性的情况.而基于数据采集的本事具有无罕见系统支拨、无需任何代码修改的优点， 但其污点也很彰着， 其可用的数据局限于开导东说念主员在开导时的主不雅选拔或者一些常用的监控筹划， 如CPU/内存/磁盘的期骗率等.采集分散式软件系统日记的方法适用于无法修改或难以修改分散式软件系统的源码且软件系统有大批日记输出的情况; 采集操作系统内核事件日记的方法适用于运行头绪较低的分散式软件系统.在基于代码入侵的本事中， 跟着软件堆栈头绪的不断缩小， 跟踪数据内容的可定制性会缩小， 其通用性会不断增强， 但表层应用的信息也越来越少.如平直侵入分散式软件系统代码不错获取丰富的表层应用(分散式软件系统)的信息， 但侵入操作系统内核接口则难以获取表层应用的信息.比拟于操作系统的内核数据结构， 分散式软件系统的日记含有更丰富的与表层应用相干的信息， 但其数目较少.内核事件的数目较多， 但空匮表层应用信息， 难以领会.
Table 1 Pros & cons of tracing data acquiring methods
表 1 不同跟踪数据获取本事的优污点
2.3 苦求事件索求
苦求事件索求本事将与某一苦求相干的整个事件从获取的整个跟踪数据中索求出来， 生成以苦求为单元的事件集结.其主要措置的问题是， 若何将与某一苦求相干的整个事件从因苦求并发酿成的不同苦求的事件互相交叉的事件集结中索求出来.苦求事件索求本事可进一步辩别为:(1)基于苦求标识的苦求事件索求， 通过跟踪数据中含有的苦求的全局ID或者苦求的局部ID(如苦求在组件内的ID/程度/线程/关节变量等)， 将与一个苦求相干的整个事件从大批跟踪数据中索求/荫庇出来; (2)基于统计算计的苦求事件索求， 通过对分散式软件系统的代码或跟踪数据的统计与分析发现与一个苦求相干的事件在时代或概率上的轨则， 凭证学习到的轨则将事件辩别到一个苦求当中; (3)基于因果关系的苦求事件索求， 领先进行因果关系判断， 期骗得到的整个事件的因果关系将因果相干的事件关联， 互相干联的事件属于统一个苦求.
2.3.1 基于苦求标识的苦求事件索求此类本事期骗跟踪数据中可在全局独一标识一个苦求的全局ID或在一定范围内(组件、程度、线程等)独一标识一个苦求的局部ID女同， 手脚区分不同苦求的事件的标识.基于苦求标识的方法凭证所使用ID的作用范围可进一步辩别为以下两类.
(1) 基于苦求全局ID的苦求事件索求方法.该类方法要求获取的跟踪数据中每个事件都有一个全局范围内独一标识一个苦求的ID， 苦求ID沟通的事件属于统一个苦求.使用此类方法进行苦求事件索求有两种阶梯: ①在跟踪数据获取时， 使用代码侵入的方法在产生跟踪数据时为一个苦求的整个跟踪数据表明其所属的苦求的全局ID; ②分散式软件系统产生的日记中存在随机全局独一标识一个苦求的ID， 且每条日记中都含有其所属的苦求的全局ID.文献[3， 14， 15， 18-20， 22-24， 27， 28， 48， 49]是通过侵入分散式软件系统不同软件堆栈的样式产生苦求的全局ID并随苦求在分散式软件系统中的实行进行ID的传播， 因此， 其整个的跟踪数据中都含有苦求的全局ID， 将含有统一苦求全局ID的整个事件聚会， 即可得回一个苦求的整个的事件的集结.而文献[8]则是期骗在Facebook应酬办事的系统日记中的全局ID将每一个日记事件辩别至一个苦求的事件集结中， 这需要开导阶段在分散式系统的源代码中添加对分散式跟踪的救济.
(2) 基于苦求局部ID的苦求事件索求方法.此类方法的基本方法如下:①基于组件/程度/线程/方法范围内的局部ID， 如苦求的局部ID、线程ID、日记中的变量等， 将一个苦求的整个事件凭证这些ID辩别为多个子集结; ②寻找随机关联两个不同集结的事件(即领域事件); ③合并凭证领域事件随机进行关联的两个事件子集结; ④叠加方法②与方法③， 直至无法寻找到新的领域事件.期望情况下， 经过这4步后， 凭证局部ID辩别的一个苦求的多个子集结不错合并为一个集结， 这个集结包含与此苦求相干的整个事件.如文献[46]采集分散式软件系统运行时操作系统产生的内核事件.其领先将整个内核事件按照线程ID辩别为多个Event Slice， 将与一个苦求相干的整个内核事件辩别到多个以线程ID为局部ID的子集结中.凭证对内核事件的分析， 寻找不错将两个不同线程ID代表的不同的Even Slice团结起来的Marker事件.当发现Marker事件之后， 凭证Marker事件将两个不同的Event Slice进行团结生成新的Event Slice并连续寻找Marker事件， 以关联更多的Event Slice.当无法连续找到Marker事件之后， 一个苦求的整个的内核事件就都被团结到了一个Event Slice中， 即Event Sketch.文献[47， 50]的苦求事件索求方法与文献[46]相似.文献[38]以为， 在日记中泛泛不存在一个苦求的全局ID， 但会存在多个与一个苦求相干的局部ID.该方法领先凭证蚁合苦求进口找到苦求运行的局部ID， 然后将含有此局部ID的Log entries都索求出来， 再从这些Log entries中寻找其他可能的局部ID以关联更多的Log entries， 如斯递归， 直至无法关联更多的Log entries.这些所筹商联起来的Log entries即索求到的苦求事件的集结.文献[37]中的Object ID、文献[51]中的UUID及文献[52]中的TaskID均手脚雷同的局部ID的机制来索求属于统一苦求的事件.
2.3.2 基于统计算计的苦求事件索求此类本事通过对圭表代码或者跟踪数据的统计分析发现与一个苦求相干的事件在时代或概率上的轨则， 凭证统计轨则将事件辩别到一个苦求当中.凭证所使用的分析方法的不同， 咱们不错将基于统计分析的苦求事件索求本事更具体地辩别为以下两类.
(1) 基于运行时数据分析的苦求事件索求.这类方法使用典型的机器学习方法， 在离线学习阶段从系统运行时产生的数据中挖掘统一苦求的不同类型事件的关联章程; 在在线应用阶段， 当出现的事件高慢学习到的关联章程时， 则将这些事件辩别到统一苦求的事件集结当中.文献[45]忽视了一种基于操作系统的内核事件数据算计苦求在系统中的实行旅途的方法PInfer.PInfer领先将内核事件分为两种:成对出现的Communication event和其他非成对出现的Rest event， 两个成对出现的Communication event组成一个Communication Event Pair.PInfer离线地从串行的内核事件中学习Communication Event Pair的检测模子与Communication Event Pair之间的迁徙模子(关联关系).针对前者， 忽视了一种基于图的Communication Event Pair检测算法.针对后者， 忽视了一种基于马尔可夫过程的计议Communication Event Pair之间的迁徙概率的方法.在在线应用阶段， 忽视了一种索求苦求事件并生成请务实行旅途的Graph-based Communication Path-generation算法， 该算法期骗在离线学习阶段学习到的Communication Event Pair检测模子和Communication Event Pair迁徙模子索求属于一个苦求的整个的事件.其过程如下:凭证线程将整个的内核事件进行关联， 包括rest event和communication event; 凭证Communication Event Pair检测模子发现整个的Communication Event Pair; 凭证Communication Event Pair之间的迁徙模子， 选拔迁徙概率最高的Communication Event Pair与其关联; 凭证Communication Event Pair以及Communication Event Pair之间的迁徙关系， 关联不同线程/节点上的内核事件， 从而将与一个苦求相干的整个事件索求出来.文献[36]忽视了一种期骗LSTM(long short-term memory)深度神经蚁合从分散式软件系统的日记中学习畸形检测模子， 并期骗学习到的畸形检测模子将属于不同苦求的日记事件区分的方法.
(2) 基于静态代码分析的苦求事件索求.这类方法从分散式软件系统源代码中发现属于统一苦求的日记模板集结并索求不错用于扶植区分苦求的关节变量， 在系统运行时， 将采集到的日记与挖掘到的日记模板进行匹配， 结合关联变量列表， 将属于统一苦求的整个日记索求出来.文献[40]索求一个苦求的整个事件的方法如下:①通过对Java字节码进行反编译获取圭表源码， 将源码中的日记打印语句进行体式转化， 索求出其中的变量与非变量部分， 并将其默示为log point(正则抒发式); ②判断每个包含log point的方法M对方法①所索求到的任何变量是否会进行修改， 如果某一个变量被M以及M所调用的方法修改， 则将其放入M可修改的变量集MV(modified variable set)中， 不然， 将此变量放入M的苦求标识符集结RIC(request identifier candidate set)中; ③通过静态代码分析寻找苦求的进口方法， 一个方法M是进口方法的圭臬是其调用者N的RIC比M的RIC数目要少.经过这3步之后， 就生成了一个请务实行过程所调用的整个方法以及波及的log point的集结和一个关节变量集结RIC.在系统运行时， 系统产生的日记与挖掘到的一个请务实行过程中所波及到的log point集结进行匹配， 并凭证挖掘到的关节变量集结RIC区分不同的苦求， 从而将与某一苦求相干的整个日记事件索求至该苦求的事件集结中.
2.3.3 基于因果关系的苦求事件索求此类本事依赖于事件之间的因果判断本事， 从苦求的第1个事件起， 凭证两个事件之间的因果关系不断地关联事件， 直至无法关联更多的事件， 这些互相干联的事件即属于统一个苦求的整个事件.
文献[1]忽视了基于NETCOM_ID与DATA_ID的判断分散式软件系统的系统调用事件之间的因果关系方法， 将禁受外部办事苦求的recv事件手脚苦求的第1个事件， 凭证NETCOM_ID和DATA_ID判断分散式软件系统其他系统调用互相之间的因果关系及与recv事件的因果关系， 将属于该苦求的整个因果相干的系统调用事件相干联， 从而索求出一个苦求的整个事件.文献[9]凭证算计的系统调用的事件之间的因果关系， 不断地串同与一个苦求相干的整个事件.文献[53]使用机器学习方法挖掘事件因果关系的章程， 并凭证挖掘到的章程判断事件之间的因果关系， 凭证事件之间的因果关系关联并索求出与一个苦求相干的整个事件.
2.3.4 不同苦求事件索求本事的对比分析表 2回归了不同苦求事件索求本事的优污点.基于苦求标识的苦求事件索求比拟于基于统计算计的苦求事件索求， 其准确性较高， 索求效用也较高， 且不需要大批的历史数据或源代码进行离线老师， 污点是依赖跟踪数据中的苦求ID， 或者需要在基于代码侵入获取跟踪数据时截至苦求ID的生成与传播， 或者需要在开导阶段向日记中添加此类ID.基于苦求全局ID的方法适用于分散式软件系统会自动地为每个苦求产生一个ID并随苦求的处理而对苦求的ID进行传播的情况; 基于苦求局部ID的方法适用于分散式软件系统对苦求在局部的处理过程中会产生一个局部的ID且不同的局部ID之间不错确立关联关系的情况.基于统计算计的苦求事件索求不要求跟踪数据中含有苦求的ID， 但其依赖于特定的假定， 如假定统一苦求的事件存在时代序列上的模式或者特定的关联章程.当该假定在某些分散式软件系统中不可随即， 则无法索求出属于统一苦求的整个事件， 且泛泛无法准确索求一个苦求的整个事件.基于运行时数据分析的方法适用于不存在苦求全局ID或者局部ID且对苦求事件索求的准确率要求不高的情况; 基于静态代码分析的方法适用于分散式软件系统的源代码可控且蚁合通讯较少的情况.基于因果关系的苦求事件索求方法， 其优点依赖于因果关系判断本事， 在存在大批并发苦求的分散式软件系统中， 需要判断整个苦求的纵情两个事件之间的因果关系， 其索求的效用会相对较低， 适用于对事件索求效用与准确率要求不高的情况.比拟于局部ID， 全局ID对跟踪数据获取本事的要求更高， 需要在侵入不同软件堆栈时产生并截至苦求的全局ID的传播; 或者在开导过程中， 添加救济分散式跟踪的代码， 截至苦求ID的生成与传播， 并在日记中添加苦求的全局ID.基于静态代码分析的劣势在于其无法关联统一苦求中通过蚁合交互产生的因果相干的事件， 且需要造访源代码， 但其关于不跨蚁合的苦求事件(专指日记事件)的索求准确性很高.不同的苦求事件索求本事也不错进行组合使用.
绿色成人快播网站
Table 2 Pros & cons of methods of distinguishing events from different service requests
表 2 不同苦求事件索求本事的优污点
2.4 因果关系判断
事件因果关系判断需要在得到一个苦求的事件集结或整个苦求的事件集结之后， 判断事件集结中整个事件之间的因果关系， 可进一步辩别为基于章程的事件因果关系判断和基于统计算计的事件因果关系判断， 前者基于跟踪数据中的父子事件ID、时代戳等数据， 期骗已知或东说念主为界说的章程判断事件之间的因果关系， 后者期骗统计分析方法， 从大批历史的苦求跟踪数据中算计事件之间的因果关系.
2.4.1 基于章程的因果关系判断此类本事通过跟踪数据中含有的表明事件因果关系的ID(父子事件ID)或期骗跟踪数据中的时代戳或者凭证事件是否依赖于统一数据的读写， 判定事件之间的因果关系， 可进一步辩别为以下3类.
(1) 基于父子事件ID的因果关系判断.这类因果关系判断本事的前提是在跟踪数据获取时摄取主动侵入的样式， 生成用于关联父事件和子事件的ID进行传播并写入跟踪数据中， 期骗在父事件中标识的子事件的ID或者在子事件中标识的父事件ID， 判定两个事件的因果关系(父事件为因， 子事件为果).如文献[15]在侵入分散式软件系统时， 在每种方法的进口与复返责罚别产生跟踪数据， 跟踪数据中包含对该方法进行调用的方法的MID， 凭证MID不错判断两个方法调用事件之间的因果关系.文献[1]通过DATA_ID机制判断蚁合音信发送与禁受事件的因果关系， DATA_ID沟通的一双蚁合事件， send事件是recv事件的因.文献[18]则在组件之间互相调用时， 记载面前组件调用的组件的ID， 从而判断组件调用事件之间的因果关系.文献[54， 55]雷同是通过父子事件ID来进行事件之间因果关系的判断.
(2) 基于时代戳的因果关系判断.此类方法在一个苦求的事件集结中凭证每个事件的时代戳判断事件之间的因果关系， 时代戳较小的事件是第1个时代戳大于其自身时代戳的事件的父事件， 即按照事件发生的时代挨次来决定事件之间的因果关系.凭证时代戳判定事件的因果关系的方法主要有两种:①只是使用时代戳的大小来判断整个事件的因果关系[49， 56]; ②使用时代戳的大小判断在一个节点或者线程内的整个事件的因果关系， 使用其他信息， 如领域事件[38， 51]、蚁合音信的发送/禁受[57]， 来判断不同节点上的事件之间的因果关系.文献[56]领先凭证Task ID或者reservation ID将整个的日记归类到以task/reservation ID为基本单元的文献中， 完成苦求事件索求过程.然后， 将日记事件转化为日记模板.终末， 绝对按照一个Task ID所代表的一个日记文献中的整个日记的时代戳大小对日记事件进行排序， 前一个事件是后一个事件的父事件， 并生成一个有向图来默示整个事件之间的因果关系.比拟于文献[56]， 文献[3]对时代戳的使用更为合理， 其仅在一个节点之内按照时代戳的大小判断事件的因果关系.文献[58]在一个组件的里面使用时代戳来判断事件的因果关系， 但不同节点上组件的时代戳的比较需要通过一双蚁合音信的发送和禁受事件来进行算计.
(3) 基于数据读写依赖的因果关系判断.这类方法是在音信队伍、音信中间件及分享内存中捏取统一音信的写入与读取， 进而判断统一音信的写入是否为读取事件的父事件.文献[59]忽视了一种检测基于音信中间件的分散式应用的组件/应用之间依赖关系的方法， 即判定统一音信的不同组件/应用的读/写之间的因果关系， 其责任旨趣是基于常见的音信中间件公约中的Message ID字段的剖析.在组件/应用向音信中间件写入音信和读取音信时刻别剖析音信中的Message ID字段， 从而判断音信中间件中统一音信的写入和读出事件之间的因果关系.文献[60]则忽视了一种分享内存情况下的特定内存区域的音信读写事件因果关系判断的方法.
2.4.2 基于统计算计的因果关系判断这类本事摄取统计方法从大批的历史跟踪数据或分散式软件系统的源代码中发现事件间因果关系的模式， 从而自动判定统一个苦求的两个事件的因果关系， 可进一步辩别为以下两类.
(1) 基于运行时数据分析的因果关系判断.此类方法将机器学习方法应用到大批的历史运行时数据中， 发现事件之间因果关系的模式， 从而在新的苦求中使用发现的模式判断苦求的整个事件之间的因果关系.文献[8]忽视了苦求事件因果关系判断方法Mystery Machine.期骗日记中含有的苦求的全局ID， 将与某一苦求相干的整个事件索求出来， 并将整个的事件以segment为单元进行组织.segment即〈task， start_event， end_event〉这么一个三元组.整个的segments之间都假定存在因果关系.Mystery Machine期骗大批同类型的办事苦求的历史数据， 对这些因果关系进行精简.在同类型办事的历史的跟踪数据中， 当发现使某一因果关系不可立的segment模式时， 删除两个segments之间的因果关系.不断叠加此过程， 直至凭证历史的同类型办事苦求的跟踪数据无法找到使适面前的任一因果关系不可立的模式.文献[61]摄取了与文献[8]基本沟通的方法， 但其运行的全邻接图是无向图， 因此， 凭证历史数据对无向边进行精简之后， 需要凭证V-Structure旨趣校服边的目的， 即因果关系.文献[53]忽视了一种期骗无监督机器学习方法凭证日记中的时代戳从历史日记中挖掘日记之间因果关系章程的方法， 并将挖掘出的事件之间的因果关系章程应用于到在线的苦求中， 判断事件之间的因果关系.基于运行时数据分析的因果关系判断方法与基于运行时数据分析的苦求事件索求方法在使用机器学习方法上并莫得本色的区别， 两者的区别在于其目的不同， 后者温和若何使用机器学习方法从运行时数据中学习事件属于统一苦求的模式; 前者温和若何使用机器学习方法从运行时数据中学习事件之间存在因果关系的模式.
(2) 基于静态代码分析.此类方法通过分析分散式软件系统的源代码， 算计日记打印点在一个苦求的实行过程中所出现的逻辑挨次， 这种逻辑挨次即在一个苦求中两条日记音信所出现的先后挨次(因果关系).文献[40]通过对Java字节码的反编译获取分散式软件系统的源代码， 进而从圭表源代码中索求日记的模板.其获取日记(模板)之间的逻辑挨次的方法分为两步:①在统一方法中， 凭证日记打印语句出现的先后挨次， 生成在统一方法中的日记模板之间的逻辑挨次; ②通过方法调用分析， 确立跨方法的统一请务实行旅途上的日记之间的逻辑挨次.领先寻找进口方法， 然后递归地寻找方法调用， 最终身成一棵方法调用树.跨方法的日记之间的逻辑挨次凭证方法调用树中节点之间的父子关系来进行判断.Caller方法输出终末一个日记音信是Callee方法输出的第1个日记音信的父事件.基于静态代码分析的因果关系判断方法与基于静态代码分析的苦求事件索求方法的区别在于， 后者通过静态代码分析的方法发当代码中的关节变量， 并将此类关节变量用作苦求的全局ID或局部ID用于苦求事件索求; 前者则通过静态代码分析的方法分析方法之间的调用关系， 并将方法之间的调用关系映射为运行时方法调用事件之间的因果关系.
2.4.3 不同因果关系判断本事的对比分析表 3回归了不同因果关系判断本事的优污点.基于章程的事件因果关系判断本事其效用更高， 不需要老师阶段， 且计议量少， 平直凭证章程即可判断事件之间的因果关系.而基于统计算计的事件因果关系判断方法的优点在于不需要在跟踪数据中存在父子事件ID， 多用于基于分散式软件系统的日记构建请务实行旅途的方法.基于父子事件ID来判断苦求当中的事件的因果关系是效用最高且最准确的方法， 但其前提是需要对分散式软件系统的软件堆栈的不同头绪进行代码侵入， 并在请务实行过程中传播父事件与子事件的ID， 以及两个ID之间的父子关系， 仅适用于每个事件中都存在其父事件或子事件ID的情况.基于时代戳的事件因果关系判断索求效用也比较高， 其主要劣势在于无法判断因多线程编程导致的并行与同步问题酿成的事件之间的多依赖关系， 即一个事件可能有多个父事件或者子事件， 而凭证时代戳的大小判断事件因果关系无法捏取到这种多依赖关系， 适用于不同节点之间的时钟相对同步且对因果关系判断的准确率要求较低的情况.基于数据读写依赖的方法仅适用于判断数据读取事件与数据写入事件之间的因果关系的情况.基于运行时数据分析的方法适用于对苦求事件索求的准确率要求不高的情况.基于静态代码分析的事件因果关系判断方法不受节点间时代不同步问题的影响， 但这种方法基本无法处理因蚁合通讯酿成的不同节点上的事件之间的因果关系， 适用于分散式软件系统源代码可控且蚁合通讯较少的情况.在一种分散式跟踪本事中可能同期会使用几种不同的因果关系判断方法来提高因果关系判断的准确性.如文献[1]使用时代戳判断统一线程内的事件的因果关系， 同期使用父子事件ID判断蚁合音信的发送与禁受事件的因果关系.
Table 3 Pros & cons of methods of determining causal relationships for events
表 3 不同因果关系判断本事的优污点
2.5 苦求旅途默示
请务实行旅途默示本事对苦求所包含的事件和事件之间的因果关系进行建模， 其目的在于最大化地保留事件的因果关系以得回对请务实行旅途更准确的描绘以及高效地撑持分散式软件系统的不同的运维任务.请务实行旅途默示本事按照默示模子的不同可进一步辩别为:(1)基于序列模子的请务实行旅途默示; (2)基于树模子的请务实行旅途默示; (3)基于有向图模子的请务实行旅途默示.
2.5.1 基于序列模子的请务实行旅途默示此类本事将苦求的实行过程建模为一个事件序列.分散式软件系统的苦求处理是高度并行的， 多线程、异步蚁合通讯等都使得序列模子无法准确形色如今分散式软件系统的苦求处理过程.因此， 选拔序列模子来对苦求的实行旅途进行建模大多出于两方面的洽商:(1)受限于跟踪数据， 无法构建除序列外的其他模子.如当跟踪数据中仅有时代戳信息可用于扶植判断事件之间的因果关系时， 泛泛会选拔序列模子; (2)运维任务相对浅易， 但对计议速率要求较高.如在苦求步履畸形检测过程中， 将请务实行旅途建模为序列， 饱和发现一些特定类型的畸形[22， 49， 51].也有议论责任采用有一定容错才略的模子来处理将包含大批并行的请务实行旅途建模为序列模子所导致的演叨， 这些方法大多摄取概率图模子来默示苦求的实行旅途， 但其本色依然是将一次请务实行产生的事件手脚一个序列.如文献[44]将请务实行旅途建模为序列， 但洽商到用序列默示并行处理苦求的问题， 从一个苦求的多个序列化的实行旅途中构建一个马尔可夫过程(Markov process)， 当纵情一次苦求的实行旅途(序列)在马尔可夫过程的图模子中存在一条迁徙旅途时， 以为请务实行旅途莫得出现畸形.
2.5.2 基于树模子的请务实行旅途默示此类本事将苦求的实行过程建模为一棵树.树的根节点是苦求的肇始节点， 代表的是苦求参加分散式软件系统所激发的第1事件， 每一个叶子节点都与其平直父节点存在因果关系(父节点为因， 子节点为果).天然树模子随机默示分散式软件系统中的并行处理， 但与多线程并行随同的时时是线程同步等操作， 如pthread_join等.因此， 摄取树模子默示并行处理的苦求， 或者因为跟踪本事无法拿获线程及程度的同步操作， 或者出于简化分散式软件系统的并行处理的需求， 不洽商因程度及线程同步导致的事件之间的因果关系.树模子比较常见的用途是确立一个苦求的完好的方法调用链[25， 26， 54， 55]， 或蚁合通讯的调用树(包括普通send/recv与RPC调用)[28， 35， 62， 63]， 文献[3， 16， 23， 33， 50]雷同使用树模子来默示请务实行旅途.
2.5.3 基于有向图模子的请务实行旅途默示此类本事将苦求的实行过程建模为一个图， 一般是指有向无环图(DAG).图中每个节点是一个事件， 而有向边是事件之间的因果关系， 一个事件可能会有多个先行者节点(父事件)和多个后继节点(子事件).图模子是在形色请务实行旅途时抒发才略最强的模子， 随机默示并行处理、线程同步等操作.文献[1， 64]等均摄取有向无环图模子对请务实行旅途进行默示.
2.5.4 不同请务实行旅途默示本事的对比分析表 4回归了不同请务实行旅途默示本事的优污点.总的来说， 序列模子泛泛无法有用地默示分散式软件系统中准确的请务实行旅途， 需要对其进行容错处理， 将其转化为图/概率图模子， 适用于不需要请务实行旅途精确描绘苦求处理过程且对请务实行旅途上的计议效用要求较高的情况.树模子具有抒发并行处理的才略， 但无法抒发因线程同步导致的一个事件含有多个父事件的情况， 适用于需要同期兼顾请务实行旅途精确描绘苦求处理过程的才略与计议效用的场景.而图模子具有最强的抒发才略， 但构建图模子对跟踪数据有较高的要求， 或者有大批的同类型的办事苦求的历史数据， 适用于对请务实行旅途上的计议效用要求不高的各式情况.
Table 4 Pros & cons of methods of modeling request execution paths
表 4 不同请务实行旅途默示本事的优污点
3 分散式跟踪本事应用议论
3.1 分散式跟踪本事应用概况
分散式跟踪本事已被应用到大批不同的经管任务中， 如文献[65-68]期骗分散式跟踪本事产生的请务实行旅途匡助运维与开导东说念主员领会分散式软件系统的结构、步履与状态， 文献[69]期骗分散式跟踪本事对云计议资源的使用进行紧密化地计价， 文献[70]期骗分散式跟踪本事跟踪系统中电力资源的突然， 文献[71]则期骗分散式跟踪本事跟踪阴私数据的清楚问题， 文献[48]忽视了一种以请务实步履单元的资源经管系统.表 5给出了连年来国表里工业界所忽视的分散式跟踪本事卓越应用领域.分散式跟踪本事产生的请务实行旅途随机精确地描绘分散式软件系统举座的实行逻辑， 因此对请务实行旅途进行存储、查询、可视化不错极地面便捷运维东说念主员对分散式软件系统中的请务实功绩况进行监控， 进而提高故障会诊的效用与准确率， 匡助运维东说念主员发现并优化请务实行过程中的性能问题.文献[64]提供了一种在请务实行旅途上进行相办事件查询和旅途抽象的谈话， 用于故障会诊.学术界也对请务实行旅途的可视化忽视了不同的方法[39， 42， 72].
Table 5 Application of distributed tracing technology
表 5 分散式跟踪本事的应用
但使用请务实行旅途对分散式软件系统中的苦求进行监控， 依然需要东说念主工凭证苦求的实功绩态或者成立阈值来判断请务实行是否出现故障与性能问题， 并在检测出故障后东说念主工进行故障的定位与根因分析， 在出现性能问题后东说念主工分析请务实行的性能瓶颈从而进行优化.关于限制浩瀚、结构复杂、不时更新的分散式软件系统， 这仍然是一项贫困的责任.因此， 若何基于请务实行旅途， 自动化地进行分散式软件系统的故障会诊、性能分析安靖成为议论热门.本文要点先容学术界在基于请务实行旅途的故障会诊与性能分析方面的相干议论责任.
3.2 基于请务实行旅途的故障会诊分散式软件系统由于复杂的结构和浩瀚的代码量， 不可幸免地存在软件劣势， 且时时部署在千千万万的假造/物理节点上， 运行环境至极复杂.分散式软件系统里面的劣势与外部的复杂环境导致分散式软件系统时时地发生故障.这些故障可能由资源竞争、树立演叨、软件劣势、硬件失效等原因导致， 在系统运行时则推崇为分散式软件系统中的办事请务实行过程出现畸形甚而实行失败.分散式软件系统中的故障会诊主要复兴3个问题:(1)分散式软件系统中是否出现故障， 即畸形检测问题; (2)故障出当今分散式软件系统的什么位置， 即故障定位问题; (3)分散式软件系统中出现故障的原因， 即故障根因会诊问题.
请务实行旅途精确描绘了分散式软件系统因处理苦求产生的一系列步履， 因此， 基于请务实行旅途， 不错检测出更细粒度的请务实行过程的畸形， 继而检测出使用传统的基于监控和基于日记的故障会诊方法检测不到的系统的故障.当系统发生故障时， 凭证请务实行旅途精确地定位故障的位置， 会诊故障的根因.基于请务实行旅途的故障会诊主要措置3个问题:(1)畸形检测， 检测分散式软件系统中的苦求是否正常实行; (2)故障定位， 在分散式软件系统发生故障之后， 找到引起故障的事件/日记/代码片断/组件等; (3)根因会诊， 对故障的根因进行评释.
在畸形检测方面， 文献[73]在文献[18]的基础上通过侵入JVM已毕了其分散式跟踪系统， 期骗分散式跟踪系统构建的请务实行旅途(组件之间的调用树)对整个的请务实行旅途构建一个概率高下文无关文法(probabilistic context free grammar).在步履畸形检测阶段， 计议待检测的请务实行旅途在面前概率高下文无关文法模子中生成的概率， 当概率小于某阈值时， 以为请务实行过程出现了步履畸形， 系统发生了故障.咱们在TPC-W WIPSo应用中通过东说念主工注入故障， 应用并对比了文献[73]忽视的基于概率高下文无关文法的模子检测旅途结构畸形和基于HTTP演叨代码检测系统故障两种方法， 进而发当今请务实行旅途中应用其模子检测系统故障的方法的准确率达到90%， 远远高于基于HTTP的演叨代码检测系统故障的准确率.文献[56]中请务实行旅途为日记事件的序列， 通过索求日记的模板， 将请务实行旅途转换成一个日记模板的有向图(message flow graph， 简称MFG).在步履畸形检测阶段， 摄取其所忽视的图的剪辑距离计议算法， 计议由待检测请务实行旅途构建的MFG与由正常请务实行旅途构建的MFG的相似度， 当相似度小于某阈值时， 以为待检测的请务实行旅途中存在步履畸形， 系统发生了故障.文献[51]从日记音信中构建苦求的实行旅途， 并对每一种办事苦求的正常的实行旅途构建一个自动机(automaton)， 在在线检测阶段， 将待检测的请务实行旅途输入构建的自动机检测请务实行旅途是否出现畸形.文献[43]与文献[51]雷同， 不外其从正常的请务实行旅途(日记模板序列)中构建一个有限状态自动机(finite state automaton)， 用于畸形检测.文献[74]忽视了一种基于贝叶斯方法从请务实行旅途中检测其中是否存在慢性故障的方法.
在故障定位方面， 文献[38]从分散式软件系统的日记中算计生成请务实行旅途， 将请务实行旅途默示为日记模板的序列， 然后期骗他们忽视的一种日记对王人算法， 对比存在故障的请务实行旅途和正常的请务实行旅途， 定位出导致故障的日记模板卓越在代码中的位置.文献[56]从日记中生成请务实行旅途的碎屑， 为每一个任务生成一个MFG(message flow graph)手脚苦求的实行旅途， 然后使用基于图剪辑距离的算法进行离群点(与其他任务的MFG不同的任务)分析， 并索求出离群点中独到的日记模板序列， 将故障定位至索求出的少许的日记模板中.而文献[75]则期骗从日记中算计出的正常的以日记模板为节点的请务实行旅途， 检测出待检测的苦求的实行旅途的畸形节点， 从而发现故障的日记模板， 并通过扫描圭表的源代码， 确立日记模板与日记打印语句之间的映射关系， 从而将故障定位至源代码中产生故障日记的日记打印语句.文献[18]则使用层级聚类算法UPGMA检测畸形的请务实行旅途， 并通过雅卡尔相似所有(Jaccard similarity coefficient)将故障定位至具体的组件.
在根因会诊方面， 文献[30]基于文献[31]忽视的分散式跟踪本事， 在分散式软件系统中进行大批的故障注入现实并采集故障下的请务实行旅途， 确立故障与请务实行旅途之间的关联关系.在发生故障时将待检测的请务实行旅途与数据库中的请务实行旅途进行相似度匹配， 选拔相似度最高的几个有故障的请务实行旅途， 进而对故障根因作念出会诊.
分散式跟踪本事已在故障会诊领域得到了大批应用， 分散式跟踪本事产生的请务实行旅途随机匡助运维东说念主员更准确地检测出分散式软件系统中的畸形步履[73]， 提高故障定位的粒度[38]， 并自动会诊故障的根因[30].基于请务实行旅途的畸形检测泛泛从正常的请务实行旅途中构建图模子(高下文无关文法、有限状态机等)， 将待检测的请务实行旅途输入构建的图模子中进行锤真金不怕火.基于请务实行旅途的故障定位在畸形检测方法的基础上， 将图上的每个卓越赋予一定的位置属性(如组件、日记打印代码等).面前， 基于请务实行旅途的根因会诊的相干议论责任未几， 主如若通过确立故障与请务实行旅途之间的关联关系， 当发现待检测的请务实行旅途与已知的存在故障的请务实行旅途相匹配时， 自动回报故障的根因.
飞极速在线 3.3 基于请务实行旅途的性能分析分散式软件系统的性能问题是连年来倍受温和的问题， 性能问题时时会影响用户的体验， 导致资源败坏与客户流失.关联词， 由于分散式软件系统时时分散在大批的节点上， 组件之间的交互比较复杂， 导致对分散式软件系统进行性能分析成为一个难题.传统的性能分析方法泛泛摄取几类资源的监控数据(如CPU、内存的期骗率、反映时代、浑沌量等)检测分散式软件系统的性能问题.关联词由于监控数据泛泛是以单个节点/程度/线程为中心， 无法精确地判断波及大批节点与程度的分散式软件系统的性能问题.
通过将分散式跟踪本事产生的请务实行旅途与相干的分散式系统的性能筹划相结合， 如反映延长、CPU突然等， 不错在分散式软件系统中进行精确的性能分析[76].基于请务实行旅途的性能分析主要需措置两个问题: (1)苦求反映延长畸形检测; (2)资源突然畸形检测.前者使用反映时代正常的苦求手脚参照， 基于这类苦求在正常实行情况下的反映延长， 细粒度地检测苦求的反映时代是否出现了不合乎预期反映时代的气象， 并在请务实行旅途中定位引起反映延长的具体位置; 后者结合请务实行旅途与分散式软件系统的资源突然信息(CPU/ Memory/Disk等)， 构建某类苦求在特定资源上的资源突然模式， 当该苦求的某类资源突然与所构建的资源突然模式不符时， 则以为该苦求出现了资源突然畸形， 并会诊畸形资源突然的原因.
在苦求反映延长畸形检测方面， 文献[15]忽视了一种基于请务实行旅途检测苦求反映延长畸形的方法.领先， 凭证苦求类型对整个的请务实行旅途进行聚类.基于假定:含有苦求反映延长畸形的一类苦求， 其反映延长的分散会比较分散， 文献[15]使用变异所有CV(coefficient of variation)来斟酌每一类苦求的反映延长分散的分散程度， 当CV大于某阈值时， 则以为此类苦求中出现了延长畸形.文献[13]使用KS-锤真金不怕火(Kolmogorov-Smirnov test)检测苦求的反映延长是否合乎正常的请务实行的反映延长的分散.文献[55]基于Dapper生成的请务实行旅途， 凭证每次RPC调用所耗时代与资源突然算计本次苦求的实行时代， 当苦求的实行时代与算计的请务实行时代的偏差进步一定阈值时， 检测出性能畸形并判断性能畸形是由请务实行结构变化还是子RPC性能畸形导致.文献[77]则忽视了一种将时代序列化的监控数据与苦求的事件序列相干联， 从而匡助运维东说念主员会诊性能故障根因的方法.文献[11， 27， 78， 79]雷同基于分散式跟踪产生的请务实行旅途， 确立苦求正常实行下的苦求反映延长分散的模子， 并凭证构建的模子进行苦求反映延长畸形检测.
在资源突然畸形检测方面， 文献[14]将请务实行旅途与每个节点上的资源突然通落后代相干联并进行可视化， 扶植运维东说念主员查找故障根因.文献[24]则不错监控每个苦求在实行过程中实时的资源突然， 通过可视化发现资源的畸形突然.
在分散式软件系统的性能分析领域， 请务实行旅途精确描绘分散式软件系统的实行逻辑的特色， 使得准确地分析分散式软件系统的性能故障与瓶颈成为可能.关于分散式软件系统， 面前的相干议论责任期骗请务实行旅途手脚框架， 将请务实行的时代与资源突然信息镶嵌请务实行旅途， 使用可视化或者统计锤真金不怕火方法来进行分散式软件系统的性能分析， 信托以前会有更多议论责任忽视结合请务实行旅途与时代和资源突然信息的性能分析方法.
4 分散式跟踪本事议论预计分散式跟踪本事是分散式软件系统率域一项要紧的本事， 不仅在学术界与工业界出现了大批的分散式跟踪本事议论责任与分散式跟踪系统， 也出现了大批的议论责任探索将分散式跟踪本事应用到不同的运维场景中， 如领会分散式软件系统的架构与步履[65]， 精确会诊分散式软件系统中的故障[73]， 检测分散式软件系统中的性能问题[76].通过本文对具体的分散式跟踪本事与系统的分析不错看出， 已有的分散式跟踪本事的议论责任东要聚会在以下两个方面:(1)系统日记及内核事件日记之间的因果关系算计问题， 相干议论责任忽视不同的算计方法判断系统日记之间以及内核事件日记之间的因果关系; (2)基于代码侵入的跟踪数据获取问题， 相干议论责任东要议论在不同头绪软件堆栈中若何成立跟踪点并假想苦求高下文的传播机制， 但在一些问题上的议论仍处于低级阶段， 需要议论者进一步的探索与议论， 主要包括:(1)数据读写依赖问题; (2)通用性问题; (3)评价问题.因此， 本节将从分散式跟踪本事中的数据读写依赖问题、通用性问题、评价问题这3个方面分析面前分散式跟踪本事的不及并探讨以前的议论目的.
4.1 分散式跟踪本事中的数据读写依赖问题跟着分散式软件系统的不断发展， 为提高分散式软件系统的性能与浑沌量， 缩小分散式软件系统的耦合度， 音信队伍尤其是音信中间件在大型分散式软件系统中得到了大批的应用， 典型的音信中间件如RabbitMQ、ActiveMQ、Kafka.在分散式软件系统中， 不同的组件将音信发送到音信中间件的音信队伍中， 其他的组件从音信中间件中禁受所订阅的音信并进行处理.音信队伍也不单是存在于音信中间件中， 许多分散式系统自身摄取了音信队伍来提高性能与浑沌量， 如在Hadoop的RPC通讯中， RPC客户端发送的音信领先会被RPC办事端置入音信队伍， 由Handler读取队伍中的RPC苦求并进行信得过的方法调用且将调用复返的驱逐置入另一个音信队伍中， 由Responser将RPC调用的驱逐复返给RPC客户端.因此， 在分散式软件系统中一个苦求的完好处理过程可能会屡次经过音信队伍.如果分散式跟踪本事无法准确拿获对统一音信的读写产生的事件之间的因果关系， 则分散式跟踪本事将会对一个苦求产生多个请务实行旅途碎屑， 从而无法描绘苦求在分散式软件系统中完好、准确的处理过程， 称其为数据读写依赖问题.跟着音信队伍在分散式软件系统中越来越粗糙的应用， 数据读写依赖问题使得分散式跟踪本事面对着新的挑战.
数据读写依赖问题还是引起了议论者的温和， Chanda[60]等东说念主忽视了一种判断对分享的内存区域进行读写的事件之间因果关系的判断方法， Zhang[80]等东说念主在挪动平台中忽视了凭证对统一事件的读写判定事件之间因果关系判断的方法， Wu[59]等东说念主则基于对辞退一定圭臬的音信中间件的音信的剖析， 索求每个音信读取与写入事件中的音信ID， 进而判断统一音信的读写事件的因果关系.但已有的议论责任仅能在特定应用场景中判断特定类型的音信读写之间的因果关系， 分散式跟踪本事中面对的数据读写依赖问题并莫得得到很好的措置.若何处理分散式软件系统中复杂的数据读写依赖问题， 进而生成完好、准确的请务实行旅途， 是分散式跟踪本事所面对的一个要紧的问题， 也将是分散式跟踪本事的要紧议论目的之一.
4.2 分散式跟踪本事的通用性问题面前， 大批的分散式跟踪本事仅能跟踪特定分散式软件系统中的办事苦求[3， 81]， 或者处理基于特定运行时环境[18， 19， 22， 23]、特定系统框架[63， 68]及特定企业大众邻接库[9， 24]的分散式软件系统.而跟着开源软件的发展及微办事架构的兴起， 分散式软件系统的结构变得愈加复杂， 一个分散式软件系统可能会由多个不同团队使用不同谈话开导的不同的办事与组件组成， 导致对一个苦求在分散式软件系统的跟踪可能需要多个不同分散式跟踪本事的共同配合才略完好跟踪苦求的处理过程[24]， 但不同分散式跟踪本事产生的请务实行旅途在粒度、数据结构、因果关系、旅途默示方面都有巨大的不同， 给分散式跟踪本事的应用带来了巨大的挑战.
针对通用型的分散式跟踪系统， 有的议论者从系统日记脱手[8， 51]， 从系统日记中使用统计方法构建苦求的实行旅途; 有的议论者从操作系统层级期骗分散式软件系统的系统调用[1]或者产生的内核事件[46]忽视分散式跟踪本事.从系统日记中算计请务实行旅途面对着苦求旅途的准确性不高的问题， 而从操作系统层级构建分散式跟踪系统则面对着空匮表层应用信息、请务实行旅途难以领会的问题.若何结合两类提高分散式跟踪本事通用性的方法， 忽视了一种通用的分散式跟踪本事将是以前的议论趋势之一.
针对不同分散式跟踪本事产生的实行旅途的粒度、数据结构、因果关系、旅途默示方面的不兼容的问题， Alawneh[82]倡议对其进行圭臬化， 而开源的分散式跟踪系统Zipkin[25]与Opentracing[26]则基于Dapper忽视了各自的数据模子， 对事件类型、因果关系与请务实行旅途忽视了表率.但面前的分散式跟踪领域仍枯竭一种通用的数据模子， 随机适用于不同粒度、欠亨场景下的分散式跟踪本事.一个通用的数据模子随机提高不同分散式跟踪本事之间的兼容性， 且随机加快分散式软件系统中基于请务实行旅途的故障会诊、性能分析、系统率悟等各项运维任务的算法的忽视， 从而施展分散式跟踪本事的价值.
4.3 分散式跟踪本事的评价问题由于面前分散式跟踪本事的评价筹划不够完善， 相干议论责任评价分散式跟踪本当事人要从该本事所引入的系统性能的支拨[9]以及基于请务实行旅途的运维任务， 还是障会诊[1]的效果等方面来进行， 无法完好地评价一个分散式跟踪本事， 制约了分散式跟踪本事的发展.基于对相干议论责任的分析与回归， 分散式跟踪本事自身的评价筹划应该包括以下几个方面.
(1) 支拨.分散式跟踪本事所引入的支拨有3个方面:①将分散式跟踪本事应用于分散式软件系统后， 分散式软件系统中苦求反映时代的加多; ②将分散式跟踪本事应用于分散式软件系统后， 分散式软件系统的浑沌量(泛泛是指分散式软件系统所能并发处理的苦求的数目)的缩小; ③为已毕分散式跟踪， 所需要的修改分散式软件系统的代码的责任量.
(2) 通用性.分散式跟踪系统的通用性代表了分散式跟踪本事高慢不同类型、不同架构、不同谈话的分散式软件系统的跟踪要求的才略.
(3) 准确性.准确性是指分散式跟踪本事产生的苦求旅途中事件之间的正确因果关系占整个拿获的事件之间因果关系的百分比.
(4) 完好性.完好性形色了分散式跟踪本事产生的请务实行旅途完好描绘苦求的端到端处理过程的才略.
相干的议论责任对若何评价苦求反映时代支拨[19]、系统浑沌量支拨[9]以及代码修改的支拨[20]提供了可量化的评价方法， 但若何对分散式跟踪本事的通用性、准确性与完好性进行评价则枯竭相干的议论责任与圭臬.文献[31]天然对其分散式跟踪本事的准确性与完好性进行了评价， 但其评价方法依赖于巨匠所进行的东说念主工判断， 无法应用到其他分散式跟踪本事的评价中.因此， 一个用于评价分散式跟踪本事的基准(benchmark)系统以及在相应基准系统上对分散式跟踪本事的支拨、通用性、准确性及完好性进行评价的筹划体系关于促进分散式跟踪本事的发展是必要的.相应的议论责任也会对分散式跟踪本事的完善与应用产生积极的影响.
5 扫尾语分散式跟踪本事是精确描绘分散式软件系统的步履与状态的要紧技巧， 对高慢分散式软件系统中的故障检测、性能调优、系统率悟、资源审计等一系列运维任务有着要紧的意旨， 其议论受到了工业界和学术界的粗糙温和.但面前分散式跟踪本事仍面对着新的挑战， 如无法准确地判断因数据读写依赖导致的事件之间的因果关系， 分散式跟踪本事的通用性差， 空匮有用的对分散式跟踪本事的评价筹划等， 这些都需要进一步的议论.
本文从分散式跟踪本事的基本见地开赴， 忽视了分散式跟踪本事的议论框架， 并在该框架下详备地分析并回归了已有的分散式跟踪本事的议论责任.通过整理回归已有的分散式跟踪本事卓越应用的相干责任， 进一步分析了分散式跟踪本事面前所面对的问题， 并对以前的议论目的进行了预计， 为相干议论东说念主员开展下一步议论责任提供了一些想路.
致谢 在此女同， 咱们向对本文责任给以救济和建议的同业默示诚意的感谢.
