前言

隨著微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務。互聯(lián)網(wǎng)應用構建在不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發(fā)、可能使用不同的編程語言來實現(xiàn)、有可能布在了幾千臺服務器，橫跨多個不同的數(shù)據(jù)中心。因此，就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問題的工具，以便發(fā)生故障的時候，能夠快速定位和解決問題。

全鏈路監(jiān)控組件就在這樣的問題背景下產生了。最出名的是谷歌公開的論文提到的 Google Dapper。想要在這個上下文中理解分布式系統(tǒng)的行為，就需要監(jiān)控那些橫跨了不同的應用、不同的服務器之間的關聯(lián)動作。

所以，在復雜的微服務架構系統(tǒng)中，幾乎每一個前端請求都會形成一個復雜的分布式服務調用鏈路。一個請求完整調用鏈可能如下圖所示：

那么在業(yè)務規(guī)模不斷增大、服務不斷增多以及頻繁變更的情況下，面對復雜的調用鏈路就帶來一系列問題：

• 如何快速發(fā)現(xiàn)問題？
• 如何判斷故障影響范圍？
• 如何梳理服務依賴以及依賴的合理性？
• 如何分析鏈路性能問題以及實時容量規(guī)劃？

同時我們會關注在請求處理期間各個調用的各項性能指標，比如：吞吐量（TPS）、響應時間及錯誤記錄等。

• 吞吐量，根據(jù)拓撲可計算相應組件、平臺、物理設備的實時吞吐量。
• 響應時間，包括整體調用的響應時間和各個服務的響應時間等。
• 錯誤記錄，根據(jù)服務返回統(tǒng)計單位時間異常次數(shù)。

全鏈路性能監(jiān)控 從整體維度到局部維度展示各項指標，將跨應用的所有調用鏈性能信息集中展現(xiàn)，可方便度量整體和局部性能，并且方便找到故障產生的源頭，生產上可極大縮短故障排除時間。

有了全鏈路監(jiān)控工具，我們能夠達到：

• 請求鏈路追蹤，故障快速定位：可以通過調用鏈結合業(yè)務日志快速定位錯誤信息。
• 可視化：各個階段耗時，進行性能分析。
• 依賴優(yōu)化：各個調用環(huán)節(jié)的可用性、梳理服務依賴關系以及優(yōu)化。
• 數(shù)據(jù)分析，優(yōu)化鏈路：可以得到用戶的行為路徑，匯總分析應用在很多業(yè)務場景。

1、目標要求

如上所述，那么我們選擇全鏈路監(jiān)控組件有哪些目標要求呢？Google Dapper 中也提到了，總結如下：

• 探針的性能消耗
• 代碼的侵入性
• 可擴展性
• 數(shù)據(jù)的分析

2、功能模塊

一般的全鏈路監(jiān)控系統(tǒng)，大致可分為四大功能模塊：

• 埋點與生成日志
• 收集和存儲日志
• 分析和統(tǒng)計調用鏈路數(shù)據(jù)，以及時效性
• 展現(xiàn)以及決策支持

3、Google Dapper

3.1、Span

基本工作單元，一次鏈路調用（可以是 RPC，DB 等沒有特定的限制）創(chuàng)建一個 span，通過一個 64 位 ID 標識它，uuid 較為方便，span 中還有其他的數(shù)據(jù)，例如描述信息，時間戳，key-value 對的（Annotation）tag 信息，parent_id 等, 其中 parent-id 可以表示 span 調用鏈路來源。

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

Span 數(shù)據(jù)結構：

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

3.2、Trace

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

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

3.3、Annotation

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

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

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

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

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

Annotation 數(shù)據(jù)結構：

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

3.4、調用示例

3.4.1、請求調用示例

當用戶發(fā)起一個請求時，首先到達前端 A 服務，然后分別對 B 服務和 C 服務進行 RPC 調用；

B 服務處理完給 A 做出響應，但是 C 服務還需要和后端的 D 服務和 E 服務交互之后再返還給 A 服務，最后由 A 服務來響應用戶的請求；

3.4.2、調用過程追蹤 

請求到來生成一個全局 TraceID，通過 TraceID 可以串聯(lián)起整個調用鏈，一個 TraceID 代表一次請求。

