[[419923]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了解決上述問(wèn)題，我們需要支持在客戶(hù)端 Agent 進(jìn)行無(wú)損統(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)用鏈采樣率的影響。用戶(hù)可以放心的調(diào)整采樣率，調(diào)用鏈成本最多可降低 90% 以上。流量和集群規(guī)模越大的用戶(hù)，成本優(yōu)化效果越顯著。

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

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

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

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

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

無(wú)論是動(dòng)態(tài)降級(jí)還是動(dòng)態(tài)開(kāi)啟，都需要在不重啟應(yīng)用的前提下進(jìn)行動(dòng)態(tài)配置下推。而開(kā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)用，可以開(kāi)啟自動(dòng)慢調(diào)用診斷開(kāi)關(guān)進(jìn)行監(jiān)聽(tīng)；而應(yīng)用 B 耗時(shí)對(duì) CPU 開(kāi)銷(xiāo)比較敏感，可以關(guān)閉此開(kāi)關(guān)；兩個(gè)應(yīng)用各取所需，互不影響。

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