ACM通信

研究突出了

轴心跟踪:分布式系统的动态因果监测

作者:乔纳森·梅斯，瑞安·罗尔克，罗德里戈·丰塞卡
ACM通讯，2020年3月，63卷，第3期，94-102页
10.1145 / 3378933
评论

众所周知，对分布式系统进行监控和故障排除非常困难;潜在的问题是复杂的、多变的、不可预测的。目前常用的监视和诊断工具(日志、计数器和指标)有两个重要的限制:记录的内容是先验定义的，信息是以组件或机器为中心的方式记录的，这使得将跨这些边界的事件关联起来极为困难。本文介绍了Pivot Tracing，这是一种用于分布式系统的监控框架，它通过将动态插装与一种新的关系操作符(happens -before join)相结合来解决这两种限制。Pivot Tracing使用户在运行时能够在系统的某一点定义任意的指标，同时能够根据在系统的其他部分有意义的事件进行选择、筛选和分组，甚至在跨越组件或机器边界时也是如此。Pivot Tracing不会使用昂贵的全局聚合来关联跨组件事件，也不会执行脱机分析。相反，Pivot Tracing通过在请求执行时附带元数据，直接将发生的事件关联起来。这为Pivot Tracing提供了较低的运行时开销——对于许多跨组件监视查询，开销不到1%。

回到顶部

1.简介

分布式系统的监控和故障排除是困难的。潜在的问题有很多:硬件和软件故障、错误配置、热点、激进的租户，甚至是不切实际的用户期望。尽管这些问题具有复杂和不可预测的性质，但目前常用的大多数监视和诊断工具(日志、计数器和指标)至少有两个基本限制:记录的内容是在开发或部署时预先定义的，信息是以组件或机器为中心的方式捕获的，这使得将跨这些边界的事件关联起来极为困难。

虽然在使用机器学习技术和静态分析来提高日志的质量及其在故障排除中的应用方面已经取得了很大的进展，¹⁶日志在收回和开销之间进行了固有的权衡，因为必须预先定义记录的内容。

为了解决这一限制，动态仪表系统，如Fay⁷和DTrace⁴启用对生产系统中意外性能问题的诊断^3.通过提供在运行时选择要激活的大量跟踪点中的哪一个的能力。然而，当涉及到跨地址空间或操作系统实例边界的相关事件时，动态插装仍然是有限的。这个限制是基本的，因为Fay和DTrace都不能影响被监视系统来跨这些边界传播监视上下文。

在本文中，我们提出了Pivot Tracing，一个将动态工具与因果跟踪技术相结合的监控框架^8，23从根本上提高两种技术的能力和适用性。在运行时，Pivot Tracing使操作人员和用户能够在系统的某一点获得几乎任意的度量，同时通过来自系统其他部分的先前事件进行选择、过滤和分组，甚至在跨越组件或机器边界时也是如此。Pivot Tracing通过将系统事件建模为流的分布式数据集的元组来公开这些特性。用户可以使用Pivot Tracing类似linq的查询语言编写关于系统事件的关系查询。Pivot Tracing将查询编译为有效的检测代码，并在查询中指定的事件源动态安装该代码，将结果的流数据集返回给用户。

Pivot Tracing的关键贡献是“连接前发生”操作符，，使查询能够通过Lamport的happens -before关系上下文化，→。¹⁵使用，查询可以基于在执行中先于事件的任何事件的属性对事件进行分组和筛选。

为了跟踪事件之间的“事前发生”关系，Pivot Tracing借鉴了因果跟踪技术，并利用通用元数据传播机制沿每个请求的执行路径传递部分查询执行状态。这允许在请求执行期间内联求值，极大地减少了查询开销，并避免了全局求值的可伸缩性问题。

我们已经为基于java的系统实现并开源了Pivot Tracing的原型，并测试了各种分布式系统，包括HDFS、HBase、MapReduce、Tez、YARN和Spark。在我们的全面评估中，¹⁶我们展示了Pivot Tracing可以有效地识别各种各样的根本原因，比如软件bug、错误配置和硬件故障。我们展示了Pivot Tracing是动态的，可扩展到新的分析类型，并支持在低执行开销的互操作应用程序之间进行跨层分析。

回到顶部

2.动机

2.1.轴心跟踪

在本节中，我们通过Hadoop堆栈上的一个监视任务来启动Pivot Tracing。我们在这里的目标是演示Pivot Tracing可以做些什么，我们将它的设计和实现的细节分别留给第3节和第4节。

