首先，我們了解一下移動端全鏈路 Trace 的背景：

從移動端的視角來看，一個 App 產品從概念產生，到最終的成熟穩(wěn)定，產品研發(fā)過程中涉及到的研發(fā)人員、工程中的代碼行數(shù)、工程架構規(guī)模、產品發(fā)布頻率、線上業(yè)務問題修復時間等等都會發(fā)生比較大的變化。這些變化，給我們在排查問題方面帶來不小的困難和挑戰(zhàn)，業(yè)務問題會往往難以復現(xiàn)和排查定位。

比如，在產品初期的時候，工程規(guī)模往往比較小，業(yè)務流程也比較簡單，線上問題往往能很快定位。而等到工程規(guī)模比較大的時候，業(yè)務流程往往涉及到的模塊會比較多，這個時候有些線上問題就會比較難以復現(xiàn)和定位排查。

本文匯集了筆者在 2022 D2 終端技術大會上的相關技術分享，希望能給大家?guī)硪恍┧伎己蛦l(fā)。

端側問題為什么很難復現(xiàn)和定位？

線上業(yè)務問題為什么很難復現(xiàn)和排查定位？經過我們的分析，主要是由 4 個原因導致：

移動端 & 服務端日志采集不統(tǒng)一，沒有統(tǒng)一的標準規(guī)范來約束數(shù)據的采集和處理。

端側往往涉及的模塊非常多，研發(fā)框架也各不相同，代碼相互隔離，設備碎片化，網絡環(huán)境復雜，會導致端側數(shù)據采集比較難。

從端視角出發(fā)，不同框架、系統(tǒng)之間的數(shù)據在分析問題時往往獲取比較難，而且數(shù)據之間缺少上下文關聯(lián)信息，數(shù)據關聯(lián)分析不容易。

業(yè)務鏈路涉及到的業(yè)務域往往也會比較多，從端的視角去復現(xiàn)和排查問題，往往需要對應域的同學參與排查，人肉運維成本比較高。

這些問題如何來解決？ 我們的思路是四步走：

建立統(tǒng)一標準，使用 標準協(xié)議 來約束數(shù)據的采集和處理。

針對不同的平臺和框架，統(tǒng)一數(shù)據采集能力。

對多系統(tǒng)、多模塊產生的數(shù)據進行自動上下文關聯(lián)分析和處理。

我們也基于機器學習，在自動化經驗分析方面做了一些探索。

統(tǒng)一數(shù)據采集標準

如何統(tǒng)一標準？ 目前行業(yè)內也有各種各樣的解決方案，但存在的問題也很明顯：

不同方案之間，協(xié)議/數(shù)據類型不統(tǒng)一；

不同方案之間，也比較難以兼容/互通。

標準這里，我們選擇了 OTel，OTel 是 OpenTelemetry 的簡稱，主要原因有兩點：

OTel 是由云原生計算基金會（CNCF）主導，它是由 OpenTracing 和 OpenCensus 合并而來，是目前可觀測性領域的準標準協(xié)議；

OTel 對不同語言和數(shù)據模型進行了統(tǒng)一，可以同時兼容 OpenTracing 和 OpenCensus，它還提供了一個廠商無關的 Collectors，用于接收、處理和導出可觀測數(shù)據。

在我們的解決方案中，所有端的數(shù)據采集規(guī)范都基于 OTel，數(shù)據存儲、處理、分析是基于 SLS 提供的 LogHub 能力進行構建。

端側數(shù)據采集的難點

只統(tǒng)一數(shù)據協(xié)議還不夠，還要解決端側在數(shù)據采集方面存在的一些問題?？偟膩碚f，端側采集當前面臨 3 個主要的難點：

數(shù)據串聯(lián)難

性能保障難

不丟數(shù)據難