除了 TraceID 外，還需要 SpanID 用于記錄調用父子關系。每個服務會記錄下 parent id 和 span id，通過他們可以組織一次完整調用鏈的父子關系。

一個沒有 parent id 的 span 成為 root span，可以看成調用鏈入口。

所有這些 ID 可用全局唯一的 64 位整數(shù)表示；

整個調用過程中每個請求都要透傳 TraceID 和 SpanID。

每個服務將該次請求附帶的 TraceID 和附帶的 SpanID 作為 parent id 記錄下，并且將自己生成的 SpanID 也記錄下。

要查看某次完整的調用則 只要根據(jù) TraceID 查出所有調用記錄，然后通過 parent id 和 span id 組織起整個調用父子關系。

3.4.3、調用鏈核心工作

調用鏈數(shù)據(jù)生成，對整個調用過程的所有應用進行埋點并輸出日志。

調用鏈數(shù)據(jù)采集，對各個應用中的日志數(shù)據(jù)進行采集。

調用鏈數(shù)據(jù)存儲及查詢，對采集到的數(shù)據(jù)進行存儲，由于日志數(shù)據(jù)量一般都很大，不僅要能對其存儲，還需要能提供快速查詢。

指標運算、存儲及查詢，對采集到的日志數(shù)據(jù)進行各種指標運算，將運算結果保存起來。

告警功能，提供各種閥值警告功能。

3.4.4、整體部署架構

通過 AGENT 生成調用鏈日志。

通過 logstash 采集日志到 kafka。

kafka 負責提供數(shù)據(jù)給下游消費。

storm 計算匯聚指標結果并落到 es。

storm 抽取 trace 數(shù)據(jù)并落到 es，這是為了提供比較復雜的查詢。比如通過時間維度查詢調用鏈，可以很快查詢出所有符合的 traceID，根據(jù)這些 traceID 再去 Hbase 查數(shù)據(jù)就快了。

logstash 將 kafka 原始數(shù)據(jù)拉取到 hbase 中。hbase 的 rowkey 為 traceID，根據(jù) traceID 查詢是很快的。

3.4.5、AGENT 無侵入部署

通過 AGENT 代理無侵入式部署，將性能測量與業(yè)務邏輯完全分離，可以測量任意類的任意方法的執(zhí)行時間，這種方式大大提高了采集效率，并且減少運維成本。根據(jù)服務跨度主要分為兩大類 AGENT：

務內 AGENT，這種方式是通過 Java 的 agent 機制，對服務內部的方法調用層次信息進行數(shù)據(jù)收集，如方法調用耗時、入?yún)?、出參等信息?/p>

跨服務 AGENT，這種情況需要對主流 RPC 框架以插件形式提供無縫支持。并通過提供標準數(shù)據(jù)規(guī)范以適應自定義 RPC 框架：

• Dubbo 支持；
• Rest 支持；
• 自定義 RPC 支持；

3.4.6、調用鏈監(jiān)控好處

準確掌握生產一線應用部署情況；

從調用鏈全流程性能角度，識別對關鍵調用鏈，并進行優(yōu)化；

提供可追溯的性能數(shù)據(jù)，量化 IT 運維部門業(yè)務價值；

快速定位代碼性能問題，協(xié)助開發(fā)人員持續(xù)性的優(yōu)化代碼；

協(xié)助開發(fā)人員進行白盒測試，縮短系統(tǒng)上線穩(wěn)定期；

4、方案比較

市面上的全鏈路監(jiān)控理論模型大多都是借鑒 Google Dapper 論文，本文重點關注以下三種 APM 組件：

Zipkin：由 Twitter 公司開源，開放源代碼分布式的跟蹤系統(tǒng)，用于收集服務的定時數(shù)據(jù)，以解決微服務架構中的延遲問題，包括：數(shù)據(jù)的收集、存儲、查找和展現(xiàn)。

Pinpoint：一款對 Java 編寫的大規(guī)模分布式系統(tǒng)的 APM 工具，由韓國人開源的分布式跟蹤組件。

