自動化日誌收集及分析在支付寶 App 內的演進

背景

結合《螞蟻金服面對億級併發場景的組件體系設計》，咱們可以通盤瞭解支付寶移動端基礎組件體系的構建之路和背後的思考，本文基於服務端組建體系的大背景下，着重探討「自動化日誌手機與分析」在支付寶 App 內的演進之路。

支付寶移動端技術服務框架

這是整個支付寶移動端無線基礎團隊的技術架構圖，同時螞蟻金服體系內的其餘業務 口碑、網商銀行、香港支付寶、天弘基金等) 經過移動開發平臺 mPaaS進行代碼開發、打包、灰度發佈、上線、問題修復、運營、分析。所以，mPaaS 源自於支付寶移動端的核心技術架構，並在 App 全生命週期的每一個環節提供特定的能力支持。接下來，咱們將着重分享「日誌診斷」和「移動分析」兩個能力背後的架構演進和選型思考。

支付寶移動端技術服務框架：數據分析框架

如圖所示，即數據分析能力的技術架構圖，其中「數據同步」、「埋點SDK」、「日誌網關」是移動端專屬的能力，其他部分是全部的數據分析平臺都必須具有的數據結構。

1. 日誌採集

接下來咱們重點分析支付寶移動端的日誌採集框架，首先第一部分是「日誌 SDK」，日誌 SDK 會向業務層提供一個埋點接口，使用起來就和 Java 裏面的 logger.info 的感受同樣：業務層只須要把想記錄的信息傳遞給日誌 SDK。日誌 SDK 會在拿到業務日誌後，去系統內部獲取相關的系統級別的上下文信息，好比機型、操做系統版本、App 版本、手機分辨率、用戶ID (若是用戶登陸了)、設備ID、上一個頁面、當前頁面等，接着把這些信息與業務日誌內容整合成一個埋點，而後記錄到設備的硬盤上。對，只是記錄到硬盤上，並無上報到服務端。

日誌 SDK 會在合適的時機，去和日誌網關交互，判斷獲取什麼樣的日誌、什麼級別的日誌能夠上報。若是能夠上報，是以什麼頻率上報、在什麼網絡條件下上報。所以經過日誌 SDK 與日誌網關的交付，咱們能夠來實現日誌的策略式降級。日誌的策略式降級這點對於支付寶特別重要，由於目前支付寶的體量，平常的日誌上報量爲約 30W 條日誌/s；而在大促的時候，日誌量會是平常的幾十倍！ 因此，若是大促期間不採用任何的日誌降級策略的話，咱們的帶寬會被日誌打包，支付寶的正常業務功能就不可用了。

由此，咱們能夠總結，在大促高併發場景下，咱們須要只保留關鍵日誌的上傳，其他日誌通通降級。即便是平常業務處理，咱們也只容許日誌在 WIFI 條件下上報，防止發生流量相關的投訴。

埋點網關除了提供日誌上報的策略開關能力以外，就是接收客戶端的日誌。它在接受到客戶端日誌以後，會對日誌內容進行校驗，發現無效的日誌會丟棄掉。而對有效合法的埋點，會根據客戶端上報的公網 IP 地址，反解出城市級別的地址位置信息並添加到埋點中，而後將埋點存放在它本身的硬盤上。

2. 埋點分類

通過多年的實踐，支付寶把日誌埋點分爲了四類。

（1）行爲埋點：用於監控業務行爲，即業務層傳遞的日誌埋點屬於行爲埋點，行爲埋點屬於「手動埋點」，須要業務層開發同窗本身開發。不過也不是所有的業務行爲都須要業務方手動開發，有一些具有很是通用性的業務事件，支付寶把它們的埋點記錄放到了框架層，如報活事件、登陸事件。所以，行爲埋點也能夠叫作 "半自動埋點"。

（2）自動化埋點：屬於「全自動化埋點」，用於記錄一些通用的頁面級別、組件級別的行爲，好比頁面打開、頁面關閉、頁面耗時、組件點擊等。

（3）性能埋點：屬於「全自動化埋點」，用於記錄 App 的電量使用狀況、流量使用、內存使用、啓動速度等。

（4）異常埋點：屬於「全自動化埋點」，嚴格上講，也算是性能埋點的一種。可是它記錄的是最關鍵的最直接影響用戶的性能指標，好比 App 的閃退狀況、卡死、卡頓狀況等。這類埋點，就屬於即時大促期間也不能降級的埋點！

圖中的代碼示例即爲一條行爲埋點樣例，你們能夠看到，埋點實際上就是一條 CSV 文本。咱們能夠看到裏面有日誌網關添加進行的地址位置信息內容，也有日誌 SDK 給添加的客戶端設備信息。

3. 日誌處理模型

下面咱們來總體瞭解支付寶內部日誌處理的通用流程：

（1）日誌切分