端側研發(fā)過程中涉及到的框架、模塊往往比較多，業(yè)務也有一定的復雜性，存在線程、協(xié)程多種異步調用 API，在數(shù)據采集過程中，如何解決數(shù)據之間的自動串聯(lián)問題？移動端設備碎片化嚴重，系統(tǒng)版本分布比較散，機型眾多，如何保障多端一致的采集性能？App 使用場景的不確定性也比較大，如何確保采集到的數(shù)據不會丟失？

端側數(shù)據串聯(lián)的難點

我們先來分析一下端側數(shù)據自動串聯(lián)所面臨的主要問題。

在端側數(shù)據采集過程中，不僅會采集業(yè)務鏈路數(shù)據，還會采集各種性能&穩(wěn)定性監(jiān)控數(shù)據，可觀測數(shù)據源比較多；

如果用到其他的研發(fā)框架，如 OkHttp、Fresco 等，可能還會采集三方框架的關鍵數(shù)據用于網絡請求，圖片加載等問題的分析和定位。對于業(yè)務研發(fā)同學來說，我們往往不會過多的關注這類三方框架技術能力，涉及到這類框架問題的排查時，過程往往比較困難；

除此之外，端側幾乎完全異步調用，而且異步調用 API 比較多，如線程、協(xié)程等，鏈路打通也存在一定的挑戰(zhàn)。

這里會有幾個共性問題：

三方框架的數(shù)據如何采集？如何串聯(lián)？

不同可觀測數(shù)據源之間如何串聯(lián)？

分布在不同線程、協(xié)程之間的數(shù)據如何自動串聯(lián)？

端側數(shù)據自動串聯(lián)方案

我們先看下端側數(shù)據自動串聯(lián)的方案。

在 OTel 協(xié)議標準中，是通過 trace 協(xié)議來約束不同數(shù)據之間的串聯(lián)關系。OTel 定義了 trace 數(shù)據鏈路中每條數(shù)據必須要包含的必要字段，我們需要確保同一條鏈路中數(shù)據的一致性。比如，同一條 trace 鏈路中，trace_id 需要相同；其次，如果數(shù)據之間有父子關系，子數(shù)據的 parent_id 也需要與父數(shù)據的 span_id 相同。

我們知道，不管是 Android 平臺，還是 iOS 平臺，線程都是操作系統(tǒng)能夠調度的最小單元。也就是說，我們所有的代碼，最終都會在線程中被執(zhí)行。在代碼被執(zhí)行過程中，如果我們能把上下文信息和當前線程進行關聯(lián)，在代碼執(zhí)行時，就能自動獲取當前上下文信息，這樣就可以解決同一個線程內的 trace 數(shù)據自動關聯(lián)問題。

在 Android 中，可以基于線程變量 ThreadLocal 來存儲當前線程棧的上下文信息，這樣可以確保在同一線程中采集到的業(yè)務數(shù)據進行自動關聯(lián)。如果是在協(xié)程中使用，基于線程變量的方案就會存在問題。因為在協(xié)程中，協(xié)程真實運行的線程是不確定的，可能會在協(xié)程執(zhí)行的生命周期內進行線程切換，我們需要利用協(xié)程調度器和協(xié)程 Context 來保持當前上下文的正確性。在協(xié)程恢復時，讓關聯(lián)的上下文信息在當前線程生效，在協(xié)程掛起時，再讓上下文信息在當前線程失效。

在 iOS 中，主要基于 activity tracing 機制來保持上下文信息的有效性。通過 activity tracing 機制，在一個業(yè)務鏈路開始時，會自動創(chuàng)建一個 activity，我們把上下文信息與 activity 進行關聯(lián)。在當前 activity 作用域范圍內，所有產生的數(shù)據都會與當前上下文自動關聯(lián)。

基于這兩種方案，在產生 Trace 數(shù)據時，SDK 會按照 OTel 協(xié)議的標準，自動把上下文信息關聯(lián)到當前數(shù)據中。最終產生的數(shù)據，會以一棵樹的形式進行邏輯關聯(lián)，樹的根節(jié)點就是 Trace 鏈路的起點。這種方式，不僅支持協(xié)程/線程內的數(shù)據自動關聯(lián)，還支持多層級嵌套。

