分布式开源_3个开源分布式跟踪工具

最新推荐文章于 2022-10-29 08:15:28 发布

cuml0912

最新推荐文章于 2022-10-29 08:15:28 发布

阅读量263

点赞数

文章标签：分布式 python java 数据库 linux

原文链接：https://opensource.com/article/18/9/distributed-tracing-tools

版权

分布式开源

分布式跟踪系统使用户可以通过分布在多个应用程序，服务和数据库以及诸如代理之类的中介中的软件系统跟踪请求。这样可以更深入地了解软件系统中正在发生的事情。这些系统产生图形表示，这些图形表示请求在每个步骤上花费了多少时间并列出了每个已知步骤。

查看此内容的用户可以确定系统在哪里发生延迟或阻塞。当请求开始失败时，操作员和开发人员可以看到问题的确切位置，而不必像二进制搜索树那样测试系统。这也可以揭示在部署之间可能发生性能变化的地方。通过提醒异常行为自动捕获回归总是比让客户告诉您更好。

这种追踪的东西如何工作？好吧，每个请求都会获得一个特殊的ID，该ID通常会插入标头中。此ID唯一标识该交易。此事务通常称为跟踪。跟踪是整个事务的总体抽象概念。每条迹线由跨度组成。这些跨度是正在执行的实际工作，例如服务调用或数据库请求。每个范围也具有唯一的ID。跨区可以创建称为子跨区的后续跨区，并且子跨区可以具有多个父级。

一旦事务（或跟踪）运行完毕，就可以在表示层中对其进行搜索。我们稍后将在这个空间中讨论一些工具，但是下图显示了Istio演练中的 Jaeger 。它显示单个跟踪的多个跨度。您可以一目了然地更好地了解交易的故事，这样的强大功能立即显而易见。

该演示使用Istio的内置OpenTracing实现，因此即使不修改应用程序也可以进行跟踪。它还使用与OpenTracing兼容的Jaeger。

那么什么是OpenTracing？让我们找出答案。

OpenTracing API

OpenTracing是Zipkin的基础上提供的一种规范，可提供跨平台兼容性。它提供了与供应商无关的API，用于向应用程序添加跟踪并将该数据传递到分布式跟踪系统中。为OpenTracing规范编写的库可与任何兼容OpenTracing的系统一起使用。 Zipkin，Jaeger和Appdash是采用开放标准的开放源代码工具的示例，但即使是Datadog和Instana之类的专有工具也采用了开放标准。随着OpenTracing达到无处不在的状态，这种情况有望继续。

开放式人口普查

好的，我们有OpenTracing，但是在我的搜索中不断弹出的OpenCensus是什么？它是竞争标准，完全不同还是互补？

答案取决于您问谁。我将尽我最大的努力来解释差异（据我所知）：OpenCensus采用了一种更整体的或包罗万象的方法。 OpenTracing专注于建立开放的API和规范，而不是针对每种语言和跟踪系统的开放实现。 OpenCensus不仅提供规范，还提供语言实现和有线协议。它还通过包括通常不在分布式跟踪系统范围内的其他度量来超越跟踪。

OpenCensus允许在运行应用程序的主机上查看数据，但它也具有可插拔的导出器系统，用于将数据导出到中央聚合器。 OpenCensus团队目前生产的出口商包括Zipkin，Prometheus，Jaeger，Stackdriver，Datadog和SignalFx，但是任何人都可以创建出口商。

在我看来，有很多重叠之处。一个不一定比另一个更好，但重要的是要知道每个做什么和不做什么。 OpenTracing主要是一个规范，其他人则负责实现和提出意见。 OpenCensus为本地组件提供了一种全面的方法，尽管意见更多，但仍需要其他系统进行远程聚合。

工具选项

齐普金

Zipkin是最早的此类系统之一。它是由Twitter根据有关Google使用的内部系统的Google Dapper论文开发的。 Zipkin是使用Java编写的，可以将Cassandra或ElasticSearch用作可扩展后端。大多数公司应该对这些选择之一感到满意。支持的最低Java版本是Java6。它还使用Thrift二进制通信协议，该协议在Twitter堆栈中很流行，并作为Apache项目托管。

该系统由报告者（客户端），收集器，查询服务和Web UI组成。 Zipkin旨在通过在事务上下文中仅发送跟踪ID来通知接收者正在进行跟踪的方式来安全生产。然后，将每个报告器中收集的数据异步传输到收集器。收集器将这些跨度存储在数据库中，并且Web UI将这些数据以可消耗格式显示给最终用户。可以通过三种不同的方法将数据传递给收集器：HTTP，Kafka和Scribe。

Zipkin社区还创建了Brave ，它是与Zipkin兼容的Java客户端实现。它没有依赖关系，因此不会拖拽您的项目或将其与与您的企业标准不兼容的库相混淆。还有许多其他实现，并且Zipkin与OpenTracing标准兼容，因此这些实现也应与其他分布式跟踪系统一起使用。流行的Spring框架具有一个名为Spring Cloud Sleuth的组件，该组件与Zipkin兼容。

积家

Jaeger是来自Uber Technologies的较新项目， CNCF已将其作为孵化项目。它是用Golang编写的，因此您不必担心在主机上安装依赖项或解释器或语言虚拟机的任何开销。与Zipkin相似，Jaeger还支持Cassandra和ElasticSearch作为可扩展的存储后端。 Jaeger还与OpenTracing标准完全兼容。

Jaeger的架构类似于Zipkin，具有客户端（报告程序），收集器，查询服务和Web UI，但是在每个主机上还具有一个代理，用于本地聚合数据。代理通过UDP连接接收数据，然后将其分批发送给收集器。收集器以Thrift协议的形式接收该数据并将其存储在Cassandra或ElasticSearch中。查询服务可以直接访问数据存储，并将该信息提供给Web UI。

默认情况下，用户不会从Jaeger客户端获得所有跟踪。系统对通过每个客户端的0.1％（1,000个中的1个）跟踪进行采样。保留和传输所有跟踪信息对于大多数系统而言将有些不堪重负。但是，这可以通过配置代理来增加或减少，客户端为其配置咨询代理。但是，这种采样并不是完全随机的，并且越来越好。 Jaeger使用概率采样，该方法试图对是否应该采样新迹线做出有根据的猜测。自适应采样正在其路线图上，它将通过添加其他决策环境来改进采样算法。

Appdash

Appdash是类似于Jaeger的用Golang编写的分布式跟踪系统。它是由Sourcegraph根据Google的Dapper和Twitter的Zipkin创建的。与Jaeger和Zipkin相似，Appdash支持OpenTracing标准。这是后来添加的内容，需要的组件与默认组件不同。这增加了风险和复杂性。

从高层看，Appdash的体系结构主要由三个组件组成：客户端，本地收集器和远程收集器。没有太多的文档，因此此描述来自测试系统和查看代码。 Appdash中的客户端已添加到您的代码中。 Appdash提供了Python，Golang和Ruby实现，但是OpenTracing库可以与Appdash的OpenTracing实现一起使用。客户端收集跨度并将其发送给本地收集器。然后，本地收集器将数据发送到运行自己的本地收集器的集中式Appdash服务器，该服务器是系统中所有其他节点的远程收集器。