[[419923]]

隨著微服務架構的興起，服務端的調用依賴愈加復雜，為了快速定位異常組件與性能瓶頸，接入分布式鏈路追蹤 Trace 已經成為 IT 運維領域的共識。但是，開源自建、開源托管或商業化自研 Trace 產品之間到底有哪些差異，我該如何選擇？這是許多用戶在調研 Trace 方案時都會遇到的疑問，也是最容易混淆的誤區。

為了搞清楚這個問題，我們需要從兩方面入手，一是梳理線上應用的核心風險與典型場景。二是對比開源自建、托管與商業化自研三種 Trace 方案的能力差異。所謂“知己知彼，百戰不殆”，只有結合自身實際情況，才能選擇出最適合的方案。

一 “兩類風險”與“十大典型問題”

線上應用風險主要分為“錯”、“慢”兩大類。其中“錯”的原因通常是程序運行不符合預期，比如 JVM 加載了錯誤版本的類實例，代碼進入異常分支，環境配置錯誤等。而“慢”的原因通常是資源不足，比如突發流量導致 CPU 打滿，微服務或數據庫線程池被耗盡，內存泄漏導致持續 FGC 等等。

無論是“錯”問題，還是“慢”問題。從用戶的角度，都是希望能夠快速定位根因，及時止損，并消除隱患。但是，根據作者五年多的 Trace 開發、運維與雙十一大促備戰經驗來看，絕大部分線上問題是無法僅通過鏈路追蹤的基礎能力就能夠有效定位并解決的。線上系統的復雜性決定了一款優秀的 Trace 產品必須提供更加全面、有效的數據診斷能力，比如代碼級診斷、內存分析、線程池分析等；同時，為了提高 Trace 組件的易用性和穩定性，還需要提供動態采樣、無損統計、接口名稱自動收斂等能力。這也是為什么業界主流 Trace 產品都在逐步向 APM、應用可觀測領域升級。為了方便理解，本文仍然以 Trace 來統一表述應用層的可觀測能力。

綜上所述，線上應用為了保障最終的業務穩定性，在做鏈路追蹤方案選型時，除了 Trace 通用基礎能力外（如調用鏈、服務監控、鏈路拓撲），還可以參考下面列舉的“十大典型問題”（以 Java 應用為例），綜合對比開源自建、開源托管與商業化自研 Trace 產品的差異化表現。

1.【代碼級自動診斷】接口偶發性超時，調用鏈只能看到超時接口名稱，看不到內部方法，無法定位根因，也難以復現，怎么辦？

負責穩定性的同學應該對這種場景不陌生：系統在夜間或整點大促時會出現偶發性的接口超時，等到發現問題再去排查時，已經丟失了異常現場，并且難以復現，無法通過手動 jstack 來診斷。而目前開源的鏈路追蹤實現一般只能通過調用鏈看到超時的接口，具體是什么原因，哪段代碼導致的異常始終無法定位，最后只能不了了之。上述場景重復上演直至釀成故障，最終蒙受巨大的業務損失。

為了解決上述問題，需要一種精準、輕量級的慢調用自動監聽功能，無需事先埋點，就能夠真實還原代碼執行的第一現場，自動記錄慢調用的完整方法棧。如下圖所示，當接口調用超過一定閾值（比如2秒），會啟動對該次慢請求所在線程的監聽，直至該次請求在第 15秒結束后立即停止監聽，精準保留該次請求生命周期內所在線程的快照集，并還原完整的方法棧及耗時。

2.【池化監控】微服務/數據庫線程池經常被打滿，導致服務超時，排查起來非常困難，如何解決？

微服務/數據庫線程池滿導致業務請求超時，這類問題每天都在頻繁發生。具備豐富診斷經驗的同學，會有意識的查看對應的組件日志，比如 Dubbo 在線程池滿的情況下會輸出相關的異常記錄。但是，如果組件沒有輸出線程池信息，或者運維同學排查經驗不夠豐富，這類問題就會變得非常棘手。目前，開源版本 Trace 一般只提供 JVM 概覽監控，無法具體查看每個線程池的狀態，更無法判斷線程池是否耗盡。

