[[419923]]

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

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

一 “兩類風(fēng)險(xiǎn)”與“十大典型問題”

線上應(yīng)用風(fēng)險(xiǎn)主要分為“錯(cuò)”、“慢”兩大類。其中“錯(cuò)”的原因通常是程序運(yùn)行不符合預(yù)期，比如 JVM 加載了錯(cuò)誤版本的類實(shí)例，代碼進(jìn)入異常分支，環(huán)境配置錯(cuò)誤等。而“慢”的原因通常是資源不足，比如突發(fā)流量導(dǎo)致 CPU 打滿，微服務(wù)或數(shù)據(jù)庫線程池被耗盡，內(nèi)存泄漏導(dǎo)致持續(xù) FGC 等等。

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

綜上所述，線上應(yīng)用為了保障最終的業(yè)務(wù)穩(wěn)定性，在做鏈路追蹤方案選型時(shí)，除了 Trace 通用基礎(chǔ)能力外（如調(diào)用鏈、服務(wù)監(jiān)控、鏈路拓?fù)洌€可以參考下面列舉的“十大典型問題”（以 Java 應(yīng)用為例），綜合對(duì)比開源自建、開源托管與商業(yè)化自研 Trace 產(chǎn)品的差異化表現(xiàn)。

1.【代碼級(jí)自動(dòng)診斷】接口偶發(fā)性超時(shí)，調(diào)用鏈只能看到超時(shí)接口名稱，看不到內(nèi)部方法，無法定位根因，也難以復(fù)現(xiàn)，怎么辦？

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

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

2.【池化監(jiān)控】微服務(wù)/數(shù)據(jù)庫線程池經(jīng)常被打滿，導(dǎo)致服務(wù)超時(shí)，排查起來非常困難，如何解決？

微服務(wù)/數(shù)據(jù)庫線程池滿導(dǎo)致業(yè)務(wù)請(qǐng)求超時(shí)，這類問題每天都在頻繁發(fā)生。具備豐富診斷經(jīng)驗(yàn)的同學(xué)，會(huì)有意識(shí)的查看對(duì)應(yīng)的組件日志，比如 Dubbo 在線程池滿的情況下會(huì)輸出相關(guān)的異常記錄。但是，如果組件沒有輸出線程池信息，或者運(yùn)維同學(xué)排查經(jīng)驗(yàn)不夠豐富，這類問題就會(huì)變得非常棘手。目前，開源版本 Trace 一般只提供 JVM 概覽監(jiān)控，無法具體查看每個(gè)線程池的狀態(tài)，更無法判斷線程池是否耗盡。

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

3.【線程分析】大促壓測/發(fā)布變更后，發(fā)現(xiàn) CPU 水位非常高，如何分析應(yīng)用性能瓶頸點(diǎn)，針對(duì)性優(yōu)化？

我們?cè)谧龃蟠賶簻y，或者大版本變更（包含很多代碼邏輯）時(shí)，會(huì)遇到 CPU 水位突然變得很高，但是又無法清晰的定位是哪一段代碼導(dǎo)致的，只能不停的做 jstack，肉眼比對(duì)線程狀態(tài)變化，然后根據(jù)經(jīng)驗(yàn)不斷進(jìn)行優(yōu)化嘗試，最終消耗了大量的精力，效果卻一般般。

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

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

4.【異常診斷】執(zhí)行發(fā)布/配置變更后，接口大量報(bào)錯(cuò)，但無法第一時(shí)間定位原因，造成業(yè)務(wù)故障？

影響線上穩(wěn)定性的最大“元兇”就是變更，無論是應(yīng)用發(fā)布變更，還是動(dòng)態(tài)配置變更，都可能引起程序運(yùn)行出現(xiàn)異常。那么，如何快速判斷變更風(fēng)險(xiǎn)，第一時(shí)間發(fā)現(xiàn)問題，及時(shí)止損呢？

在這里，分享一個(gè)阿里內(nèi)部發(fā)布系統(tǒng)的異常發(fā)布攔截實(shí)踐，其中最重要的監(jiān)測指標(biāo)之一，就是 Java Exception/Error 的異常數(shù)比對(duì)。無論是 NPE（NullPointException），還是 OOM（OutOfMemoryError），基于全部/特定異常數(shù)的監(jiān)控與告警，可以快速發(fā)現(xiàn)線上異常，特別是變更時(shí)間線前后要尤為注意。

獨(dú)立的異常分析診斷頁面，可以查看每一類異常的變化趨勢與堆棧詳情，還可以進(jìn)一步查看關(guān)聯(lián)的接口分布，如下圖所示。

5.【內(nèi)存診斷】應(yīng)用頻繁 FGC，懷疑有內(nèi)存泄漏，但無法定位異常對(duì)象，怎么辦？

FullGC 絕對(duì)是 Java 應(yīng)用最常見問題之一，對(duì)象創(chuàng)建過快、內(nèi)存泄漏等各種原因都會(huì)導(dǎo)致 FGC。而排查 FGC 最有效的手段就是執(zhí)行堆內(nèi)存 HeapDump。各種對(duì)象的內(nèi)存占用一目了然，清晰可見。

白屏化的內(nèi)存快照功能，可以指定機(jī)器執(zhí)行一鍵 HeapDump 與分析，大幅提升內(nèi)存問題的排查效率，還支持內(nèi)存泄漏場景下自動(dòng) Dump 保存異常快照現(xiàn)場，如下圖所示：

6.【在線調(diào)試】同一份代碼，線上運(yùn)行態(tài)與本地調(diào)試行為不一致，該如何排查？

