淘寶用戶端診斷體系更新實踐

作者｜伝逸

淘寶作為一個航母級的應用，每天都有數億的使用者在使用。保證用戶端的穩定性是我們的首要目标。為此，我們也提出了5-15-60的目标。即問題告警時，5分鐘響應，15分鐘定位，60分鐘恢複。

但是現有的排查體系并不能很好的達到這個目标，分析下來主要原因是：

監控階段

1. 通過Crash堆棧、異常資訊進行聚合統計，不夠精細準确，不夠靈敏；
2. 監控到異常後，端側行為比較單一，隻上報異常資訊，無法提供更多有用資料；
3. 手淘大部分問題都和線上變更有關，但是缺少對變更品質的監控。

排查階段

1. 監控上報的異常資訊不足，依賴日志進行問題排查；
2. Crash或異常時不會主動上傳日志，需要手動撈取， 使用者不線上擷取不到日志；
3. 擷取日志之後：

1. 1. 缺少分類，缺乏标準，日志雜亂，看不懂其他子產品的日志；
   2. 缺少場景資訊，無法完整的重制異常時使用者的操作場景；
   3. 缺少整個生命周期相關的事件資訊，無法掌握app的運作情況；
   4. 各個子產品上下遊的日志資訊無法有效關聯形成完整鍊路；
   5. 現有日志可視化工具功能較弱，無法提高排查效率；

1. 問題排查靠人工分析，效率低下，相同問題缺少沉澱；
2. 各個系統間的資料缺少關聯，需要到多個平台擷取資料。

診斷體系更新思路

針對以上現有問題，我們重新設計了整個無線運維排查診斷體系的架構。在新的架構中，我們引入了場景的概念。以往端上發生的異常都是一個個獨立的事件，沒有辦法針對不同的異常做更精細的處理和資料收集。而引入場景概念後，一個場景可能是一個異常和多種條件的組合，針對不同的場景可以做配置，使得異常資訊的收集更加豐富，更加精準。

同時我們重新定義了端側異常資料，主要包括标準的Log日志資料、記錄調用鍊路的Trace全鍊路資料、運作時相關的Metric名額資料以及發生異常時的現場快照資料。平台側可以利用異常資料進行監控和告警。也可以對這些資料進行可視化的解析，針對業務的差異，平台提供了插件化的能力來解析資料。利用這些語義化後的資訊，平台可以進行初步的問題診斷。

是以接下來要實作的目标是：

1. 實作端側場景化的監控運維；
2. 更新日志體系，實作LOG、TRACE、METRIC資料整合， 提供更加豐富和精準的排查資訊；
3. 完成高可用體系資料整合，提供面向問題排查的标準化接⼝和平台；
4. 插件化支撐平台賦能，業務自定義診斷插件，完成診斷體系平台間對接；
5. 平台依據診斷資訊，給出診斷結果，能做到自動化、智能化；
6. 依據診斷結果給出解決方案或提出整改需求，形成從需求->研發->釋出->監控->排查->診斷->修複->需求的閉環。

日志體系更新

目前分析運作日志還是端側排查問題的主要手段，前面也提到我們的日志本身存在一些問題。是以我們第一步是對日志體系進行了更新。（在此之前我們完善了日志自身的基礎能力，比如提升寫入性能、提升日志壓縮率、提升上傳成功率、建立日志的資料大盤等等）

為了提高日志的排查效率，我們從日志内容着手，重新制定了端側的标準日志協定。标準化的日志協定可以為我們在平台側進行日志可視化建設、自動化日志分析提供幫助。我們從Log、Trace、Metric角度出發，依照手淘的實際情況将現有的日志分為以下幾類：

1. CodeLog: 相容原有的日志，這些日志相對雜亂；
2. PageLog：記錄端上頁面跳轉情況，排查問題時可以從頁面次元對日志進行劃分；
3. EventLog：記錄端側各種事件，比如前背景切換、網絡狀态、配置變更、異常、點選事件等等；
4. MetricLog: 記錄端側運作時的各種名額資料，比如記憶體、CPU、業務的各種名額資料；
5. SpanLog: 全鍊路日志資料。把各個獨立的點串聯起來，定義統一的性能度量、異常檢測的标準。基于OpenTrace的方案和服務端打通，形成端到端的全鍊路排查機制。

