快速了解分布式跟蹤系統 Zipkin（分布式追蹤系統）

概述

快速啟動

Docker

Java

從源代碼運行

概述

快速啟動

Docker

Java

從源代碼運行

zipkin 的架構

1、Zipkin Tracer

2、Transport

Zipkin Server

流程圖

幾個核心概念

Span

Trace

Annotation

小結

概述

FROM https://zipkin.io/

Zipkin is a distributed tracing system.

Zipkin 是一個分布式鏈路追蹤系統。

It helps gather timing data needed to troubleshoot latency problems in service architectures.

它可以收集分布式場景下的調用鏈路數據，用于解決服務之間延遲問題。

Features include both the collection and lookup of this data.

功能包括四部分：鏈路的收集、存儲、查找、展示。

If you have a trace ID in a log file, you can jump directly to it. Otherwise, you can query based on attributes such as service, operation name, tags and duration. Some interesting data will be summarized for you, such as the percentage of time spent in a service, and whether or not operations failed.

如果在日志文件中有 trace ID，則可以直接跳轉到它。否則，您可以根據服務、操作名稱、tags 和持續時間等屬性進行查詢。將為你總結一些有趣的數據，例如在服務中花費的時間的百分比，以及操作是否失敗。

The Zipkin UI also presents a Dependency diagram showing how many traced requests went through each application. This can be helpful for identifying aggregate behavior including error paths or calls to deprecated services.

Zipkin UI 還提供了一個依賴關系圖，顯示每個應用程序跟蹤了多少請求。這有助于識別聚合行為，包括錯誤路徑或對棄用服務的調用。

Applications need to be “instrumented” to report trace data to Zipkin. This usually means configuration of a tracer or instrumentation library. The most popular ways to report data to Zipkin are via HTTP or Kafka, though many other options exist, such as Apache ActiveMQ, gRPC and RabbitMQ. The data served to the UI are stored in-memory, or persistently with a supported backend such as Apache Cassandra or Elasticsearch.

需要對應用程序進行“檢測”，以便向 Zipkin 報告跟蹤數據。這通常意味著配置跟蹤程序或檢測庫。最流行的向 Zipkin 報告數據的方式是通過 HTTP 或 Kafka，盡管還有許多其他選項，如 Apache ActiveMQ、 gRPC 和 RabbitMQ。提供給用戶界面的數據存儲在內存中，或者通過支持的后端持久地存儲在內存中，比如 Cassandra 或 Elasticsearch。

和市面上其它分布式鏈路追蹤系統一樣，Zipkin 也是根據 Google 論文《Dapper，大規模分布式系統的跟蹤系統》作為理論，進行設計。Zipkin 最初由 Twitter公司開源，而后演化出 Open Zipkin) 社區。

快速啟動

from https://zipkin.io/pages/quickstart.html

in this section we’ll walk through building and starting an instance of Zipkin for checking out Zipkin locally. There are three options: using Java, Docker or running from source.

在本節中，我們將逐步構建并啟動一個 Zipkin 實例，用于檢查本地 Zipkin。有三種選擇: 使用 Java、 Docker 或者從源代碼運行。

If you are familiar with Docker, this is the preferred method to start. If you are unfamiliar with Docker, try running via Java or from source.

如果您熟悉 Docker，這是首選的啟動方法。如果你不熟悉 Docker，可以嘗試通過 Java 或源代碼運行。

Regardless of how you start Zipkin, browse to http://your_host:9411 to find traces!

不管你如何開始 Zipkin，可以瀏覽 http://your_host:9411 網站找到蛛絲馬跡！

Docker

The Docker Zipkin) project is able to build docker images, provide scripts and a docker-compose.yml for launching pre-built images. The quickest start is to run the latest image directly:

Dockerzipkin 項目能夠構建 Docker 鏡像，提供腳本和 Docker-compose。用于運行鏡像。最快的開始是直接運行最新的鏡像:

docker run -d -p 9411:9411 openzipkin/zipkin

Java

if you have Java 8 or higher installed, the quickest way to get started is to fetch the latest release) as a self-contained executable jar:

如果你已經安裝了 Java8 或更高版本，最快的方法就是以獨立的可執行 jar 的形式獲取最新版本:

curl -sSL https://zipkin.io/quickstart.sh | bash -s java -jar zipkin.jar

從源代碼運行

Zipkin can be run from source if you are developing new features. To achieve this, you’ll need to get Zipkin’s source) and build it.

如果你正在開發新的特性，Zipkin 可以從源代碼運行。為了實現這一點，你需要獲得 Zipkin 的源代碼并構建它。

# get the latest source git clone https://github.com/openzipkin/zipkin cd zipkin # Build the server and also make its dependencies ./mvnw -DskipTests --also-make -pl zipkin-server clean install # Run the server java -jar ./zipkin-server/target/zipkin-server-*exec.jar

zipkin 的架構

From https://zipkin.io/pages/architecture.html

Tracers live in your applications and record timing and metadata about operations that took place. They often instrument libraries, so that their use is transparent to users. For example, an instrumented web server records when it received a request and when it sent a response. The trace data collected is called a Span.

示蹤程序存在于應用程序中，記錄發生的操作的計時和元數據。它們經常使用 instrument庫，因此它們的使用對用戶是透明的。例如，一個檢測過的 web 服務器在收到請求和發送響應時都會記錄。收集的跟蹤數據稱為 Span。

Instrumentation is written to be safe in production and have little overhead. For this reason, they only propagate IDs in-band, to tell the receiver there’s a trace in progress. Completed spans are reported to Zipkin out-of-band, similar to how applications report metrics asynchronously.

Instrumentation 的編寫是為了在生產中保證安全，并且開銷很小。由于這個原因，它們只在帶內傳播 id，以告訴接收者有一個正在進行的跟蹤。已完成的跨度報告給 Zipkin 帶外，類似于應用程序異步報告指標的方式。

For example, when an operation is being traced and it needs to make an outgoing http request, a few headers are added to propagate IDs. Headers are not used to send details such as the operation name.

例如，當一個操作正在被跟蹤并且它需要發出一個傳出 http 請求時，會添加一些頭來傳播 id。標頭不用于發送諸如操作名稱之類的詳細信息。

The component in an instrumented app that sends data to Zipkin is called a Reporter. Reporters send trace data via one of several transports to Zipkin collectors, which persist trace data to storage. Later, storage is queried by the API to provide data to the UI.

發送數據到 Zipkin 的測試應用程序中的組件被稱為 Reporter。 記者通過幾種傳輸方式中的一種將跟蹤數據發送給 Zipkin 收集者，這些收集者將跟蹤數據存儲起來。 隨后，存儲將被 API 查詢，以向 UI 提供數據。

Zipkin 整體架構如下圖所示，分成三個部分：

【紅框】Zipkin Tracer ：負責從應用中，收集分布式場景下的調用鏈路數據，發送給 Zipkin Server 服務。

【藍框】Transport ：鏈路數據的傳輸方式，目前有 HTTP、MQ 等等多種方式。

【綠框】Zipkin Server ：負責接收 Tracer 發送的 Tracing 數據信息，將其聚合處理并進行存儲，后提供查詢功能。之后，用戶可通過 Web UI 方便獲得服務延遲、調用鏈路、系統依賴等等。

1、Zipkin Tracer

一般來說，在 Java 應用程序中，我們使用 Brave 庫，作為 Zipkin Server 的 Java Tracer 客戶端。同時它的 instrumentation 子項目，已經提供了 SpringMVC、MySQL、Dubbo 等等的鏈路追蹤的功能。

Instrumented Client 和 Instrumented Server 的區別：

Instrumented Client 和 Instrumented Server，它們是指分布式架構中使用了 Tracer 工具的兩個應用，Client 會調用 Server 提供的服務，兩者都會向 Zipkin 上報鏈路數據。

Non-Instrumented Server，指的是未使用 Trace 工具的 Server，顯然它不會上報鏈路數據，但是調用其的 Instrumented Client 還是會上報鏈路數據。

2、Transport

Reporter 通過 Transport 發送追蹤數據到 Zipkin 的 Collector，Collector 持久化數據到 Storage 中。之后，API 從 Storage 中查詢數據提供給 UI。

一般來說，在 Java 應用程序中，我們使用 zipkin-reporter-java 庫，作為 Zipkin Reporter 客戶端。

包括如下的 Transport 方式：