假设我们正在管理一个由8台机器组成的集群，并且希望知道整个集群如何使用磁盘带宽。在这些机器上，我们同时运行着负载在HBase、HDFS和MapReduce中的客户端。知道HBase是一个分布式数据库，通过分布式文件系统HDFS访问数据就足够了。MapReduce除了通过HDFS访问数据外，还可以直接访问磁盘，进行外部排序，在任务之间shuffle数据。图1描述此场景以及以下客户端应用程序:

图1。6个客户机工作负载通过分布式数据库HBase间接访问8个集群机器上的磁盘;HDFS，一个分布式文件系统;MapReduce，一个数据处理框架。

默认情况下，系统公开一些磁盘消耗的指标，例如每个HDFS DataNode聚合的磁盘读吞吐量。为了用Pivot Tracing再现这个度量，我们定义了一个tracepoint为DataNodeMetrics类来拦截incrBytesRead三角洲(int)方法。跟踪点是应用程序源代码中可以运行检测的位置，参见第3节。然后，我们使用Pivot Tracing的LINQ-like查询语言运行以下查询¹⁷：

Q1:从增加在DataNodeMetrics.incrBytesRead
GroupByincr.host
选择incr.host,总和(incr.delta)

该查询导致每台机器每次都聚合delta参数incrBytesRead调用，并按主机名分组。每台机器每秒报告它的本地聚合，从中我们产生时间序列图2一个．

图2。在这个例子中，Pivot Tracing根据其他应用程序的客户端标识符分组，公开了一个低级的HDFS度量。轴心跟踪可以在系统的某一点公开任意的指标，同时能够根据在系统的其他部分有意义的事件进行选择、筛选和分组，甚至在跨越组件或机器边界时也是如此。(a)来自测量DataNodeMetrics的HDFS每台机器的DataNode吞吐量。(b) HDFS DataNode吞吐量按高级客户端应用分组。(c)透视表显示MRsort10g的磁盘读写火花。按主机分组行;列按源进程分组。底部的行和右边的列显示总数，而右下角显示总的总数。

但是，如果我们希望测量每个客户端应用程序的HDFS使用情况，事情就会变得更有趣。HDFS只有其直接客户端的可见性，因此是所有HBase和所有MapReduce客户端的聚合视图。在最好的情况下，应用程序必须在客户端估计吞吐量。使用Pivot Tracing，我们为HDFS的客户端协议定义了跟踪点(DataTransferProtocol), HBase (ClientService)和MapReduce (ApplicationClientProtocol)，并使用客户端进程的名称作为查询的按键组。图2 b显示了每个客户端应用程序的全局HDFS读吞吐量，由以下查询产生:

Q2:从增加在DataNodeMetrics.incrBytesRead
加入cl在第一个(ClientProtocols)在cl - >增加
GroupBycl.procName
选择cl.procName,总和(incr.delta)

->符号表示连接之前发生。Pivot Tracing的实现将在请求第一次通过任何客户端协议方法时记录进程名，并在执行过程中传播它。然后，每当执行到达incrBytesRead在DataNode上，Pivot Tracing将发出读取或写入的字节，并按记录的名称分组。此查询公开HDFS目前无法公开的客户端磁盘吞吐量信息。

图2 c演示了Pivot Tracing沿着任意维度分组指标的能力。它是由两个类似于Q2的查询生成的FileInputStream而且FileOutputStream，仍然与客户端进程名连接。在同一个实验中，我们展示了MRSORT10G的每个机器、每个应用程序的磁盘读写吞吐量。这个图类似于一个透视表，其中跨行求和产生每台机器的总数，跨列求和产生每系统的总数，右下角显示的是全局总数。在这个示例中，客户端应用程序提供了一个进一步的维度，我们可以根据这个维度展示统计信息。

上面的查询Q1是在本地处理的，而查询Q2需要将信息从客户机进程传播到数据访问点。Pivot Tracing的查询优化器在需要的地方安装动态插装，并确定必须在何时进行此类传播以处理查询。HDFS、HBase和MapReduce提供的开箱即用的指标无法提供这里所展示的分析。简单的关联—例如确定哪一个HDFS的数据节点是由高级客户端应用程序读取的——这通常是不可能的。度量标准在系统之间是特别的;HDFS每秒计算IO字节，而HBase每秒公开操作。它对跨层分析的支持非常有限:MapReduce简单地计算全局HDFS的输入和输出字节数;HBase没有显式地将HDFS的指标与HBase的操作关联起来。