有了這些資料之後。在平台側配合日志可視化平台，可以對端側的行為進行快速回放。得益于日志的标準化，可以從平台側對日志進行分析，快速展示存在異常的節點。

端側診斷更新

用戶端是整個診斷體系的源頭，一切的異常資料，運作資訊都是由用戶端上的各種工具進行收集上報的。目前端側主要工具有：

1. APM：收集端側的各種運作、性能等資訊，資料上報到服務端；
2. TLOG：收集端側運作時的日志資訊，日志檔案存放在本地，需要時服務端下發指令進行撈取；
3. UT：端側埋點工具，很多業務異常資訊都會通過UT進行上報告警；
4. 異常監控：這個以Crash SDK為代表，主要收集端側的Crash資訊，還有收集異常、使用者輿情等相關的SDK；
5. 排查工具：記憶體檢測、卡頓檢測、白屏檢查等工具。這些沒有直接歸類在APM中，因為這些工具是采樣運作，有的甚至預設是關閉狀态。

可以看到端側其實已經有不少成熟的工具在使用，但是在排查問題時候經常發現資料缺失等問題，主要原因在于一方面在平台側這些資料比較分散，沒有一個統一的接口進行查詢；另一方面用戶端沒有對這些工具的資料做整合，發生異常時這些工具間少有互動，造成了資料缺失。

為了解決這些問題，我們在端側引入了全新的診斷SDK和染色SDK。它們的主要功能有：

1. 對接現有工具，收集端側運作資料。把這些資料按照标準的日志協定寫入到TLOG日志中；
2. 監聽端側的變更資訊，生成變更的染色辨別；
3. 監聽端側異常，異常發生時生成快照資訊（包括運作資訊、變更資訊），上報服務端；
4. 場景化診斷資料上報，根據服務端配置的規則，在特定場景進行資料收集和上報；
5. 支援定向診斷，根據服務端下發的配置，調用對應的排查工具進行資料收集；
6. 支援實時日志上傳，針對特定使用者和裝置進行線上調試。

▐  異常快照

端側的異常主要包括Crash、業務異常、輿情等。當異常發生時，上報的資料格式、内容、通道、平台都不一樣。若想要增加一些資料，端側和相應平台都需要進行改造。是以我們對端側異常監控相關的SDK進行了監聽，對于業務提供了異常通知接口。當診斷SDK接收到異常時，會利用目前收集到的運作資訊生成一份快照資料。每個快照資料會有一個唯一的snapshotID。我們隻需要把這個ID傳遞給對應的SDK，這樣對現有的SDK改動是最小的。

快照資料随着端側能力的加強也會越來越豐富。收集到的快照資訊會上傳到診斷平台，平台之間可以利用snapshotID進行資料關聯。對于診斷平台來說，可以根據快照資訊、日志資訊對異常進行分析，給出初步的診斷結果。

▐  變更監控

手淘中大部分的問題是因為線上變更導緻的。現有監控排查體系并沒有專門對變更進行監控，主要還是依賴異常數量、異常趨勢進行告警。這就有一定的滞後性，導緻很難在放量階段快速的發現問題。同時對于變更釋出也沒有一個統一的管控标準。是以我們在端側引入了染色SDK來收集變更資料，配合無線運維的變更診斷平台，對變更釋出進行監控，做到可灰階、可觀測、可復原。

目前端側的變更包括通用的配置變更（Orange平台）、AB試驗變更和業務自定義的變更（試金石、安全、新奧創等等）。染色SDK在端側和這些SDK進行對接，收集到端側的變更資料後會生成對應的染色辨別并上報。配合TLOG和診斷SDK，記錄這些變更，并且在發生異常時給異常資訊打标。平台側也會和各個釋出平台、高可用資料平台打通，根據用戶端上報的資料進行釋出決策。

• 染色辨別

變更其實是服務端向用戶端下發資料，用戶端使用的過程。 

是以針對變更，我們定義出：

