簡介：本文將分享 ARMS 在全鏈路追蹤領(lǐng)域的最佳實踐，分享主要分為四部分。首先，是對分布式鏈路追蹤的整體簡介。其次，是對 ARMS 在分布式鏈路追蹤領(lǐng)域的核心能力進行介紹。然后，介紹如何從 0 到 1 構(gòu)建整套全鏈路追蹤體系。最后，介紹一些最佳實踐案例。

作者 | 涯海&白玙

今天，我來跟大家分享 ARMS 在全鏈路追蹤領(lǐng)域的最佳實踐，分享主要分為四部分。首先，是對分布式鏈路追蹤的整體簡介。其次，是對 ARMS 在分布式鏈路追蹤領(lǐng)域的核心能力進行介紹。然后，介紹如何從 0 到 1 構(gòu)建整套全鏈路追蹤體系。最后，介紹一些最佳實踐案例。

什么是分布式鏈路追蹤

首先，什么是分布式鏈路追蹤。我對分布式鏈路追蹤的理解就是跟蹤請求在分布式系統(tǒng)中的流轉(zhuǎn)路徑與狀態(tài)，從而協(xié)助開發(fā)人員能夠進行故障診斷、容量評估、性能瓶頸分析等工作。?

我們可以看到典型的鏈路軌跡追蹤例子：比如用戶通過手機做了一個下單動作，這個請求會通過移動端來到網(wǎng)關(guān)，再到應用層，比如說有交易、下單、支付等等一系列的應用，然后中間也會穿插到去調(diào)用云基礎(chǔ)設(shè)施，這樣用戶的行為軌跡是能夠被清晰還原出來的。

為了更方便的理解這個概念，我們可以把鏈路追蹤和物流追蹤做對比。在發(fā)送快遞物流時，每個快遞包裹都會賦予一個唯一的快遞單號，對于系統(tǒng)請求來說就是全局唯一的 TraceId。通過快遞單號來查詢快遞途徑哪些站點，是否有延遲或丟件情況。那么，也同樣可以通過 TraceId 來查詢請求在每個系統(tǒng)之間的流轉(zhuǎn)路徑和狀態(tài)。除了快遞訂單查詢之外，還可以把整個物流狀態(tài)，按照站點去進行匯總統(tǒng)計，來看每個站點吞吐，從而進行物流提效的優(yōu)化工作。

對于鏈路追蹤來說也是一樣的，我們可以把鏈路數(shù)據(jù)進行一個統(tǒng)計，然后去看每一個應用或接口的狀態(tài)，或者去梳理它們之間的強弱依賴。那么，什么樣的系統(tǒng)更加需要鏈路追蹤呢？當微服務架構(gòu)拆分的越精細，服務間依賴越復雜的系統(tǒng)，就更加的需要鏈路追蹤技術(shù)，比較典型的就是電商這種。

接下來我們看一下鏈路追蹤作為可觀測的三元組之一，就是 Traces、Metrics 和 Logs。其最大價值就是實現(xiàn)了除機器和時間維度之外的用戶行為的確定性關(guān)聯(lián)。怎么理解這個事情呢？就是在沒有 Tracing 之前，比如說通過指標或者日志，只能根據(jù)數(shù)據(jù)在同一臺機器上，并且在同一個時間點，判斷它們應該是在一起的。但這只是弱關(guān)聯(lián)，并不是強關(guān)聯(lián)。而調(diào)用鏈會很明確說明這個請求就是這個數(shù)據(jù)，就是來到了這個節(jié)點，這個信息是一定準確的。通過這種確定性的關(guān)聯(lián)，除了可以將服務應用接口層面的數(shù)據(jù)關(guān)聯(lián)起來之外，還可以通過打標上下文傳遞的方式，把一些業(yè)務的標簽，比如說來自于什么渠道、訂單金額等這種直接、間接的數(shù)據(jù)都關(guān)聯(lián)起來，發(fā)揮 1+1>N 的價值。?

接下來再看一下鏈路追蹤的應用場景，我對它做了一個初步分級。

從下往上看，最基礎(chǔ)級就是通過調(diào)用鏈來還原單次請求的軌跡狀態(tài)，這是最基本的應用。