2.2.主跟踪概述

图3概述了Pivot Tracing如何启用Q2这样的查询。我们在描述中引用图中的数字(例如，)。系统中对Pivot跟踪的全面支持需要两种基本机制:动态代码注入和因果元数据传播。

图3。Pivot Tracing概述(章节2.2)。

Pivot Tracing中的查询引用一个或多个公开的变量tracepoints-系统中枢轴跟踪可以插入仪器的地方。跟踪点定义不是系统代码的一部分，而是关于在何处以及如何更改系统以获得导出标识符的说明。Pivot跟踪中的跟踪点类似于面向方面编程中的切入点，¹⁴并且可以引用任意接口/方法签名组合。跟踪点由具有系统知识的人员定义，可能是开发人员或专家操作人员，并为queries()定义词汇表。它们可以在任何时间点定义和安装，并可以共享和传播。

Pivot跟踪将系统事件建模为流分布式数据集的元组。用户在这个dataset()上提交关系查询，然后将其编译为一个称为的中间表示建议()。Advice使用一个小指令集来处理查询，并直接映射到本地Pivot Tracing代理动态安装在相关跟踪点()上的代码。之后，在系统中执行的请求在每次执行到达跟踪点时调用已安装的通知。

我们通过支持来区分Pivot Tracing与之前的工作连接在进程、机器和应用程序边界内或跨边界发生的事件之间。要高效地实现连接前发生的事件，需要一个跟踪点中的通知沿着执行路径将信息发送到后续跟踪点中的通知。这是通过一个新的行李抽象，它使用因果元数据传播()。例如，在查询Q2中，cl.procName的第一次调用中打包了ClientProtocols控件处理时访问的跟踪点incrBytesReadtracepoint。

一些跟踪点中的通知还会发出元组()，该元组在本地聚合，然后最终通过消息总线流到客户机(和)。

2.3.监控和故障排除挑战

轴心跟踪解决了监视和故障排除中的两个主要挑战。首先，当预先选择记录执行的内容时，在调用和开销之间有一个固有的权衡。其次，要诊断许多重要的问题，需要关联和集成跨组件、系统和机器边界的数据。

一种方法不能适用于所有人。分布式系统中的问题是复杂的、多变的、不可预测的。缺省情况下，诊断问题所需的信息可能不会被系统上报或包含在系统日志中。目前的方法将日志和统计机制与产品的开发路径联系在一起，在这种情况下，开发者的期望和激励与运营商和用户的需求之间存在不匹配。小组成员在SLAML²讨论了“向开发人员关闭操作循环”的重要需求。根据Yuan等人的研究，²⁵关于故障诊断，“(……)现有的日志消息包含的信息太少。尽管日志消息在故障诊断中被广泛使用，但仍然很少系统地设计日志消息来支持这一功能。”

这种不匹配可以在Apache问题跟踪器上的用户提出的许多问题中观察到¹⁶请求新的指标，对聚合方法的更改，或现有指标的新的分解。由于开发人员的拖延或惰性，许多问题仍未得到解决。

最终，应用程序可能会被更新以记录更多的信息，但这对性能和信息过载都有影响。用户必须为默认启用的任何系统支付性能开销，无论它们的实用性如何。例如，HBase SchemaMetrics是为了帮助开发人员而引入的，但HBase的所有用户都要为此支付10%的性能开销。¹⁰对于希望与Ganglia集成的用户，HBase用户指南中有如下警告:“默认情况下，HBase会在每个region服务器上释放大量的metrics。Ganglia可能很难处理所有这些指标。考虑增加Ganglia服务器的容量或减少HBase释放的指标数量。”

大量的记录信息给用户带来了一个“大海捞针”的问题²¹；虽然系统可能会暴露与问题相关的信息(例如，在日志中)，但提取这些信息需要经过很长一段时间的系统熟悉。例如，Mesos集群状态是通过单个JSON端点公开的，即使客户端只需要状态子集的信息，它也可能变得非常庞大。¹⁶

动态仪表框架，如Fay，⁷DTrace,⁴和SystemTap^20.通过允许在运行时动态地安装几乎任意的检测工具来解决这些限制，并且已经证明在诊断复杂和微妙的系统问题方面非常有用。^3.但是由于没有副作用，所以在共享信息方面受到了限制。在Fay中，只有位于相同地址空间中的探针才能共享信息，而在DTrace中，范围仅限于单个操作系统实例。