而商業化自研 Trace 提供的池化監控可以直接看到指定線程池的最大線程數、當前線程數、活躍線程數等，線程池耗盡或高水位風險一覽無余。此外，還可以設置線程池使用百分比告警，比如設置 Tomcat 線程池當前線程數超過最大線程數 80% 就提前短信通知，達到 100% 時電話告警。

3.【線程分析】大促壓測/發布變更后，發現 CPU 水位非常高，如何分析應用性能瓶頸點，針對性優化？

我們在做大促壓測，或者大版本變更（包含很多代碼邏輯）時，會遇到 CPU 水位突然變得很高，但是又無法清晰的定位是哪一段代碼導致的，只能不停的做 jstack，肉眼比對線程狀態變化，然后根據經驗不斷進行優化嘗試，最終消耗了大量的精力，效果卻一般般。

那么有沒有快速分析應用性能瓶頸的方法呢？答案必須是有，而且不止一種。最常見的就是手動觸發一次持續一段時間（比如 5min） ThreadDump，然后分析這段時間內的線程開銷與方法棧快照。手動觸發 ThreadDump 的缺陷就是性能開銷比較大，無法常態化運行，不能自動保留已發生的現場快照。比如壓測期間 CPU 高，等到壓測結束復盤時，現場已經不在了，手動 ThreadDump 已經來不及了。

第二種就是提供常態化線程分析功能，能夠自動記錄每類線程池的狀態、數量、CPU 耗時和內部方法棧。在任意時間段內，點擊按 CPU 耗時排序，就可以定位 CPU 開銷最大的線程類別，然后點擊方法棧，可以看到具體的代碼卡點，如下圖所示有大量 BLOCKED 狀態的方法卡在數據庫連接獲取，可以通過調大數據庫連接池來優化。

4.【異常診斷】執行發布/配置變更后，接口大量報錯，但無法第一時間定位原因，造成業務故障？

影響線上穩定性的最大“元兇”就是變更，無論是應用發布變更，還是動態配置變更，都可能引起程序運行出現異常。那么，如何快速判斷變更風險，第一時間發現問題，及時止損呢？

在這里，分享一個阿里內部發布系統的異常發布攔截實踐，其中最重要的監測指標之一，就是 Java Exception/Error 的異常數比對。無論是 NPE（NullPointException），還是 OOM（OutOfMemoryError），基于全部/特定異常數的監控與告警，可以快速發現線上異常，特別是變更時間線前后要尤為注意。

獨立的異常分析診斷頁面，可以查看每一類異常的變化趨勢與堆棧詳情，還可以進一步查看關聯的接口分布，如下圖所示。

5.【內存診斷】應用頻繁 FGC，懷疑有內存泄漏，但無法定位異常對象，怎么辦？

FullGC 絕對是 Java 應用最常見問題之一，對象創建過快、內存泄漏等各種原因都會導致 FGC。而排查 FGC 最有效的手段就是執行堆內存 HeapDump。各種對象的內存占用一目了然，清晰可見。

白屏化的內存快照功能，可以指定機器執行一鍵 HeapDump 與分析，大幅提升內存問題的排查效率，還支持內存泄漏場景下自動 Dump 保存異常快照現場，如下圖所示：

6.【在線調試】同一份代碼，線上運行態與本地調試行為不一致，該如何排查？

本地調試通過的代碼，一發到生產環境就各種報錯，到底哪里出了問題？相信開發同學都經歷過這樣的噩夢。而導致這種問題的原因有很多，比如 Maven 依賴多版本沖突，不同環境動態配置參數不一致，不同環境依賴組件差異等等。

為了解決線上運行代碼不符合預期的問題，我們需要一款在線調試診斷工具，能夠實時查看當前程序運行態的源代碼、出入參、執行方法棧與耗時、靜態對象或動態實例的值等等，讓在線調試就像本地調試一樣方便，如下圖所示：

7.【全鏈路追蹤】用戶反饋網站打開非常慢，如何實現 Web 端到服務端的全鏈路調用軌跡追蹤？

前后端全鏈路打通的關鍵在于遵循同一套透傳協議標準，目前開源僅支持后端應用接入，缺少前端埋點（如 Web/H5、小程序等）。前后端全鏈路追蹤方案如下圖所示：

