OpenTracing：分布式追踪的开放标准
作者：Gianluca Arbezzano254 / 开发者, 产品, 公司
2017 年 10 月 25 日
导航至
日志帮助您了解您的应用程序正在做什么。几乎每个应用程序都会为其托管服务器生成自己的日志。但是在现代分布式系统和微服务环境中，日志是不够的。
我们可以使用像 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 的常见用例包括
- 微服务——例如，重建事务在微服务架构中经历的旅程。
- 缓存——故障排除以确定请求是否正在命中缓存。
- 仲裁——例如，追踪单个进程的完整历史记录，并确定当多个服务并行而不是顺序联系它时的行为。
- 消息总线监控——确定队列中消息的适当跨度和分布，以确保它们触发正确的事件序列，并确保消息简短、离散，并且永远不是数据泄漏的来源。
InfluxData 在 OpenTracing 方面的工作
认识到简化微服务平台故障排除的需求，InfluxData 决定在其 Zipkin Telegraf 插件中添加追踪功能。Zipkin 是一个分布式追踪系统，可帮助收集解决微服务常见延迟问题所需的时间数据。
Zipkin 使用 Cassandra 作为其所有追踪的后备存储。我们发现 Telegraf 收集追踪，然后将其数据存储到 InfluxDB（原生时间序列数据库）中将非常有用。由于这些追踪都带有时间戳，因此 InfluxDB 是存储它们的更好选择。它针对时间序列数据进行了优化，并从头开始构建用于指标和事件。如果您已经将指标存储在 InfluxDB 中，那么将您的追踪也存储在那里是有意义的，尤其如此，因为您随后可以使用 InfluxData 的原生处理引擎 Kapacitor 来操纵/交叉分析追踪和其他指标。
在 InfluxData，我们使用我们构建的东西。为了验证我们自己的理论，我们正在我们的 InfluxDB Cloud 服务中实施 OpenTracing。我们很快将分享有关实施的详细信息，以及它如何帮助我们进行故障排除。
OpenTracing 受到公司的广泛关注，因为开发人员想知道他们的应用程序中发生了什么。通过 OpenTracing，开发人员能够了解每个请求从哪里开始、要去哪里以及在其旅程中发生了什么。拥有更多知识使他们能够采取适当的行动。
您可以通过观看最近的 InfluxData OpenTracing 网络研讨会了解更多信息。
