分布式追踪系统使用户能够跟踪请求穿过分布式在多个应用、服务和数据库以及代理等中间媒介的软件系统。这可以更深入地了解软件系统内部正在发生的事情。这些系统生成图形化表示，显示请求在每个步骤上花费了多少时间，并列出每个已知的步骤。
审查此内容的用户可以确定系统在何处遇到延迟或阻塞。当请求开始失败时，操作员和开发人员可以准确地看到问题从哪里开始，而不是像二叉搜索树一样测试系统。 这也可以揭示从部署到部署可能发生性能变化的位置。 通过警报异常行为来自动捕获回归总是比让您的客户告诉您更好。
这种追踪技术是如何工作的？ 嗯，每个请求都会获得一个特殊的 ID，通常注入到标头中。 此 ID 唯一标识该事务。 此事务通常称为跟踪。 跟踪是整个事务的总体抽象概念。 每个跟踪都由 span 组成。 这些 span 是正在执行的实际工作，例如服务调用或数据库请求。 每个 span 也有一个唯一的 ID。 Span 可以创建后续的 span，称为子 span，而子 span 可以有多个父 span。
一旦事务（或跟踪）运行完毕，就可以在表示层中搜索它。 在这个领域有几个工具我们稍后会讨论，但下图显示了来自我的 Istio 演练的 Jaeger。 它显示了单个跟踪的多个 span。 这种力量立即显而易见，因为您可以更好地一目了然地了解事务的故事。
此演示使用 Istio 的内置 OpenTracing 实现，因此即使不修改我的应用程序，我也可以进行跟踪。 它还使用了与 OpenTracing 兼容的 Jaeger。
那么什么是 OpenTracing？ 让我们来看看。
OpenTracing API
OpenTracing 是一项规范，它从 Zipkin 发展而来，旨在提供跨平台兼容性。 它为向应用程序添加跟踪并将数据传递到分布式跟踪系统提供了供应商中立的 API。 为 OpenTracing 规范编写的库可以与任何 OpenTracing 兼容的系统一起使用。 Zipkin、Jaeger 和 Appdash 是采用开放标准的开源工具的示例，但即使是 Datadog 和 Instana 等专有工具也在采用它。 随着 OpenTracing 达到普及状态，这种情况预计将继续下去。
OpenCensus
好的，我们有 OpenTracing，但是这个 OpenCensus 东西是什么，它不断出现在我的搜索中？ 它是竞争标准、完全不同的东西还是互补的东西？
答案取决于您问谁。 我将尽力解释差异（就我理解而言）：OpenCensus 采取更全面或全包的方法。 OpenTracing 专注于建立开放的 API 和规范，而不是针对每种语言和跟踪系统的开放实现。 OpenCensus 不仅提供规范，还提供语言实现和线路协议。 它还超越了跟踪，包括通常在分布式跟踪系统范围之外的其他指标。
OpenCensus 允许查看应用程序运行所在主机上的数据，但它也具有可插拔的导出器系统，用于将数据导出到中央聚合器。 OpenCensus 团队当前生成的导出器包括 Zipkin、Prometheus、Jaeger、Stackdriver、Datadog 和 SignalFx，但任何人都可以创建导出器。
从我的角度来看，有很多重叠之处。 一个不一定比另一个更好，但重要的是要知道每个都做什么和不做什么。 OpenTracing 主要是一个规范，其他人进行实施和观点表达。 OpenCensus 为本地组件提供了一种整体方法，具有更多的观点表达，但仍然需要其他系统进行远程聚合。
工具选项
Zipkin
Zipkin 是最早的此类系统之一。 它是由 Twitter 基于关于 Google 使用的内部系统的 Google Dapper 论文 开发的。 Zipkin 是使用 Java 编写的，它可以使用 Cassandra 或 ElasticSearch 作为可扩展的后端。 大多数公司应该对这些选项之一感到满意。 支持的最低 Java 版本是 Java 6。它还使用 Thrift 二进制通信协议，该协议在 Twitter 堆栈中很流行，并作为 Apache 项目托管。
该系统由 reporters（客户端）、collectors、查询服务和 Web UI 组成。 Zipkin 旨在在生产中安全使用，方法是在事务上下文中仅传输跟踪 ID，以通知接收者正在进行跟踪。 然后将每个 reporter 中收集的数据异步传输到 collectors。 Collectors 将这些 span 存储在数据库中，Web UI 以可消费的格式将此数据呈现给最终用户。 向 collectors 交付数据可以通过三种不同的方法进行：HTTP、Kafka 和 Scribe。
Zipkin 社区 还创建了 Brave，这是一个与 Zipkin 兼容的 Java 客户端实现。 它没有依赖项，因此它不会拖累您的项目或用与您的公司标准不兼容的库来搞乱它们。 还有许多其他实现，并且 Zipkin 与 OpenTracing 标准兼容，因此这些实现也应该与其他分布式跟踪系统一起工作。 流行的 Spring 框架有一个名为 Spring Cloud Sleuth 的组件，它与 Zipkin 兼容。
Jaeger
Jaeger 是 Uber Technologies 的一个较新项目，CNCF 后来将其采纳为孵化项目。 它用 Golang 编写，因此您不必担心主机上安装了依赖项，也不必担心解释器或语言虚拟机带来的任何开销。 与 Zipkin 类似，Jaeger 也支持 Cassandra 和 ElasticSearch 作为可扩展的存储后端。 Jaeger 也完全兼容 OpenTracing 标准。
Jaeger 的架构与 Zipkin 类似，具有客户端（reporters）、collectors、查询服务和 Web UI，但它在每台主机上都有一个代理来本地聚合数据。 代理通过 UDP 连接接收数据，对其进行批处理并发送到 collector。 Collector 以 Thrift 协议的形式接收数据，并将数据存储在 Cassandra 或 ElasticSearch 中。 查询服务可以直接访问数据存储，并将信息提供给 Web UI。
默认情况下，用户不会从 Jaeger 客户端获得所有跟踪。 系统对通过每个客户端的跟踪的 0.1%（千分之一）进行采样。 保留和传输所有跟踪对于大多数系统来说有点不堪重负。 但是，可以通过配置代理来增加或减少此值，客户端会咨询代理以获取其配置。 然而，这种抽样并非完全随机，并且正在变得更好。 Jaeger 使用概率抽样，试图对是否应该对新跟踪进行抽样做出有根据的猜测。 自适应采样已在其路线图上，这将通过添加其他上下文来改进抽样算法以进行决策。
Appdash
Appdash 是一个用 Golang 编写的分布式跟踪系统，就像 Jaeger 一样。 它由 Sourcegraph 基于 Google 的 Dapper 和 Twitter 的 Zipkin 创建。 与 Jaeger 和 Zipkin 类似，Appdash 支持 OpenTracing 标准； 这是后来添加的，需要一个与默认组件不同的组件。 这增加了风险和复杂性。
在高层次上，Appdash 的架构主要由三个组件组成：客户端、本地 collector 和远程 collector。 没有太多文档，因此此描述来自测试系统和审查代码。 Appdash 中的客户端被添加到您的代码中。 Appdash 提供 Python、Golang 和 Ruby 实现，但 OpenTracing 库可以与 Appdash 的 OpenTracing 实现一起使用。 客户端收集 span 并将它们发送到本地 collector。 然后，本地 collector 将数据发送到运行其自身本地 collector 的集中式 Appdash 服务器，该服务器是系统中所有其他节点的远程 collector。
评论已关闭。