Logan:美團點評的開源移動端基礎日志庫


logo

前言

Logan是美團點評集團移動端基礎日志組件,這個名稱是Log和An的組合,代表個體日志服務。同時Logan也是“金剛狼”大叔的名號,當然我們更希望這個產品能像金剛狼大叔一樣犀利。

Logan已經穩定迭代了一年多的時間。目前美團點評絕大多數App已經接入並使用Logan進行日志收集、上傳、分析。近日,我們決定開源Logan生態體系中的存儲SDK部分(Android/iOS),希望能夠幫助更多開發者合理的解決移動端日志存儲收集的相關痛點,也歡迎更多社區的開發者和我們一起共建Logan生態。Github的項目地址參見:https://github.com/Meituan-Dianping/Logan

背景

隨着業務的不斷擴張,移動端的日志也會不斷增多。但業界對移動端日志並沒有形成相對成體系的處理方式,在大多數情況下,還是針對不同的日志進行單一化的處理,然后結合這些日志處理的結果再來定位問題。然而,當用戶達到一定量級之后,很多“疑難雜症”卻無法通過之前的定位問題的方式來進行解決。移動端開發者最頭疼的事情就是“為什么我使用和用戶一模一樣的手機,一模一樣的系統版本,仿照用戶的操作卻復現不出Bug”。特別是對於Android開發者來說,手機型號、系統版本、網絡環境等都非常復雜,即使拿到了一模一樣的手機也復現不出Bug,這並不奇怪,當然很多時候並不能完全拿到真正完全一模一樣的手機。相信很多同學見到下面這一幕都似曾相識:

用(lao)戶(ban):我發現我們App的XX頁面打不開了,UI展示不出來,你來跟進一下這個問題。

你:好的。

於是,我們檢查了用戶反饋的機型和系統版本,然后找了一台同型號同版本的手機,試着復現卻發現一切正常。我們又給用戶打個電話,問問他到底是怎么操作的,再問問網絡環境,繼續嘗試復現依舊未果。最后,我們查了一下Crash日志,網絡日志,再看看埋點日志(發現還沒報上來)。

你內心OS:奇怪了,也沒產生Crash,網絡也是通的,但是為什么UI展示不出來呢?

幾個小時后……

用(lao)戶(ban):這問題有結果了嗎?

你:我用了各種辦法復現不出來……暫時查不到是什么原因導致的這個問題。

用(lao)戶(ban):那怪我咯?

你:……

如果把一次Bug的產生看作是一次“凶案現場”,開發者就是破案的“偵探”。案發之后,偵探需要通過各種手段搜集線索,推理出犯案過程。這就好比開發者需要通過查詢各種日志,分析這段時間App在用戶手機里都經歷了什么。一般來說,傳統的日志搜集方法存在以下缺陷:

  • 日志上報不及時。由於日志上報需要網絡請求,對於移動App來說頻繁網絡請求會比較耗電,所以日志SDK一般會積累到一定程度或者一定時間后再上報一次。
  • 上報的信息有限。由於日志上報網絡請求的頻次相對較高,為了節省用戶流量,日志通常不會太大。尤其是網絡日志等這種實時性較高的日志。
  • 日志孤島。不同類型的日志上報到不同的日志系統中,相對孤立。
  • 日志不全。日志種類越來越多,有些日志SDK會對上報日志進行采樣。

面臨挑戰

美團點評集團內部,移動端日志種類已經超過20種,而且隨着業務的不斷擴張,這一數字還在持續增加。特別是上文中提到的三個缺陷,也會被無限地進行放大。

before

查問題是個苦力活,不一定所有的日志都上報在一個系統里,對於開發者來說,可能需要在多個系統中查看不同種類的日志,這大大增加了開發者定位問題的成本。如果我們每天上班都看着疑難Bug掛着無法解決,確實會很難受。這就像一個偵探遇到了疑難的案件,當他用盡各種手段收集線索,依然一無所獲,那種心情可想而知。我們收集日志復現用戶Bug的思路和偵探破案的思路非常相似,通過搜集的線索盡可能拼湊出相對完整的犯案場景。如果按照這個思路想下去,目前我們並沒有什么更好的方法來處理這些問題。