再往上，可以對鏈路數(shù)據(jù)去做預聚合或后聚合統(tǒng)計的分析，去看整個鏈路在概率分布上的一些信息，比如說整個服務維度的監(jiān)控數(shù)據(jù)，上下游整體的依賴，這是第二級——聚合分析。?

第三等級，就是除了調(diào)用鏈數(shù)據(jù)本身具備的這些鏈路數(shù)據(jù)之外，還可以更進一步發(fā)揮關(guān)聯(lián)性作用，把一些間接的業(yè)務數(shù)據(jù)，包括容器或者 JVM 的一些指標信息或者是一些變更的日志事件，也能夠通過調(diào)用鏈緊密的關(guān)聯(lián)在一起，形成多維數(shù)據(jù)關(guān)聯(lián)和分析，最終來實現(xiàn)我們根因定位的能力。

再往后有點像自動駕駛，有了這么多數(shù)據(jù)，能不能夠自動發(fā)現(xiàn)其中一些問題？可以結(jié)合領(lǐng)域?qū)＜医?jīng)驗和恰當?shù)乃惴?#xff0c;來實現(xiàn)整個診斷流程自動化或者半自動化。?

最后一步就是診斷問題的最終目標--保障系統(tǒng)穩(wěn)定。能不能夠把問題診斷和系統(tǒng)恢復兩個事關(guān)聯(lián)在一起？從而實現(xiàn)整個系統(tǒng)的故障自愈，進一步提升穩(wěn)定性。這個就需要與管控系統(tǒng)去融合。目前開源 Tracing 系統(tǒng)大概是在 L1 到 L3 的等級。ARMS 我們那邊沉淀了很多領(lǐng)域?qū)＜医?jīng)驗以及算法可以做到 L4 等級，ARMS 再加上一些應用托管服務進行自動流控降級、彈性擴縮容，把監(jiān)控和管控系統(tǒng)結(jié)合在一起，從而實現(xiàn)故障自愈能力。

接下來我們再看看鏈路追蹤的發(fā)展趨勢。在 2010 年，隨著谷歌論文發(fā)表，拉開了整個鏈路追蹤的技術(shù)序幕，很多廠商都紛紛實現(xiàn)了自己的鏈路追蹤技術(shù)。當然，在谷歌之前也有很多其他探索，但谷歌給了后續(xù)實現(xiàn)者比較完整的理論基礎(chǔ)。同時，通過自身實踐，證明了鏈路追蹤的企業(yè)級價值，這是開山鼻祖式的奠基。

到了 2016 年，因為之前大家廠商紛紛實現(xiàn)自己的鏈路追蹤，這個標準沒有統(tǒng)一，就為遷云、上云帶來很多問題。因此，開源社區(qū)發(fā)起了 OpenTracing 項目，定義了相對比較完善標準的鏈路的通用規(guī)范，也發(fā)展出了類似 Jaeger 這種符合 OpenTracing 規(guī)范的開源實現(xiàn)。到了2019年，大家考慮到可觀測逐漸向一體化發(fā)展，光有 Tracing 也不夠，需要把Tracing和指標和日志能夠關(guān)聯(lián)在一起，OpenTracing 定義就相對比較狹隘，不能滿足可觀測的需求。所以在 2019 年，就是 OpenTeleMetry，然后提出了這樣的一個開源項目。將 OpenTracing 和 OpenCensus 進行了融合，能夠致力于去解決 Logs 和 Traces、Metrics 三者有機統(tǒng)一。

ARMS 的鏈路追蹤到底具備哪些能力

接下來，我們看一下 ARMS 的鏈路追蹤到底具備哪些能力。首先，我把 ARMS 的能力抽象為四個點：

• 解決接入難的問題。比如說企業(yè)有很多不同類型應用，不同語言的應用。除了前端后關(guān)聯(lián)，服務端也有很多如 Java 、Go 等應用。ARMS可以更有效地去完成這些應用的追蹤接入。
• 解決診斷難的問題。ARMS 可以提供各種各樣的，比如說日志和 Trace 的全息排查，或者是線程剖析這種深度的診斷的能力來幫助你去定位根因。
• 解決運維難的問題。在大規(guī)模場景下，鏈路的探針管理、升級都是比較困難的事情，包括服務端的穩(wěn)定性托管， ARMS 可以提供穩(wěn)定可靠的全托管、免運維能力。
• 解決成本高的問題。ARMS 作為云上產(chǎn)品可以按需按量地來使用。隨著業(yè)務爆發(fā)式增長，只需要按量地去付費就可以，也不需要一開始就購買一大批機器或投入比較大人力。

