阿里雲 雲原生應用研發平臺EMAS 張月（此間）

前言

當 App 發佈到用戶手裡之後，開發者對 App 運行狀態的感知就只能通過各類業務和穩定性監控了。這些監控平臺會把線上問題（如崩潰堆棧、異常網絡請求等）及業務數據採集到服務端，然後給用戶提供聚合 Metrics 等 BI 數據。但這個過程很容易丟失細節，不能直觀反映問題發生原因，導致線上問題很難排查分析。

可能聰明的你會想，我把所有的日誌都上報到後端不就行了？但是這樣會給 App 帶來很多無意義的網絡消耗，也會造成比較大的網絡和存儲的壓力。阿里雲遠程日誌（ https://www.aliyun.com/product/emascrash/tlog ）在這個場景下應運而生，通過將日誌存放 App 本地，需要時拉取的方式，在犧牲了一點實時性的情況下，解決了上報日誌費流量存儲，不上報日誌沒辦法查問題的困境。

遠程日誌具體在裡面做了哪些事情？內部又是怎麼實現的？接下來我就會從 功能、架構、體驗優化 三個方面來介紹一下遠程日誌發展過程，最後再聊聊我們的展望。

功能

如前言介紹的一樣，我們會把日誌先存在 App 本地，當需要的時候再拉取上來做分析查看。整個過程可以簡單拆解成如下幾步：

移動端特性

• C層面實現：性能提升，一份代碼多端支持
• 加密存儲：使用非對稱加密方式，日誌存儲上報更安全
• 日誌輪轉：最長支持7天日誌存儲，每天最大存儲 10M
• MMAP機制：避免緩存日誌丟失，提升性能 (注：MMAP 機制是將文件直接映射成內存的操作，避免頁緩存到文件的拷貝，詳情可移步：https://www.cnblogs.com/huxiao-tee/p/4660352.html )

後端特性

遠程日誌的定位是異步拉取，把問題日誌從移動設備端拉回來分析。結合不同使用場景，用戶對設備精準度、拉取及時性、拉取成功率等不同側重的特點，我們在拉取模式和產品聯動上做了不同的實踐。

拉取模式

精準拉取：指定設備列表

舉個例子，一個風和日麗的上午，你剛到公司，發現老闆滿臉不爽的告訴你昨天晚上他 App 崩潰了。那擺在眼前就是兩條路，要麼搞定這個問題，要麼“提桶跑路”。這個時候遠程日誌出場了，你可以熟練的輸入老闆的設備Id，做一次日誌拉取，查查老闆 App 的日誌定位原因，解決問題。

這個模式下，用戶使用面臨了兩個體驗問題：

• 拉取速度慢。下發拉取任務後，需要終端用戶重新打開App才能完成日誌上傳，但這個時間很不可控。
• 拉取成功率低。下發拉取任務會有部分設備inactive，導致沒辦法接受拉取指令，導致日誌無法上傳。

針對這個問題，我們在拉取上做了相關的優化，實現了智能篩選的功能。

智能篩選：指定篩選條件

用戶不需要指定目標設備列表，而是關心某個或幾個維度下的設備詳細日誌。那用戶可以設定拉取的設備組合條件，系統自動幫用戶選取設備。

為了加快設備拉取速度以及拉取成功率，遠程日誌在選取設備增加了如下策略：

• 自動篩選最近啟動的設備拉取。
• 自動調整篩選出的設備池，擴大拉取規模，最多擴大到原始規模的8倍等。
  

聯動崩潰數據

在端上問題發生的場景中，大多數是因為崩潰或者異常行為。為了給與對這種場景支撐，我們提供了崩潰分析數據聯動的支持，打破了「崩潰分析」 和「遠程日誌」兩個產品之間的數據孤島，提供了問題排查的更多的可能性。

數據聯動：崩潰設備列表

通過崩潰分析提供崩潰設備列表，可以幫遠程日誌直接劃定待拉取設備範圍，用戶更加省力，通過 EMAS 「崩潰分析」中的列表頁一鍵跳轉拉取。

這個方式極大簡化了用戶在排查崩潰相關問題時選定設備列表的工作，但對於每個崩潰問題還是需要創建拉取日誌任務。這個拉取過程還是存在一個時間上的遲滯感，這不僅會打斷工程師的排查思路，也會消磨排查問題的積極性。我們能否免除拉取動作，直接把崩潰問題對應的設備日誌準備好呢？「智能拉取」就是為了解決這個場景的問題。

智能拉取：提前拉取

我們加深了前面的數據聯動，對於首現和 Top 崩潰問題，每天7點定時創建任務，開發同學上班的時候基本上都已經拉取成功了，極大的提升了開發同學的問題排查效率。

架構

體驗優化

除了在內功上打磨，產品的使用體驗上我們也做了相當多的優化，也和大家分享一下。

• 任務消息通知，讓你能夠第一時間感知日誌上報
• 整合任務詳情與日誌詳情頁面，查看任務日誌更方便
• 完善任務、設備、日誌查詢篩選
• 任務時間線透出，感知任務生命週期
• 頂部菜單欄變側邊欄，控制檯與EMAS風格統一
• 拉取任務持久化，容錯性更好。
  

到此，遠程日誌的現有的功能、架構和體驗介紹就此結束了，接下來說說我們對未來的規劃。

展望

增加上報形式

目前都是通過服務端下發任務，端上接受任務上報這種「被動上報」的模式，有一定的侷限性，我們接下來希望對客戶端在某些情況下「主動上報」日誌，比如連續Crash，或者用戶在App內反饋問題時上報做相應的支持。

豐富採集數據

現在我們的日誌打印僅限於用戶日誌，還需要支持更多的無痕埋點，記錄用戶操作路徑和網絡IO等操作，讓日誌數據更豐富，能夠通過日誌復現用戶操作流水，機器狀態的變化。

更多產品聯動

「崩潰分析」是我們產品聯動的第一站，除了崩潰和異常，對品質有追求的App開發者也越發重視性能問題，畢竟「功能決定現在，性能決定未來」，後續我們也會思考和如何將「性能分析」產品和遠程日誌打通，更好的服務我們的用戶。

移動研發平臺 EMAS

阿里巴巴應用研發平臺 EMAS 是國內領先的雲原生應用研發平臺（移動App、H5應用、小程序、Web應用等），基於廣泛的雲原生技術（Backend as a Service、Serverless、DevOps、低代碼等），致力於為企業、開發者提供一站式的應用研發管理服務，涵蓋開發、測試、運維、運營等應用全生命週期。
歡迎大家移步使用：https://cn.aliyun.com/product/emas