HTTP ，通過 okhttp3 或 urlconnection 實現。

ActiveMQ，通過 activemq-client 實現。

RabbitMQ，通過 amqp-client 實現。

Kafka，通過 kafka 或 kafka08 實現。

Thrift，通過 libthrift 實現。

請求量級小的時候，選擇 HTTP 方式即可。量級比較大的時候，推薦使用 Kafka 消息隊列。

Zipkin Server

Zipkin Server 包括 Collector、Storage、API、UI 四個組件。

Collector：負責接收 Tracer 發送的鏈路數據，并為了后續的查詢，對鏈路數據進行校驗、存儲、索引。

Storage；負責存儲鏈路數據，目前支持 Memory、MySQL、Cassandra、ElasticSearch 等數據庫。

Memory ：默認存儲器，用于簡單演示為主，生產環境下不推薦。

MySQL ：小規模使用時，可以考慮 MySQL 進行存儲。

ElasticSearch ：主流基本采用 ElasticSearch 存儲鏈路數據。

Cassandra ：在 Twitter 內部被大規模使用，，因為 Cassandra 易跨站，支持靈活的 schema。

API：負責提供了一個簡單的 JSON API 查詢和獲取追蹤數據。API 的主要消費者就是 Web UI。

UI：Web UI 負責提供了基于服務、時間和標記（annotation）查看服務延遲、調用鏈路、系統依賴等等的界面。

流程圖

讓我們來一起看個 Zipkin 的示例流程圖：

from https://zipkin.io/pages/architecture.html

As mentioned in the overview, identifiers are sent in-band and details are sent out-of-band to Zipkin. In both cases, trace instrumentation is responsible for creating valid traces and rendering them properly. For example, a tracer ensures parity between the data it sends in-band (downstream) and out-of-band (async to Zipkin).

正如概述中提到的，標識符發送到帶內，詳細信息發送到帶外 Zipkin。在這兩種情況下，跟蹤檢測都負責創建有效的跟蹤并正確地呈現它們。例如，跟蹤程序確保了它發送的帶內(下游)和帶外(async to Zipkin)數據之間的奇偶校驗。

Here’s an example sequence of http tracing where user code calls the resource /foo. This results in a single span, sent asynchronously to Zipkin after user code receives the http response.

下面是用戶代碼調用資源/foo 的 http 跟蹤示例序列。這將導致一個跨度，在用戶代碼接收到 http 響應后異步發送到 Zipkin。

