Android客戶端的日志采集系統研究

譚倚靖　譚智文　張亮　韋通明　蘇萬德

【摘? 要】本文研究一種Android客戶端日志采集系統的整體解決方案，實現終端日志的“全量滾動緩存+動態配置上報”，保證日志信息的完整存儲，并減少無用日志上報。

【關鍵詞】日志系統；客戶端；Android系統；日志采集

中圖分類號：U463.6? ? 文獻標志碼：A? ? 文章編號：1003-8639（ 2023 ）08-0040-03

Research on Log Collection System of Android Client

TAN Yi-jing，TAN Zhi-wen，ZHANG Liang，WEI Tong-ming，SU Wan-de

（SAIC GM Wuling Automobile Co.，Ltd.，Guangxi Laboratory of New Energy Automobile，

Guangxi Key Laboratory of Automobile Four New Features，Liuzhou 545007，China）

【Abstract】This paper studies an overall solution of Android client log collection system to achieve the“full rolling cache+dynamic configuration reporting”of terminal logs，ensure the complete storage of log information，and reduce the reporting of useless logs.

【Key words】log system；client；Android system；log collection

日志是操作系統或應用程序在運行時的事件記錄，為開發人員提供程序運行過程中的狀態變化信息，用于處理和觀察分析系統或程序的運行是否符合預期的結果。

1? 客戶端系統的多樣性問題

服務端的日志系統較為成熟，目前主流的日志系統使用ELK作為日志的分布式存儲，使用skywalking作為微服務架構中的分布式鏈路解決方案，使得開發者能夠便捷地收集和查詢日志，協助處理系統問題。而客戶端與服務端不同，相較于服務端穩定的網絡架構，客戶端需要面對更多的多樣性問題。

1）客戶端平臺的多樣性。云平臺上的服務器、每個人手里的手機以及物聯網設備等終端都可以作為客戶端，不同的客戶端通常使用不同的操作系統，這就要求客戶端的日志系統需要在多平臺實現，或者具備跨平臺的能力。

2）客戶端場景的多樣性。客戶端為用戶所有，用戶在客戶端進行業務交互時，其是否同意采集并上傳日志、產品應用是否希望用戶感知到日志的采集與回傳操作、流量的消耗是否合理……這些問題都需要基于具體的應用場景來設計，場景需求的多樣性則要求客戶端日志系統需要具備較高的可配置能力，同時，日志采集需要盡量低消耗與無感知。

3）客戶端網絡環境的多樣性。互聯網有多種接入方式，常見的有：WIFI接入、移動蜂窩網絡接入、有線寬帶接入、USB橋接網絡接入……多種網絡可能隨時切換，也隨時可能出現網絡不穩定、短時離網等異常情況。為保證日志數據不因為網絡問題而丟失，要求客戶端的日志系統需要具備數據緩存、數據壓縮、斷點續傳、超時重連等機制，以保證日志系統在復雜網絡條件下能夠正常運作。

2? Android客戶端的日志采集系統現狀

客戶端系統種類甚多，對于實現復雜業務場景的客戶端系統，在出現系統異常時，常常難以為每個問題提供場景復現與復測條件，因此需要日志收集系統的支持。當前，在復雜業務客戶端系統中，開源的Android應用最為廣泛，故本文主要探討Android客戶端的日志采集系統如何實現，并解決客戶端日志系統面臨的主要難點問題。

在Android系統的應用中，日志級別分為錯誤日志（Error）、警告日志（Warn）、信息日志（Info）、調試日志（Debug）、詳細日志（Verbose）。日志級別用于篩選日志內容時，使用者可根據實際需要來選擇查看不同級別的日志。

目前，常見的Android日志收集方式主要有以下3種。

1）日志僅本地存儲，用戶主動回傳。在客戶端出現嚴重問題時，引導用戶主動操作上報日志壓縮文件。通常作為操作系統方的實現方式，例如：手機系統、車機系統，采集的日志類型包含系統日志、應用日志、內核日志、外部設備日志等，日志內容全，覆蓋范圍廣。由于操作系統的重要性，在發布正式版本前大多經過了一層層的嚴格測試，線上問題較少。采用這種日志收集形式，便于更針對性地解決特定用戶的特定問題，并最大程度減少對于網絡資源以及服務端資源的消耗。

2）監聽系統應用程序異常，上傳錯誤日志。通常面向應用層的軟件，主要由第三方提供服務，在捕獲到App發生異常時，自動采集錯誤日志到第三方后臺，主要用于解決應用程序崩潰問題以及應用無響應問題。這種方式接入簡單高效，能夠快速、便捷地為App開發者提供錯誤統計以及日志數據。缺點則是日志內容有限，且只能在嚴重錯誤發生時獲取日志信息，而業務功能錯誤無法收集。