本地調(diào)試通過的代碼，一發(fā)到生產(chǎn)環(huán)境就各種報(bào)錯(cuò)，到底哪里出了問題？相信開發(fā)同學(xué)都經(jīng)歷過這樣的噩夢(mèng)。而導(dǎo)致這種問題的原因有很多，比如 Maven 依賴多版本沖突，不同環(huán)境動(dòng)態(tài)配置參數(shù)不一致，不同環(huán)境依賴組件差異等等。

為了解決線上運(yùn)行代碼不符合預(yù)期的問題，我們需要一款在線調(diào)試診斷工具，能夠?qū)崟r(shí)查看當(dāng)前程序運(yùn)行態(tài)的源代碼、出入?yún)ⅰ?zhí)行方法棧與耗時(shí)、靜態(tài)對(duì)象或動(dòng)態(tài)實(shí)例的值等等，讓在線調(diào)試就像本地調(diào)試一樣方便，如下圖所示：

7.【全鏈路追蹤】用戶反饋網(wǎng)站打開非常慢，如何實(shí)現(xiàn) Web 端到服務(wù)端的全鏈路調(diào)用軌跡追蹤？

前后端全鏈路打通的關(guān)鍵在于遵循同一套透傳協(xié)議標(biāo)準(zhǔn)，目前開源僅支持后端應(yīng)用接入，缺少前端埋點(diǎn)（如 Web/H5、小程序等）。前后端全鏈路追蹤方案如下圖所示：

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

8.【無損統(tǒng)計(jì)】調(diào)用鏈日志成本太高，開啟客戶端采樣后，監(jiān)控圖表就不準(zhǔn)了，如何解決？

調(diào)用鏈日志是與流量是正相關(guān)的，To C 類業(yè)務(wù)的流量非常大，調(diào)用鏈全量上報(bào)與存儲(chǔ)的成本會(huì)非常高，但是如果開啟客戶端采樣后，又會(huì)面臨統(tǒng)計(jì)指標(biāo)不準(zhǔn)確的問題，比如采樣率設(shè)置為 1%，一萬次請(qǐng)求僅會(huì)記錄其中一百條，根據(jù)這一百條日志聚合出來的統(tǒng)計(jì)數(shù)據(jù)會(huì)導(dǎo)致嚴(yán)重的樣本傾斜問題，無法精確反映實(shí)際服務(wù)流量或耗時(shí)。

為了解決上述問題，我們需要支持在客戶端 Agent 進(jìn)行無損統(tǒng)計(jì)，同一個(gè)指標(biāo)在一段時(shí)間內(nèi)（通常為15秒）不論請(qǐng)求多少次，都只會(huì)上報(bào)一條數(shù)據(jù)。這樣統(tǒng)計(jì)指標(biāo)的結(jié)果就始終是精準(zhǔn)的，不會(huì)受到調(diào)用鏈采樣率的影響。用戶可以放心的調(diào)整采樣率，調(diào)用鏈成本最多可降低 90% 以上。流量和集群規(guī)模越大的用戶，成本優(yōu)化效果越顯著。

9.【接口名稱自動(dòng)收斂】RESTFul 接口由于時(shí)間戳、UID等參數(shù)導(dǎo)致 URL 名稱發(fā)散，監(jiān)控圖表都是無意義的斷點(diǎn)，如何解決？

當(dāng)接口名稱中存在時(shí)間戳、UID等可變參數(shù)時(shí)，會(huì)導(dǎo)致同一類接口的名稱各不相同，且出現(xiàn)次數(shù)極少，不具備監(jiān)控價(jià)值，并對(duì)存儲(chǔ)/計(jì)算造成熱點(diǎn)，影響集群穩(wěn)定性。此時(shí)，我們就需要對(duì)發(fā)散的接口進(jìn)行分類聚合，以提高數(shù)據(jù)分析價(jià)值和集群穩(wěn)定性。

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

10.【動(dòng)態(tài)配置下發(fā)】線上突發(fā)流量導(dǎo)致資源不足，需要立即對(duì)非核心功能進(jìn)行降級(jí)，如何在不重啟應(yīng)用的情況下實(shí)現(xiàn)動(dòng)態(tài)降級(jí)或調(diào)優(yōu)？

意外總是突如其來的，流量突發(fā)、外部攻擊、機(jī)房故障都可能會(huì)導(dǎo)致系統(tǒng)資源不足，為了保住最重要的核心業(yè)務(wù)不受影響，我們往往需要在不重啟應(yīng)用的場景下，動(dòng)態(tài)降級(jí)一些非核心功能釋放資源，比如調(diào)低客戶端調(diào)用鏈采樣率，關(guān)閉一些性能開銷較大的診斷模塊等。與此相反，有些時(shí)候我們需要?jiǎng)討B(tài)開啟一些高開銷的深度診斷功能，以分析當(dāng)下的異常現(xiàn)場，比如內(nèi)存 Dump。

無論是動(dòng)態(tài)降級(jí)還是動(dòng)態(tài)開啟，都需要在不重啟應(yīng)用的前提下進(jìn)行動(dòng)態(tài)配置下推。而開源 Trace 通常不具備這樣的能力，需要自行搭建元數(shù)據(jù)配置中心并進(jìn)行相應(yīng)的代碼改造。而商業(yè)化 Trace 不僅支持動(dòng)態(tài)配置下推，還可以細(xì)化到每個(gè)應(yīng)用獨(dú)立配置，比如應(yīng)用 A 存在偶發(fā)性慢調(diào)用，可以開啟自動(dòng)慢調(diào)用診斷開關(guān)進(jìn)行監(jiān)聽；而應(yīng)用 B 耗時(shí)對(duì) CPU 開銷比較敏感，可以關(guān)閉此開關(guān)；兩個(gè)應(yīng)用各取所需，互不影響。

二 開源自建 vs. 開源托管 vs. 商業(yè)化自研