Skywalking：國產的優(yōu)秀 APM 組件，是一個對 JAVA 分布式應用程序集群的業(yè)務運行情況進行追蹤、告警和分析的系統(tǒng)。

以上三種全鏈路監(jiān)控方案需要對比的項提煉出來：

• 探針的性能
• collector 的可擴展性
• 全面的調用鏈路數(shù)據(jù)分析
• 對于開發(fā)透明，容易開關
• 完整的調用鏈應用拓撲

探針的性能

比較關注探針的性能，畢竟 APM 定位還是工具，如果啟用了鏈路監(jiān)控組建后，直接導致吞吐量降低過半，那也是不能接受的。對 skywalking、zipkin、pinpoint 進行了壓測，并與基線（未使用探針）的情況進行了對比。

選用了一個常見的基于 Spring 的應用程序，他包含 Spring Boot, Spring MVC，redis 客戶端，mysql。監(jiān)控這個應用程序，每個 trace，探針會抓取 5 個 span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。這邊基本和 skywalkingtest 的測試應用差不多。

模擬了三種并發(fā)用戶：500，750，1000。使用 jmeter 測試，每個線程發(fā)送 30 個請求，設置思考時間為 10ms。使用的采樣率為 1，即 100%，這邊與生產可能有差別。pinpoint 默認的采樣率為 20，即 50%，通過設置 agent 的配置文件改為 100%。zipkin 默認也是 1。組合起來，一共有 12 種。下面看下匯總表：

從上表可以看出，在三種鏈路監(jiān)控組件中，skywalking 的探針對吞吐量的影響最小，zipkin 的吞吐量居中。pinpoint 的探針對吞吐量的影響較為明顯，在 500 并發(fā)用戶時，測試服務的吞吐量從 1385 降低到 774，影響很大。然后再看下 CPU 和 memory 的影響，在內部服務器進行的壓測，對 CPU 和 memory 的影響都差不多在 10% 之內。

4.1、collector 的可擴展性

collector 的可擴展性，使得能夠水平擴展以便支持大規(guī)模服務器集群。

4.1.1、zipkin

4.1.2、skywalking

skywalking 的 collector 支持兩種部署方式：單機和集群模式。collector 與 agent 之間的通信使用了 gRPC。

4.1.3、pinpoint

同樣，pinpoint 也是支持集群和單機部署的。pinpoint agent 通過 thrift 通信框架，發(fā)送鏈路信息到 collector。

4.2、全面的調用鏈路數(shù)據(jù)分析

全面的調用鏈路數(shù)據(jù)分析，提供代碼級別的可見性以便輕松定位失敗點和瓶頸。

4.2.1、zipkin

 zipkin 的鏈路監(jiān)控粒度相對沒有那么細，從上圖可以看到調用鏈中具體到接口級別，再進一步的調用信息并未涉及。

4.2.2、 skywalking

skywalking 還支持 20+ 的中間件、框架、類庫，比如：主流的 dubbo、Okhttp，還有 DB 和消息中間件。上圖 skywalking 鏈路調用分析截取的比較簡單，網(wǎng)關調用 user 服務，由于支持眾多的中間件，所以 skywalking 鏈路調用分析比 zipkin 完備些。

4.2.3、pinpoint

pinpoint 應該是這三種 APM 組件中，數(shù)據(jù)分析最為完備的組件。提供代碼級別的可見性以便輕松定位失敗點和瓶頸，上圖可以看到對于執(zhí)行的 sql 語句，都進行了記錄。還可以配置報警規(guī)則等，設置每個應用對應的負責人，根據(jù)配置的規(guī)則報警，支持的中間件和框架也比較完備。

4.4、對于開發(fā)透明，容易開關

對于開發(fā)透明，容易開關，添加新功能而無需修改代碼，容易啟用或者禁用。我們期望功能可以不修改代碼就工作并希望得到代碼級別的可見性。

對于這一點，Zipkin 使用修改過的類庫和它自己的容器 (Finagle) 來提供分布式事務跟蹤的功能。但是，它要求在需要時修改代碼。skywalking 和 pinpoint 都是基于字節(jié)碼增強的方式，開發(fā)人員不需要修改代碼，并且可以收集到更多精確的數(shù)據(jù)因為有字節(jié)碼中的更多信息。

