0 問題背景

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

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

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

一個請求完整調用鏈

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

1. 如何快速發(fā)現問題？
2. 如何判斷故障影響范圍歌溉？
3. 如何梳理服務依賴以及依賴的合理性垄懂？
4. 如何分析鏈路性能問題以及實時容量規(guī)劃？

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

1. 吞吐量匙头，根據拓撲可計算相應組件漫谷、平臺、物理設備的實時吞吐量蹂析。
2. 響應時間舔示，包括整體調用的響應時間和各個服務的響應時間等。
3. 錯誤記錄电抚，根據服務返回統(tǒng)計單位時間異常次數惕稻。

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

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

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

1 目標要求

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

1. 探針的性能消耗

   APM組件服務的影響應該做到足夠小。服務調用埋點本身會帶來性能損耗豫柬，這就需要調用跟蹤的低損耗告希，實際中還會通過配置采樣率的方式，選擇一部分請求去分析請求路徑烧给。在一些高度優(yōu)化過的服務燕偶，即使一點點損耗也會很容易察覺到，而且有可能迫使在線服務的部署團隊不得不將跟蹤系統(tǒng)關停础嫡。

2. 代碼的侵入性

   即也作為業(yè)務組件指么，應當盡可能少入侵或者無入侵其他業(yè)務系統(tǒng)，對于使用方透明榴鼎，減少開發(fā)人員的負擔伯诬。

   對于應用的程序員來說，是不需要知道有跟蹤系統(tǒng)這回事的巫财。如果一個跟蹤系統(tǒng)想生效盗似，就必須需要依賴應用的開發(fā)者主動配合，那么這個跟蹤系統(tǒng)也太脆弱了翁涤，往往由于跟蹤系統(tǒng)在應用中植入代碼的bug或疏忽導致應用出問題桥言，這樣才是無法滿足對跟蹤系統(tǒng)“無所不在的部署”這個需求。

3. 可擴展性

   一個優(yōu)秀的調用跟蹤系統(tǒng)必須支持分布式部署葵礼，具備良好的可擴展性号阿。能夠支持的組件越多當然越好≡Х郏或者提供便捷的插件開發(fā)API扔涧，對于一些沒有監(jiān)控到的組件，應用開發(fā)者也可以自行擴展。

4. 數據的分析

   數據的分析要快 枯夜，分析的維度盡可能多弯汰。跟蹤系統(tǒng)能提供足夠快的信息反饋，就可以對生產環(huán)境下的異常狀況做出快速反應湖雹。分析的全面咏闪，能夠避免二次開發(fā)。

2 功能模塊

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

1. 埋點與生成日志

   埋點即系統(tǒng)在當前節(jié)點的上下文信息鸽嫂，可以分為 客戶端埋點、服務端埋點征讲，以及客戶端和服務端雙向型埋點据某。埋點日志通常要包含以下內容traceId、spanId诗箍、調用的開始時間癣籽，協議類型、調用方ip和端口滤祖，請求的服務名筷狼、調用耗時，調用結果氨距，異常信息等桑逝，同時預留可擴展字段，為下一步擴展做準備俏让；

   不能造成性能負擔：一個價值未被驗證楞遏，卻會影響性能的東西，是很難在公司推廣的首昔！

   因為要寫log寡喝，業(yè)務QPS越高，性能影響越重勒奇。通過采樣和異步log解決预鬓。

2. 收集和存儲日志

   主要支持分布式日志采集的方案，同時增加MQ作為緩沖赊颠；

   1. 每個機器上有一個 deamon 做日志收集格二，業(yè)務進程把自己的Trace發(fā)到daemon，daemon把收集Trace往上一級發(fā)送竣蹦；
   2. 多級的collector顶猜，類似pub/sub架構，可以負載均衡痘括；
   3. 對聚合的數據進行 實時分析和離線存儲长窄；
   4. 離線分析 需要將同一條調用鏈的日志匯總在一起滔吠；

3. 分析和統(tǒng)計調用鏈路數據，以及時效性

   調用鏈跟蹤分析：把同一TraceID的Span收集起來挠日，按時間排序就是timeline疮绷。把ParentID串起來就是調用棧。

   拋異诚保或者超時冬骚，在日志里打印TraceID。利用TraceID查詢調用鏈情況懂算，定位問題唉韭。

   依賴度量：

   1. 強依賴：調用失敗會直接中斷主流程
   2. 高度依賴：一次鏈路中調用某個依賴的幾率高
   3. 頻繁依賴：一次鏈路調用同一個依賴的次數多

   離線分析：按TraceID匯總，通過Span的ID和ParentID還原調用關系犯犁，分析鏈路形態(tài)。

   實時分析：對單條日志直接分析女器，不做匯總酸役，重組。得到當前QPS驾胆，延遲涣澡。

4. 展現以及決策支持

3 Google Dapper

3.1 Span

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

Span

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

Span數據結構：

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。比如：你運行的分布式大數據存儲一次Trace就由你的一次請求組成奈应。

