容器、Serverless 程式設計方式的誕生極大提升了軟體傳遞與部署的效率。在架構的演化過程中，可以看到兩個變化：
應用架構開始從單體系統逐漸轉變為微服務，其中的業務邏輯随之而來就會變成微服務之間的調用與請求。
資源角度來看，傳統伺服器這個實體機關也逐漸淡化，變成了看不見摸不到的虛拟資源模式。
從以上兩個變化可以看到這種彈性、标準化的架構背後，原先運維與診斷的需求也變得越來越複雜。為了應對這種變化趨勢，誕生一系列面向 DevOps 的診斷與分析系統，包括集中式日志系統（Logging），集中式度量系統（Metrics）和分布式追蹤系統（Tracing）。
Logging，Metrics 和 Tracing 有各自專注的部分。
Logging - 用于記錄離散的事件。例如，應用程式的調試資訊或錯誤資訊。它是我們診斷問題的依據。
Metrics - 用于記錄可聚合的資料。例如，隊列的目前深度可被定義為一個路徑成本，在元素入隊或出隊時被更新；HTTP 請求個數可被定義為一個計數器，新請求到來時進行累加。
Tracing - 用于記錄請求範圍内的資訊。例如，一次遠端方法調用的執行過程和耗時。它是我們排查系統性能問題的利器。
這三者也有互相重疊的部分，如下圖所示。
通過上述資訊，我們可以對已有系統進行分類。例如，Zipkin 專注于 tracing 領域；Prometheus 開始專注于 metrics，随着時間推移可能會內建更多的 tracing 功能，但不太可能深入 logging 領域； ELK，阿裡雲日志服務這樣的系統開始專注于 logging 領域，但同時也不斷地內建其他領域的特性到系統中來，正向上圖中的圓心靠近。
Dapper(Google) : 各 tracer 的基礎
StackDriver Trace (Google)
Zipkin(twitter)
Appdash(golang)
鷹眼(taobao)
谛聽(盤古，阿裡雲雲産品使用的Trace系統)
雲圖(螞蟻Trace系統)
sTrace(神馬)
X-ray(aws)
分布式追蹤系統發展很快，種類繁多，但核心步驟一般有三個：代碼埋點，資料存儲、查詢展示。
下圖是一個分布式調用的例子，用戶端發起請求，請求首先到達負載均衡器，接着經過認證服務，計費服務，然後請求資源，最後傳回結果。
資料被采集存儲後，分布式追蹤系統一般會選擇使用包含時間軸的時序圖來呈現這個 Trace。
但在資料采集過程中，由于需要侵入使用者代碼，并且不同系統的 API 并不相容，這就導緻了如果您希望切換追蹤系統，往往會帶來較大改動。
OpenTracing 是一個輕量級的标準化層，它位于應用程式/類庫和追蹤或日志分析程式之間。
OpenTracing 已進入 CNCF，正在為全球的分布式追蹤，提供統一的概念和資料标準。
OpenTracing 通過提供平台無關、廠商無關的 API，使得開發人員能夠友善的添加（或更換）追蹤系統的實作。
OpenTracing 中的 Trace（調用鍊）通過歸屬于此調用鍊的 Span 來隐性的定義。
特别說明，一條 Trace（調用鍊）可以被認為是一個由多個 Span 組成的有向無環圖（DAG圖），Span 與 Span 的關系被命名為 References。
例如：下面的示例 Trace 就是由8個 Span 組成：
有些時候，使用下面這種，基于時間軸的時序圖可以更好的展現 Trace（調用鍊）：
每個 Span 包含以下的狀态:（譯者注：由于這些狀态會反映在 OpenTracing API 中，是以會保留部分英文說明）
An operation name，操作名稱
A start timestamp，起始時間
A finish timestamp，結束時間
Span Tag，一組鍵值對構成的 Span 标簽集合。鍵值對中，鍵必須為 string，值可以是字元串，布爾，或者數字類型。
Span Log，一組 span 的日志集合。
每次 log 操作包含一個鍵值對，以及一個時間戳。
鍵值對中，鍵必須為 string，值可以是任意類型。
但是需要注意，不是所有的支援 OpenTracing 的 Tracer，都需要支援所有的值類型。
SpanContext，Span 上下文對象 (下面會詳細說明)
References(Span間關系)，相關的零個或者多個 Span（Span 間通過 SpanContext 建立這種關系）
每一個 SpanContext 包含以下狀态：
任何一個 OpenTracing 的實作，都需要将目前調用鍊的狀态（例如：trace 和 span 的 id），依賴一個獨特的 Span 去跨程序邊界傳輸
Baggage Items，Trace 的随行資料，是一個鍵值對集合，它存在于 trace 中，也需要跨程序邊界傳輸
如上圖所示，Jaeger 主要由以下幾部分組成。
Jaeger Client - 為不同語言實作了符合 OpenTracing 标準的 SDK。應用程式通過 API 寫入資料，client library 把 trace 資訊按照應用程式指定的采樣政策傳遞給 jaeger-agent。
Agent - 它是一個監聽在 UDP 端口上接收 span 資料的網絡守護程序，它會将資料批量發送給 collector。它被設計成一個基礎元件，部署到所有的主控端上。Agent 将 client library 和 collector 解耦，為 client library 屏蔽了路由和發現 collector 的細節。
Collector - 接收 jaeger-agent 發送來的資料，然後将資料寫入後端存儲。Collector 被設計成無狀态的元件，是以您可以同時運作任意數量的 jaeger-collector。
Data Store - 後端存儲被設計成一個可插拔的元件，支援将資料寫入 cassandra、elastic search。
Query - 接收查詢請求，然後從後端存儲系統中檢索 trace 并通過 UI 進行展示。Query 是無狀态的，您可以啟動多個執行個體，把它們部署在 nginx 這樣的負載均衡器後面。
需要架設并維護存儲。
UI比較薄弱，有一些個性化的分析需求無法快速滿足（例如對比，統計延遲分布等）。
原生 Jaeger 僅支援将資料持久化到 cassandra 和 elasticsearch 中，使用者需要自行維護後端存儲系統的穩定性，調節存儲容量。Jaeger on Aliyun Log Service 借助阿裡雲日志服務的海量資料處理能力，讓您享受 Jaeger 在分布式追蹤領域給您帶來便捷的同時無需過多關注後端存儲系統的問題。
下面通過一段視訊向您展示如何使用 Jaeger on Aliyun Log Service 診斷 HotROD 出現的問題。視訊包含以下内容：
如何配置日志服務
如何通過 docker-compose 運作 Jaeger
如何運作 HotROD
通過 Jaeger UI 如何檢索特定的 trace
通過 Jaeger UI 如何檢視 trace 的詳細資訊
通過 Jaeger UI 如何定位應用的性能瓶頸
通過日志服務管理控制台，如何定位應用的性能瓶頸
應用程式如何使用 OpenTracing API
<video src="http://cloud.video.taobao.com//play/u/2143829456/p/1/e/6/t/1/50081772711.mp4"></video>
視訊中用到的查詢分析樣例
<a href="http://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html">http://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html</a>
的傑出貢獻！