自動化日志收集及分析在支付寶 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；大家看到了 FLINKSPARK 也出現在了實時模型的推薦技術選擇中。這兩個技術呢，分别從不同的起點出發，達到了相同的終點。

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 技術實踐幹貨

釘釘群：通過釘釘搜尋群号“23124039”

期待你的加入～