Trace

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

3.3 Annotation

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

(1) cs：Client Start氓皱，表示客戶端發(fā)起請求
(2) sr：Server Receive路召，表示服務端收到請求
(3) ss：Server Send，表示服務端完成處理波材，并將結果發(fā)送給客戶端
(4) cr：Client Received股淡，表示客戶端獲取到服務端返回信息

Annotation數據結構：

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

3.4 調用示例

1. 請求調用示例

   1. 當用戶發(fā)起一個請求時，首先到達前端A服務廷区，然后分別對B服務和C服務進行RPC調用唯灵；
   2. B服務處理完給A做出響應，但是C服務還需要和后端的D服務和E服務交互之后再返還給A服務隙轻，最后由A服務來響應用戶的請求埠帕；

   請求調用示例

2. 調用過程追蹤

   1. 請求到來生成一個全局TraceID，通過TraceID可以串聯起整個調用鏈玖绿，一個TraceID代表一次請求搞监。
   2. 除了TraceID外，還需要SpanID用于記錄調用父子關系镰矿。每個服務會記錄下parent id和span id琐驴，通過他們可以組織一次完整調用鏈的父子關系。
   3. 一個沒有parent id的span成為root span秤标，可以看成調用鏈入口绝淡。
   4. 所有這些ID可用全局唯一的64位整數表示；
   5. 整個調用過程中每個請求都要透傳TraceID和SpanID苍姜。
   6. 每個服務將該次請求附帶的TraceID和附帶的SpanID作為parent id記錄下牢酵，并且將自己生成的SpanID也記錄下。
   7. 要查看某次完整的調用則 只要根據TraceID查出所有調用記錄衙猪，然后通過parent id和span id組織起整個調用父子關系馍乙。

   整個調用過程追蹤

3. 調用鏈核心工作

   1. 調用鏈數據生成布近，對整個調用過程的所有應用進行埋點并輸出日志。
   2. 調用鏈數據采集丝格，對各個應用中的日志數據進行采集撑瞧。
   3. 調用鏈數據存儲及查詢，對采集到的數據進行存儲显蝌，由于日志數據量一般都很大预伺，不僅要能對其存儲，還需要能提供快速查詢曼尊。
   4. 指標運算酬诀、存儲及查詢，對采集到的日志數據進行各種指標運算骆撇，將運算結果保存起來瞒御。
   5. 告警功能，提供各種閥值警告功能神郊。

4. 整體部署架構

   整體部署架構

   1. 通過AGENT生成調用鏈日志葵腹。
   2. 通過logstash采集日志到kafka。
   3. kafka負責提供數據給下游消費屿岂。
   4. storm計算匯聚指標結果并落到es。
   5. storm抽取trace數據并落到es鲸匿，這是為了提供比較復雜的查詢爷怀。比如通過時間維度查詢調用鏈，可以很快查詢出所有符合的traceID带欢，根據這些traceID再去 Hbase 查數據就快了运授。
   6. logstash將kafka原始數據拉取到hbase中。hbase的rowkey為traceID乔煞，根據traceID查詢是很快的吁朦。

5. AGENT無侵入部署

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

   1. 服務內AGENT纺讲，這種方式是通過 Java 的agent機制，對服務內部的方法調用層次信息進行數據收集囤屹，如方法調用耗時熬甚、入參、出參等信息肋坚。

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

      （1）Dubbo支持；
      
      （2）Rest支持诲泌；
      
      （3）自定義RPC支持盲赊；
      

6. 調用鏈監(jiān)控好處

   1. 準確掌握生產一線應用部署情況；
   2. 從調用鏈全流程性能角度档礁，識別對關鍵調用鏈角钩，并進行優(yōu)化；
   3. 提供可追溯的性能數據呻澜，量化 IT 運維部門業(yè)務價值递礼；
   4. 快速定位代碼性能問題，協助開發(fā)人員持續(xù)性的優(yōu)化代碼羹幸；
   5. 協助開發(fā)人員進行白盒測試脊髓，縮短系統(tǒng)上線穩(wěn)定期；

4 方案比較

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

1. Zipkin：由Twitter公司開源将硝，開放源代碼分布式的跟蹤系統(tǒng)，用于收集服務的定時數據屏镊，以解決微服務架構中的延遲問題依疼，包括：數據的收集、存儲而芥、查找和展現律罢。
2. Pinpoint：一款對Java編寫的大規(guī)模分布式系統(tǒng)的APM工具，由韓國人開源的分布式跟蹤組件棍丐。
3. Skywalking：國產的優(yōu)秀APM組件误辑，是一個對JAVA分布式應用程序集群的業(yè)務運行情況進行追蹤、告警和分析的系統(tǒng)歌逢。

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

1. 探針的性能

   主要是agent對服務的吞吐量巾钉、CPU和內存的影響。微服務的規(guī)模和動態(tài)性使得數據收集的成本大幅度提高秘案。