接下來，我們逐一介紹下這四個方面：

首先就是接入難， ARMS 目前提供了 Java 無侵入的探針技術(shù)方式，如果你是 Java 應用就可以很快地接入 ARMS。比如說通過一個 -javaagent 的命令，或者是在 ACK 容器服務環(huán)境下，通過一個 Annotation 就可以很快地接入。如果是非Java語言，也可以利用開源 SDK 通過修改 Endpoint 快速地接入到 ARMS，從而實現(xiàn)全鏈路追蹤，基本上相當于是開箱即用的。

我們對語言組件的覆蓋也是相對比較齊全的，主流組件基本上都有支持。同時， ARMS 完全兼容開源的 OpenTracing、 OpenTelemetry 等各種開源格式。如已接入，遷移到 ?ARMS 也是非常的方便。

其次，診斷難。在生產(chǎn)環(huán)境去診斷問題時，有時不僅僅需要調(diào)用鏈，還需要很多其他的數(shù)據(jù)一起結(jié)合。比如說發(fā)現(xiàn)某個應用接口或者是業(yè)務出現(xiàn)問題，根據(jù)各種各樣條件來去篩選出想要的調(diào)用鏈，通過調(diào)用鏈來去追溯上下游，看看問題大概瓶頸點在哪里。如果這個時候出現(xiàn)了比較慢的一些情況，就是接口粒度還不足以定位問題的時候，我們可以通過 ARMS 的線程剖析功能，自動地幫你把慢調(diào)用本地完整的方法棧能夠獲取下來，能夠?qū)崿F(xiàn)代碼級定位。如果是業(yè)務上出錯了，還可以跟業(yè)務日志進行關(guān)聯(lián)綁定，能夠看到每次調(diào)用，每筆請求關(guān)聯(lián)背后業(yè)務的行為和日志是什么樣的。如果前面這四步仍然不足以去定位根因，還可以結(jié)合內(nèi)存快照或是線程池分析，常見的就是數(shù)據(jù)庫連接打滿，或者是線程池打滿等。?

除了上面這一整套診斷能力幫助團隊完成定位之外，ARMS 也能夠通過自動診斷能力解決常見問題。比如說我們經(jīng)常會遇到一些數(shù)據(jù)庫 MySQL 問題，數(shù)據(jù)庫 MySQL 有很多原因比方說服務端原因，服務端的連接池打滿，或者是客戶端的連接池打滿，或者是客戶端一次查了特別多數(shù)據(jù)需要分批等等。面對這些常見的原因，ARMS 都可以自動診斷出來。

解決完診斷難，接下來就是運維難的問題。越是體量越大的公司，這個問題會越嚴重。ARMS 作為阿里鷹眼的升級，在雙十一場景下結(jié)合多年驗證與優(yōu)化，沉淀了大量經(jīng)驗，比如說我們的 Agent 是會經(jīng)過多輪、各種級別的灰度驗證，保證我們客戶端側(cè)穩(wěn)定。服務端也會支持比如說多可用區(qū)容災或者是全鏈路端的 SLO 體系建設(shè)，還有包括我們多級的客戶支持和 Oncall 應急值班，這些都是可以直接享受到這樣的服務，而不需要重新的去建設(shè)這樣的體系。

在大部分場景下，除了穩(wěn)定性之外，還經(jīng)常會遇到海量數(shù)據(jù)場景下查詢性能問題，當數(shù)據(jù)達到每天幾百 TB，數(shù)據(jù)存儲和數(shù)據(jù)查詢的索引可能已失效，無法滿足業(yè)務要求。ARMS 沉淀了多種性能加速方案，比如說可以實現(xiàn)最基礎(chǔ)的就是租戶地域隔離，其次數(shù)據(jù)可以通過應用去做路由存儲，如果應用級還不夠，還可以再繼續(xù)根據(jù)數(shù)據(jù)的一些特定的特征，如 TraceId 或者其他特征進一步打散，從而提高并發(fā)查詢的效率。