1. 變更類型：用來區分變更的種類，比如配置變更（orange）、試驗變更（ABTest）、業務A變更，業務B變更等等；
2. 配置類型：一個變更類型下可能有多個配置，比如orange變更，每個配置有一個namespace，用來區配置設定置的類型；
3. 版本資訊: 代表了一個配置的一次具體的釋出。不一定所有配置變更都有明确的版本資訊，可以把某個釋出或配置的唯一辨別作為版本資訊。比如每個orange配置釋出都有一個version，每個ABTest釋出都有一個publishID。

有了這些資訊我們就可以給每一個變更生成一個唯一的染色辨別。通過上報染色辨別我們可以統計出變更的生效數；通過在快照資訊中攜帶染色辨別，可以計算有變更辨別的crash率、輿情數量；通過和高可用大盤資料進行比較監控變更的品質。業務也可以在網絡請求中帶上染色辨別，用于統計相關的接口是否存異常。

• 灰階定義

對于染色SDK我們是希望在灰階期間可觀測，提早發現問題，不把變更導緻的問題帶到線上全量環境中，是以我們把釋出過程定位為三個階段：

1. 準備期：準備變更資料，預發驗證、送出審批、線上釋出。這個階段可以确定釋出變更的類型、配置、版本；
2. 灰階期：對部分使用者下發變更配置。我們的染色監控也主要是在這個階段運作，主要為上報染色辨別和在異常快照中攜帶染色辨別。平台側在這個階段對資料進行處理，生成灰階相關資料；
3. 全量期：當灰階達标之後，進入全量期。這個時候向所有滿足條件的使用者推送配置。

▐  資料上報控制

因為手淘使用者量太大，變更全量之後如果還繼續上報生效資料，對服務端的壓力會很大。同時異常資訊中如果繼續打标意義也不大了。是以我們必須有一個機制來管控端側的染色資料上報。

針對orange、ABTest這些通用的變更，我們進行了單獨适配，可以根據實驗号、配置namespace進行黑白名單控制、采樣控制或釋出狀态來控制。但對于自定義變更來說，可控制的條件千差萬别，如果要做到精細的控制就必須要了解這個特定的變更。是以我們定義了一些通用的條件：灰階辨別、采樣率、過期時間來控制。

這些資訊是通過配置檔案的形式下發到端上。端側無需關注這些條件設定的邏輯，而是在平台側進行設定，平台側對接釋出平台、高可用平台，并根據上報資料進行決策。目前主要還是依據配置中的灰階辨別+逾時時間來決定是否上報。

▐  釋出門禁

端側上報了生效數、異常染色等資料之後，服務端就可以根據這些資料來監控變更。根據相關Crash數量、輿情數量、灰階時間等來判定目前變更是否達到了全量釋出的标準。 

同時也會列出和這次變更相關的crash資訊、輿情資訊。輔助判定本次變更釋出是否存在風險。

目前已經有Orange配置變更、AB試驗變更、詳情、下單等業務接入。效果還是不錯，已經成功規避了4個線上故障。 

▐  場景化上報

場景化資料上報，是診斷體系中的一個重要能力。以往都是當告警時我們手動的從端上撈取相關資料進行排查，并且不同異常需要的資料也不相同，經常要跨多個平台，進行多次操作。這就導緻資料擷取滞後，整個排查時長不可控。是以在端側具備了新的日志标準、異常快照收集、異常變更染色等基礎能力後，我們引入了場景化上報。

舉個列子，按照現有的排查方式，當線上發生異常告警時，我們一般先通過上報的異常資訊來排查，但受限于現有資訊不全，往往還需要通過拉取TLOG來做進一步排查，然而TLOG撈取又依賴使用者線上，這就導緻整個排查定位時間非常長。 

引入場景化概念之後，當平台檢測到異常數量快要達到門檻值的時候，可以自動生成一份場景規則配置，圈選一批使用者下發到端上。當端上發生了相同異常的時候，場景引擎會負責收集和上報所需要的資料，這樣當告警達到門檻值時平台上就已經有足夠的資料進行分析定位。 

• 場景規則

場景引擎主要用來執行服務端下發的場景規則，而一個場景規則主要由三部分構成：

觸發(Trigger)

可以是端上的一個行為或一個事件。相對于以前隻有在Crash、業務異常時才上報資料，我們對異常觸發時機進行了擴充。