不過,雖然偵探破案和開發者查日志解決問題的思路很像,但實質並不一樣。我們處理的是Bug,不是真實的案件。換句話說,因為我們的“死者”是可見的,那么就可以從它身上獲取更多信息,甚至和它進行一次“靈魂的交流”。換個思路想,以往的操作都是通過各種各樣的日志拼湊出用戶出現Bug的場景,那可不可以先獲取到用戶在發生Bug的這段時間產生的所有日志(不采樣,內容更詳細),然后聚合這些日志分析出(篩除無關項)用戶出現Bug的場景呢?

個案分析

新的思路重心從“日志”變為“用戶”,我們稱之為“個案分析”。簡單來說,傳統的思路是通過搜集散落在各系統的日志,然后拼湊出問題出現的場景,而新的思路是從用戶產生的所有日志中聚合分析,尋找出現問題的場景。為此,我們進行了技術層面的嘗試,而新的方案需要在功能上滿足以下條件:

  • 支持多種日志收集,統一底層日志協議,抹平日志種類帶來的差異。
  • 日志本地記錄,在需要時上報,盡可能保證日志不丟失。
  • 日志內容要盡可能詳細,不采樣。
  • 日志類型可擴展,可由上層自定義。

我們還需要在技術上滿足以下條件:

  • 輕量級,包體盡量小
  • API易用
  • 沒有侵入性
  • 高性能

橫空出世

在這種背景下,Logan橫空出世,其核心體系由四大模塊構成:

  • 日志輸入
  • 日志存儲
  • 后端系統
  • 前端系統

最佳實踐

process

日志輸入

常見的日志類型有:代碼級日志、網絡日志、用戶行為日志、崩潰日志、H5日志等。這些都是Logan的輸入層,在不影響原日志體系功能的情況下,可將內容往Logan中存儲一份。Logan的優勢在於:日志內容可以更加豐富,寫入時可以攜帶更多信息,也沒有日志采樣,只會等待合適的時機進行統一上報,能夠節省用戶的流量和電量。

以網絡日志為例,正常情況下網絡日志只記錄端到端延時、發包大小、回包大小字段等等,同時存在采樣。而在Logan中網絡日志不會被采樣,除了上述內容還可以記錄請求Headers、回包Headers、原始Url等信息。

日志存儲

Logan存儲SDK是這個開源項目的重點,它解決了業界內大多數移動端日志庫存在的幾個缺陷:

  • 卡頓,影響性能
  • 日志丟失
  • 安全性
  • 日志分散

Logan自研的日志協議解決了日志本地聚合存儲的問題,采用“先壓縮再加密”的順序,使用流式的加密和壓縮,避免了CPU峰值,同時減少了CPU使用。跨平台C庫提供了日志協議數據的格式化處理,針對大日志的分片處理,引入了MMAP機制解決了日志丟失問題,使用AES進行日志加密確保日志安全性。Logan核心邏輯都在C層完成,提供了跨平台支持的能力,在解決痛點問題的同時,也大大提升了性能。

為了節約用戶手機空間大小,日志文件只保留最近7天的日志,過期會自動刪除。在Android設備上Logan將日志保存在沙盒中,保證了日志文件的安全性。

詳情請參考:美團點評移動端基礎日志庫——Logan

后端系統

后端是接收和處理數據中心,相當於Logan的大腦。主要有四個功能:

  • 接收日志
  • 日志解析歸檔
  • 日志分析
  • 數據平台

接收日志

客戶端有兩種日志上報的形式:主動上報和回撈上報。主動上報可以通過客服引導用戶上報,也可以進行預埋,在特定行為發生時進行上報(例如用戶投訴)。回撈上報是由后端向客戶端發起回撈指令,這里不再贅述。所有日志上報都由Logan后端進行接收。

日志解析歸檔

客戶端上報的日志經過加密和壓縮處理,后端需要對數據解密、解壓還原,繼而對數據結構化歸檔存儲。

日志分析

不同類型日志由不同的字段組合而成,攜帶着各自特有信息。網絡日志有請求接口名稱、端到端延時、發包大小、請求Headers等信息,用戶行為日志有打開頁面、點擊事件等信息。對所有的各類型日志進行分析,把得到的信息串連起來,最終匯集形成一個完整的個人日志。

數據平台

數據平台是前端系統及第三方平台的數據來源,因為個人日志屬於機密數據,所以數據獲取有着嚴格的權限審核流程。同時數據平台會收集過往的Case,抽取其問題特征記錄解決方案,為新Case提供建議。

前端系統

一個優秀的前端分析系統可以快速定位問題,提高效率。研發人員通過Logan前端系統搜索日志,進入日志詳情頁查看具體內容,從而定位問題,解決問題。