第四點就是大家比較關(guān)心的成本問題，ARMS 除了自身按需存儲之外，還通過冷熱數(shù)據(jù)分離和精準采樣方案，進一步降低用戶成本。

比如說我們可以把熱數(shù)據(jù)，比如說 30 分鐘內(nèi)數(shù)據(jù)我們會經(jīng)常查詢，我們可以把它存在熱存儲里面，滿足全量的分析的需求。30 分鐘之后的數(shù)據(jù)進行持久化，比方說 15 天、30 天。這個時候可以僅把其中錯、慢或者滿足一定業(yè)務特征（比如說 VIP 用戶的一些鏈路）存儲下來，這樣整個存儲成本就會比較低，并保持查詢體驗。

當然，在做鏈路采樣時就無可避免的會遇到指標數(shù)據(jù)不準的情況。ARMS 通過在客戶端完成預聚合，來保證鏈路數(shù)據(jù)無論怎么去采樣，即使千分之一，但依舊保證指標數(shù)據(jù)精準性。

這里做個簡單對比，如果采用開源方案，最起碼需要存儲以及流計算處理服務器建設(shè)，這種 ES 和 ECS 的成本大概 200 元/天。但如果直接使用 ARMS 的按量付費，每天大概只需要十幾塊錢。每 GB 成本可能只要 1 毛 9 不到 2 毛錢，遠遠低于開源自建成本。

值得一提的就是，ARMS 進入 Gartner APM 象限，也是國內(nèi)唯一的云廠商，Gartner 對 ARMS 的 APM 評價是中國影響力最強，對開源集成性也非常好，成本也是非常大優(yōu)勢。

如何從 0 到 1 建設(shè)追蹤體系

介紹完產(chǎn)品核心能力之后，來講講如何從 0 到 1 建設(shè)追蹤體系。

我們大概可能需要完成這樣 4 步：

第一步，完成整個應用的全鏈條全鏈路的上下文透傳，從端側(cè)設(shè)備開始到后端，然后網(wǎng)關(guān)或者是應用等等。這里面的話其實就涉及到異構(gòu)語言的數(shù)據(jù)打通和前后端的透傳，這一套方案 ARMS 是都已實現(xiàn)了。

第二步，完成了客戶端的這種全鏈路埋點之后，我們數(shù)據(jù)要上報上來，就會面臨存儲和計算的成本，最好的方式就是說能夠按需去存儲數(shù)據(jù)，只存有價值的數(shù)據(jù)來降低成本。

第三步就是數(shù)據(jù)存儲下來之后，肯定還要通過查詢再發(fā)揮它的價值。這時候遇到的問題就是數(shù)據(jù)之間的格式不統(tǒng)一，能不能把所有的指標數(shù)據(jù)轉(zhuǎn)化成一個比方說 Prometheus的這種格式，這樣指標數(shù)據(jù)格式相對統(tǒng)一了，Traces 能不能支持這種 OpenTelemetry 的格式，然后是日志支持 Loki 這種方案。

如果數(shù)據(jù)格式跟開源保持統(tǒng)一再去做第 4 步，釋放價值就會比較容易。除了產(chǎn)品提供的預置大盤之外，還可以靈活自定義用戶檔案。當然還可以按照用戶的使用習慣，也可以做一些自定義的控制臺。同樣道理，告警也是一樣的，我們可以去用 PromQL 做一個靈活的自定義的告警，同時我們也支持把數(shù)據(jù)路由到用戶名下的一些存儲，比如說 SLS 下面，這樣你想去做一些二次的批量的分析，這些都可以支持。這就是我們從 0 到 1 去建設(shè)鏈路追蹤體系的大概步驟。

