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

Logan是美團點評集團移動端基礎日誌元件，這個名稱是Log和An的組合，代表個體日誌服務。同時Logan也是“金剛狼”大叔的名號，當然我們更希望這個產品能像金剛狼大叔一樣“犀利”。此前我們公眾號釋出過一篇文章《Logan：美團點評移動端基礎日誌庫揭秘》，主要講述了Logan的很多技術細節。本文將重點闡述Logan的整體框架。

Logan已經穩定迭代了一年多的時間。目前美團點評絕大多數App已經接入並使用Logan進行日誌收集、上傳、分析。近日，我們決定開源Logan生態體系中的儲存SDK部分（Android/iOS），希望能夠幫助更多開發者合理的解決移動端日誌儲存收集的相關痛點，也歡迎更多社群的開發者和我們一起共建Logan生態。GitHub的專案地址參見：

。

背景

隨著業務的不斷擴張，移動端的日誌也會不斷增多。但業界對移動端日誌並沒有形成相對成體系的處理方式，在大多數情況下，還是針對不同的日誌進行單一化的處理，然後結合這些日誌處理的結果再來定位問題。然而，當使用者達到一定量級之後，很多“疑難雜症”卻無法透過之前的定位問題方式來進行解決。

移動端開發者最頭疼的事情就是“為什麼我使用和使用者一模一樣的手機，一模一樣的系統版本，仿照使用者的操作卻復現不出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結構化後入庫，然後透過機器學習快速分析上報的日誌，指出日誌中可能存在的問題，並給出解決方案建議；

• 資料開放平臺。業務方可以透過資料開放平臺獲取資料，再結合自身業務的特性研發出適合自己業務的工具、產品。

 平臺支援

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

 測試覆蓋率

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

 開源計劃

在集團內部已經形成了以Logan為中心的個案分析生態系統。本次開源的內容有iOS、Android客戶端模組、資料解析簡易版，小程式版本、Web版本已經在開源的路上，後臺系統，前端系統也在我們開源計劃之中。

未來我們會提供基於Logan大資料的資料平臺，包含機器學習、疑難日誌解決方案、大資料特徵分析等高階功能。

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

團隊介紹

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

姜騰，專案核心開發者。

立成，專案核心開發者。

白帆，專案核心開發者。