OpenTracing：分布式跟踪的开源标准

作者：Gianluca Arbezzano254 / 开发者，产品，公司
2017年10月25日

导航至

Spans

日志有助于您了解应用程序正在做什么。大多数应用程序都会为其宿主服务器生成自己的日志。但在现代分布式系统和微服务环境中，日志就远远不够了。

我们可以使用ElasticSearch等服务来收集应用程序的所有日志，当只处理一个应用程序时，这很简单。但如今，应用程序更像是一系列服务的集合，每个服务都会生成自己的日志。由于每个日志记录了服务的操作和事件，我们如何跨这些服务来获取对应用程序的洞察呢？

像这样的问题证明了为什么分布式跟踪正在成为有效监控的必需品，促使需要一种跟踪标准。

OpenTracing理论

虽然跟踪可以提供对随着进程数量增加的应用的可见性，但到目前为止，为跟踪而对系统进行仪表化的工作既费时又复杂。OpenTracing标准改变了这一点，使得应用分布式跟踪的仪表化变得只需最小的努力。

2016年10月，OpenTracing成为在云原生计算基金会指导下的一项项目。在CNCF的管理下，OpenTracing旨在成为分布式系统仪表化的开放、厂商中立的行业标准。它为开发者提供了一种跟踪线程的方法——从开始到结束跟踪请求，并在规模上理解分布式系统。

在OpenTracing中，跟踪描述了事务或工作流在分布式系统中的传播过程。跟踪的概念借鉴了科学界的一个工具，即有向无环图（DAG），它从清晰的开头到清晰的结尾阶段化了一个过程的部分。某些步骤组或中间的跨度可能是可重复的，但永远不会像没有退出条件的“do循环”那样无限重复。

因此，在这个上下文中，跟踪是由跨度组成的DAG——命名、计时操作代表跟踪中连续工作段。分布式跟踪中的每个组件都将贡献自己的跨度。

现在您已经了解了一些背景信息，以下定义应该更容易理解：跟踪是一组共享同一根的跨度。对于OpenTracing，跟踪是通过收集所有共享TraceId的跨度来构建的。

在这种情况下，跨度是一组与特定远程过程调用相对应的注释。每个跨度代表一个时间单位，并有自己的日志。跨度上下文是一个键/值存储，可以附加到特定的跨度上，您可以在上面记录以更好地理解跨度所引用的事件。基本上，跟踪是关于跨度、进程间传播和活动跨度管理。

为什么OpenTracing的采用率在增长

在微服务架构中，相互通信的应用程序比以往任何时候都多。虽然应用程序性能监控对于调试单个应用程序内部很好，但随着系统扩展到多个服务，如何了解每个服务花费了多少时间、异常发生在哪里以及系统的整体健康状况？特别是，如何测量服务之间的网络延迟——例如一个应用程序到另一个应用程序的请求需要多长时间？

进入分布式跟踪仪表化。随着在基于云的环境中进行的服务的高级分布，跟踪将成为支持这些服务的云基础设施的关键部分。

如果您在开发过程中使用过Firefox浏览器，您知道当您打开其浏览器控制台（Ctrl + Shift + J）时，您可以看到当前在缓存中正在执行的组件及其当前操作状态。在某种程度上，那是一种跟踪。

希望服务器端服务跟踪标准的必要性就像客户端端服务跟踪标准的必要性一样明显。我们之所以需要OpenTracing，是因为存在不同的语言和不同的库，每个库可能使用自己的仪表化，可能发送不同的数据，并可能访问自己的数据库。因此，您很少从单个组件中获得单个跟踪。这个事实产生了为应用代码、库代码和所有类型的系统仪表化建立通用语言的需要。

OpenTracing用例

OpenTracing 文档中提供了对追踪的通用定义：“一种轻量级的标准化层，位于应用程序/库代码与各种消费追踪和因果关系数据的系统之间。”作为描述系统行为的标准机制，OpenTracing因此成为应用程序、库、服务、和框架“描述和传播分布式追踪”的一种方式，而无需了解底层的OpenTracing实现。这就是它的价值所在。

如GitHub上所述，OpenTracing的常见用例包括

  • 微服务——例如，重建事务在微服务架构中经过的路径。
  • 缓存——故障排除以确定请求是否触发了缓存。
  • 仲裁——例如，追踪单个过程的完整历史，并确定当多个服务并行而不是顺序地接触它时的行为。
  • 消息总线监控——确定队列中消息的正确跨度（span）和分布，确保它们触发正确的事件序列，并确保某些消息简短、离散，且永远不会成为数据泄露的来源。

InfluxData 与 OpenTracing 的工作

认识到简化微服务平台故障排除的必要性，InfluxData 决定将其追踪功能添加到Zipkin Telegraf插件中。Zipkin是一个分布式追踪系统，有助于收集解决微服务中常见的延迟问题的所需时间数据。

Zipkin使用Cassandra作为其所有追踪的后端存储。我们发现，对于Telegraf来说，收集追踪数据并将其存储到InfluxDB（一个本地的时间序列数据库）很有用。由于这些追踪数据都是带时间戳的，因此InfluxDB是存储它们的更好的选择。它针对时间序列数据进行了优化，并从头开始构建以支持指标和事件。如果您已经在InfluxDB中存储指标，那么在这里存储您的追踪数据也是有意义的，特别是因为您可以使用InfluxData的本机处理引擎Kapacitor操纵/交叉分析追踪与其他指标。

InfluxData 使用我们构建的（技术）。为了验证我们的理论，我们在InfluxDB Cloud服务中实施了OpenTracing。我们将很快分享一些实施细节以及它在故障排除方面的帮助。

由于开发人员想要了解其应用程序中发生的事情，OpenTracing正在得到许多公司的关注。通过OpenTracing，开发人员能够了解每个请求的起始点、目的地以及其旅程中的情况。更多的知识让他们能够采取适当的行动。

您可以观看InfluxData最近的OpenTracing网络研讨会来了解更多信息。