三方框架的數(shù)據采集和串聯(lián)

針對三方框架的數(shù)據采集，我們先看看業(yè)內通行的做法，目前主要有兩類：

如果三方庫支持攔截器或代理的配置，一般會通過在對應攔截器增加埋點代碼的方式來實現(xiàn)；

如果三方庫對外暴露的接口比較少，一般會通過 Hook 或其他方式增加埋點代碼，或者不支持對應框架的埋點。

這種做法會存在兩個主要的問題：

埋點不完全，拿 OkHttp 來舉例說明，三方 SDK 內部也可能存在對 OkHttp 的依賴，通過攔截器的方式，可能只支持當前業(yè)務代碼的埋點采集，三方 SDK 的網絡請求信息無法被采集到，會導致埋點信息不完全；

可能需要侵入業(yè)務代碼，為了實現(xiàn)對應框架的埋點，需要有一個切入時機，這個切入時機往往需要在對應框架初始化時增加代碼配置項來實現(xiàn)。

如何解這兩個問題？

我們使用的方案是實現(xiàn)一個 Gradle Plugin，在 Plugin 中對字節(jié)碼進行插樁處理。我們知道，Android App 在打包的過程中，有個流程會把 .class 文件轉為 .dex 文件，在這個過程中，可以通過 transform api 對 class 文件進行處理。我們是借助 ASM 的方式來實現(xiàn) class 文件的插樁處理。在對字節(jié)碼處理的過程中，需要先找到合適的插樁點，然后注入合適的指令。

這里拿 OkHttp 的字節(jié)插樁進行舉例：插樁的目標是在 OkHttpClient 調用 newCall 方法時，把當前線程的上下文信息關聯(lián)到 OkHttp 的 Request 中。在 Transform 過程中，我們先根據 OkHttpClient 的類名過濾出目標 class 文件，然后再根據 newCall 這個方法名過濾要插樁的方法。接下來，需要在 newCall 方法開始的地方把上下文信息插入到 request 的 tags 對象中。經過我們的分析，需要在 newCall 方法調用開始的時候，插入目標代碼。為了方便實現(xiàn)和調試，我們在擴展庫中實現(xiàn)了一個 OkHttp 的輔助工具，在目標位置插入調用這個工具的字節(jié)碼，傳入 request 對象就可以了。

插入后的字節(jié)碼會和擴展庫進行關聯(lián)。這樣就能解決三方框架數(shù)據采集和上下文自動關聯(lián)的問題。

相對于傳統(tǒng)做法，使用字節(jié)碼插樁的方案，業(yè)務代碼侵入性會更低，埋點對業(yè)務代碼和三方框架都能生效，同時結合擴展庫也能完成上下文的自動關聯(lián)。

如何確保性能

在可觀測數(shù)據采集過程中，會有大量的數(shù)據產生，對內存、CPU 占用、I/O 負載都有一定的性能要求。

我們基于 C 對核心部分進行實現(xiàn)，確保多平臺的性能一致性，并從三個方面對性能做了優(yōu)化：

首先，是對協(xié)議化處理過程進行優(yōu)化。數(shù)據協(xié)議方面選擇使用 Protocal Buffer 協(xié)議，Protocal Buffer 相對 JSON 來說，不僅速度更快，而且更省內存空間。在協(xié)議的序列化上，我們采用了手動封裝協(xié)議的實現(xiàn)，在序列化的過程中，避免了很多臨時內存空間的開辟、復制以及無關函數(shù)的調用。

其次，在內存管理方面，我們直接對 SDK 的最大使用內存做了可配置的大小限制。內存的使用，可以根據業(yè)務情況按需配置，避免 SDK 內存占用過大對 App 的穩(wěn)定性造成影響；其次，還引入了動態(tài)內存管理機制，內存空間的使用按需增加，不會一直占用 App 的內存空間，避免內存空間的浪費。同時還提升了字符串的處理性能。在字符的處理上，引入了動態(tài)字符串機制，它可以記錄字符串自身的長度，獲取字符長度時，操作復雜度低，而且可以避免緩沖區(qū)溢出，同時也可以減少修改字符串時帶來的內存重分配次數(shù)。