┌─────────────┐ ┌───────────────────────┐ ┌─────────────┐ ┌──────────────────┐ │ User Code │ │ Trace Instrumentation │ │ Http Client │ │ Zipkin Collector │ └─────────────┘ └───────────────────────┘ └─────────────┘ └──────────────────┘ │ │ │ │ ┌─────────┐ │ ──┤GET /foo ├─? │ ────┐ │ │ └─────────┘ │ record tags │ │ ?───┘ │ │ ────┐ │ │ │ add trace headers │ │ ?───┘ │ │ ────┐ │ │ │ record timestamp │ │ ?───┘ │ │ ┌─────────────────┐ │ │ ──┤GET /foo ├─? │ │ │X-B3-TraceId: aa │ ────┐ │ │ │X-B3-SpanId: 6b │ │ │ │ └─────────────────┘ │ invoke │ │ │ │ request │ │ │ │ │ │ │ ┌────────┐ ?───┘ │ │ ?─────┤200 OK ├─────── │ │ ────┐ └────────┘ │ │ │ record duration │ │ ┌────────┐ ?───┘ │ ?──┤200 OK ├── │ │ │ └────────┘ ┌────────────────────────────────┐ │ │ ──┤ asynchronously report span ├────? │ │ │ │{ │ │ "traceId": "aa", │ │ "id": "6b", │ │ "name": "get", │ │ "timestamp": 1483945573944000,│ │ "duration": 386000, │ │ "annotations": [ │ │--snip-- │ └────────────────────────────────┘

由上圖可以看出，應用的代碼（User Code）發起 Http Get 請求（請求路徑 /foo），經過 Zipkin Tracer 框架（Trace Instrumentation）攔截，并依次經過如下步驟，記錄鏈路信息到 Zipkin Server 中：

1、record tags ：記錄 tags 信息到 Span 中。

2、add trace headers ：將當前調用鏈的鏈路信息記錄到 Http Headers 中。

3、record timestamp ：記錄當前調用的時間戳（timestamp）。

4、發送 HTTP 請求，并攜帶鏈路相關的 Header。例如說， X-B3-TraceId:aa，X-B3-SpandId:6b。

5、調用結束后，記錄當次調用所花的時間（duration）。

6、將步驟 1-5，匯總成一個 Span（最小的 Trace 單元），異步上報該 Span 信息給 Zipkin Collector。

Trace instrumentation report spans asynchronously to prevent delays or failures relating to the tracing system from delaying or breaking user code.

異步地跨越跟蹤檢測報告，以防止與跟蹤系統相關的延遲或故障延遲或破壞用戶代碼。

幾個核心概念

zipkin 涉及 Span、Trace、Annotation 等基本概念，這些概念還是比較重要的，所以下面我們就具體介紹下這些概念。

Span

基本工作單元，Span 表示一個服務調用的開始和結束時間，即執行的時間段。一次鏈路調用（可以是 RPC，DB 等沒有特定的限制）創建一個 span，通過一個 64 位 ID 標識它，uuid 較為方便，span 中還有其他的數據，例如描述信息，時間戳，key-value 對的（Annotation）tag 信息，parent_id 等,其中 parent-id 可以表示span調用鏈路來源。

對于每個 Trace 樹，Trace 都要定義一個全局唯一的 TraceID，在這個跟蹤中的所有 Span 都將獲取到這個TraceID。每個 Span 都有一個 ParentID 和它自己的 SpanID。上面圖中 Frontend Request 調用的 ParentID 為空，SpanID 為 1；然后 Backend Call 的 ParentID 為 1，SpanID 為 2；Backend DoSomething 調用的 ParentID 也為 1，SpanID 為 3，其內部還有兩個調用，Helper Call 的 ParentID 為 3，SpanID 為 4，以此類推。

上圖說明了 span 在一次大的跟蹤過程中是什么樣的。Dapper 記錄了 span 名稱，以及每個 span 的 ID 和父 ID，以重建在一次追蹤過程中不同 span 之間的關系。如果一個 span 沒有父 ID 被稱為 root span。所有 span 都掛在一個特定的跟蹤上，也共用一個 TraceID。

Span 數據結構：

type Span struct { TraceID int64 // 用于標示一次完整的請求id Name string ID int64 // 當前這次調用span_id ParentID int64 // 上層服務的調用span_id 最上層服務parent_id為null Annotation []Annotation // 用于標記的時間戳 Debug bool }

Trace

類似于 樹結構的 Span 集合，表示一次完整的跟蹤，從請求到服務器開始，服務器返回 response 結束，跟蹤每次 rpc 調用的耗時，存在唯一標識 trace_id。比如：你運行的分布式大數據存儲一次 Trace 就由你的一次請求組成。

每種顏色的 note 標注了一個 span，一條鏈路通過 TraceId唯一標識，Span 標識發起的請求信息。樹節點是整個架構的基本單元，而每一個節點又是對 span 的引用。節點之間的連線表示的 span 和它的父 span 直接的關系。雖然 span 在日志文件中只是簡單的代表 span 的開始和結束時間，他們在整個樹形結構中卻是相對獨立的。

Annotation

注解，用來記錄請求特定事件相關信息（例如時間），一個 span 中會有多個 annotation 注解描述。通常包含四個注解信息：

(1) cs：Client Start，表示客戶端發起請求

(2) sr：Server Receive，表示服務端收到請求

(3) ss：Server Send，表示服務端完成處理，并將結果發送給客戶端

(4) cr：Client Received，表示客戶端獲取到服務端返回信息

Annotation 數據結構：

type Annotation struct { Timestamp int64 Value string Host Endpoint Duration int32 }

因為 Zipkin 的模型基本符合 Opentracing 規范，所以大家有空可以去了解下《OpenTracing 官方標準》（https://github.com/opentracing-contrib/opentracing-specification-zh），進一步了解分布式鏈路追蹤。

小結

本文僅僅是簡單的 Zipkin 入門文章，如果大家想更好的使用 Zipkin，推薦詳細閱讀下官方文檔。

Java 分布式

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。