3）實時回傳核心業務功能的相關日志。在指定的業務代碼位置直接定義日志上傳規則及內容，每當產生新日志時即刻上報，信息冗余量較大，一般僅用于特定核心業務功能的狀態上報。

3? 研究目標

基于Android客戶端的日志采集系統現狀分析可知，前端日志采集的難點主要在于如何解決日志數據量大、價值密度低的問題。若全量日志數據盡數存儲并回傳，會顯著地占用客戶端設備的I/O性能、CPU計算性能、存儲容量以及網絡流量，且其中能夠直接發揮作用的有效日志卻可能不足總量的萬分之一，服務端接收到的數據量更與用戶數量直接相關，這大量的冗余數據對用戶和服務端的資源都造成了浪費。所以，主流的解決方案都會考慮解決或回避這些問題，例如：僅在發生程序崩潰時上傳錯誤日志，盡量提高上傳日志數據的價值密度，僅上傳特定用戶的日志數據，降低服務端資源消耗，更針對性地處理用戶問題。

本文研究一種“全量滾動緩存+動態配置上報”的Android客戶端日志采集系統解決方案。①全量滾動緩存是指對系統中所有的日志進行本地持久化存儲，并加入數據隊列的處理模式，當日志內容超出存儲池大小的時候，依次存儲新的日志和刪除最舊的日志內容，以保證存儲完整的日志信息，但不會超出預設的存儲池大小；②動態配置上報是指通過后臺動態配置的方式，控制日志數據是否上報、上報的內容、上報的頻率等信息，依據需求來確定需要上報的內容和方式，減少無用日志上報。

根據Android客戶端日志采集系統解決方案的主要思想，可以將設計目標拆分為以下4個方面。

1）配置功能：日志采集需要具備動態配置功能，可以通過服務端配置文件控制日志存儲池大小、日志內容上報的過濾條件、上報頻率等配置參數。

2）性能要求：日志采集模塊需要接入方便，穩定高效，對項目的入侵度低，對目標設備性能影響小。

3）日志存儲：日志采集內容可以進行本地持久化，不擠兌應用的存儲空間，日志內容滾動更新，應用意外停止時具備防止日志內容丟失的機制。

4）數據安全性：日志采集內容需要保證安全性，對內容進行加密，防止信息泄露。

本文設計的日志采集系統在適用范圍方面，只要是具備數據存儲能力和網絡傳輸能力的設備，都符合本文設計的系統要求，而市面上運行Android系統的主要設備有智能手機、平板電腦、汽車的車載車機模塊、智能電視或機頂盒等，都具備存儲與網絡傳輸的基礎能力。

4? 數據模型定義

數據模型中的數據結構采用JSON格式，主要原因是Android依賴庫自帶JSON庫，無需增加其他第三方依賴，且性能穩定，并提供了很好的可讀性。主要的數據模型有“日志數據模型”和“配置文件數據模型”。日志數據模型示例見表1，配置文件數據模型示例見表2。

5? 系統架構詳細設計

系統的架構設計分為日志管理控制模塊、本地存儲模塊、加密模塊、網絡請求模塊、自動化日志插樁模塊、Crash與ANR日志收集模塊，整體架構設計如圖1所示。

1）日志管理控制模塊：整個日志采集系統的主要業務邏輯模塊。用于管理日志系統的整體調度，控制是否開始日志收集、日志文件的緩存大小、緩存時間、日志上報時間間隔等信息。配置信息的獲取時機是在系統的初始化過程中，即在系統每次啟動時請求最新的配置信息。為了進一步保證配置信息的及時更新，對需要更新的配置信息，將會在每次上報日志的響應體中進行跟隨返回指向性配置。日志管理配置信息獲取流程如圖2所示。

若使用長鏈接或消息推送協議的方式來更新配置信息，會更高效與及時，但這樣無疑會增加整個系統的復雜度，也需要付出更多的性能代價，故本文建議的配置更新方式為請求伴隨的方式。

2）本地存儲模塊：日志系統的核心模塊。日志信息通常數據量龐大，讀寫I/O本就是比較消耗性能的操作，如果調度寫入日志信息存儲到本地，會太過消耗系統的I/O資源，若日志采集系統會從性能上影響到業務功能的流暢性，則是得不償失的。因為存儲部分是整個系統中的主要性能模塊，所以需要盡可能地對其進行性能優化。Android系統的應用運行采用的是java虛擬機的執行機制，內存的分配與回收由虛擬機自行調度，面對大量的日志數據持續處理的條件下，硬件配置較低的宿主設備會頻繁觸發GC，而表現到頂層應用的現象就是卡頓，可通過Android的NDK工具集，使用C++的原生代碼實現整個日志的存儲調度。同時還可以利用linux的mmap內存映射方法，省去寫入存儲前需經過buffer內存空間的過程，直接映射內存地址，當發生應用意外中斷和I/O資源滿載等異常情況時，能夠大大降低數據丟失風險。