跨越边界。这就引出了第二个挑战:Pivot Tracing地址。在多租户、多应用程序栈中，问题的根本原因和症状可能出现在不同的进程、计算机和应用程序层中，并且可能对不同的用户可见。一个应用程序的用户可能需要关联来自其他依赖应用程序的信息，以便诊断跨多个系统的问题。例如,hbase - 4145⁹概述了MapReduce如何缺乏在每个任务基础上访问HBase指标的能力，以及该框架只返回所有任务的聚合。便- 1949¹⁸概述了任务的执行程序如何不传播故障信息，因此如果执行程序失败，诊断可能会很困难。在讨论中，开发人员指出:“真正有趣/有用的信息隐藏在四五个不同的地方之一，可能分布在许多不同的机器上。这会导致在日志中进行不愉快和重复的搜索，以寻找出错的线索。有很多信息隐藏在日志文件中，很难进行关联。”

以前的研究提出了观察或推断事件之间关系的机制，日志记录实践的研究得出的结论是，端到端跟踪有助于导航它们概述的日志记录问题。¹⁶

各种各样的这些机制也在生产系统中实现，例如谷歌的Dapper，²³Apache的HTrace,¹和Twitter的Zipkin。²⁴这些方法可以获得比仅以组件为中心的日志或度量更丰富的关于特定执行的信息，并可用于故障排除、调试、性能分析和异常检测等方面。然而，这些系统中的大多数会记录或重构执行轨迹，以便进行离线分析，因此与第一个挑战(关于记录什么)共享上述问题。

回到顶部

3.设计

我们现在详细介绍Pivot Tracing背后的基本概念和机制。Pivot Tracing是一个用于分布式系统的动态监控和跟踪框架。在较高的层次上，它的目标是通过关联系统中任意点的指标和事件来实现灵活的运行时监控。第2节中列出的挑战激发了以下高级设计目标:

1. 在运行时动态配置和安装监视。
2. 低系统开销，以启用“始终开启”监控。
3. 从多个流程和应用程序捕获事件之间的因果关系。

Tracepoints。跟踪点为Pivot Tracing查询提供系统级的入口点。跟踪点通常对应于一些事件:用户提交请求、低级IO操作完成、调用外部RPC等。跟踪点标识系统代码中Pivot Tracing可以安装和运行检测的一个或多个位置，比如方法的名称。由于Pivot Tracing使用动态工具来安装查询，跟踪点不需要预先定义，也不需要预先修改系统代码;它们只是对源代码中位置的引用。跟踪点只有在安装了引用它的查询之后才会实体化。跟踪点导出可以通过插装访问的命名变量，例如方法参数或局部变量，以及几个默认变量:主机、时间戳、进程id、进程名和跟踪点定义。

每当系统执行到达一个跟踪点时，将调用为该跟踪点配置的任何插装，生成一个具有其导出变量的元组。然后，安装在跟踪点上的任何检测代码都可以访问这些代码。

查询语言。Pivot跟踪使用户能够表达关于一个或多个跟踪点导出的变量的高级查询。我们将跟踪点调用抽象为元组的流数据集;因此，Pivot跟踪查询是跨多个这样的数据集的元组的关系查询。

为了表达查询，Pivot Tracing为类似linq的文本查询(如第2节中概述的那些)提供了一个解析器。表1概述了Pivot Tracing支持的查询操作。Pivot Tracing支持几种典型的操作，包括投影(Π)、选择(σ)、分组(G)和聚合(A)Count, Sum, Max, Min，而且平均．Pivot Tracing还定义了时间过滤器最近的，MostRecentN，第一个,倘若，取1或N个最近或最近发生的事件。最后，Pivot Tracing介绍了发生过一起查询操作符()．

表1。Pivot Tracing查询语言支持的操作。

发生过连接。Pivot Tracing的一个关键贡献是happens before连接查询操作符。happens before连接使来自两个Pivot Tracing查询的元组能够基于Lamport的happens before关系进行连接，→。¹⁵事件一个而且b发生在系统的任何地方一个发生过b和写一个→b如发生事件一个在事件发生之前发生的b它们是作为同一请求执行的一部分发生的。^一个如果一个而且b不属于同一案件吗一个b如果发生一个没有导致的发生b,然后一个b(例如，它们发生在两个不通信的并行执行线程中);如果一个→b然后b一个。

对于任意两个查询问₁而且问₂，加入之前发生的事问₁问₂产生的元组t₁t₂对所有t₁∈问₁而且t₂∈问₂这样t₁→t₂．也就是说,问₁生产t₁之前问₂产生的元组t₂在同一个请求的执行中。图4展示了一个多次触发跟踪点A、B和C的执行示例，并概述了不同查询为此执行将产生的元组。