最后，在文件緩存管理方面，我們也限制了文件大小的上限，避免對端設備存儲空間的浪費。在緩存文件的落盤處理上，我們引入了 Ring File 機制，把緩存數(shù)據存儲在多個文件上面，以日志文件組的形式對多個文件進行組裝。整個日志文件組以環(huán)形數(shù)組的形式，從頭開始寫，寫到末尾再回到頭重新循環(huán)寫。

通過這種方式寫數(shù)據，可以減少寫文件時的隨機 Seek，而且 Ring File 的機制，可以確保單個日志文件不會過大，從而盡可能的降低系統(tǒng) I/O 的負載。除了 Ring File 的機制外，還把斷點保存、緩存清理的邏輯放到了一起聚合執(zhí)行，減少隨機 Seek。checkpoint 的文件大小也做了限制，在超出指定大小后會對 checkpoint 文件進行清理，避免 checkpoint 文件過大影響文件讀寫效率。

經過上面的這些優(yōu)化措施之后，最終 SDK 采集數(shù)據的吞吐量提升了 2 倍，內存和 CPU 占用都有明顯的降低。每秒鐘最高可支持 400+條數(shù)據的采集。

如何確保日志不丟失？

性能滿足要求還不夠，還需要確保采集到的數(shù)據不能丟失。在 App 的使用過程中，app 經?？赡軙霈F(xiàn)異常崩潰，手機設備異常重啟，以及網絡質量差，網絡延時、抖動大的情況。在這類異常場景下，如何確保采集到數(shù)據不會丟失？

在采集數(shù)據時，我們使用了預寫日志（WAL）機制，并結合自建網絡加速通道來優(yōu)化這個問題。

引入預寫日志機制的目的是確保寫入到 SDK 的數(shù)據，在發(fā)送到服務器之前，不會因為異常原因而丟失。這個過程的核心是，在數(shù)據成功發(fā)送到服務器之前，先把數(shù)據緩存在移動設備的磁盤上，數(shù)據發(fā)送成功之后，再移除磁盤上的緩存數(shù)據。如果因為 App 異常原因，或者設備重啟導致數(shù)據發(fā)送失敗，因為緩存的數(shù)據還在，SDK 會根據記錄的斷點信息對數(shù)據發(fā)送進度進行恢復。同時預寫日志機制可以確保數(shù)據的寫入和發(fā)送并發(fā)執(zhí)行，不會互相阻塞；

在數(shù)據發(fā)送之前，還會對多條數(shù)據做聚合處理，并通過 lz4 算法進行壓縮處理，這種做法可以降低數(shù)據發(fā)送時的請求次數(shù)和網絡傳輸流量的消耗。如果數(shù)據發(fā)送失敗，還會有重試策略，確保數(shù)據至少能成功發(fā)送一次；

在數(shù)據發(fā)送時，SDK 支持就近接入加速邊緣節(jié)點，并通過邊緣節(jié)點與 SLS 之間的內部網絡加速通道傳輸數(shù)據。

經過這三種主要的方式優(yōu)化之后，數(shù)據包的平均大小降低了 2.1 倍，整體的 QPS 平均提升 13 倍，數(shù)據整體的發(fā)送成功率達到了 99.3%，網絡延時平均下降了 50%。

多系統(tǒng)數(shù)據關聯(lián)處理

解決了端側數(shù)據的串聯(lián)和采集性能問題之后，還需要處理多系統(tǒng)之間的數(shù)據存儲和關聯(lián)分析問題。

