分布式跟蹤系統使用戶能夠通過分布在多個應用程序，服務和數據庫以及代理等中介上的軟件系統來跟蹤請求。這樣可以更深入地了解軟件系統中發生的情況。這些系統生成圖形表示，顯示請求在每個步驟上花費了多少時間并列出每個已知步驟。

用戶可以確定系統在哪里遇到延遲或阻塞。當請求開始失敗時，操作員和開發人員可以確切地看到問題的開始位置，而不是像二進制搜索樹那樣測試系統。這還可以揭示從部署到部署可能發生的性能變化。通過警告異常行為而不是讓客戶告訴你，***自動捕獲回歸。

跟蹤事件是如何工作的?每個請求都會獲得一個特殊的ID，通常會將其注入到標頭中。此ID唯一標識該事務。此事務通常稱為跟蹤。跟蹤是整個事務的整體抽象概念。每個跟蹤都由span組成。這些span是正在執行的實際工作，如服務調用或數據庫請求。每個span也有一個唯一的ID。span可以創建稱為子span的后續span，并且子span可以具有多個父級。

[[245045]]

OpenTracing API

OpenTracing是一種源自Zipkin的規范，旨在提供跨平臺兼容性。它提供了供應商中立的API，用于向應用程序添加跟蹤并將數據傳遞到分布式跟蹤系統。為OpenTracing規范編寫的庫可以與任何符合OpenTracing的系統一起使用。Zipkin，Jaeger和Appdash是采用開放標準的開源工具的例子，但即使是像Datadog和Instana這樣的專有工具也在采用它。隨著OpenTracing無處不在，這種情況有望繼續下去。

OpenCensus

有OpenTracing，但是OpenCensus呢?它是競爭標準，完全不同的東西，還是互補的東西?

OpenTracing專注于建立開放的API和規范，而不是針對每種語言和跟蹤系統的開放實現。OpenCensus不僅提供規范，還提供語言實現和有線協議。它還包括通過包含通常在分布式跟蹤系統范圍之外的其他度量標準來進行跟蹤。

OpenCensus允許在運行應用程序的主機上查看數據，但它還具有可插拔的導出系統，用于將數據導出到中央聚合器。

二者有重疊。一個不一定比另一個好，但重要的是要知道每個做什么和不做什么。OpenTracing主要是一個規范。OpenCensus為本地組件提供了一種整體方法，具有更多的觀點，但仍需要其他系統進行遠程聚合。

Zipkin

是最早的此類系統之一。它是由Twitter基于Google Dapper論文開發的，內容涉及Google使用的內部系統。Zipkin是使用Java編寫的，它可以使用Cassandra或ElasticSearch作為可擴展的后端。大多數公司應該對其中一種選擇感到滿意。支持***的Java版本是Java 6.它還使用Thrift二進制通信協議，該協議在Twitter堆棧中很流行，并作為Apache項目托管。

該系統由reporters(客戶端)，收集器(collectors)，查詢服務和Web UI組成。Zipkin通過在事務上下文中僅傳輸跟蹤ID來通知接收者正在進行跟蹤，從而保證生產中的安全。然后將每個報告器中收集的數據異步傳輸到收集器。收集器將這些span存儲在數據庫中，并且Web UI以可使用的格式將該數據呈現給最終用戶。向收集器傳遞數據可以通過三種不同的方法進行：HTTP，Kafka和Scribe。

Zipkin與OpenTracing標準兼容，流行的Spring框架有一個名為Spring Cloud Sleuth的組件，它與Zipkin兼容。

Jaeger

Jaeger是Uber Technologies的一個新項目，CNCF已將其作為孵化項目采用。它是用Golang編寫的，因此你不必擔心在主機上安裝依賴項或者解釋器或語言虛擬機的任何開銷。與Zipkin類似，Jaeger也支持Cassandra和ElasticSearch作為可擴展的存儲后端。Jaeger還完全兼容OpenTracing標準。

Jaeger的架構與Zipkin類似，包括客戶端(reporters)，收集器，查詢服務和Web UI，但它在每個主機上都有一個本地聚合數據的代理。代理通過UDP連接接收數據，并將其批處理并發送給收集器。收集器以Thrift協議的形式接收該數據，并將該數據存儲在Cassandra或ElasticSearch中。查詢服務可以直接訪問數據存儲并將該信息提供給Web UI。

默認情況下，用戶不會從Jaeger客戶端獲取所有跟蹤。系統會對通過每個客戶端的0.1%(1/1000)跟蹤進行采樣。保留和傳輸所有跟蹤對于大多數系統來說有點壓力。但是，可以通過配置客戶端進行配置的代理來增加或減少這種情況。然而，這種抽樣并不是完全隨機的，它正在變得越來越好。Jaeger使用概率抽樣，試圖對是否應該對新蹤跡進行抽樣進行有根據的猜測。自適應采樣是其路線圖，它將通過添加額外的上下文來制定決策來改進采樣算法。

Appdash

Appdash是一個用Golang編寫的分布式跟蹤系統，就像Jaeger一樣。它是由Sourcegraph基于Google的Dapper和Twitter的Zipkin創建的。與Jaeger和Zipkin類似，Appdash支持OpenTracing標準。

Appdash的架構主要由三個部分組成：客戶端，本地收集器和遠程收集器。沒有很多文檔，所以這個描述來自測試系統和查看代碼。Appdash中的客戶端會添加到你的代碼中。 Appdash提供Python，Golang和Ruby實現，但OpenTracing庫可以與Appdash的OpenTracing實現一起使用。客戶端收集span并將它們發送到本地收集器。然后，本地收集器將數據發送到運行其自己的本地收集器的集中式Appdash服務器，該收集器是系統中所有其他節點的遠程收集器。