分布式追踪：过去、现在和未来

分布式跟踪是一个存在争议的话题。该技术曾经是每届 KubeCon 的元老，人们期望它会彻底改变可观测性。

快进 5 年了，炒作已经有所减弱，关于痛苦的讨论也越来越多，采用率也很温和。与此同时，围绕技术扩展和标准化的活动仍在持续进行——开放遥测（基于 OpenTracing）是继 Kubernetes 之后的第二大 CNCF 项目。那么分布式追踪有什么用呢？应该立即实施还是观望？

在本文中，让我们深入探讨分布式跟踪

1. 分布式跟踪有何特别之处以及我们为什么需要它？
2. 如今分布式追踪存在哪些问题？
3. 即将到来的发展是什么？它们如何应对现有的挑战？

简介 - 分布式跟踪如何工作

对于外行来说，分布式跟踪是一项技术，允许我们在单个请求遍历分布式环境的多个不同组件/微服务时跟踪该请求。请求路径中进行的每个网络调用都会被捕获并表示为一个跨度。

为了实现这一点，分布式跟踪工具将唯一的跟踪上下文（跟踪 ID）插入到每个请求的标头中，并实现机制以确保跟踪上下文在整个请求路径中传播。

分布式跟踪如何表示请求路径

为什么我们首先需要分布式跟踪

分布式跟踪是独特的，因为它专注于将请求作为可观察性的单位。在监控/度量平台中，组件（例如服务、主机）是被观察的基本单元。随着时间的推移，人们可以向这些平台询问有关该单位作为一个整体的行为的问题。例如，该服务在特定时间范围内的运行状况/吞吐量/错误率是多少？

对于日志，被观察的基本单位是事件——例如，每当代码执行期间发生事件时，打印一些信息。这些“事件”是开发人员在编写代码时主观定义的。日志的挑战在于它们都是脱节的，每个组件都单独打印自己形式的日志消息，没有简单的方法将它们连接在一起以使其有意义。

相比之下，通过分布式跟踪，所观察到的是单个请求，因为它遍历多个组件。这使我们能够提出有关整个分布式系统的问题，并了解复杂的互连系统中发生了什么。

分布式跟踪的基本情况在于这样的论点：这种围绕请求的方向最接近最终用户的体验。因此，它也是我们检查和排除分布式架构故障的最直观方式。

分布式追踪的演变

由于过去十年分布式软件架构的广泛采用，分布式跟踪变得越来越重要。

现代基于微服务的架构是 90 年代末互联网发展故事的演变，当时请求响应系统的使用变得很普遍。

“随着 90 年代末互联网的爆炸式增长，请求响应系统大量涌现，例如带有 Web 服务器前端和数据库后端的两层网站......请求是推理系统的新维度，与任何一台机器或过程正交。”

- 分布式追踪实践，O'Reilly Media

在这些微服务架构中，每个请求最终都会遇到许多（数十个甚至数百个微服务），并在其间进行多次网络调用。请参阅下面的 Uber 微服务架构，该架构拥有 3000 多个服务。

Uber 2018 年的微服务架构。来源： https ://www.uber.com/en-IN/blog/microservice-architecture/

在此类复杂的系统中，分布式跟踪对于任何形式的故障排除都至关重要。因此，分布式跟踪是由大公司率先采用的，这些公司是使用大型、复杂、分布式环境的早期采用者。

• Google 2010 年发布的 Dapper 论文是分布式追踪的开始

  
  

• 在接下来的几年里，又有两家公司开源了自己的分布式追踪系统（Twitter 于 2012 年开源了 Zipkin，Uber 于 2017 年开源了 Jaeger）。即使在今天，Zipkin 和 Jaeger 仍然是最流行的分布式跟踪工具之一

  
  

• 自 2016 年以来，通过 OpenTracing 项目，我们付出了巨大的努力来标准化跨组件的分布式跟踪。 OpenTracing 最终于 2019 年更名为OpenTelemetry。OpenTelemetry广泛流行，在全球拥有数千名贡献者

  
  

• 现在，分布式跟踪被广泛认为是继指标和日志之后可观察性的第三个“支柱”。大多数主要的监控和可观察性参与者都提供分布式跟踪工具作为其产品的一部分。

分布式追踪的现状：理论与现实