2. collector的可擴展性

   能夠水平擴展以便支持大規(guī)模服務器集群砰苍。

3. 全面的調用鏈路數據分析

   提供代碼級別的可見性以便輕松定位失敗點和瓶頸。

4. 對于開發(fā)透明阱高，容易開關

   添加新功能而無需修改代碼师骗，容易啟用或者禁用。

5. 完整的調用鏈應用拓撲

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

4.1 探針的性能

比較關注探針的性能辟癌，畢竟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.2 collector的可擴展性

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

1. zipkin

   開發(fā)zipkin-Server（其實就是提供的開箱即用包）采缚，zipkin-agent與zipkin-Server通過http或者mq進行通信针炉，http通信會對正常的訪問造成影響，所以還是推薦基于mq異步方式通信扳抽，zipkin-Server通過訂閱具體的topic進行消費篡帕。這個當然是可以擴展的，多個zipkin-Server實例進行異步消費mq中的監(jiān)控信息贸呢。

   zipkin

2. skywalking

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

3. pinpoint

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

4.3 全面的調用鏈路數據分析

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

1. zipkin

   zipkin鏈路調用分析

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

2. skywalking

   skywalking鏈路調用分析

   skywalking 還支持20+的中間件览芳、框架斜姥、類庫，比如：主流的dubbo沧竟、Okhttp铸敏，還有DB和消息中間件。上圖skywalking鏈路調用分析截取的比較簡單悟泵，網關調用user服務杈笔，由于支持眾多的中間件，所以skywalking鏈路調用分析比zipkin完備些糕非。

3. pinpoint

   pinpoint鏈路調用分析

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

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

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

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

4.5 完整的調用鏈應用拓撲

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

pinpoint鏈路拓撲

skywalking鏈路拓撲

zipkin鏈路拓撲

上面三幅圖宣虾，分別展示了APM組件各自的調用拓撲惯裕，都能實現完整的調用鏈應用拓撲。相對來說绣硝，pinpoint界面顯示的更加豐富蜻势，具體到調用的DB名，zipkin的拓撲局限于服務于服務之間鹉胖。

4.6 Pinpoint與Zipkin細化比較

4.6.1 Pinpoint與Zipkin差異性

1. Pinpoint 是一個完整的性能監(jiān)控解決方案：有從探針握玛、收集器、存儲到 Web 界面等全套體系甫菠；而 Zipkin 只側重收集器和存儲服務挠铲，雖然也有用戶界面，但其功能與 Pinpoint 不可同日而語寂诱。反而 Zipkin 提供有 Query 接口拂苹，更強大的用戶界面和系統(tǒng)集成能力，可以基于該接口二次開發(fā)實現刹衫。
2. Zipkin 官方提供有基于 Finagle 框架（Scala 語言）的接口醋寝，而其他框架的接口由社區(qū)貢獻搞挣，目前可以支持 Java带迟、Scala、Node囱桨、Go仓犬、Python、Ruby 和 C# 等主流開發(fā)語言和框架舍肠；但是 Pinpoint 目前只有官方提供的 Java Agent 探針搀继，其他的都在請求社區(qū)支援中（請參見 #1759 和 #1760）窘面。
3. Pinpoint 提供有 Java Agent 探針，通過字節(jié)碼注入的方式實現調用攔截和數據收集叽躯，可以做到真正的代碼無侵入财边，只需要在啟動服務器的時候添加一些參數，就可以完成探針的部署点骑；而 Zipkin 的 Java 接口實現 Brave酣难，只提供了基本的操作 API，如果需要與框架或者項目集成的話黑滴，就需要手動添加配置文件或增加代碼憨募。
4. Pinpoint 的后端存儲基于 HBase，而 Zipkin 基于 Cassandra袁辈。

4.6.2 Pinpoint與Zipkin相似性

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

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

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

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

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

4.6.4 難度及成本

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

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

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

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

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

4.6.5 通用性和擴展性

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

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

4.6.6 社區(qū)支持

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

4.6.7 其他

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

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

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

4.6.8 總結

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

5 Tracing和Monitor區(qū)別

Monitor可分為系統(tǒng)監(jiān)控和應用監(jiān)控闷哆。系統(tǒng)監(jiān)控比如CPU腰奋，內存，網絡抱怔，磁盤等等整體的系統(tǒng)負載的數據劣坊，細化可具體到各進程的相關數據。這一類信息是直接可以從系統(tǒng)中得到的屈留。應用監(jiān)控需要應用提供支持局冰，暴露了相應的數據。比如應用內部請求的QPS灌危，請求處理的延時康二，請求處理的error數，消息隊列的隊列長度勇蝙，崩潰情況沫勿，進程垃圾回收信息等等。Monitor主要目標是發(fā)現異常味混，及時報警藕帜。

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

Tracing和應用級的Monitor技術棧上有很多共同點盗誊。都有數據的采集时甚，分析隘弊，存儲和展式。只是具體收集的數據維度不同荒适，分析過程不一樣梨熙。