在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

基于OTel的移動端全鏈路Trace為什么很難復(fù)現(xiàn)和定位?

OSC開源社區(qū) ? 來源:阿里巴巴終端技術(shù) ? 2023-02-01 09:27 ? 次閱讀

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

3f2c2a5a-a1bb-11ed-bfe3-dac502259ad0.png

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

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

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

端側(cè)問題為什么很難復(fù)現(xiàn)和定位?

3f6b3b6e-a1bb-11ed-bfe3-dac502259ad0.png

線上業(yè)務(wù)問題為什么很難復(fù)現(xiàn)和排查定位?經(jīng)過我們的分析,主要是由 4 個原因?qū)е拢?/p>

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

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

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

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

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

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

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

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

我們也基于機器學(xué)習(xí),在自動化經(jīng)驗分析方面做了一些探索。

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

3f8b3f7c-a1bb-11ed-bfe3-dac502259ad0.png

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

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

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

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

OTel 是由云原生計算基金會(CNCF)主導(dǎo),它是由 OpenTracing 和 OpenCensus 合并而來,是目前可觀測性領(lǐng)域的準標準協(xié)議;

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

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

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

3fd10bc4-a1bb-11ed-bfe3-dac502259ad0.png

只統(tǒng)一數(shù)據(jù)協(xié)議還不夠,還要解決端側(cè)在數(shù)據(jù)采集方面存在的一些問題。總的來說,端側(cè)采集當(dāng)前面臨 3 個主要的難點:

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

性能保障難

不丟數(shù)據(jù)難

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

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

4013ee9e-a1bb-11ed-bfe3-dac502259ad0.png

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

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

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

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

這里會有幾個共性問題:

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

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

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

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

40657d68-a1bb-11ed-bfe3-dac502259ad0.png

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

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

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

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

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

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

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

408556b0-a1bb-11ed-bfe3-dac502259ad0.png

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

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

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

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

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

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

如何解這兩個問題?

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

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

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

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

如何確保性能

40c81c84-a1bb-11ed-bfe3-dac502259ad0.png

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

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

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

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

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

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

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

如何確保日志不丟失?

40ea8aee-a1bb-11ed-bfe3-dac502259ad0.png

性能滿足要求還不夠,還需要確保采集到的數(shù)據(jù)不能丟失。在 App 的使用過程中,app 經(jīng)常可能會出現(xiàn)異常崩潰,手機設(shè)備異常重啟,以及網(wǎng)絡(luò)質(zhì)量差,網(wǎng)絡(luò)延時、抖動大的情況。在這類異常場景下,如何確保采集到數(shù)據(jù)不會丟失?

在采集數(shù)據(jù)時,我們使用了預(yù)寫日志(WAL)機制,并結(jié)合自建網(wǎng)絡(luò)加速通道來優(yōu)化這個問題。

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

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

在數(shù)據(jù)發(fā)送時,SDK 支持就近接入加速邊緣節(jié)點,并通過邊緣節(jié)點與 SLS 之間的內(nèi)部網(wǎng)絡(luò)加速通道傳輸數(shù)據(jù)。

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

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

412d1a3a-a1bb-11ed-bfe3-dac502259ad0.png

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

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

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

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

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

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

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

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

416074de-a1bb-11ed-bfe3-dac502259ad0.png

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

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

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

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

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

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

最終產(chǎn)物會包含幾個主要的信息:

邊信息,可以體現(xiàn)調(diào)用關(guān)系。

依賴信息,可以體現(xiàn)服務(wù)依賴關(guān)系。

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

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

自動化問題根因定位探索

417e0224-a1bb-11ed-bfe3-dac502259ad0.png

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

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

如何在端側(cè)問題排查定位方向,通過技術(shù)手段進行研發(fā)效能的提速? 我們基于機器學(xué)習(xí)技術(shù)做了一些探索。

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

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

案例:多端鏈路追蹤

41b5fdc8-a1bb-11ed-bfe3-dac502259ad0.png

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

這里有一個模擬 Android、iOS、服務(wù)端,端到端鏈路追蹤的場景。

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

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

整體架構(gòu)

41ee024a-a1bb-11ed-bfe3-dac502259ad0.png

接下來,我們來看下整套解決方案的架構(gòu):

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

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

再往上是數(shù)據(jù)處理層,對關(guān)鍵指標、Trace 鏈路、依賴關(guān)系、拓撲結(jié)構(gòu)、還有特征等進行了預(yù)處理。

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

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

42b8046e-a1bb-11ed-bfe3-dac502259ad0.png

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

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

在數(shù)據(jù)側(cè),會豐富可觀測數(shù)據(jù)源,后續(xù)會支持網(wǎng)絡(luò)質(zhì)量、性能等相關(guān)數(shù)據(jù)的采集

在應(yīng)用側(cè),會提供用戶訪問監(jiān)測、性能分析等能力