然而，尽管有希望、令人兴奋和社区努力，目前分布式跟踪的采用率约为 25%。尽管微服务架构显然需要分布式跟踪，但使用日志和指标来凑合的公司并不罕见。

与此同时，当今世界的平均解决生产错误时间正在增加。 73% 的公司表示，今天需要一个多小时才能解决生产问题。

如果问任何一个开发人员，他们一生中最痛苦的时刻是什么，他们都会谈论花费在调试生产中的 Sev-1 错误上的时间，而这似乎有几百人在紧张地进行。

看来，任何关心 MTTR 的公司（几乎是每家公司）都应该使用分布式跟踪，并且在这种环境中采用率应该会飙升。但实际数字并不支持这一点——那又是什么呢？

当今分布式跟踪面临的挑战

如今，分布式追踪存在几个问题，公司必须克服这些问题才能获得价值——所有这些问题都没有在主流叙述中得到广泛讨论。

1、执行难！

如今，为了在服务中实现分布式跟踪，我们需要更改代码并发布版本。虽然更改代码是对可观察性的常见要求，但分布式跟踪面临的具体挑战是 -每个服务或组件都需要进行检测才能获得分布式跟踪，否则跟踪就会中断。

人们不能像监控或日志记录那样仅仅从一项服务开始就可以实现价值。分布式跟踪需要跨一组服务进行检测以生成可用的跟踪。

这需要多个团队和服务所有者之间的协调来更改他们的服务。因此，这成为一个组织问题 - 想象一下让数百个团队在几个月内对他们的服务进行测试，然后才能实现价值。

这是当今分布式跟踪面临的最大挑战。

2. 需要复杂的抽样决策

其次，分布式跟踪生成的跟踪数据量可能非常巨大。想象一下数百个服务，每个服务为每个请求发出少量跟踪数据。这将是每秒数百万个请求，并且使得分布式跟踪在存储和网络带宽方面都变得昂贵。

虽然日志记录也做同样的事情（并且每个请求发出更多数据，然后由大量日志聚合工具管理），但不同之处在于当今大多数公司已经有了日志记录。引入一种几乎与日志记录一样庞大的数据类型是一项艰巨的任务，并且可能会使支出增加一倍。

为了解决这个成本问题，当今所有分布式跟踪系统都使用采样并仅记录跟踪的子集。目前实践中常见的采样率在 0.1% 到 2% 之间。理由是，即使 1% 的样本也足以给出性能瓶颈所在的总体情况。

如今，大多数平台都允许客户选择采样策略并做出自己的成本与可见性权衡。然而，这个决策过程增加了检测和管理分布式跟踪系统本已复杂的开销。

3. 但抽样会显着降低价值

让我们假设一家公司努力对每个服务/组件进行检测，然后决定采样策略以确保他们不会倾家荡产。

现在怎么办——我们应该预期 MTTR 会大幅下降吗？不可以，因为由于采样，开发人员无法使用分布式跟踪来实际解决问题。

想象一下开发人员的经历 - “我找不到我知道的问题。我生成了错误，但我找不到相应的跟踪”。

那么会发生什么呢？开发人员不再信任分布式跟踪数据的质量，而是恢复到常规的调试/故障排除方法（即使用日志）

4、开发者使用频率低

考虑到这些限制，如今分布式跟踪主要作为解决性能问题的一种方法来销售。

请记住，基本的分布式跟踪实际上只是告诉我们谁调用了谁以及每个跨度花费了多长时间。分布式跟踪不会告诉我们服务中发生了什么导致错误/高延迟。为此，开发人员仍然必须查看日志消息和/或在本地重现问题以进行调试。

在典型的公司中，绩效问题可能占总数的不到 10%。所以实际上，分布式跟踪仅对这一小部分问题有用。

发布和拥有服务的开发人员平均每年可能使用分布式跟踪工具 2-3 次。

所有这些挑战的影响

总之：

1. 分布式追踪很难实现
2. 分布式追踪需要大量采样来控制成本
3. 但抽样大大降低了价值
4. 因此，开发人员仅将跟踪用于奇怪的一次性性能用例

所有这些使得分布式追踪的投资回报率案例变得相当模糊。

在典型的炒作周期中，我们可以说，我们现在已经过了期望过高的阶段，幻灭感开始显现。