目前集團內部的Logan前端日志詳情頁已經具備以下功能:

  • 日志可視化。所有的日志都經過結構化處理后,按照時間順序展示。
  • 時間軸。數據可視化,利用圖形方式進行語義分析。
  • 日志搜索。快速定位到相關日志內容。
  • 日志篩選。支持多類型日志,可選擇需要分析的日志。
  • 日志分享。分享單條日志后,點開分享鏈接自動定位到分享的日志位置。

Logan對日志進行數據可視化時,嘗試利用圖形方式進行語義分析簡稱為時間軸。

timeline

每行代表着一種日志類型。同一日志類型有着多種圖形、顏色,他們標識着不同的語義。

例如時間軸中對代碼級日志進行了日志類別的區分:

codelog

利用顏色差異,可以輕松區分出錯誤的日志,點擊紅點即可直接跳轉至錯誤日志詳情。

個案分析流程

case

  • 用戶遇到問題聯系客服反饋問題。

  • 客服收到用戶反饋。記錄Case,整理問題,同時引導用戶上報Logan日志。

  • 研發同學收到Case,查找Logan日志,利用Logan系統完成日志篩選、時間定位、時間軸等功能,分析日志,進而還原Case“現場”。

  • 最后,結合代碼定位問題,修復問題,解決Case。

定位問題

結合用戶信息,通過Logan前端系統查找用戶的日志。打開日志詳情,首先使用時間定位功能,快速跳轉到出問題時的日志,結合該日志上下文,可得到當時App運行情況,大致推斷問題發生的原因。接着利用日志篩選功能,查找關鍵Log對可能出問題的地方逐一進行排查。最后結合代碼,定位問題。

當然,在實際上排查中問題比這復雜多,我們要反復查看日志、查看代碼。這時還可能要借助一下Logan高級功能,如時間軸,通過時間軸可快速找出現異常的日志,點擊時間軸上的圖標可跳轉到日志詳情。通過網絡日志中的Trace信息,還可以查看該請求在后台服務詳細的響應棧情況和后台響應值。

未來規划

  • 機器學習分析。首先收集過往的Case及解決方案,提取分析Case特征,將Case結構化后入庫,然后通過機器學習快速分析上報的日志,指出日志中可能存在的問題,並給出解決方案建議;
  • 數據開放平台。業務方可以通過數據開放平台獲取數據,再結合自身業務的特性研發出適合自己業務的工具、產品。

平台支持

Platform iOS Android Web Mini Programs
Support

目前Logan SDK已經支持以上四個平台,本次開源iOS和Android平台,其他平台未來將會陸續進行開源,敬請期待。

測試覆蓋率

由於Travis、Circle對Android NDK環境支持不夠友好,Logan為了兼容較低版本的Android設備,目前對NDK的版本要求是16.1.4479499,所以我們並沒有在Github倉庫中配置CI。開發者可以本地運行測試用例,測試覆蓋率可達到80%或者更高。

開源計划

在集團內部已經形成了以Logan為中心的個案分析生態系統。本次開源的內容有iOS、Android客戶端模塊、數據解析簡易版,小程序版本、Web版本已經在開源的路上,后台系統,前端系統也在我們開源計划之中。

未來我們會提供基於Logan大數據的數據平台,包含機器學習、疑難日志解決方案、大數據特征分析等高級功能。

最后,我們希望提供更加完整的一體化個案分析生態系統,也歡迎大家給我們提出建議,共建社區。

system

Module Open Source Processing Planning
iOS    
Android    
Web    
Mini Programs    
Back End    
Front End    

團隊介紹

周輝,項目發起人,美團點評資深移動架構師。

姜騰,項目核心開發者。

立成,項目核心開發者。

白帆,項目核心開發者。

招聘

點評平台移動研發中心,Base上海,為美團點評集團大多數移動端提供底層基礎設施服務,包含網絡通信、移動監控、推送觸達、動態化引擎、移動研發工具等。同時團隊還承載流量分發、UGC、內容生態、整合中心等業務研發,長年虛位以待有志於專注移動端研發的各路英雄。歡迎投遞簡歷:hui.zhou#dianping.com。


發現文章有錯誤、對內容有疑問,都可以關注美團技術團隊微信公眾號(meituantech),在后台給我們留言。我們每周會挑選出一位熱心小伙伴,送上一份精美的小禮品。快來掃碼關注我們吧!

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM