ACM通信
研究突出了
技术视角:轴心追踪视角
分布式系统是很难在最好的情况下进行管理:诊断、调试、容量规划和运行时属性(如超时或服务级别目标(SLO)阈值)的配置，由于分发带来的额外复杂性而变得更具挑战性。如果一个请求将由多个独立的微服务提供服务，那么这些挑战就会叠加在一起。
然而，这种服务环境是完全正常的——几乎每个在线服务都使用一系列不同的通信功能来满足每个用户的请求。例如，在购物网站上销售单个商品可能涉及身份验证服务、机器人检测服务、库存管理服务和支付服务，其中每一个都将被分片N在(分布式)持久存储之前可能使用缓存层的方法。随着分布而来的是规模:由数百甚至数千个嵌套rpc组成的请求在Web服务中并不罕见。用于批处理、流水线、并发、容错、屏蔽请求、负载平衡和其他此类带内动态控制系统的标准机制进一步加剧了理解系统行为的困难。
在这样的环境中，服务提供者如何调试他们的系统?如果购物车结帐请求延迟超过了第99个百分点，我们如何确定是哪个微服务负责以及为什么?处理这类问题的一个重要工具是跟踪，它与日志、计数器和指标相当，并且是它的补充。
典型的端到端请求跟踪系统依赖RPC子系统在微服务之间传播唯一的请求标识符，从而将因果相关的服务调用联系在一起。跟踪还将捕获关于请求的元数据，在沿途的每一跳中收集—诸如URI字符串或客户机标识符、每个主机的名称和IP地址等详细信息，以及性能指标，如请求在每个组件上消耗了多少CPU。
这种设计很简单，但在普遍性和成本之间有一种内在的张力。大多数跟踪系统在这个权衡空间中选择一个点，在这个点中，每个服务实例在本地生成记录，并直接将它们传输到收集器，收集器根据跟踪标识符对来自整个系统的记录进行分组。使用这种方法，可以针对跟踪(脱机)运行的查询集是不受限制的，但是系统可以产生大量的数据，相应的成本很高。因此，请求以较低的采样率(。在生产中，01%或更低是典型的)，这意味着可能会遗漏一些对检测和诊断问题至关重要的罕见事件。
本文描述的Pivot Tracing系统选择了不同的权衡。它不是急切地将跟踪记录交给收集器进行长期存储和未来处理，而是按需在分布式系统内部安装连续查询，并动态地在tracepoints准确地记录回答当前活动查询所需的信息。通过这种设计，Pivot Tracing更倾向于专一性，以换取低成本，同时消除了减少样本请求的需要。一个特别吸引人的方面是查询语言在元组流上由熟悉的关系操作符组成，扩展为指定因果相关事件之间的连接(使用happens -before操作符)，这支持对不同类型组件生成的数据以及请求生命周期中的不同点进行一些简洁的“透视表”风格的分析。
Pivot Tracing倾向于专一性，以换取低成本;消除了对下样例请求的需要。
这篇论文还对传统方法提出了另一个有趣的转变，即概念行李。在原地连续执行查询时，输入数据从何而来?在一个组件上生成的信息(例如，客户机应用程序的名称)如何到达在另一个组件上运行的查询(例如，将该名称与读取的字节数连接在一起的文件系统节点)?包袱是一个容器，用于在带内传播因果相关的“元组流”，以及请求本身。这是一个有趣的设计选择，因为传播和查询处理成本是由活动系统本身承担的，因此必须谨慎管理，但作为回报，我们拥有了一个灵活而强大的工具，可以对复杂的分布式系统进行交互式调试。
虽然跟踪系统已经有20多年的历史，但它们在生产中的应用直到最近几年才成为主流。现在大多数云提供商都为他们的客户提供了跟踪支持，并且有一个活跃的开源社区，定义了一些标准，比如OpenTracing(现在已经成为规范的一部分)、OpenCensus和OpenZipkin。尽管如此，在跟踪复杂的调试和丰富的分析洞察力以帮助管理复杂的分布式系统方面，仍然有很多未实现的潜力，这篇发人深省的论文及时地为对话做出了贡献。
数字图书馆是由计算机协会出版的。版权所有©2020 ACM股份有限公司
没有发现记录