如果我们从最终状态的角度思考，如果计算系统的未来是分布式的，那么分布式跟踪自然是可观察性的最基本向量。在那个世界中，任何具有分布式架构的公司都使用跟踪作为对生产中发生的任何问题进行故障排除的主要机制 - 真正的“可观察性” - 与我们今天拥有的系统的被动监控不同。

不过，在达到最终状态之前，我们需要对现状进行一些改进。好消息是，其中大部分工作已经在进行中。让我们逐一看看。那么我们未来可以期待看到什么？

分布式追踪的未来

即时检测，无需更改代码

想象一下，放入一个代理并能够一次性覆盖整个分布式系统（所有服务、组件），而无需更改代码。

这在未来 2-3 年内看起来确实是可能的。

OpenTelemetry 的自动检测库已经为某些编程语言启用了此功能（但是在 Go 等编译语言中存在不足）。与此同时， eBPF 等技术正在不断发展，以实现系统范围内的检测，而无需更改代码。两者之间，我们可以放心地期望仪器问题将在几年内得到解决。

抽样让位于基于人工智能的兴趣请求选择

在法学硕士的世界里，随机抽样开始看起来像是黑暗时代的遗迹。理想情况下，我们应该能够查看 100% 的痕迹，识别任何看起来异常的东西，并将其存储起来以供将来检查。不再随机抽样。

如果我们仔细想想，我们并不真正关心大约 95% 的“满意的请求”。我们只关心大约 5% 的异常痕迹 - 错误、异常、高延迟或某种形式的软错误。所以我们只需要一种方法来查看 100% 并挑选出有趣的 5%。

如今有一些机制（例如基于尾部的采样）旨在实现这一目标。在基于尾部的采样中，系统会等待请求中的所有跨度都完成，然后根据完整的跟踪来决定是否必须保留它。

基于尾部的采样的主要挑战是，您必须存储跟踪的所有范围，直到整个请求完成，然后决定是否保留/丢弃跟踪。这意味着我们将每个请求以及所有跨度存储一段时间（直到请求完成）——这需要一个单独的数据架构，其中包含用于负载平衡、存储和处理的组件，这是高度复杂且昂贵的。

OpenTelemetry 有一个基于尾部的采样收集器，但是它还不成熟，并且存在一些可扩展性挑战（由于上述问题）。与此同时，包括ZeroK.ai在内的多家公司正在致力于使用人工智能来提高异常检测的效率和可扩展性。

随着该领域的快速发展，我们可以合理预期该问题也将在未来 3-5 年内得到解决。

“丰富”的分布式跟踪的出现使得所有调试成为可能

当跟踪从“仅性能问题”领域发展到“所有问题”时，才是真正飞跃到下一代跟踪。这就是分布式追踪的真正力量被释放的时候。

为了实现这一点，每个跟踪都需要具有丰富的上下文。

想象一个场景，其中每个跟踪中的每个跨度都有：

• 请求和响应有效负载（带有 PII 屏蔽）

• 任何异常的堆栈跟踪

• 日志

• 库伯内特斯事件

• Pod 状态

• 以及在此期间发生的任何其他事情

  
  

一体化、无缝流程。

想象一下，如果人们正在寻找的跟踪非常容易找到 - 不存在与采样相关的数据间隙，问题被重复数据删除和分组，并且可以跨多个维度进行过滤。

这就是开发人员调试任何软件问题所需的全部内容。潜在地，所有人工智能模型都需要诊断并向开发人员指出问题所在。

在这个世界中，轨迹成为可观察性的主轴，取代了日志记录。这就是分布式追踪的最终状态——虽然它还没有出现，但从我们今天的位置来看它是可见的。

实现这一点的主要障碍是存储所有这些上下文数据将导致数据量爆炸。我们需要在数据处理和存储架构方面进行深入创新才能实现这一目标。现在还为时尚早，我们必须等待，看看这里会发生什么。

概括

总之，分布式跟踪是能够观察生产中的分布式应用程序架构所需的必要且直观的视图。

第一代分布式追踪虽然前景光明，但也受到了一些挑战的困扰，这些挑战使得公司很难从追踪中获得价值，这在一定程度上阻碍了其采用。

然而，该领域正在发生一些令人兴奋的发展，预计这些发展将使追踪比我们今天所拥有的更容易、更简单、更强大，使未来的可观察性更加无缝。