4.5、完整的調用鏈應用拓撲

自動檢測應用拓撲，幫助你搞清楚應用的架構。

 上面三幅圖，分別展示了 APM 組件各自的調用拓撲，都能實現(xiàn)完整的調用鏈應用拓撲。相對來說，pinpoint 界面顯示的更加豐富，具體到調用的 DB 名，zipkin 的拓撲局限于服務于服務之間。

4.6、Pinpoint 與 Zipkin 細化比較

4.6.1、Pinpoint 與 Zipkin 差異性

Pinpoint 是一個完整的性能監(jiān)控解決方案：有從探針、收集器、存儲到 Web 界面等全套體系；而 Zipkin 只側重收集器和存儲服務，雖然也有用戶界面，但其功能與 Pinpoint 不可同日而語。反而 Zipkin 提供有 Query 接口，更強大的用戶界面和系統(tǒng)集成能力，可以基于該接口二次開發(fā)實現(xiàn)。

Zipkin 官方提供有基于 Finagle 框架（Scala 語言）的接口，而其他框架的接口由社區(qū)貢獻，目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流開發(fā)語言和框架；但是 Pinpoint 目前只有官方提供的 Java Agent 探針，其他的都在請求社區(qū)支援中（請參見 #1759 和 #1760）。

Pinpoint 提供有 Java Agent 探針，通過字節(jié)碼注入的方式實現(xiàn)調用攔截和數(shù)據(jù)收集，可以做到真正的代碼無侵入，只需要在啟動服務器的時候添加一些參數(shù)，就可以完成探針的部署；而 Zipkin 的 Java 接口實現(xiàn) Brave，只提供了基本的操作 API，如果需要與框架或者項目集成的話，就需要手動添加配置文件或增加代碼。

Pinpoint 的后端存儲基于 HBase，而 Zipkin 基于 Cassandra。

4.6.2、Pinpoint 與 Zipkin 相似性

Pinpoint 與 Zipkin 都是基于 Google Dapper 的那篇論文，因此理論基礎大致相同。兩者都是將服務調用拆分成若干有級聯(lián)關系的 Span，通過 SpanId 和 ParentSpanId 來進行調用關系的級聯(lián)；最后再將整個調用鏈流經的所有的 Span 匯聚成一個 Trace，報告給服務端的 collector 進行收集和存儲。

即便在這一點上，Pinpoint 所采用的概念也不完全與那篇論文一致。比如他采用 TransactionId 來取代 TraceId，而真正的 TraceId 是一個結構，里面包含了 TransactionId, SpanId 和 ParentSpanId。而且 Pinpoint 在 Span 下面又增加了一個 SpanEvent 結構，用來記錄一個 Span 內部的調用細節(jié)（比如具體的方法調用等等），因此 Pinpoint 默認會比 Zipkin 記錄更多的跟蹤數(shù)據(jù)。但是理論上并沒有限定 Span 的粒度大小，所以一個服務調用可以是一個 Span，那么每個服務中的方法調用也可以是個 Span，這樣的話，其實 Brave 也可以跟蹤到方法調用級別，只是具體實現(xiàn)并沒有這樣做而已。

4.6.3、字節(jié)碼注入 vs API 調用

Pinpoint 實現(xiàn)了基于字節(jié)碼注入的 Java Agent 探針，而 Zipkin 的 Brave 框架僅僅提供了應用層面的 API，但是細想問題遠不那么簡單。字節(jié)碼注入是一種簡單粗暴的解決方案，理論上來說無論任何方法調用，都可以通過注入代碼的方式實現(xiàn)攔截，也就是說沒有實現(xiàn)不了的，只有不會實現(xiàn)的。但 Brave 則不同，其提供的應用層面的 API 還需要框架底層驅動的支持，才能實現(xiàn)攔截。比如，MySQL 的 JDBC 驅動，就提供有注入 interceptor 的方法，因此只需要實現(xiàn) StatementInterceptor 接口，并在 Connection String 中進行配置，就可以很簡單的實現(xiàn)相關攔截；而與此相對的，低版本的 MongoDB 的驅動或者是 Spring Data MongoDB 的實現(xiàn)就沒有如此接口，想要實現(xiàn)攔截查詢語句的功能，就比較困難。