數(shù)據存儲方面，我們直接基于 SLS LogHub 能力，把相關的數(shù)據統(tǒng)一存儲，基于 SLS，日均可以承載 PB 級別的流量，這個吞吐量可以支持移動端可觀測數(shù)據的全量采集。

解決了數(shù)據的統(tǒng)一存儲問題之后，還需要處理兩個主要的問題。

第一個問題，不同系統(tǒng)可觀測數(shù)據之間的上下文關聯(lián)如何處理？

根據 OTel 協(xié)議的約束，我們可以基于 parent_id 和 span_id 來處理根節(jié)點、父節(jié)點、子節(jié)點之間的映射關系。首先，在查詢 Trace 數(shù)據鏈路時，會先從 SLS 拉取一定時間段內的所有 Trace 數(shù)據。然后按照 OTel 協(xié)議的約束，對每條數(shù)據進行節(jié)點類型的判定。

由于多系統(tǒng)的數(shù)據可能存在延時，在查詢 Trace 數(shù)據鏈路時，有些數(shù)據可能還沒有到達。我們還需要對暫時不存在的父節(jié)點進行虛擬化處理，確保 Trace 鏈路的準確性。接下來，還需要對節(jié)點進行規(guī)整處理，把屬于同一個 parent_id 的節(jié)點進行聚合，然后再按照每個節(jié)點的開始時間進行排序，最終就可以得到一條 trace 鏈路信息，基于這個鏈路信息，我們可以還原出系統(tǒng)的調用鏈路。

第二個問題， 在進行 Trace 分析時，我們往往還需要從系統(tǒng)視角出發(fā)，對不同維度的數(shù)據進一步分析。比如，如果想從設備 ID、App 版本、服務調用等不同維度，對 Trace 數(shù)據進一步分析，該怎么做？我們來看一下怎么解決這個問題。

多系統(tǒng)數(shù)據拓撲生成

當我們從系統(tǒng)整體視角對問題進行分析時，所需要的 Trace 數(shù)據規(guī)模往往會比較大，每分鐘可能有數(shù)千萬條數(shù)據，而且對數(shù)據的時效性要求也比較高。傳統(tǒng)的流處理方式在這種場景下很容易遇到性能瓶頸問題。我們采用的方案是，把流處理問題轉換為批處理問題，把傳統(tǒng)的鏈路處理視角轉換為系統(tǒng)處理視角。經過視角轉化之后，從系統(tǒng)視角來看，解決這個問題最主要的核心，就是如何確定兩個節(jié)點之間的關系。

我們看一下具體的處理過程。在批處理上，我們使用了 MapReduce 框架。首先，在數(shù)據源處理階段，我們基于 SLS 的定時分析（ScheduledSQL）能力，對數(shù)據進行聚合處理，按照分鐘級從 Trace 數(shù)據源中撈取數(shù)據。在 Map 階段，先按照 traceID 進行分組，對分組之后的數(shù)據再按照 spanID、parentID 維度對數(shù)據進行聚合。

然后計算出相關的統(tǒng)計數(shù)據，如成功率、失敗率、延時指標等基礎統(tǒng)計數(shù)據。在實際的業(yè)務使用中，往往還會采集一些和具體業(yè)務屬性相關的數(shù)據，這部分數(shù)據往往會根據業(yè)務的不同，有比較大的差異。針對這部分類型的數(shù)據，在聚合處理的過程中，支持按照其他維度對結果進行分組。此時會得到兩種中間產物：

包含兩個節(jié)點關系的聚合數(shù)據，我們把這種類型的數(shù)據，叫做邊信息

以及未匹配到的原始數(shù)據

這兩種中間產物，在 Combine 階段還會再進行聚合處理，最終會得到包含基礎統(tǒng)計指標，以及其他維度的結果數(shù)據。

最終產物會包含幾個主要的信息：

邊信息，可以體現(xiàn)調用關系。

依賴信息，可以體現(xiàn)服務依賴關系。

還有指標信息，以及其他資源信息等。其中，業(yè)務屬性相關的數(shù)據會體現(xiàn)在資源信息中。