接下來，每個步驟都單獨來看。第一步，就是要完成異構(gòu)應用的全鏈路的追蹤，比如說前端或者說整個透傳的格式，或需要采用統(tǒng)一格式，比如說我們可以選擇統(tǒng)一的 Jaeger 格式來透傳來我們的協(xié)議頭，我們前端接入比如說我們可以采用 CDN 或者 NPM 兩種的這種低代碼的接入方式，可以支持外部小程序等各種各樣的場景，我們后端如果是 JAVA 的話，就會優(yōu)先推進使用 ARMS Agent 來完成無侵入的這樣的一個代碼的接入。并且在 JAVA 的應用上面，我們會提供很多比如說邊緣診斷、無損統(tǒng)計的這樣一些高階的能力，非 JAVA 的話就可以比方說我們可以通過開源的 Agent 和 SDK 來接入，然后并且上報到我們的 Endpoint 上面，當然 ARMS 也在去兼容 SkyWalking 的協(xié)議格式。

第二步，正如剛才所講，數(shù)據(jù)打通之后，需要去進行精準采樣和冷熱存儲分離。但是對于使用者來說，需要去定義我們尾部采樣策略，比如說默認的除了錯慢全采之外，有沒有需要根據(jù)業(yè)務特征進行采樣，或者是按需的去調(diào)整數(shù)據(jù)存儲周期。

第三步，就是需要去自定義監(jiān)控大盤，就除了 ARMS 提供的默認大盤之外，你還可以基于 Grafana，把業(yè)務數(shù)據(jù)、應用數(shù)據(jù)，甚至容器數(shù)據(jù)放在一起，來去定制統(tǒng)一監(jiān)控大盤。比如說雙 11 大促，或日常線上應急場景，都可以去快速地瀏覽整個業(yè)務線的表現(xiàn)，能夠快速地定位到問題的大致范圍。

第四步，當建立監(jiān)控之外，還需要有一個比較有效的告警機制，因為大家平時也不太會去一直盯著監(jiān)控或者是 Trace 控制臺，肯定需要有應急入口，告警其實就是我們運維的第一入口。在這里介紹三個比較典型的告警實踐。

比如說公司或者是團隊在剛起步或新產(chǎn)品剛上線的時候，很多東西都是比較缺失的。這個時候，我們可以通過 ARMS 的告警模板能力，把比較通用的應用、容器、中間件的告警能力能夠快速地構(gòu)建出來，解決從 0 到 1 的問題。

當團隊或者是公司一步步成長起來，數(shù)據(jù)會越來越多，系統(tǒng)會越來越多。等到膨脹到一定程度時，告警可能分散在多個系統(tǒng)之中。這個時候又會帶來效率問題，就可以使用 ARMS 的告警能力，把多個告警源的數(shù)據(jù)放在一起去分析，甚至可以去做組合過濾規(guī)則。比如，當流量突然激增，性能后端的耗時變高，CPU 打滿的時候，發(fā)出建議擴容或是建議降級的告警通知。

當企業(yè)進一步地發(fā)展，發(fā)展得很好，團隊越來越多，人員越來越多。這個時候，可能一個系統(tǒng)會有很多個團隊來共同的去協(xié)作運維，我們不僅僅需要解決數(shù)據(jù)爆炸問題，還需要解決人員協(xié)同的問題。這個時候就可以基于 ARMS 的 ChatOps 能力來解決應急協(xié)同問題。

第五步，即使前面都做了之后，還有很多公司有建設(shè)自己專屬平臺的意愿，因為可能大家已經(jīng)有了比較好的可觀測或監(jiān)控報警方面的經(jīng)驗以及場景沉淀，只需擴充部分這樣的能力，是完全可以基于 ARMS 這種開放數(shù)據(jù)的能力。無論是通過外部頁面的嵌入，還是 Open API 建設(shè)，或是直接把存儲開放出來，進行批量數(shù)據(jù)分析，都可以更好地完成二次開發(fā)。

最佳實踐

最后，我們來介紹常見實踐案例。比如，調(diào)用鏈通常聚合成一個應用維度的拓撲，或者是服務維度的拓撲，但這個時候往往還不夠，還可能會更關(guān)注某特定場景。

同樣是下單場景，有時候關(guān)注整體的下單還不夠，可能還需要關(guān)注某個新渠道或新上線品類。我們可能需要看某個線下零售的渠道，它的下單鏈路情況是怎么樣的。或者是某個新品類，需要把這一部分業(yè)務場景單獨剝離出來，去做鏈路染色，從而能夠?qū)崿F(xiàn)這一部分特定業(yè)務場景的應用和依賴的梳理。這個就是通過無侵入的業(yè)務染色實現(xiàn)的。

