Dapper,大规模分布式系统的跟踪系统

所需积分/C币:16 2015-07-03 01:14:34 1.09MB PDF
收藏 收藏 3
举报

Dapper,大规模分布式系统的跟踪系统
2. Dapper的分布式跟踪 (user) Reply Request A(Frontend) Ipc B( Middle Tier)C D(Backend)E 图1:这个路径由用户的Ⅹ请求发起,穿过一个简单的服务系统。用字母标识的节点代表分布式系 统中的不同处理过程 分布式服务的跟踪系统需要记录在一次特定的请求后系统中完成的所有工作的信息。举个例子,图 1展现的是一个和5台服务器相关的一个服务,包括:前端(A),两个中间层(B和C),以及两个 后端(D和E)。当一个用户(这个用例的发起人)发起一个请求时,首先到达前端,然后发送两个 RPC到服务器B和C。B会马上做出反应,但是C需要和后端的D和E交互之后再返还给A,由A 来响应最初的请求。对丁这样一个请求,简单实用的分布式跟踪的实现,就是为服务器上每一次你 发送和接收动作来收集跟踪标识符( message identifiers和时间戳( timestamped events)a 为了将所有记录条目与一个给定的发起者(例如,图1中的 Request)关联上并记录所有信息,现 在有两种解决方案,黑盒( black-box)和基于标注( annotation- based)的监控方案。黑盒方案[1,15,2] 假定需要跟踪的除了上述信息之外没有额外的信息,这样使用统计回归技术来推断两者之间的关系。 基丁标注的方案3,12,9,16]依赖丁应用程序或中间件明确地标记一个全局ID,从而连接每一条记 录和发起者的请求。虽然黑盒方案比标注方案更轻便,他们需要更多的数据,以获得足够的精度, 因为他们依赖于统计推论。基于标注的方案最主要的缺点是,很明显,需要代码植入。在我们的生 环境中,因为所有的应用程序都使用相冋的线程模型,控制流和RPC系统,我们发现,可以把代 码植入限制在一个很小的通用组件库中,从而实现了监测系统的应用对开发人员是有效地透明。 我们倾向于认为, Dapper的跟踪架构像是内嵌在RPC调用的树形结构。然而,我们的核心数据模 型不只局限于我们的特定的RPC框架,我们还能跟踪其他行为,例如Gmai的SMTP会话,外界的 HTP请求,和外部对Sα服务器的査询等。从形式上看,我们的 Dapper跟踪模型使用的树形结构, Span以及 Annotation。 21跟踪树和span 在 Dapper跟踪树结构中,树节点是整个构的基本单元,而每·个节点又是对span的引用。节点 之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简单的代表span 的开始和结束时间,他们在整个树形结构中却是相对独立的,任何RPC相关的时间数据、零个或多 个特定应用程序的 Annotation的相关内容会在23节中讨论。 Backend DoSomething id: 3 图2:5个span在 Dapper跟踪树种短暂的关联关系 在图2中说明了span在一个大的跟踪过程中是什么样的。 Dapper记录了span名称,以及每个span 的1D和父1D,以重建在一次追踪过程中不同span之间的关系。如果一个span没有父D被称为root span。所有span都挂在一个特定的跟踪上,也共用一个跟踪id(在图中未示出)。所有这些用全 局唯一的64位整数标示。在一个典型的 Dapper跟踪中,我们希望为每一个RPC对应到一个单一的 span上,而且每一个额外的组件层都对应一个跟踪树型结构的层级。 pan name ="Helper. Call trace id= 100 span id =5 span parent id =3 ( time) Annotations (Client)<Start> Client Send Client Recv <End> (Server) Server Recv Server Send 图3:在图2中所小的一个单独的span的细节图 图3给出了一个更详细的典型的 Dapper跟踪span的记录点的视图。在图2中这种某个span表述 了两个“ Helper. Call"的RPC(分别为 server端和 client端)。span的开始吋间和结束吋间,以及任何RPC 的时间信息都通过 Dapper在RPC组件库的植入记录下来。如果应用稈序开发者选择在跟踪中增加 他们自己的注释(如图中“foo"的注释)(业务数据),这些信息也会和其他span信息一样记录下来。 记住,任何一个span可以包含来自不同的主机信息,这些也要记录卜来。事实上,每一个 RPC span 可以包含客户端和服务器两个过程的注释,使得链接两个主机的span会成为模型巾所说的span。山 于客户端和服务器上的吋间戳来自不同的主机,我们必须考虑到吋间偏差。在我们的分析⊥具,我 们利用了这个事实:RPC客户端发送一个请求之后,服务器端才能接收到,对于响应也是一样的(服 务器先响应,然后客户端才能接收到这个响应)。这样一来,服务器端的RPC就有一个时间戳的 个上限和下限。 22植入点 Dapper可以以对应用丌发者近乎零浸入的成本对分布式控制路径进行跟踪,几乎完全依赖于基于少 量通用组件库的改造。如下: 一个线程在处理跟踪控制珞径的过程中, Dapper把这次跟踪的上下文的在 Threadlocal中 进行存储。追踪上卜文是一个小而且容易复制的容器,其中承载了scan的属性比如跟踪ID 和 span ID 当计算过程是延迟调用的或是异步的,大多数 Google开发者通过线程池或其他执行器,使 用一^通用的控制流库来回调。 Dapper确保所有这样的回调可以存储这次跟踪的上卜文, 而当回调函数被触发时,这次跟琮的上下文会与适当的线程关联上。在这种方式下, Dapper 可以使用 trace d和 span ID米辅助构建异步调用的路径。 几乎所有的 Google的进程间通信是建立在一个用C++和Java开发的RPC框架上。我们把跟 踪植入该框架来定义RPC中所有的 spano span的1D和跟踪的D会从客户端发送到服务端。 像那样的基于RPC的系统被广泛使用在 Google中,这是亠个重要的植入点。当那些非RPC 通信框架发展成熟并找到了自己的用户群之后,我们会计划对RPC通信框架进行植入。 υ apper的跟踪数据是独立于语言的,很多在生产环境中的跟踪结合了用C++和Java写的进程的数据。 在3.2节中,我们讨论应用程序的透明度时我们会把这些理论的是如何实践的进行讨论。 2.3 Annotation const string& request=·冫 if (HitCache() TRACEPRINTF (cache hit for s,request cstr() else TRACEPRINTF("cache miss for s", request,cstr()i /7 Java Tracer t =Tracer getCurrent Tracer()i string request if (hitCache() t record("cache hit for "t request)i else t record( "cache miss for request) 上:述植入点足够推导出复杂的分布式系统的跟踪细节,使得 Dapper的核心功能在不改动 Google应 用的情况下可用。然而, Dapper还允许应用程序开发人员在 Dapper跟踪的过程中添加额外的信息, 以监控史高级别的系统行为,或帮助调试问题。我们允许用户通过一个简单的AP定义带时间翟的 Annotation,核心的示例代码入图4所示,这些 Annotation可以添加任意内容。为了保护 Dapper的 用户意外的过分热衷于日志的记录,每一个跟踪span有一个可配置的总 Annotation量的上限。但 是,应用程序级的 Annotation是不能替代用于表示span结构的信息和记录着RPC相关的信息。 除了简单的文本 Annotation, Dapper也支持的 key-value映射的 Annotation,提供给开发人员更强 的跟踪能力,如持续的计数器,二进制消息记求和在一个进程上跑着的任意的用户数据。键值对的 Annotation方式用来在分布式追踪的上下文中定义某个特定应用程序的相关类型。 24采样率 低损耗的是 Dapper的一个关键的设计目标,因为如果这个工具价值未被证实伯又对性能有景响的 话,你可以理解服务运营人员为什么不愿意部署它。况且,我们想让开发人员使用 Annotation的 AP,而不用担心额外的开销。我们还发现,某些类型的web服务对植入带来的性能损耗确实非常敏 感。因此,除了把 Dapper的收集工作对基本组件的性能损耗限制的尽可能小之外,我们还有进 步控制损耗的办法,那就是遇到大量请求吋只记录其中的一小部分。我们将在44节中讨论跟踪的 采样率方案的更多细节。 <instrumented binaries> log file file file production host machines (read) r daemon re日 Collectors (write) trace id span 12 span 23 span 34 span 45 56 123456 <data> <data> 246802|<data> <datas 357913 <data> (Central Bigtable repository for trace data 图5: Dapper收集管道的总览 25跟踪的收集 Dapper的跟踪记录和收集管道的过程分为三个阶段(参见图5)。首先,span数据写入(1)本地日 志文件中。然后 Dapper的守护进程和收集组件把这些数据从生产环境的主机中拉出米(2),最终 写到(3) Dapper的 Bigtable仓库中。一次跟踪被设计成 Bigtable中的一行,每一列相当于一个spar Bigtable的支持稀疏表格布局正适合这种情况,因为每一次跟踪可以有任意多个span。跟踪数据收集 的平均延迟-即从应用中的二进制数据传输到中央仓库( Bigtable)所花费的时间-不多于15秒。The 98th percentile latency is itself bimodal over time; approximately 75% of the time, 98th percentile collection latency is less than two minutes but the other approximately 25% of the time it can grow to be many hours (统计学相关,不会翻详) Dapper还提供了一个A門来简化访问我们仓库中的跟踪数据。 Google的开发人员用这个APl,以构 建通用和特定应用程序的分析工具。第5.1节包含更多如何使用它的信息。 25.1带外数据跟踪收集 tip1:带外数据:传输层协议使用带外数据(out- of-band,OOB)来发送一些重要的数据,如果通信一方有 重要的数需要通知对方时,协议能够将这些数据快速地发送到对方。为∫发送这些数据,协议一般 不使用与普通数据相同的通道而是使用另外的通道。 tip2:这里指的in-band策略是把跟踪数据随着调用链进行传送,out-of-band是通过其他的链路进行 跟踪数据的收集, Dapper的写日志然后进行日志采集的方式就属于 out-of-band策略 υ apper系统请求树树自身进行跟踪记汞和收集带外数据。这样做是为两个不相关的原因。首先,带 内收集方案-这里跟悰数据会以RPC响应头的形式被返回-公影响应用程序网络动态。在 Google里 的许多规模较大的系统中,一次跟踪成千上万的span)不少见。然而,RPC回应大小-甚至是接近 大型分布式的跟踪的棖节点的这种情况下-仍然是比较小的:通常小于10K。在这种情况下,带内 Dapper的跟踪数据会让应用程序数据和倾向于使用后续分析结果的数据量相形见绌。其次,带内收 集方案假定所有的RPC是亢美嵌套的。我们发现,在所有的后端的系统返回的最终结果之前,有许 多中闩件会把结果返回给他们的调用者。带内收集系统是无法解释这种非嵌套的分布式执行模式的 26安全和隐私考虑 记录·定量的RPC有效负载信息将丰富 Dapper的跟踪能力,因为分析L具能够在有效载荷数据(方 法传递的参数)中找到相关的样例,这些样例可以解释被监控系统的为何表现异常。然而,有些情 况下,有效载荷数据可能包含的一些不应该透露给未经授权用户(包括正在 debug的工程师)的内部 信息。 由于安全和隐私问题是不可忽略的, dapper中的虽然存储RPC方法的名称,但在这个时候不记录任 何有效载荷数据。相反,应用程序级别的 Annotation提供了一个方便的可选机制:应用程序开发人 员可以在span中选择关联那些为以后分析提供价值的数据 Dapper还提供了一些安仝上的便利,是它的设计者事先没有预料到的。通过跟踪公开的安全协议参 数, Dapper可以通过相应级别的认证或加密,来监视应用程序是否满足安全策略。例如。 Dapper还 可以提供信息,以基于策略的的隔离系统按预期执行,例如支撑敏感数据的应用程序不与未经授权 的系统组件进行了交互。这样的测算提供了比派码审核更强大的保障。 3 Dapper部署状况 Dapper作为我们生产环境下的跟踪系统已经超过两年。在本节中,我们会汇报系统状态,把重点放 在 Dapper如何满足了我们的目标一一无处不在的部署和应用级的透明。 31 Dapper运行库 也许 Dapper代码中中最关键的部分,就是对基础RPC、线程控制和流程控制的组件库的植入,其 中包括span的创建,采样率的设置,以及把日志写入本地磁檻。除了做到轻量级,植入的代码更 需要稳定和健壮,因为它与海量的应用对接,维护和bug修复变得困难ε植入的核心代码是由未超 过1000行的C+和不超过800行Java代码组成。为了支持键值对的 Annotation还添加了额外的500 行代码 32生产环境下的涵盖面 Dapper的渗透可以总结为两个方面:一方面是可以创建 Dapper跟踪的过程(与 Dapper植入的组件 库相关),和生产环境下的服务器上在运行 Dapper跟踪收集守护进程。 Dapper的守护进程的分布相 当于我们服务器的简单的拓扑图,它存在于Goge几乎所有的服务器上。这很难确定精确的 Dapper- ready进程部分,因为过程即便不产生跟踪信息、 Dapper也是无从知哓的。尽管如此,考虑到无处不 在 Dapper组件的植入库,我们估计几乎每一个 Google的牛产进稈都是支持跟踪的。 在某些情况下 Dapper的是不能正确的跟踪控制路径的。这些通常源于使用非标准的控制流,或是 Dapper的错误的把路径关联归到不相关的事件上。 Dapper提供∫一个简单的库来帮助开发者手动 控制跟踪传播作为一种变通方法。目前有40个C++应用程序和33个Java应用程序需要一些于动控 制的追踪传播,不过这只是上千个的跟踪中的一小音分。也有非常小的一部分程序使用的非组件性 质的通信库(比如原生的 TCP Socket或 SOAP RPC),因此不能直接支持 Dapper的跟踪。但是这些应 用可以单独接入到 Dapper中,如果需要的话。 考虑到生产环境的安全, Dapper的跟踪也可以关闭。事实上,它在部署的早起就是默认关闭的,直 到我们对 Dapper的稳定性和低损耗有了足够的信心之后才把它开启, Dapper的团队偶尔会执行审 查寻找跟踪配置的变化,来看看那些服务关闭了 Dapper的跟踪。但这和情况不多见,而且通常是源 于对监控对性能消耗的担忧。绎过了对实际性能消耗的进一步调査和测量,所有这些关闭 Dapper 跟踪都已经恢复开启了,不过这些已经不重要了。 33跟踪 Annotation的使用 程序员倾向于使用特定应用程序的 Annotation,无论是作为一和分布式调试日志文件,还是通过 些应用程序特定的功能对跟踪进行分类。例如,所有的 Bigtable的请求会把被访问的表名也记录到 Annotation中。日前,70%的 Dapper span和90%的所有 Dapper跟踪都至少有一个特殊应用的 Annotation。 41个Java应用和68个C+应用中都添加自定义的 Annotation为了更好地理解应用程序中的span在 他们的服务中的行为。值得注意的是,迄今为止我们的Java开发者比C++开发者更多的在每一个跟 踪span上采用 Annotation的AP。这可能是因为我们的Java应用的作用域往往是更接近最终用户 (C+偏底层);这些类型的应用程序经常处理更广泛的请求组合,因此具有比较复杂的控制路径。 4.处理跟踪损耗 跟踪系统的成木由两部分组成:1.正在被监控的系统在生成追踪和牧集追踪数据的消耗导致系统性 能下降,2。需要使用一部分资源来冇储和分析跟踪数据。虽然你可以说一个有价值的组件植入跟 踪带来一部分性能损耗是值得的,我们相信如果基本损袛能达到可以忽略的程度,那么对跟踪系统 最初的推广会有极大的帮助。 在本节中,我们会展现一下三个方面: Dapper组件操作的消耗,跟踪收集的消耗,以及 Dapper对生 产环境负载的影响。我们还介绍了 Dapper可调节的采样率机制如何帮我们处理低损耗和跟踪代表性 之间的平衡和取舍 41生成跟踪的损耗 生成跟踪的开销是 Dapper性能影响中最关键的部分,因为收集和分析可以更谷易在紧急情况下被 关闭。 Dapper运行库中最重要的跟踪生成消耗在于创建和销毁span和 annotation,并记录到本地 磁盘供后续的收集。根span的创建和销毁需要损耗平均204纳秒的时间,而同样的操作在其他span 上需要消耗176纳秒。时间上的差别主要在于需要在跟span上给这次跟踪分配一个全局唯一的1D 如果一个span没有被采样的话,那么这个额外的span下创建 annotation的成本几乎可以忽略不 计,他由在 Dapper运行期对 Threadlocal査找操作构成,这平均只消耗9纳秒。如果这个span被计 入采样的话,会用一个用字符串进行标注一在图4中有展现-平均需要消耗40纳秒。这些数据都是 在2.2GHz的x86服务器上采集的。 在 Dapper运行期写入到木地憾檻是最昂贵的操作,但是他们的可见损耗大大减少,因为写入日志文 件和操作相对于被跟踪的应用系统来说都是异步旳。不过,日志写入的操作如果在大流量的情况, 尤其是每一个请求都被跟踪的情况下就会变得可以察觉到。我们记录了在4.3节展示了一次Web搜 索的负载下的性能消耗。 42跟踪收集的消耗 读出眼踪薮据也会对正在被监控的负载产生干扰。表1展示的是最坏情况卜, Dapper收集日志的 守护进稈在高于实际情况的负载基准下进行测试时的cpu使用率。在牛产环境下,跟踪数据处理中, 这个守护进程从米没有超过03%的单核cpu使用率,而且只有很少量的内存使用(以及堆碎片的噪 音)。我们还限制」 Dapper守护进程为内核 scheduler最低的优先级,以防在一台高负载的服务尜上 发生cpu竞争。 Dapper也是一个带宽資源的轻量缴的消费者,每一个span在我们的仓库中传输只占用了平均426的 byte。作为网络行为中的极小部分, Dapper的数据收集在 Google的生产环境中的只占用了0.01%的 网络资源。 Process count Data Rate Daemon CPU Usage (per host)( per process) (single CPU core 25 10K/sec 0.125% 10 200K/sec 0.267% 50 2K/sec 0.130 表1: Dapper守护进程在负载测试吋的cpU资源使用率 43在生产环境下对负载的影响 每个请求都会利用到大量的服务器的吞吐量的线上服务,这是对有效跟踪最主要的需求之 种情况需要生成大量的跟踪薮据,并且他们对性能的影响是最敏感的。在表2中我们用集群卜的网 络搜索服务作为例子,我们通过调整采样率,来衡量 Dapper在延迟和吞吐量方面对性能的影响。 Sampling Avg Latency Avg. Throughput frequency(%c change (0 change) 1/1 16.3 l/2 9.40% 0.73% 1/4 6.38 0.30% 1/8 12 0.23 1/16 2.12% 0.08 1/1024 0.20% 0.06 表2:刚终搜索集群中,对不同采样率对网络延迟和吞吐的影响。廷迟和吞吐的实验误差分别是2.5% 和015%。 我们看到,虽然对吞吐量的影响不是很明显,但为了避免明显的延迟,跟琮的样还是必要的。然 而,延迟和吞吐量的带来的损失在把采样率调整到小于1/16之后就仝部在实验误差范围内。在灾 饯中,我们发现即便采样率调整到1/1024仍然是有足够量的跟踪数据的用来跟踪大量的服务。保持 Dapper的性能损耗基线在一个非常低的水平是很重要的,因为它为那些应用提供了一个宽松的坏 境使用完整的 Annotation apl而无惧性能损尖。使用较低的采样率还有额外的好处,可以让持久化到 硬盘中的跟踪数据在垃圾回收机制处理之前保留更长的时间,这样为 Dapper的收集组件给了更多 的灵活性。 44可变采样 任何给定进程的 Dapper的消耗和每个进程单位时间的跟踪的采样率成正比。 Dapper的第一个生产 版本在Goge内部的所有进稈上使用统一的采样率,为1/1024。这个简单的方案是对我们的高吞 吐量的线上服务米说是非常有用,因为那些感兴趣的事件(在大昋吐量的情况下)仍然很有可能经常出 现,并且通常足以被捕捉到 然而,在较低的采样率和较低的传输负载下可能会导致错过重要事件,而想用较高的采样率就需要 能接受的性能损耗。对丁这样的系统的解决方案就是覆盖默认的采样率,这需要手动干预的,这种 情况是我们试图避免在 dapper中出现的。 我们在部署可变采样的过程中,参数化配置采样率时,不是使用一个统一的采样方案,而是使用 个采样期望率来标识单位时间内米样的追踪。这样一来,低流量低负载自动提高釆样率,而在髙流 量高负载的情况下会降低采样率,使损耗一直保持在控制之下。实际使用的采样家会随着跟踪本身 记录下来,这有利于从 Dapper的跟踪数据中准确的分析 45应对积极采样( Coping with aggressive sampling) 新的 Dapper用户往往觉得低采样率-在高吞吐量的服务下经常低至0.01%-将会不利于他们的分 析。我们在 Google的经验使我们相信,对于高吞吐量服务,积极采样( aggressive sampling)并不妨碍 最重要的分析。如果一个显着的操作在系统中出现一次,他就会出现上千次。低昋吐量的服务一也许 是每秒请求几十次,而不是几十万-可以负担得起跟琮每一个请求,这是促使我们下决心使用自适 应采样率的原因。 46在收集过程中额外的采样 上述采样机制被设计为尽量减少与 Dapper运行库协作的应用程序中明显的性能损耗。 Dapper的团 队还需要控制写入中央资料厍的数据的总规模,因此为达到这个目的,我们结合了二级采样。 目前我们的生产集群每天产生超过1TB的采样跟踪数据。 Dapper的用户希望生产环境下的进程的 跟踪数据从被记录之后能保存至少两周的时间。逐渐增长的追踪数据的密度必须和 Dapper中央仓 库所消耗的服务器及硬盘存储进行权衡。对请求的高采样率还使得 Dapper收集器接近写入吞吐量的 上限 为了维持物质资源的需求和渐增的 Bigtable的昋吐之间的灵活性,我们在收集系统自身上増加了额 外的采样率的支持我们充分利用所有span都米自一个特定的跟踪并分享同一个跟踪D这个事实, 虽然这些span有可能横跨了数千个主札。对于在收集系统中的每一个span,我们用hash算法把跟 踪D转成一个标量Z,这里0<=Z<=1。如果Z比我们收集系统中的系数低的话,我们就保留这个 span信息,并写入到 Bigtable中。反之,我们就抛弃他。通过在采样决策中的跟踪ID,我们要么保 存、要么抛弃整个跟踪,而仆是单独欠理跟踪内的span。我们发现,有∫这个额外的配置参数使管 理我们的收集管道变得简单多了,因为我们可以很容易地在配置文件中调整我们的全局写入率这个 参数。 如果整ˆ跟踪过程和收集系统只使用一个采杵率参欻確实会简单一些,但是这就不能应对快速调整 在所有部署的节点上的运行期采样率配置的这个要求。我们选择了运行期采样率,这样就可以优雅 的去掉我们尢法与入到仓库中的多佘数据,我们还可以通过调节收集系统中的二级采样率系数来调 整这个运行期采样率。 Dapper的管道维护变得更容易,因为我们就可以通过修改我们的二级采样率 的配置,直接增加或减少我们的全局覆盖率和写入速度 5.通用的 Dapper工具 几年前,当 Dapper还只是个原型的时候,它只能在 Dapper开发者耐心的支持下使用。从那时起, 我们逐渐迭代的建立了收集组件,编程接口,和基于Web的交互式用户界面,帮助 Dapper的用户 独立解决自己的问题。在本节中,我们会总结一下哪些的方法有用,哪些用处不大,我们还提供关 于这些通用的分析工具的基本的使用信息 5.1 Dapper depot APl Dapper的“ Depot AP"或称作DAP,提供在 Dapper的区域仓库中对分布式跟踪数据一个直接访问。 DAP和 Dapper跟踪仓库被设计成串联的,而且DAP意味着对 Dapper仓库中的元数据暴露一个十 净和直观的的接口。我们使用了以下推荐的三种方式去暴露这样的接口 通过跟踪1D米访问:DAP可以通过他的全局唯一的跟踪ID读取任何一次跟踪信息。 ·批量访问:DAP可以利用的 MapReduce提供对上亿条 Dapper跟踪数据的并行读取。用户重 写一个虚拟函数,它接受一个 Dapper的跟踪信息作为其唯一的参数,该框架将在用户指定 的时间窗口中调用每一次收集到的跟踪信息。 索引访问: Dapper的仓厍支持一个符合我们通用调用模板的唯一索引。该索引根据通用请 求跟踪特性( commonly-requested trace features进行绘制来识别 Dapper的跟踪信息。因为跟 踪D是根据伪随机的规则创建的,这是最好的办法去访问跟某个服务或主机相关的跟踪数 据 所有这三种访问模式把用广指向不同的 Dapper跟踪记录。正如第2.1节所述的, Dapper的由span 组成的跟踪数据是用树形结构建模的,因此,跟踪数据的数据结构,也是一个简单的由span绢成 遍厉树。Span就相当于RPC调用,在这种情况下,RPC的时间信息是可用的。带时间戳的特殊的应 用标注也是可以通过这个span结构来访问的。 选择一个合适的自定乂索引是DAP设计中最具挑哉性的部分。压缩存储要求在跟踪数据利建立 个索引的情况只比实际数据小26%,所以消耗是巨大的。最初,我们部署了两个索引:第一个是主 机索引,另一个是服务名的索引。然而,我们并没有找到主机索引和存储成本之间的利害关系 用户对每一台主机感兴趣的时候,他们也会对特定的服务感兴趣,所以我们最终选择把两者相结合, 成为一个组合索引,它允许以服务名称,主机,和时间戳的顺序进行有效的查找。 511DAP在 Google内部的使用 DAP在谷歌的使用有三类:使利用DAP的持续的线上Web应用,维护良好的可以在控制台上调用 的基于DAP的工具,可以被写入,运行、不过大部分已经被忘记了的一次性分析工具。我们知道 的有3个持久性的基于DAP的应用程序,8个额外的按需定制的基于DAP分析工具,以及使用DAP 框架构建的约15~20—次性的分析工具。在这之后的工具就这是很难说明了,因为开发者可以构建、 运行和丢弃这些项目,而不需要 Dapper团队的技术支持。

...展开详情
试读 16P Dapper,大规模分布式系统的跟踪系统
立即下载 低至0.43元/次 身份认证VIP会员低至7折
    一个资源只可评论一次,评论内容不能少于5个字
    箫琴 这是号东西呀,
    2019-07-22
    回复
    W542525174 资源很好,谢谢分享
    2017-03-26
    回复
    • 签到新秀

      累计签到获取,不积跬步,无以至千里,继续坚持!
    关注 私信 TA的资源
    上传资源赚积分,得勋章
    最新推荐
    Dapper,大规模分布式系统的跟踪系统 16积分/C币 立即下载
    1/16
    Dapper,大规模分布式系统的跟踪系统第1页
    Dapper,大规模分布式系统的跟踪系统第2页
    Dapper,大规模分布式系统的跟踪系统第3页
    Dapper,大规模分布式系统的跟踪系统第4页
    Dapper,大规模分布式系统的跟踪系统第5页

    试读已结束,剩余11页未读...

    16积分/C币 立即下载 >