因此在這一點上，Brave 是硬傷，無論使用字節(jié)碼注入多么困難，但至少也是可以實現(xiàn)的，但是 Brave 卻有無從下手的可能，而且是否可以注入，能夠多大程度上注入，更多的取決于框架的 API 而不是自身的能力。

4.6.4、難度及成本

經過簡單閱讀 Pinpoint 和 Brave 插件的代碼，可以發(fā)現(xiàn)兩者的實現(xiàn)難度有天壤之別。在都沒有任何開發(fā)文檔支撐的前提下，Brave 比 Pinpoint 更容易上手。Brave 的代碼量很少，核心功能都集中在 brave-core 這個模塊下，一個中等水平的開發(fā)人員，可以在一天之內讀懂其內容，并且能對 API 的結構有非常清晰的認識。

Pinpoint 的代碼封裝也是非常好的，尤其是針對字節(jié)碼注入的上層 API 的封裝非常出色，但是這依然要求閱讀人員對字節(jié)碼注入多少有一些了解，雖然其用于注入代碼的核心 API 并不多，但要想了解透徹，恐怕還得深入 Agent 的相關代碼，比如很難一目了然的理解 addInterceptor 和 addScopedInterceptor 的區(qū)別，而這兩個方法就是位于 Agent 的有關類型中。

因為 Brave 的注入需要依賴底層框架提供相關接口，因此并不需要對框架有一個全面的了解，只需要知道能在什么地方注入，能夠在注入的時候取得什么數(shù)據(jù)就可以了。就像上面的例子，我們根本不需要知道 MySQL 的 JDBC Driver 是如何實現(xiàn)的也可以做到攔截 SQL 的能力。但是 Pinpoint 就不然，因為 Pinpoint 幾乎可以在任何地方注入任何代碼，這需要開發(fā)人員對所需注入的庫的代碼實現(xiàn)有非常深入的了解，通過查看其 MySQL 和 Http Client 插件的實現(xiàn)就可以洞察這一點，當然這也從另外一個層面說明 Pinpoint 的能力確實可以非常強大，而且其默認實現(xiàn)的很多插件已經做到了非常細粒度的攔截。

針對底層框架沒有公開 API 的時候，其實 Brave 也并不完全無計可施，我們可以采取 AOP 的方式，一樣能夠將相關攔截注入到指定的代碼中，而且顯然 AOP 的應用要比字節(jié)碼注入簡單很多。

以上這些直接關系到實現(xiàn)一個監(jiān)控的成本，在 Pinpoint 的官方技術文檔中，給出了一個參考數(shù)據(jù)。如果對一個系統(tǒng)集成的話，那么用于開發(fā) Pinpoint 插件的成本是 100，將此插件集成入系統(tǒng)的成本是 0；但對于 Brave，插件開發(fā)的成本只有 20，而集成成本是 10。從這一點上可以看出官方給出的成本參考數(shù)據(jù)是 5:1。但是官方又強調了，如果有 10 個系統(tǒng)需要集成的話，那么總成本就是 10 * 10 + 20 = 120，就超出了 Pinpoint 的開發(fā)成本 100，而且需要集成的服務越多，這個差距就越大。

4.6.5、通用性和擴展性

很顯然，這一點上 Pinpoint 完全處于劣勢，從社區(qū)所開發(fā)出來的集成接口就可見一斑。

Pinpoint 的數(shù)據(jù)接口缺乏文檔，而且也不太標準（參考論壇討論帖），需要閱讀很多代碼才可能實現(xiàn)一個自己的探針（比如 Node 的或者 PHP 的）。而且團隊為了性能考慮使用了 Thrift 作為數(shù)據(jù)傳輸協(xié)議標準，比起 HTTP 和 JSON 而言難度增加了不少。

4.6.6、社區(qū)支持

這一點也不必多說，Zipkin 由 Twitter 開發(fā)，可以算得上是明星團隊，而 Naver 的團隊只是一個默默無聞的小團隊（從 #1759 的討論中可以看出）。雖然說這個項目在短期內不太可能消失或停止更新，但畢竟不如前者用起來更加放心。而且沒有更多社區(qū)開發(fā)出來的插件，讓 Pinpoint 只依靠團隊自身的力量完成諸多框架的集成實屬困難，而且他們目前的工作重點依然是在提升性能和穩(wěn)定性上。