Header 透傳格式：統一采用 Jaeger 格式，Key 為 uber-trace-id， Value 為 {trace-id}:{span-id}:{parent-span-id}:{flags} 。
前端接入：可以采用 CDN（Script 注入）或 NPM 兩種低代碼接入方式，支持 Web/H5、Weex 和各類小程序場景。
后端接入：Java 應用推薦優先使用 ARMS Agent，無侵入式埋點無需代碼改造，支持邊緣診斷、無損統計、精準采樣等高階功能。用戶自定義方法可以通過 OpenTelemetry SDK 主動埋點。非 Java 應用推薦通過 Jaeger 接入，并將數據上報至 ARMS Endpoint，ARMS 會完美兼容多語言應用間的鏈路透傳與展示。
阿里云 ARMS 目前的全鏈路追蹤方案是基于 Jaeger 協議，正在開發 SkyWalking 協議，以便支持 SkyWalking 自建用戶的無損遷移。前端、Java 應用與非 Java 應用全鏈路追蹤的調用鏈效果如下圖所示：

8.【無損統計】調用鏈日志成本太高，開啟客戶端采樣后，監控圖表就不準了，如何解決？

調用鏈日志是與流量是正相關的，To C 類業務的流量非常大，調用鏈全量上報與存儲的成本會非常高，但是如果開啟客戶端采樣后，又會面臨統計指標不準確的問題，比如采樣率設置為 1%，一萬次請求僅會記錄其中一百條，根據這一百條日志聚合出來的統計數據會導致嚴重的樣本傾斜問題，無法精確反映實際服務流量或耗時。

為了解決上述問題，我們需要支持在客戶端 Agent 進行無損統計，同一個指標在一段時間內（通常為15秒）不論請求多少次，都只會上報一條數據。這樣統計指標的結果就始終是精準的，不會受到調用鏈采樣率的影響。用戶可以放心的調整采樣率，調用鏈成本最多可降低 90% 以上。流量和集群規模越大的用戶，成本優化效果越顯著。

9.【接口名稱自動收斂】RESTFul 接口由于時間戳、UID等參數導致 URL 名稱發散，監控圖表都是無意義的斷點，如何解決？

當接口名稱中存在時間戳、UID等可變參數時，會導致同一類接口的名稱各不相同，且出現次數極少，不具備監控價值，并對存儲/計算造成熱點，影響集群穩定性。此時，我們就需要對發散的接口進行分類聚合，以提高數據分析價值和集群穩定性。

此時，我們需要提供一種針對接口名稱的自動收斂算法，可以主動識別可變參數，將同一類接口進行聚合，觀察類別變化趨勢，更符合用戶監控訴求；同時避免了接口發散導致的數據熱點問題，提升了整體的穩定性與性能。如下圖所示：/safe/getXXXInfo/xxxx 都會被歸為一類，否則每一條請求都是一張只有一個數據點的圖表，用戶可讀性會變的很差。

10.【動態配置下發】線上突發流量導致資源不足，需要立即對非核心功能進行降級，如何在不重啟應用的情況下實現動態降級或調優？

意外總是突如其來的，流量突發、外部攻擊、機房故障都可能會導致系統資源不足，為了保住最重要的核心業務不受影響，我們往往需要在不重啟應用的場景下，動態降級一些非核心功能釋放資源，比如調低客戶端調用鏈采樣率，關閉一些性能開銷較大的診斷模塊等。與此相反，有些時候我們需要動態開啟一些高開銷的深度診斷功能，以分析當下的異常現場，比如內存 Dump。

無論是動態降級還是動態開啟，都需要在不重啟應用的前提下進行動態配置下推。而開源 Trace 通常不具備這樣的能力，需要自行搭建元數據配置中心并進行相應的代碼改造。而商業化 Trace 不僅支持動態配置下推，還可以細化到每個應用獨立配置，比如應用 A 存在偶發性慢調用，可以開啟自動慢調用診斷開關進行監聽；而應用 B 耗時對 CPU 開銷比較敏感，可以關閉此開關；兩個應用各取所需，互不影響。

二 開源自建 vs. 開源托管 vs. 商業化自研