審核編輯:劉清

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • API
    API
    +關(guān)注

    關(guān)注

    2

    文章

    1563

    瀏覽量

    63559
  • Trace
    +關(guān)注

    關(guān)注

    0

    文章

    19

    瀏覽量

    10719
  • SDK
    SDK
    +關(guān)注

    關(guān)注

    3

    文章

    1066

    瀏覽量

    47731
  • SLS
    SLS
    +關(guān)注

    關(guān)注

    0

    文章

    15

    瀏覽量

    9041
  • 調(diào)度器
    +關(guān)注

    關(guān)注

    0

    文章

    98

    瀏覽量

    5460

原文標題:SLS:基于 OTel 的移動端全鏈路 Trace 建設(shè)思考和實踐

文章出處:【微信號:OSC開源社區(qū),微信公眾號:OSC開源社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦
    熱點推薦

    大普技術(shù)時鐘同步解決方案再添新品

    據(jù)國際數(shù)據(jù)公司(IDC)預(yù)測,到2025年,全球超過60%的數(shù)字化轉(zhuǎn)型項目將依賴高精度位置服務(wù)。傳統(tǒng)衛(wèi)星導(dǎo)航的米級定位精度已難以滿足智能交通、工業(yè)互聯(lián)網(wǎng)、災(zāi)害監(jiān)測等前沿領(lǐng)域的嚴苛要求。
    的頭像 發(fā)表于 06-05 15:50 ?136次閱讀

    定位到通信:頂堅單北斗防爆終端構(gòu)建防爆作業(yè)安全屏障

    頂堅單北斗防爆手持終端通過整合北斗衛(wèi)星導(dǎo)航系統(tǒng)、多模通信技術(shù)、本質(zhì)安全防爆設(shè)計以及智能物聯(lián)功能,構(gòu)建了覆蓋定位、通信、監(jiān)控與應(yīng)急響應(yīng)的安全屏障,為高危行業(yè)作業(yè)提供了革命性的安全保
    的頭像 發(fā)表于 05-27 11:34 ?124次閱讀
    從<b class='flag-5'>定位</b>到通信:頂堅單北斗防爆終端構(gòu)建防爆作業(yè)<b class='flag-5'>全</b><b class='flag-5'>鏈</b><b class='flag-5'>路</b>安全屏障

    泰克科技測試解決方案助力人形機器人發(fā)展

    在剛剛舉辦的人形機器人科技創(chuàng)新大會中,泰克科技(Tektronix)作為測試、測量和監(jiān)測解決方案的創(chuàng)新者,展示了其測試解決方案,為與會者提供了深入了解其在人形機器人研發(fā)領(lǐng)域的最新進展和創(chuàng)新技術(shù)的機會。
    的頭像 發(fā)表于 05-21 14:56 ?412次閱讀

    重磅預(yù)售!RT-Trace調(diào)試工具

    嵌入式開發(fā)者注意!調(diào)試神器RT-Trace即將登陸淘寶!嵌入式開發(fā)從業(yè)者們:您是否常被調(diào)試效率低下、線程分析不清、故障定位困難所困擾?別愁!專為嵌入式開發(fā)者打造的高性能調(diào)試工具RT-Trace即將
    的頭像 發(fā)表于 05-20 18:15 ?313次閱讀
    重磅預(yù)售!RT-<b class='flag-5'>Trace</b>調(diào)試工具

    4月22日北京|國產(chǎn)化模塊測試儀器大會

    隨著5G、物聯(lián)網(wǎng)、通信等技術(shù)的快速發(fā)展、國際環(huán)境復(fù)雜多變,傳統(tǒng)測試儀器因體積龐大、功能單一、擴展性差等問題難以滿足高頻、高精度、多場景的測試需求,在此背景下,“國產(chǎn)化模塊測試儀器大會”將于4月
    的頭像 發(fā)表于 04-18 16:44 ?250次閱讀
    4月22日北京|國產(chǎn)化<b class='flag-5'>全</b><b class='flag-5'>鏈</b><b class='flag-5'>路</b>模塊測試儀器大會

    安博電子:品控體系賦能供應(yīng)安全

    檢測、智能交付的品控體系,安博電子不僅能確保電子元器件的高可靠性與一致性,更以高透明的供應(yīng)管理模式,助力客戶降低風(fēng)險、提升運營效率,推動行業(yè)標準升級,與全球
    的頭像 發(fā)表于 04-07 17:03 ?335次閱讀
    安博電子:<b class='flag-5'>全</b><b class='flag-5'>鏈</b><b class='flag-5'>路</b>品控體系賦能供應(yīng)<b class='flag-5'>鏈</b>安全

    智能推送系統(tǒng)的統(tǒng)計功能:數(shù)據(jù)閉環(huán)下的運營增效革命

    在精細化運營時代,APP企業(yè)面臨的核心挑戰(zhàn)已從“如何觸達用戶”轉(zhuǎn)向“如何量化每一次觸達的價值”。MobPush智能推送系統(tǒng)的統(tǒng)計功能,通過追蹤用戶從推送接收、點擊到最終轉(zhuǎn)化的完整路徑,構(gòu)建
    的頭像 發(fā)表于 02-25 17:23 ?309次閱讀

    使用OTDR進行光纖測試的方法

    :確保在安全的環(huán)境下操作OTDR,避免激光對眼睛造成傷害。 2. 連接OTDR 將OTDR連接到光纖的一。通常,OTDR會有一個發(fā)射和一個接收
    的頭像 發(fā)表于 12-31 09:17 ?1979次閱讀

    調(diào)試PCIE動態(tài)均衡介紹

    ,它會衰減數(shù)據(jù)流中的關(guān)鍵高頻分量,此外,由連接器和過孔引起的阻抗不連續(xù)會進一步降低性能。 PCIe均衡可應(yīng)用于發(fā)送 (TxEQ)、
    的頭像 發(fā)表于 12-05 09:18 ?1545次閱讀
    調(diào)試PCIE<b class='flag-5'>鏈</b><b class='flag-5'>路</b>動態(tài)均衡介紹

    PCle培訓(xùn)概述

    電子發(fā)燒友網(wǎng)站提供《PCle培訓(xùn)概述.pdf》資料免費下載
    發(fā)表于 09-11 09:16 ?0次下載
    PCle<b class='flag-5'>鏈</b><b class='flag-5'>路</b>培訓(xùn)概述

    IR615如何實現(xiàn)VPN備份?

    備份,設(shè)置主接口為WAN口備份接口為WAN(sta)口。選擇網(wǎng)絡(luò)》備份 測試:斷開IR615 WAN口網(wǎng)線,查看路由表,可以看到默認路由已經(jīng)切換到WAN(sta) OpenS
    發(fā)表于 07-25 08:27

    IG網(wǎng)關(guān)產(chǎn)品實現(xiàn)備份的方法

    。 同時可以啟用ICMP偵測功能確保通訊信號的時效性。 三:WiFi模式設(shè)定為STA后重啟設(shè)備,設(shè)定并掃描需要連接的WiFi輸入密碼,應(yīng)用連接。以上連接均可以在IG設(shè)備主頁或IR設(shè)備網(wǎng)絡(luò)連接的頁面下
    發(fā)表于 07-24 08:25

    LM2512A移動像素,24位RGB顯示接口串行器數(shù)據(jù)表

    電子發(fā)燒友網(wǎng)站提供《LM2512A移動像素,24位RGB顯示接口串行器數(shù)據(jù)表.pdf》資料免費下載
    發(fā)表于 07-04 11:53 ?0次下載
    LM2512A<b class='flag-5'>移動</b>像素<b class='flag-5'>鏈</b><b class='flag-5'>路</b>,24位RGB顯示接口串行器數(shù)據(jù)表

    光纖的相關(guān)介紹

    光纖的組成部分 光纖電纜:光信號的傳輸介質(zhì),由核心、包層和保護套構(gòu)成。 光收發(fā)器(Transceiver):將電信號轉(zhuǎn)換為光信號(發(fā)射)或?qū)⒐庑盘栟D(zhuǎn)換為電信號(接收)。 光放大
    的頭像 發(fā)表于 06-11 10:13 ?844次閱讀

    如何識別光纖問題?

    光纖網(wǎng)絡(luò)專為連續(xù)運行而設(shè)計。通常,光纖網(wǎng)絡(luò)以最佳效率運行。然而,網(wǎng)絡(luò)中有時會遇到光纖問題。由于光纖網(wǎng)絡(luò)的復(fù)雜性,這些光纖問題很難識別
    的頭像 發(fā)表于 06-11 10:12 ?875次閱讀
    主站蜘蛛池模板: 欧美性生活网站 | 精品一区二区在线观看 | 色一乱一伦一区一直爽 | 永久免费品色堂 | 狠狠做深爱婷婷综合一区 | 久久这里只有精品免费播放 | 久久综合一 | 五月天在线婷婷 | 美女操网站 | 色噜噜网站 | 四虎影院在线视频 | 小说老卫陈红张敏陈法蓉 | 女生张开腿让男人桶 | 亚洲黄色性视频 | 综合丁香 | 国产裸露片段精华合集链接 | 成人在线网站 | www视频在线观看com | 欧美一区二区视频在线观看 | 一区二区三区免费精品视频 | jinv在线视频 | 成人永久免费视频网站在线观看 | 97影院理论午夜论不卡 | 日本色图在线 | 色片免费网站 | 国产人人看 | 人人艹人人射 | 天堂网2021天堂手机版丶 | 福利视频自拍偷拍 | 色婷婷综合激情 | 草逼网址 | 中文在线最新版天堂 | www.色在线观看 | 天天爽夜夜爽免费看 | 91大神在线看 | 综合色婷婷| 成人a毛片高清视频 | 成人黄色激情网 | 日本成人在线网址 | 色噜噜狠狠色综合久 | 国产农村妇女毛片精品久久 |