图4。一个多次触发跟踪点A、B和C的示例执行。我们展示了几个Pivot Tracing查询以及每个查询的结果元组。

第2节中的查询Q2演示了happens -before连接的使用。查询中，由磁盘IO跟踪点生成的元组DataNodeMetrics.incrBytesRead的生成的第一个元组ClientProtocolstracepoint。

happens -before join通过提供关系的可见性，极大地提高了执行根本原因分析的能力之间的系统中存在的事件。“事前发生”关系是许多先前的根本原因分析方法的基础。¹⁶Pivot跟踪旨在有效地支持发生在连接之前的连接，但不能优化更通用的连接，如equijoins()。

建议。跟踪查询编译为调用的中间表示建议。Advice指定在查询中使用的每个跟踪点上执行的操作，并最终成为安装在这些跟踪点上的监视代码(第4节)。Advice有几个操作用于通过跟踪点导出的变量操作元组和计算在执行之前的跟踪点上由其他通知产生的元组上。

表2概述建议API。Observe从导出的跟踪点变量创建一个元组。Unpack检索由其他通知在执行之前的其他跟踪点生成的元组。解压缩的元组可以连接到观察到的元组，即ift_o是观察和t_u1而且t_u2解包，那么结果元组是t_ot_u1而且t_ot_u2．由该通知创建的元组可以被丢弃(Filter)，也可以在执行过程中稍后的其他跟踪点上提供给通知(Pack)，或者输出为全局聚合(Emit)。Pack和Emit都可以基于匹配的字段对元组进行分组，并执行简单的聚合，例如总和而且数．包也有以下特殊情况:第一个打包遇到的第一个元组并忽略后续元组;最近只打包最新的元组，覆盖现有的元组。倘若而且RECENTN概括这N元组。的建议API具有表现力，但限制足够，以提供一些安全保证。特别是，通知代码没有跳转或递归，并且保证会终止。

表2。由Pivot Tracing建议支持的原语操作，用于生成和聚合在第3节中定义的元组。

第2节中的查询Q2编译为建议Al和A2ClientProtocols而且DataNodeMetrics分别为:

A1:观察procName
先收拾行李吧procName

A2:观察δ
解压缩procName
发出procName,总和(δ)

图5显示此通知和跟踪点如何与系统中请求的执行交互。首先，当请求执行到达时ClientProtocols， A1被调用，它观察并打包一个包含进程名称的单值元组。然后，当执行到达DataNodeMetrics，调用A2，它解包进程名，观察的值δ，则发出一个联合元组。

图5。从第2节产生的Q2建议:A1观察并封装procName;A2解包procName，观察delta，并发出(procName, SUM(delta))。

要编译到通知的查询，我们实例化一个通知规范从子句，并为查询中使用的跟踪点变量添加一个Observe操作。为每一个加入子句中，我们为来自连接查询的变量添加一个Unpack操作。我们递归地为连接的查询生成通知，并在通知的末尾为解包的变量添加一个Pack操作。其中直接转换为Filter操作。我们为查询的输出变量添加一个Emit操作，根据任何Select子句进行限制。总体来说,GroupBy,GroupByAggregate都是由Emit和Pack处理的。

行李。Pivot跟踪通过提供行李抽象。行李是元组的每个请求容器，也就是说，当请求遍历线程、应用程序和机器边界时，它与请求一起传播。Pack和Unpack从当前请求的包袱中存储和检索元组。元组遵循请求的执行路径，因此显式地捕获happens -before关系。

包袱是前面的工作(如X-Trace)中概述的端到端元数据传播技术的概括⁸和衣冠楚楚的。²³使用“包袱”，Pivot Tracing可以有效地评估发生的情况——在请求执行期间在原位连接之前。

元组聚合和查询优化。为了减少发出的元组的数量，Pivot Tracing对包含总或GroupBy-Aggregate．轴心跟踪在每个进程中聚合发出的元组，并以固定的间隔(例如每秒一次)全局报告结果。流程级聚合大大减少了发出的元组的流量;第2节中的Q2从每个DataNode每秒大约600个元组减少到6个元组。Pivot Tracing还使用Fay描述的相同查询重写规则重写查询，以最小化请求执行期间打包的元组的数量⁷推送投影、选择和聚合术语尽可能接近源跟踪点。我们扩展了这些查询重写规则¹⁶为happens -before连接添加进一步优化。

回到顶部

4.实现

我们已经在Java中实现了一个Pivot Tracing原型，并将Pivot Tracing应用到Hadoop生态系统中的几个开源系统中。Pivot Tracing项目网站公开提供Pivot Tracing源代码和系统。^b

代理。Pivot Tracing代理线程在每个启用Pivot tracking的进程中运行，等待通过中央发布/订阅服务器的指令，将通知编织到跟踪点。由通知发出的元组由本地Pivot Tracing代理收集，该代理根据元组的源查询执行元组的部分聚合。代理以可配置的时间间隔(默认为1秒)向用户发布部分查询结果。

动态检测。我们的原型在运行时编织建议，提供类似于DTrace的动态工具⁴和仙女。⁷Java 1.5版本以后支持动态方法体重写java.lang.instrument包中。Pivot Tracing代理使用Javassist从进程中按程序语法重写和重新加载类字节码。⁵为了编织通知，我们重写方法主体，在跟踪点定义的位置添加通知调用。我们的原型支持在任何方法的入口、出口或异常返回处的跟踪点。跟踪点也可以插入到特定的行号。

要定义跟踪点，用户需要指定类名、方法名、方法签名和编织位置。Pivot跟踪还支持模式匹配，例如，类上接口的所有方法。这个特性是模仿的切入点AspectJ。¹³Pivot跟踪支持工具化特权类(例如，FileInputStream在第2节中)，通过提供一个可选的代理来放置在Java的引导类路径上。

轴心跟踪只在将通知编织到跟踪点时进行系统修改，因此不活动的跟踪点不会产生开销。不触发跟踪点的执行不受Pivot跟踪的影响。Pivot跟踪具有零探针效果:方法在默认情况下是不修改的，因此跟踪点实际上施加零开销，直到将通知编入其中。

行李。我们的行李实现使用线程局部变量来存储每个请求的行李实例。在请求开始时，我们在线程局部变量中实例化空行李;在请求的最后，我们清除线程局部变量中的包袱。行李API可以为查询获取或设置元组，并且在任何时间点都可以检索行李，以便将其传播到另一个线程或序列化到网络上。为了同时支持多个查询，查询被分配唯一的ID，元组根据这个ID打包和解包。

Hadoop的仪器。当请求跨越线程、进程或异步执行边界时，Pivot跟踪依赖于开发人员实现行李传播。我们已经在几个开源系统中实现了这种传播，这些系统目前在生产中广泛使用:HDFS、HBase、MapReduce、Tez、YARN和Spark。为了跨远程过程调用传播包袱，我们手动扩展了系统的协议定义。为了在各个进程中跨执行边界传播行李，我们实现了AspectJ¹³自动修改公共接口的检测(可运行线程,可调用的,队列)．每个系统需要50到200行手动代码修改。一旦修改，这些系统就可以支持任意的Pivot Tracing查询，而无需进一步修改。

回到顶部

5.评价

在本节中，我们将通过Hadoop分布式文件系统的一个案例研究来评估Pivot Tracing²²(HDFS)。^cHDFS是一个分布式文件系统，由一个管理文件系统元数据的中心NameNode进程和多个运行在集群上存储复制文件块的DataNode进程组成。我们描述了我们在HDFS中发现的一个副本选择bug，该bug导致了副本负载的不均匀分布。在发现bug之后，我们发现它最近已经被报告了，并在即将发布的HDFS版本中进行了修复。¹¹

HDFS通过将文件分解成块，并将每个块复制到多台机器上(通常是3台)来提供文件冗余。客户端可以读取块的任何副本，通过首先联系NameNode来找到副本主机(调用GetBlockLocations)，然后按如下步骤选择最接近的副本:(1)读取一个本地副本;(2)读取一个机架-本地副本;(3)随机选择一个副本。我们发现了一个错误，即rack-local副本选择总是遵循全局静态排序，这是由于两种冲突的行为:HDFS客户端不会在副本之间随机选择;HDFS NameNode不会随机返回给客户端的rack-local副本。该bug导致某些主机的负载过重，而其他主机的负载接近于零。

在这个场景中，我们在一个包含8个datanode和1个NameNode的HDFS集群上运行96个压力测试客户端。每台机器都有相同的硬件规格;8核，16GB内存，1Gbit网络接口。在每台主机上，我们运行一个名为stress stest的进程，它使用HDFS客户端对一个包含10,000 128MB文件的数据集执行闭环随机8kB读取，复制系数为3。我们的查询使用来自HDFS DataNode的客户端和服务器RPC协议实现的跟踪点DataTransferProtocol和NameNodeGetBlockLocations客户协议。