第二部分，ARMS Agent 除了做可觀測數(shù)據(jù)之外，同時也具備安全數(shù)據(jù)、安全行為檢測與保護的能力，面對最近比較火的 Log4j2 高危核彈級漏洞，基于 RASP 技術(shù)就可以有很好的自我防護能力。即使不改代碼，也可以通過動態(tài)配置的方式，完成安全防護。除了安全防護之外，RASP 也可以提供攻擊溯源或者漏洞定位分析等等能力，相比于傳統(tǒng)的防火墻式保護會更有效一些。因為它跟 IDC 防火墻的區(qū)別，有點像我們戴口罩和打疫苗這樣的一個區(qū)別。

第三個場景，在容器場景下實現(xiàn)全景監(jiān)控，可以把來自于 Prometheus 或者 Loki 或者 eBPF、APM 等端到端數(shù)據(jù)放在一起，通過 2D、3D 拓撲，進行全程展示和端到端鏈路的下端分析。同時，我們還提供定期巡檢，或是基于專家經(jīng)驗和算法的問題自動診斷和上報，這個就是我們在容器場景下的一個全景監(jiān)控的最佳實踐。

第四個場景，一些架構(gòu)比較復雜的用戶，具備多云以及跨云部署；出于數(shù)據(jù)安全考慮，也可能會去自建機房進行混合云部署。為了解決前后端、多語言、跨云部署的問題，ARMS 的全鏈路追蹤幫助用戶完成復雜場景的全鏈路追蹤挑戰(zhàn)，把各種場景的鏈路串聯(lián)在一起，最大化去釋放鏈路跟蹤價值。

第五部分，就是說 ARMS 最近新上線了 Trace Explore 功能，相對于傳統(tǒng)調(diào)用鏈查詢和應用服務統(tǒng)計、監(jiān)控之外，還提供實時獲取和分析能力。舉個簡單例子，我們經(jīng)常要看耗時大于三秒的請求分布在哪些接口或者是哪些 IP 上面，從而進行慢接口的處理，或單機故障排查診斷。這個時候我們在預聚合的時候，肯定沒辦法把耗時大于三秒或者是某一個特定的過濾條件等于什么的場景之下，去做一個預先統(tǒng)計。這個時候我們就需要一個靈活的后聚合分析的能力。這個就是 Trace Explorer 能夠提供這樣的一個價值。除了我們剛剛說的這種單機慢接口之外，如果我們再結(jié)合我們的業(yè)務指標，比如說我們把我們的一些用戶的等級也打到我們的 Attributes 里面對吧？我們就可以去按不同的用戶等級來去分析它的一些流量的情況，它響應的一些時延，就能夠更方便的低代碼的去完成這樣的一個自定義的分析。當然，這里還舉了一個灰度監(jiān)控，如果我們在重啟之前，比方說我們在環(huán)境變量里面注入我們當前的版本，我們就可以看到不同版本之間一個流量和性能的變化。

最后，給出了一些 ARMS 相對于開源做的更好的最佳實踐。比如說接口偶發(fā)性超時的時候，接口級的調(diào)用鏈，還不足以診斷更新，我們需要完整的方法棧，但是那個問題現(xiàn)場已經(jīng)過去了，怎么能夠自動幫你保存下來呢？那就是可以通過 ARMS 線程剖析自動診斷的這樣的一個能力。

當我們微服務或者是數(shù)據(jù)庫的性能值打滿時，這個時候可能所有的請求都會變慢，但是你在調(diào)用鏈上也很難直觀的去反映出來，因為這種資源類的問題是很難通過鏈路去記錄下來的。這個時候 ARMS 提供的這種池化監(jiān)控，能夠直接分析每一類線程當前情況，并配置告警。除此之外比如說你想分析一些內(nèi)存泄漏的問題，或者是一些線上運行代碼和本地行為不一致的問題，都可以通過白屏化的內(nèi)存診斷，或者是 Arthas 這種在線調(diào)試的這樣的一個能力，幫你快速的去定位你的根因。

以上就是今天我們對鏈路追蹤整體的介紹，也涉及到我們對整個全鏈路追蹤的一些最佳的實踐，感謝大家！

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的企业如何从 0 到 1 构建整套全链路追踪体系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。