咱們已經瞭解到，埋點實際上即爲一段 CSV 文本。而所謂日誌切分呢，即將 CSV 格式的文本轉成 KV，通俗點說就是內存裏面的 HASHMAP。這個切分的過程，能夠直接根據逗號進行切換，固然也還有不少其餘的辦法。

（2）日誌切換

日誌埋點中的內容，並非直接能夠拿來進行分析的。好比客戶端啓動時間，相關數據是按照毫秒級別的顆粒度進行上報，但實際應用上咱們只須要把數據分析到某個特定區間內的個數，因此在處理以前通常會作一個具體啓動時間到截止時間範圍編碼的映射。除了這種轉換以外，還會有一些白名單、黑名單之類的過濾轉換。

（3）維表影射

由於客戶端並不能拿到業務方須要分析的全部數據維度，如用戶的性別、職業等內容，所以在真實分析以前，咱們能夠經過維表映射，將日誌埋點中的用戶 ID 映射成業務層面的具體屬性來進行後續的分析。

（4）UID 的濾重

UID 濾重的指標有兩種：一種是 PV 指標，一種是 UV 指標。

UV 指標在作具體的計算以前，要作一步 UID 去重。所謂 UID 去重就是指檢查這個 ID 在必定時間範圍內有沒有出現過，若是出現過，那麼這條記錄就必須丟棄了。UV 是有時間週期的概念的，好比日 UV、小時 UV、分鐘 UV、月 UV 等。

（5）指標聚合

在完成了上述的全部過程後，終於要進行指標的計算了。計算的方式包括求和、平均值、最大值、最小值、95 百分位。

（6）結果寫出

就是指把計算的指標的結果輸出到各類存儲或者經過接口發送給 mPaaS 的客戶。目前咱們的計算方式有三大類，實時計算、即時計算和離線計算。下面我會介紹這三種計算方式。

• 實時計算

實時計算模式：接收到日誌後，模型當即開始進行計算，數據結果將在N分鐘(N<=2)內產出，延遲很是的低。

推薦用做實時計算的技術選型包括：1) Flink 2) Spark 3) Storm (阿里作的 JStorm） 4) akka；其中 akka 適合用做業務邏輯較輕的實時監控和報警；關鍵的業務大盤、日誌翻譯回放這些都用 Flink 作比較好。

簡單總結以下：

實時計算的優點是產出結果速度快、資源消耗少、靈活度中等； 實時計算的劣勢是學習曲線相對陡峭、維護成本較高、配置複雜度高。

• 離線計算

離線計算模式：接收到日誌後，直接保存下來，不作任何處理。待日誌量積攢一段時間後，模型可進行一次性處理多日或者多月的日誌數據。

推薦用做實時計算的技術選型包括: 1) Flink 2) Spark 3) Hive 4) Hadoop；你們看到了 FLINK\SPARK 也出如今了實時模型的推薦技術選擇中。這兩個技術呢，分別從不一樣的起點出發，達到了相同的終點。

Flink 一開始是隻作實時計算的，後來他開始提供批量離線計算能力；Spark 則正好相反。咱們目前呢，仍是充分利用每一個技術棧的最大優點，離線仍是選擇 Spark，而不是 Flink。在這裏多說兩句，以前有一個經典架構是 「Lambda」模型，是指實時計算的結果要在離線裏面再算一遍，這是由於以前總會出現實時計算丟數據、計算不許的狀況，因此實時計算出來的結果只是用來觀察一個趨勢，再等次日用離線的結果作補充，從而確保業務方可以看到準確的數據。可是在谷歌的 data-flow 計算模型的論文出來以後，目前市面上的實時計算引擎都具有了 "exactly-once" 的計算能力，換句話說，實時計算不會再出現丟數據以及計算不許的問題了。目前雖然還有「Lambda」模型，即數據會流向實時計算、離線計算兩個引擎，可是離線再也不是爲實時計算作補充，而是爲了充分利用它的性能，計算多日、多月的指標。

簡單總結以下：

離線計算的優點是 計算性能高、學習難度低； 離線計算的劣勢是 消耗資源大、延遲高、靈活度偏低。

• 即時計算

即時計算模式：接收到日誌後，只作簡單的預處理，好比日誌切分，以後就直接入庫。在須要展現界面的時候，根據用戶配置的過濾和聚合規則即時進行數據處理。

推薦用做即時計算的的技術選型包括: Clickhouse (來自俄羅斯 yandex)、Apache Druid (來自 MetaMarket)、 Pinot (來自 ：LinkedIn)。支付寶內部將即時計算模型應用到下鑽分析、漏斗分析這些場景中，有時候也直接把它當作 OLAP 數據庫使用。

簡單總結以下：

即時計算的優點是超高靈活度、任務維度UV聚合、無限下鑽能力、交付式的查詢延遲(15s內)、學習成本低； 即時計算的劣勢是資源消耗巨大、延遲中等沒法用於作實時監控與報警、維度成本高，結構複雜。