当我们注意到主机A和D上的压力测试客户端始终比其他主机上的客户端请求吞吐量更低时，我们开始了对该bug的调查，如图6，尽管相同的机器规格和设置。我们首先检查每台主机上的机器级资源利用率，这表明网络吞吐量有很大的变化(图6 b)．我们通过Pivot Tracing进行诊断，首先检查HDFS负载的不平衡是否导致了网络吞吐量的变化。以下查询将通知安装在DataNode跟踪点，即由每个传入RPC调用:

图6。跟踪导致我们发现HDFS-6268的查询结果。¹¹错误的副本选择逻辑导致客户端优先考虑由特定datanode托管的副本:如果主机A持有副本，它总是优先于其他主机;主机D总是首选的，除非主机A持有一个副本;等。主机A DataNode的负载增加降低了客户端A的吞吐量。(A)主机A和D上的客户端工作负载吞吐量降低。(b)网络传输在不同机器之间倾斜。(c) HDFS DataNode吞吐量在不同机器上存在倾斜。(d)观察到的每个客户端HDFS文件读分布(row) (col)。(e)频率每个客户端(行)将每个DataNode (col)视为一个副本位置。(f)每个客户端(row)随后选择每个DataNode (col)的频率。(g)观察到选择一个复制主机(row)而不是选择另一个复制主机(col)的频率。

第三季度:从dnop在DN。DataTransferProtocol
GroupBydnop.host
选择dnop.host,数

图6 c绘制这个查询的结果，显示每个DataNode上的HDFS请求吞吐量。它表明，主机A和D上的datanode的请求吞吐量比其他主机要高得多——主机A的平均操作次数为150次/秒，而主机H只有25次/秒。考虑到我们的压力测试客户应该是均匀随机地读取文件，这种行为是出乎意料的。我们的下一个查询在压力测试客户端和HDFS NameNode上安装advice，将每个读请求与发出它的客户端关联起来:

第四季度:从getloc在神经网络。GetBlockLocations
加入圣在StressTest。DoNextOp在圣- > getloc
GroupByst.host, getloc.src
选择st.host getloc.src,数

该查询计算每个客户机读取每个文件的次数。在图6 d，我们绘制每个主机上客户机在5分钟内的计数分布。这些分布都符合正态分布，表明所有客户机都在均匀随机地读取文件。客户端A和D上的读数据分布偏左，这与它们整体较低的读吞吐量一致。

在确认了我们的压力测试客户端的预期行为之后，我们接下来检查数据阳极的吞吐量是否仅仅是跨数据节点倾斜的块放置的结果:

Q5:从getloc在神经网络。GetBlockLocations
加入圣在StressTest。DoNextOp在圣- > getloc
GroupByst.host, getloc.replicas
选择st.host getloc.replicas,数

此查询测量每个DataNode为正在读取的文件托管副本的频率。图6 e显示，对于每个客户端，副本几乎均匀地分布在集群中的各个datanode上。这些结果表明，客户端有平等的机会从每个DataNode读取副本，但是，我们的测量在图6 c很明显，他们没有。为了更深入地了解这种不一致性，我们的下一个查询将来自的结果关联起来图6 e那些从图6 c：

Q6:从DNop在DN。DataTransferProtocol
加入圣在StressTest。DoNextOp在圣- > DNop
GroupByst.host, DNop.host
选择st.host DNop.host,数

该查询测量每个客户端选择每个DataNode读取副本的频率。我们把结果画出来图6 f看到客户明显更喜欢特定的datanode。强对角线与HDFS客户端偏好本地托管副本是一致的(在这种情况下39%的时间)。但是，当没有本地副本时，期望的行为是随机均匀选择一个机架-本地副本;很明显，这些结果表明这并没有发生。

我们最后的诊断步骤如下。首先，我们检查了一下哪一个副本是HDFS客户端从NameNode返回的位置中选择的。我们发现客户端总是选择NameNode返回的第一个位置。其次，我们测量了在NameNode返回的位置上，datanode比其他节点领先的条件概率。对于后者，我们发出了以下查询:

玩家:从DNop在DN。DataTransferProtocol
加入getloc在神经网络。GetBlockLocations
在getloc - > DNop
加入圣在StressTest。DoNextOp在圣- > getloc
在哪里st.host ! = DNop.host
GroupByDNop。主机,getloc.replicas
选择DNop。主机、getloc.replicas数