4.6.7、其他

Pinpoint 在實現(xiàn)之初就考慮到了性能問題，www.naver.com 網(wǎng)站的后端某些服務每天要處理超過 200 億次的請求，因此他們會選擇 Thrift 的二進制變長編碼格式、而且使用 UDP 作為傳輸鏈路，同時在傳遞常量的時候也盡量使用數(shù)據(jù)參考字典，傳遞一個數(shù)字而不是直接傳遞字符串等等。這些優(yōu)化也增加了系統(tǒng)的復雜度：包括使用 Thrift 接口的難度、UDP 數(shù)據(jù)傳輸?shù)膯栴}、以及數(shù)據(jù)常量字典的注冊問題等等。

相比之下，Zipkin 使用熟悉的 Restful 接口加 JSON，幾乎沒有任何學習成本和集成難度，只要知道數(shù)據(jù)傳輸結構，就可以輕易的為一個新的框架開發(fā)出相應的接口。

另外 Pinpoint 缺乏針對請求的采樣能力，顯然在大流量的生產環(huán)境下，不太可能將所有的請求全部記錄，這就要求對請求進行采樣，以決定什么樣的請求是我需要記錄的。Pinpoint 和 Brave 都支持采樣百分比，也就是百分之多少的請求會被記錄下來。但是，除此之外 Brave 還提供了 Sampler 接口，可以自定義采樣策略，尤其是當進行 A/B 測試的時候，這樣的功能就非常有意義了。

4.6.8、小結

從短期目標來看，Pinpoint 確實具有壓倒性的優(yōu)勢：無需對項目代碼進行任何改動就可以部署探針、追蹤數(shù)據(jù)細?；椒椒ㄕ{用級別、功能強大的用戶界面以及幾乎比較全面的 Java 框架支持。但是長遠來看，學習 Pinpoint 的開發(fā)接口，以及未來為不同的框架實現(xiàn)接口的成本都還是個未知數(shù)。相反，掌握 Brave 就相對容易，而且 Zipkin 的社區(qū)更加強大，更有可能在未來開發(fā)出更多的接口。在最壞的情況下，我們也可以自己通過 AOP 的方式添加適合于我們自己的監(jiān)控代碼，而并不需要引入太多的新技術和新概念。而且在未來業(yè)務發(fā)生變化的時候，Pinpoint 官方提供的報表是否能滿足要求也不好說，增加新的報表也會帶來不可以預測的工作難度和工作量。

4.7、Tracing 和 Monitor 區(qū)別

Monitor 可分為系統(tǒng)監(jiān)控和應用監(jiān)控。系統(tǒng)監(jiān)控比如 CPU，內存，網(wǎng)絡，磁盤等等整體的系統(tǒng)負載的數(shù)據(jù)，細化可具體到各進程的相關數(shù)據(jù)。這一類信息是直接可以從系統(tǒng)中得到的。應用監(jiān)控需要應用提供支持，暴露了相應的數(shù)據(jù)。比如應用內部請求的 QPS，請求處理的延時，請求處理的 error 數(shù)，消息隊列的隊列長度，崩潰情況，進程垃圾回收信息等等。Monitor 主要目標是發(fā)現(xiàn)異常，及時報警。

Tracing 的基礎和核心都是調用鏈。相關的 metric 大多都是圍繞調用鏈分析得到的。Tracing 主要目標是系統(tǒng)分析。提前找到問題比出現(xiàn)問題后再去解決更好。

Tracing 和應用級的 Monitor 技術棧上有很多共同點。都有數(shù)據(jù)的采集，分析，存儲和展式。只是具體收集的數(shù)據(jù)維度不同，分析過程不一樣。

以上就是全鏈路監(jiān)控平臺Pinpoint SkyWalking Zipkin選型對比的詳細內容，更多關于全鏈路監(jiān)控Pinpoint SkyWalking Zipkin對比的資料請關注腳本之家其它相關文章！

最新評論