3）加密模塊：日志內容反映了系統或軟件的運行狀態，輸出的參數甚至可能包含一些關鍵涉密信息，需要對日志內容進行加密，保證信息安全。對日志的內容進行加密時，由于日志數據量龐大，需要使用高效的數據加密方式，并保證日志內容不被破解。加密方案主要參考https協議的數據傳輸加密模式，對日志內容使用對稱加密方式進行加密，同時對密鑰文件使用非對稱加密方式進行加密。日志信息加密存儲流程如圖3所示。

4）網絡請求模塊：用于與服務端的網絡數據傳輸，包含日志系統的控制信息獲取，以及日志文件上報。客戶端采用隊列形式的單一請求，使用Android系統自帶的HttpURLConnection請求類，HttpURLConnection是對于http協議的封裝，底層通過Socket通信實現。其優點是作為系統庫類較為穩定，也不需要增加其他的網絡封裝庫，使得日志采集系統盡量輕量化，同時可以避免對于外部庫的依賴而產生的沖突與版本兼容問題。

5）自動化日志插樁模塊：輔助功能之一，以可選插件的形式添加到系統中，對于一些無輸出日志的功能模塊，可為其增加日志。

6）Crash與ANR日志收集模塊：輔助功能之一，以可選插件的形式添加到系統中，監聽系統是否出現Crash與ANR，自動獲取系統內的Crash堆棧日志和ANR線程日志文件上報。

6? 數據安全與用戶隱私

日志輸出的內容可能是業務應用中的各項數據，數據內容甚至可能包含用戶行為數據和隱私數據。因此，對于日志采集系統來說，一方面需要符合隱私協議與用戶手冊的內容，是否開啟日志采集，采集哪些內容需要完全可控，這一點可以通過日志采集系統中的日志管理控制模塊實現；另一方面需要保證傳輸的數據安全，不能被黑客入侵手機獲取應用內的核心信息，也不能被抓包或中間人攻擊的方式獲取到日志數據信息，這一方面則通過日志采集系統的加密模塊來實現對數據的保護。

7? 應用與拓展

本文所論述的是如何在Android客戶端實現一個高效、穩定、可控的日志采集系統，雖然未對后端服務設計進行詳細說明，但其后端服務對于前端的Android日志采集系統的功能有著重要的關聯與影響。一方面，其能夠控制日志配置的管理下發，另一方面，后端服務保存所有上傳的日志數據。

現階段后端的日志系統較為成熟，一般使用skywalking管理微服務請求調用鏈，記錄整條鏈路的調用詳情；通過trackID貫穿整條鏈路；使用logstash來過濾有效的日志信息；使用elasticsearch來存儲logstash過濾后的日志信息和skywalking的鏈路數據；使用kibana來讀取日志并展示統計信息頁面。在存儲和管理Android前端時的日志信息時，只要對日志的數據模型進行設計整合，即可對前后端的日志數據進行統一管理，降低后端服務資源消耗。此外，對于應用程序中的異步方法和多線程方法來說，日志信息的記錄會呈現為亂序，不便于將同一調用鏈下的日志進行整合排查，而通過在前端請求中也加入trackID，打通前后端日志的調用鏈關系，可以實現更高效的全鏈路日志排查。

8? 總結

本文從控制能力、終端性能、數據安全性以及前后端整合的角度，論述了在Android平臺下對于客戶端日志采集系統的整體設計。在實際應用場景中，可以結合業務需求，對日志的配置文件和日志模型進行調整，也可以根據現有的后端日志系統進行適配性調整。

參考文獻：

[1] 趙書慧. Android日志過濾器中正則表達式的應用[J]. 電子測試，2021（2）：84-85.

[2] Meng Zhaoyi，Xiong Yan，Huang Wenchao，etc. AppAngio：Revealing Contextual Information of Android App Behaviors by API-Level Audit Logs[J]. IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY，2021（16）：1912-1927.

[3] 徐永新. 高性能分布式日志系統研究與設計[J]. 工業控制計算機，2020，33（12）：44-46.

[4] 鄭仕元，劉軍. 不可信環境下的客戶端日志保護機制[J]. 計算機工程，2011，37（23）：138-140.

[5] 王祥雒，李毅. Linux中基于mmap（）的共享存儲實現研究[J]. 計算機應用，2006（S2）：307-309，320.

[6] 吳云周，程鵬，林飛. JSON在Android客戶端和網頁客戶端的應用研究[J]. 電腦編程技巧與維護，2017（18）：40-43.

（編輯? 凌? 波）

作者簡介

譚倚靖（1994—），女，工程師，主要從事大數據應用相關工作。