Logan：美團點評的開源移動端基礎日誌庫

前言

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種，並且隨着業務的不斷擴張，這一數字還在持續增長。特別是上文中提到的三個缺陷，也會被無限地進行放大。

查問題是個苦力活，不必定全部的日誌都上報在一個系統裏，對於開發者來講，可能須要在多個系統中查看不一樣種類的日誌，這大大增長了開發者定位問題的成本。若是咱們天天上班都看着疑難Bug掛着沒法解決，確實會很難受。這就像一個偵探遇到了疑難的案件，當他用盡各類手段收集線索，依然一無所得，那種心情可想而知。咱們收集日誌復現用戶Bug的思路和偵探破案的思路很是類似，經過蒐集的線索儘量拼湊出相對完整的犯案場景。若是按照這個思路想下去，目前咱們並無什麼更好的方法來處理這些問題。

不過，雖然偵探破案和開發者查日誌解決問題的思路很像，但實質並不同。咱們處理的是Bug，不是真實的案件。換句話說，由於咱們的「死者」是可見的，那麼就能夠從它身上獲取更多信息，甚至和它進行一次「靈魂的交流」。換個思路想，以往的操做都是經過各類各樣的日誌拼湊出用戶出現Bug的場景，那可不能夠先獲取到用戶在發生Bug的這段時間產生的全部日誌（不採樣，內容更詳細），而後聚合這些日誌分析出（篩除無關項）用戶出現Bug的場景呢？

個案分析

新的思路重心從「日誌」變爲「用戶」，咱們稱之爲「個案分析」。簡單來講，傳統的思路是經過蒐集散落在各系統的日誌，而後拼湊出問題出現的場景，而新的思路是從用戶產生的全部日誌中聚合分析，尋找出現問題的場景。爲此，咱們進行了技術層面的嘗試，而新的方案須要在功能上知足如下條件：

• 支持多種日誌收集，統一底層日誌協議，抹平日誌種類帶來的差別。
• 日誌本地記錄，在須要時上報，儘量保證日誌不丟失。
• 日誌內容要儘量詳細，不採樣。
• 日誌類型可擴展，可由上層自定義。

咱們還須要在技術上知足如下條件：

• 輕量級，包體儘可能小
• API易用
• 沒有侵入性
• 高性能

橫空出世

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

• 日誌輸入
• 日誌存儲
• 後端系統
• 前端系統

最佳實踐

日誌輸入

常見的日誌類型有：代碼級日誌、網絡日誌、用戶行爲日誌、崩潰日誌、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對日誌進行數據可視化時，嘗試利用圖形方式進行語義分析簡稱爲時間軸。

每行表明着一種日誌類型。同一日誌類型有着多種圖形、顏色，他們標識着不一樣的語義。

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

利用顏色差別，能夠輕鬆區分出錯誤的日誌，點擊紅點便可直接跳轉至錯誤日誌詳情。

個案分析流程

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

• 客服收到用戶反饋。記錄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大數據的數據平臺，包含機器學習、疑難日誌解決方案、大數據特徵分析等高級功能。

最後，咱們但願提供更加完整的一體化個案分析生態系統，也歡迎你們給咱們提出建議，共建社區。

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

團隊介紹

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

姜騰，項目核心開發者。

立成，項目核心開發者。

白帆，項目核心開發者。

招聘

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