基于這些產物，我們可以通過對資源、服務等信息的多個維度篩選，來統(tǒng)計出對應維度的問題分布和影響鏈路。

自動化問題根因定位探索

接下來向大家介紹下，我們在自動化問題根因定位方向的一些探索。

我們知道，隨著 App 版本的迭代，每次 App 的發(fā)版可能會涉及到多個業(yè)務的代碼變更。這些變更，有的經過充分測試，也有的未經過充分測試，或者常規(guī)測試方法沒有覆蓋到，對線上業(yè)務可能會產生一定的潛在影響，導致部分業(yè)務不可用。App 規(guī)模越大，業(yè)務模式越多，對應的業(yè)務數(shù)據量，請求鏈路，不確定性就越大。出了問題之后，往往需要多人跨域參與排查，人肉運維成本比較高。

如何在端側問題排查定位方向，通過技術手段進行研發(fā)效能的提速？ 我們基于機器學習技術做了一些探索。

我們目前的方法是，先對 Trace 源數(shù)據進行特征處理；然后再對特征進行聚類分析，去找到異常 Trace；最后再基于圖算法等，對異常 Trace 進行分析，找到異常的起始點。

首先，實時特征處理階段會讀取 Trace 源數(shù)據，對每個 Trace 鏈路按照由底向上找 5 個節(jié)點的方式生成一個特征，并對特征進行編碼。然后對編碼之后的特征通過 HDBSCAN 算法進行層次聚類分析，此時相似的異常會分到同一個組里面，接下來再從每組異常 Trace 中找出一條典型的異常 Trace。最后，通過圖算法找到這條異常 Trace 的起點，從而確定當前異常 Trace 可能存在的問題根因。通過這種方式，只要是遵循 OTel 標準協(xié)議的數(shù)據源都能夠進行處理。

案例：多端鏈路追蹤

經過對數(shù)據處理之后，我們來看下最終的效果。

這里有一個模擬 Android、iOS、服務端，端到端鏈路追蹤的場景。

我們使用 iOS App 來作為指令的發(fā)送端，Android App 來作為指令的響應端，用來模擬遠程打開汽車空調的操作。我們從圖上可以看到，iOS 端“打開車機空調”這個操作觸發(fā)后，依次經過了“用戶權限校驗”、“發(fā)送指令”、“調用網絡請求”等環(huán)節(jié)。Android 端收到指令后，依次執(zhí)行“遠程啟動空調”、“狀態(tài)檢查”等環(huán)節(jié)。

從這個調用圖可以看得到，Android、iOS、服務端，多端鏈路被串聯(lián)到了一起。我們可以從 Android、iOS、服務端的任何一個視角，對調用鏈路進行分析。每個操作的耗時，對應服務的請求數(shù)，錯誤率，以及服務依賴都能體現(xiàn)出來。

整體架構

接下來，我們來看下整套解決方案的架構：

最底層是數(shù)據源，遵循 OTel 協(xié)議，各個端對應的 SDK 按照協(xié)議規(guī)范統(tǒng)一實現(xiàn)；

數(shù)據存儲層，是直接依托于 SLS LogHub，所有系統(tǒng)采集到的數(shù)據統(tǒng)一存儲；

再往上是數(shù)據處理層，對關鍵指標、Trace 鏈路、依賴關系、拓撲結構、還有特征等進行了預處理。

最后是上層應用，提供鏈路分析、拓撲查詢、指標查詢、原始日志查詢，以及根因定位等能力

后續(xù)規(guī)劃

最后總結下我們后續(xù)的規(guī)劃：

在采集層，會繼續(xù)完善插件、注解等方式的支持，降低業(yè)務代碼的侵入性，提升接入效率

在數(shù)據側，會豐富可觀測數(shù)據源，后續(xù)會支持網絡質量、性能等相關數(shù)據的采集

在應用側，會提供用戶訪問監(jiān)測、性能分析等能力

審核編輯：劉清