该查询将DataNode与其他DataNode相关联，也就是说，选择的DataNode也托管一个副本。我们通过以下方法消除本地副本的干扰过滤只有执行非本地读取的请求。图6克表明宿主A是总是当它承载一个副本时选择;主机D总是被选中，除非主机A也是副本，以此类推。情况本不应该是这样的;由于副本选择是随机的，所以不应该优先选择任何主机。

在我们的分析中，我们得出结论，这种行为很可能是HDFS的一个bug。HDFS客户端不会随机选择副本，HDFS NameNode也不会随机选择rack-local副本。我们检查了Apache的问题跟踪器，发现这个bug最近已经被报告，并在即将发布的HDFS版本中修复了。¹¹

应用程序级别的开销。为了评估Pivot Tracing对应用程序级吞吐量和延迟的影响，我们运行了来自HiBench的基准测试，¹²YCSB,⁶HDFS DFSIO和NNBench基准测试。许多基准测试瓶颈发生在网络或磁盘上，我们注意到启用Pivot Tracing后没有显著的性能变化。

为了衡量Pivot Tracing对CPU绑定请求的影响，我们使用来自HDFS NNBench基准的请求对HDFS进行了压力测试:Read8k从一个文件读取8kB;Open打开文件进行读取;Create创建一个用于写入的文件;Rename对现有文件进行重命名。Read8kB是DataNode操作，其他为NameNode操作。我们比较了未修改的HDFS和按以下方式修改的HDFS中请求的端到端延迟:(1)启用了Pivot Tracing，(2)传播包含一个元组但没有安装建议的包，(3)传播包含60个元组(≈1kB)但没有安装建议的包，(4)安装了Q3-Q7查询。

表3显示启用Pivot Tracing的应用程序级开销最多为0.3%。这个开销包括HDFS中的空包传播、RPC调用中的包序列化以及在调试模式下运行Java的开销。最明显的开销是在包中传播60个元组时产生的，Open的开销为15.9%。由于这是一个较短的cpu绑定请求(涉及单个只读查找)，16%在合理的预期范围内。RENAME不会触发Q3-Q7查询的任何建议，仅反映为0.3%的开销。

表3。启用Pivot Tracing、启用行李传播和启用查询时，HDFS压力测试的延迟开销。

回到顶部

6.讨论

尽管Pivot Tracing在故障排除方面优于日志和度量(第2节)，但它并不是要取代日志的所有功能，比如安全审计、取证或调试。¹⁹

Pivot Tracing的每个查询开销与当前系统暴露的指标类似。对于一个系统来说，在默认情况下启用多个Pivot Tracing查询是可行的;这些查询可以是开发人员提供的合理默认值，也可以是用户安装的定制查询，以满足他们的特定需求。我们把探索使用Pivot Tracing进行自动问题检测和探索留给以后的工作。

虽然用户仅限于使用由Pivot Tracing原语组成的建议，但由于当前定义从跟踪点导出变量的方式，Pivot Tracing不能保证其查询不会产生副作用。我们可以强制要求只有受信任的管理员定义跟踪点，并在安装时要求对建议进行签名，但全面的安全分析，包括对跟踪点代码的完全消毒，超出了本文的范围。

尽管我们在本文中在8个节点的集群上评估了Pivot Tracing，但在一个200个节点的集群上初始运行的测试系统对性能的影响可以忽略不计。评估Pivot Tracing对更大的集群和更复杂查询的可伸缩性是一项正在进行的工作。建议级别的抽样是我们计划研究的另一种减少开销的方法。

我们选择用Java实现Pivot Tracing，是为了方便地使用这种语言编写的几种流行的开源分布式系统。然而，Pivot Tracing的组件是泛化的，并不局限于java——由于Pivot Tracing的独立于平台的包袱格式和受限的通知操作集，查询可以跨越用不同编程语言编写的多个系统。特别是，将happens -before与Fay或DTrace集成在一起将是一个有趣的练习。

回到顶部

7.结论

Pivot Tracing是第一个将动态检测和因果跟踪相结合的监控系统。它新颖的happens -before连接操作符从根本上提高了动态检测的表现力和因果追踪的适用性。Pivot Tracing支持在任何互操作应用程序之间进行跨层分析，并且具有较低的执行开销。最终，它的力量在于它以统一和普遍的方式集成了异构分布式系统的监控。

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2020 ACM股份有限公司

---

没有发现记录