1. 崩潰異常
2. 使用者截屏回報
3. 網絡異常 （mtop錯誤、network錯誤等）
4. 頁面異常 （白屏、顯示異常）
5. 系統異常 （記憶體占用過高、 cpu占用過高、 耗電過快、發熱、卡頓）
6. 業務異常 (業務錯誤碼、邏輯錯誤等)
7. 啟動 （一般用于定向診斷）

條件(Condition)

條件判定是整個場景化上傳的核心。增加了場景條件之後，我們可以從多個次元更精準的去劃分異常類型。條件大緻上可以分為：

1. 基礎條件：從裝置資訊、使用者資訊、版本資訊等次元去進行比對和篩選；
2. 狀态條件：主要包括網絡狀态、目前頁面、記憶體水位等運作時的資訊；
3. 特定條件：不同場景需要判定的條件是不同的。比如發生Carsh時，可以根據Exception類型、堆棧等資訊進行比對。而業務異常時可能根據錯誤碼和網絡錯誤來進行比對。

行為(Action)

當端上某個規則被觸發，并且滿足設定的所有條件時，就會觸發指定的行為，這樣就可以根據不同的場景收集不同的資料。目前端側主要行為有：

1. 上傳TLOG日志 
2. 上傳快照資訊
3. 上傳記憶體資訊
4. 協同其他排查工具根據下發的參數進行資料收集上報

• 場景下發

平台側建立了一套新的場景管理平台，可以友善的配置各種場景和條件。并且也有标準的釋出、稽核、灰階流程。通過PUSH + PULL的方式，用戶端可以及時的擷取到場景規則。

平台和端側也都支援定向下發配置的能力，通過指定一些基礎的條件，可以針對不同裝置，不同使用者進行有針對性的場景下發。

• 資料流量管控

端上比對了對應的場景規則後，就會上報各種異常資料。但是如果資料量過大，會對服務端存儲産生較大壓力。是以我們針對場景上報的資料進行了流量管控。

從排查問題的角度出發，對于同一個問題我們可能隻需要幾份相關的日志和資料。是以我們在建立一個場景時會指定一個資料上報的閥值。當平台收集到足夠的資料之後，這個場景就會停止，并通知用戶端規則下線。

同時端上為了保證使用者不因為頻繁上傳診斷資料而對正常使用造成影響，端側也有自己的限流政策。比如必須是wifi環境才可以上報、限制每天執行規則的數量、限制每天上傳的資料量、設定資料的上傳間隔時間等等。

• 自定義場景

目前我們的觸發都是一些通用的場景，從高可用工具中擷取資料上報。但是業務可能有一套自己的異常監控體系。是以我們也提供了相應的接口給業務來調用，利用我們場景下發、規則表達式執行、擷取運作資料等能力，來幫助業務進行問題診斷。業務可以定義自己的觸發時機、觸發條件。後續我們也可以加入自定義行為的能力，讓業務也可以根據場景來上報相應的資料。

• 定向診斷

端上目前除了TLOG，還有記憶體工具、性能工具、卡頓工具等其他一些排查工具。這些工具在排查特定問題時比較有用。但目前線上上都是通過配置采樣開啟或預設關閉的。而現有的配置還無法針對裝置，使用者進行定向下發。這就會導緻排查問題時拿不到完整有效的資訊。是以我們也是利用場景化定向下發能力，對現有工具進行了簡單的改造，協同這些工具進行異常資料的收集和上報。

未來展望

目前端側的診斷能力還在持續的建設中，我們也針對現有排查過程中存在的痛點進行疊代，比如實時日志、遠端調試、完善全鍊路資料、異常資料等等。此外，我們也需要看到，端側診斷不再是簡單的堆砌工具，收集資料，我們未來還需要更有針對性、更精細化的去收集和處理資料。 

而随着診斷資料的完善，下個挑戰将是平台如何利用資料進行問題根因定位、分析問題影響面、對診斷結果進行沉澱。對于端側而言，也不僅僅隻定位在資料收集，還可以依賴平台的診斷知識沉澱，結合端智能的能力，在端側實作問題診斷的能力。同時可以配合端側的降級能力、動态修複等能力，在發生異常後實作自愈。