這是目前支付寶內部的一個即時計算框架的技術架構圖。從圖中能夠看出來目前即時計算的技術架構包括用來接收數據寫入的實時日誌節點（Read-time Nodes）、用於存儲歷史數據的深度存儲（HDFS、AFS、OSS 等多種類型）、用來對歷史數據（一天之前的數據）提供查詢分析能力的歷史節點（historical）。這個計算框架徹底的支持 MySQL 協議，用戶能夠直接用 MySQL 客戶端對其進行操做。還有一個重要特性是，他能夠對任意的外部數據聯合進行分析。

• 日誌處理模型

咱們再總結一下三種計算模式：

實時計算模型：數據攝入後當即按照預約規則執行計算，並在N分鐘內產出須要的計算結果。

適用場景: 實時監控預警、鏈路追蹤 優點: 消耗資源少、產出速度快 劣勢: 配置複雜度高，靈活度低

離線計算模型：數據攝入後積攢N 小時/天 後按照預約規則進行批量處理。

適用場景: 用戶分羣、數據集市 優點:性能高、學習成本低 劣勢: 延遲高、靈活度低

即時計算模型：數據攝入後只作簡單的預處理當即入庫，待查詢時根據查詢需求實時計算出指標。

適用場景: 下鑽分析、漏斗分析 優點: 靈活度高、學習成本低 劣勢: 資源消耗巨大、延遲中 但願你們可以根據咱們的推薦選擇適合的技術棧。

• 動態埋點

說完了咱們目前的埋點類型、埋點計算模型，下面來講一下咱們目前在內部使用的下一代埋點框架，動態埋點。

咱們先針對以上四個問題進行思路串聯，每一個問題我也給出了相應的思路和解決辦法。那麼，這些答案是針對以上問題的最優解或者惟一解嗎？很顯然不是，由於這些解法都會帶來開發量。而對於客戶端來講，新的開發量就要發佈版本，同時開發新的埋點，也可能會致使 App 內部的埋點臃腫不堪。

什麼是動態埋點呢？有三個核心概念1) 埋點集、2) 動態埋點上報規則、3) 指標計算動態配置。

有了以上三項能力和配置，咱們即可以根據現有的埋點集來配置某個鏈路的監控埋點，並依據這個複雜埋點來定義具體的指標的計算規則，從而作到不用增長開發量，一樣能夠快速監控新的指標的效果。不只如此，咱們還可以讓埋點變成一種通用的資源，讓你們更好地去使用它，而不是無謂地增長埋點，使得代碼變得更臃腫。

讓咱們一塊兒看一下動態埋點框架的一些 UI 交付圖。

相應的，咱們再對焦看一下支付寶埋點相關的應用服務：實時日誌拉取。其中，它的主要技術框架包括了 mPaaS 裏面的 MPS (消息推送)、MSS(數據同步)、以及日誌網關。這是由於螞蟻系 App 會與 MPS (安卓系統)、MSS (蘋果系統) 保持長鏈接，在須要實時拉取日誌的時候，用戶能夠在 mPaaS 的控制檯上面經過這兩個渠道下發指令，而後客戶端就會把加密的明細日誌所有上報到日誌網關。

這是實時日誌拉取的界面操做展現圖。

針對於很是重要的性能指標: 閃退、卡頓、卡死， mPaaS 根據多年經驗準備了對應的大盤。如圖所示，上半部分是每分鐘的閃退數，下面是咱們根據閃退分類算法梳理出來的各個閃退分類狀況，針對每一個分類大盤裏咱們還能看到具體的設備分佈狀況。

最後，讓咱們從邏輯結構上再梳理一下 mPaaS 的服務端結構。mPaaS 包含五個核心組件:

1. MGS（網關服務）：將客戶端的請求轉發到業務服務器.

2. MDS（發佈服務）：爲客戶端提供多種資源的多種灰度策略發佈能力。

3. MPS & MSS（消息推送和數據同步服務）：以長鏈接爲基礎，來提供數據下發能力。

4. MAS,（分析服務）：也是今天講解的重點，以日誌埋點爲基礎的分析能力。

若是你們對 mPaaS 的移動分析服務感興趣，歡迎點擊文檔地址 瞭解更多詳情。

往期閱讀

《開篇 | 螞蟻金服 mPaaS 服務端核心組件體系概述》

《螞蟻金服 mPaaS 服務端核心組件體系概述：移動 API 網關 MGS》

《螞蟻金服 mPaaS 服務端核心組件：億級併發下的移動端到端網絡接入架構解析》

《mPaaS 服務端核心組件：消息推送 MPS 架構及流程設計》

《mPaaS 核心組件：支付寶如何爲移動端產品構建輿情分析體系？》

《mPaaS 服務端核心組件：移動分析服務 MAS 架構解析》

《螞蟻金服面對億級併發場景的組件體系設計》

關注咱們公衆號，得到第一手 mPaaS 技術實踐乾貨

釘釘羣：經過釘釘搜索羣號「23124039」

期待你的加入～