美團高效能終端實時日誌系統建設實踐

　　你是否經常遇到線上需要日誌排查問題但遲遲聯絡不上使用者上報日誌的情況？或者是否經常陷入由於儲存空間不足而導致日誌寫不進去的囧境？本文介紹了美團是如何從0到1搭建高效能終端實時日誌系統，從此徹底解決日誌丟失和寫滿問題的。希望能為大家帶來一些幫助和啟發。

　　 1 背景

　　1.1 Logan 簡介

　　Logan 是美團面向終端的統一日誌服務，已支援移動端App、Web、小程式、IoT 等多端環境，具備日誌採集、儲存、上傳、查詢與分析等能力，幫助使用者定位研發問題，提升故障排查效率。同時，Logan 也是業內開源較早的大前端日誌系統，具有寫入效能高、安全性高、日誌防丟失等優點。

　　1.2 Logan 工作流程

　　為了方便讀者更好地理解 Logan 系統是如何工作的，下圖是簡化後的 Logan 系統工作流程圖。主要分為以下幾個部分：

　　主動上報日誌：終端裝置在需要上報日誌時，可以透過 HTTPS 介面主動上傳日誌到 Logan 接收服務，接收服務再把原始日誌檔案轉存到物件儲存平臺。

　　日誌解密與解析：當研發人員想要檢視主動上報的日誌時會觸發日誌下載與解析流程，原始加密日誌從物件儲存平臺下載成功後進行解密、解析等操作，然後再投遞到日誌儲存系統。

　　日誌查詢與檢索：日誌平臺支援對單裝置所有日誌進行日誌型別、標籤、程式、關鍵字、時間等維度的篩選，同時也支援對一些特定型別的日誌進行視覺化展示。　　

圖1 Logan 系統工作流程圖

　　1.3 為什麼需要實時日誌？

　　如前文所述，這套“本地儲存+主動上報”的模式雖然解決了大前端場景下基礎的日誌使用需求，但是隨著業務複雜度的不斷增加，使用者對日誌的要求也越來越高，當前 Logan 架構存在的問題也變得越來越突出，主要體現在以下幾個方面：

　　部分場景上報日誌受限：由於在 Web 與小程式上使用者一般的使用場景是用完即走，當線上出現問題時再聯絡使用者主動上報日誌，整個處理週期較長，有可能會錯過排查時間。

　　缺少實時分析和告警能力：當前缺少實時分析和告警的能力，使用者曾多次提到過想要對線上異常日誌進行監控，當有符合規則的異常日誌出現時能收到告警資訊。

　　缺少全鏈路追蹤能力：當前多端的日誌散落在各個系統中，研發人員在定位問題時需要手動去關聯日誌，操作起來很不方便，美團內部缺乏一個通用的全鏈路追蹤方案。

　　針對以上痛點問題，我們提出了建設 Logan 實時日誌，旨在提供統一的、高效能的實時日誌服務，以解決美團現階段不同業務系統想要日誌上雲的需求。

　　1.4 Logan 實時日誌是什麼？

　　Logan 實時日誌是服務於移動端 App、Web、小程式、IoT 等終端場景下的實時日誌解決方案，旨在提供高擴充套件性、高效能、高可靠性的實時日誌服務，包括日誌採集、上傳、加工、消費、投遞、查詢與分析等能力。　　

圖2 Logan 實時日誌產品功能圖

　　 2 設計實現

　　2.1 整體架構　　

圖3 Logan 實時日誌整體架構圖

　　如上圖所示，整體架構主要分為五個部分，它們分別是：

　　採集端：負責端上日誌資料的採集、加密、壓縮、聚合和上報等。

　　接入層：負責提供日誌上報介面，接收日誌上報資料，並將資料轉發到資料處理層。

　　資料處理層：負責日誌資料的解密、拆分、加工和清洗等。

　　資料消費層：負責日誌資料的過濾、格式化、投遞等。

　　日誌平臺：負責日誌資料查詢與分析、業務系統接入配置、統計與告警等。

　　2.2 採集端

　　通用採集端架構，解決跨平臺複用

　　採集端SDK用於端側日誌收集，需要在多種終端環境落地，但是由於端和平臺較多、技術棧和執行環境也不一致，多端開發和維護成本會比較高。因此，我們設計了一套核心邏輯複用的通用採集端架構，具體的平臺依賴程式碼則單獨進行適配。我們目前上線了微信、MMP、Web、MRN 端側，邏輯層程式碼做到了完全複用。採集端架構設計圖如下：　　

圖4 採集端SDK架構圖

　　重點模組介紹：

　　配置管理：採集端初始化完成後，首先啟動配置管理模組，拉取和重新整理配置資訊，包括上報限流配置、指標取樣率、功能開關等，支援對關鍵配置進行灰度釋出。

　　加密：所有記錄的日誌都使用 ECDH + AES 方案加密，確保日誌資訊不洩漏。Web 版加密模組使用瀏覽器原生加密 API 進行適配，可實現高效能非同步加密，其他平臺則使用純 JS 實現。

　　儲存管理：線上資料表明，由於頁面關閉導致的日誌丟失佔比高達 1%，因此我們設計了日誌落盤功能，當日志上傳失敗後會先快取在本地磁碟，等到頁面下一次啟動時再重新恢復上傳。

　　佇列管理：需要傳送的日誌首先進行分組聚合，如果等待分組過多則需要丟棄一部分請求，防止在弱網環境或者日誌堆積太多時造成記憶體持續上漲而影響使用者。

　　落盤快取 + 上報恢復，防止日誌丟失

　　為了方便讀者更好地理解端上日誌採集過程，下面將具體介紹下采集端流程設計。當採集端初始化 API 開始呼叫時，先建立 Logger、Encryptor、Storage 等例項物件，並非同步拉取環境配置檔案。初始化完成之後，先檢查是否有成功落盤，但是上報失敗的日誌，如果有的話立即開始恢復上傳流程。當正常呼叫寫日誌 API 時，原始日誌被加密後加入當前上報組，等到有上報事件（時間、條數、導航等）觸發時，當前上報組內的所有日誌被加入上報佇列並開始上傳。採集端詳細流程圖如下：　　

圖5 採集端SDK流程圖

　　2.3 資料接入層

　　對於實時日誌系統來講，接入層需要滿足以下幾點要求：（1）支援公網上報域名；（2）支援高併發處理；（3）具備高實時性，延遲是分鐘級；（4）支援投遞資料到 Kafka 訊息佇列。

　　經過對比，美團內的統一日誌收集通道均滿足以上需求，因此我們選用了統一日誌收集通道作為接入層。採集端 SDK 透過獨立的公網域名上報日誌後，收集通道將日誌資料彙總好並投遞到指定的 Kafka 訊息佇列。如果讀者公司沒有類似的日誌收集通道，那麼可以參考以下流程搭建實時日誌系統接入層。　　

圖6 接入層流程圖

　　2.4 資料處理層

　　在資料處理框架的技術選型上，我們先後考慮了三種方案，分別是傳統架構（Java 應用）、Storm 架構、Flink 架構，這三種方案在不同維度的對比資料如下：　　

表1 技術選型對比表

　　綜合來看，雖然傳統架構有比較好的成熟度與靈活性，但是在擴充套件性、容錯性以及效能上均不能滿足系統要求，而 Flink 架構與 Storm 架構都有比較優秀的擴充套件性與容錯性，但是 Flink 架構在延遲與吞吐量上表現要更好，因此我們最終選擇了使用 Flink 架構作為資料處理框架。

　　Flink：業內領先的流式計算引擎，具有高吞吐、低延遲、高可靠和精確計算等優點，對事件視窗有很好的支援，被業內很多公司作為流式計算引擎。

　　在日誌處理流程設計上，日誌資料透過接入層處理後被投遞到彙總 topic 裡面，然後再透過 Flink 作業的邏輯處理後分發到下游。處理流程如下圖所示：　　

圖7 日誌處理層流程圖

　　彙總後的日誌資料處理和分發依賴於實時計算平臺的實時作業能力，底層使用 Flink 資料處理引擎，主要負責日誌資料的解析、日誌內容的解密以及拆分到下游等。

　　後設資料解析：透過實時作業能力完成原始日誌資料解析為 JSON 物件資料。

　　內容解密：對加密內容進行解密，此處使用非對稱協商計算出對稱加密金鑰，然後再進行解密。

　　服務維度拆分：透過 topic 欄位把日誌分發到各業務系統所屬的 topic 裡面，從而實現業務日誌相互隔離。

　　資料自定義加工：根據使用者自定義的加工語法模版，從服務 topic 實時消費並加工資料到自定義 topic 中。

　　2.5 資料消費層

　　對大部分使用者來說 Logan 實時日誌提供的日誌採集、加工、檢索能力已經能滿足大部分需求。但是在與使用者溝透過程中我們發現還有一些更高階的需求，比如指標監控、前後端鏈路串聯、離線資料計算等。於是我們將 Logan 標準化後的日誌統一投遞到 Kafka 流處理平臺，並提供一些通用的資料轉換能力，方便使用者按需接入到不同的第三方系統。資料消費層設計如下圖所示：　　

圖8 資料消費層設計圖

　　資料消費層的一些典型的應用場景：

　　網路全鏈路追蹤：現階段前後端的日誌可能分佈在不同的系統中，前端日誌系統記錄的主要是程式碼級日誌、端到端日誌等，後端日誌系統記錄的是鏈路關係、服務耗時等資訊。透過 Logan 實時日誌開放的資料消費能力，使用者可以根據自己的需求來串聯多端日誌，從而實現網路全鏈路追蹤。

　　指標聚合統計&告警：實時日誌也是一種實時的資料流，可以作為指標資料上報的載體，如果把日誌資料對接到資料統計平臺就能實現指標監控和告警了。

　　離線資料分析：如果在一些需求場景下需要對資料進行長期化儲存或者離線分析，就可以將資料匯入到 Hive 中來實現。

　　2.6 日誌平臺

　　日誌平臺的核心功能是為使用者提供日誌檢索支援，日誌平臺提供了使用者標識、自定義標籤、關鍵字等多種檢索過濾方式。在日誌底層儲存架構的選擇上，目前業界廣泛使用的是 Elasticsearch，考慮到計費與運維成本的關係，美團內部已經有一套統一的框架可以使用，所以我們也選用了 Elasticsearch 架構。同時，我們也支援透過單獨的介面層適配其他儲存引擎，日誌查詢流程如下：　　

圖9 日誌查詢流程設計圖

　　Elasticsearch：是一個分散式的開源搜尋和分析引擎，具有接入成本低、擴充套件性高和近實時性等優點，比較適合用來做大資料量的全文檢索服務，例如日誌查詢等。

　　 3 穩定性保障

　　3.1 核心監控

　　為了衡量終端實時日誌系統的可用性，我們制定了以下核心 SLA 指標：　　

表2 核心 SLA 指標表格

　　除了核心指標監控之外，我們還建設了全流程監控大盤，覆蓋了分端上報成功率、域名可用性、域名 QPS、作業吞吐量、平均聚合條數等重要觀測指標，並且針對上報成功率、域名 QPS、作業吞吐量等配置了兜底告警，當線上有異常時可以第一時間發現並進行處理。

　　3.2 藍綠髮布

　　實時日誌依賴於實時作業的處理計算能力，但是目前實時作業的釋出和部署不能無縫銜接，中間可能存在真空的情況。當重啟作業時，需要先停止原作業，再啟動新的作業。如果遇到程式碼故障或系統資源不足等情況時則會導致作業啟動失敗，從而直接面臨訊息積壓嚴重和資料延時升高的問題，這對於實時日誌系統來說是不能忍受的。

　　藍綠髮布（Blue Green Deployment）是一種平滑過渡的釋出模式。在藍綠髮布模式中，首先要將應用劃分為對等的藍綠兩個分組，藍組釋出新產品程式碼並引入少許線上流量，綠組繼續執行老產品程式碼。當新產品程式碼經線上執行觀察沒有問題後，開始逐步引入更多線上流量，直至所有流量都訪問藍組新產品。因此，藍綠髮布可以保證整體系統的穩定，在產品釋出前期就可以發現並解決問題，以保證其影響面可控。

　　目前美團已有的實時作業藍綠部署方案各不相同，由於 Logan 實時日誌接入業務系統較多，且資料量較大，經過綜合考量後，我們決定自己實現一套適合當前系統的藍綠部署方案。為了保證系統的穩定性，在作業執行過程中，啟動另外一個相同的作業，當新作業執行沒有問題後，再完成新老作業切換。藍綠髮布流程圖如下：　　

圖10 藍綠髮布流程圖

　　使用藍綠部署後，徹底解決了由於資源不足或引數不對導致的上線失敗問題，平均部署切換耗時也保持在1分鐘以內，基本避免了因釋出帶來的日誌消費延遲問題。

　　 4 落地成果

　　Logan 實時日誌在建設初期就受到了各個業務的廣泛關注，截止到 2022 年第 3 季度，Logan 實時日誌接入並上線的業務系統數量已多達二十餘個，其中包括美團小程式、優選商家、餐飲 SaaS 等大體量業務。下面是一些業務系統接入的典型使用場景，供大家參考：

　　核心鏈路還原：到家某 C 端小程式使用 Logan 實時日誌記錄程式核心鏈路中的關鍵日誌與異常日誌，當線上有客訴問題發生時，可以第一時間檢視實時日誌並定位問題。專案上線後，平均客訴定位時間從之前的 10 分鐘減少到 3 分鐘以內，排障效率有明顯提升。

　　內測階段排障：企業平臺某前端專案由於 2.0 改版改動較大，於是使用 Logan 實時日誌在內測階段新增更多的除錯日誌，方便定位線上問題。專案上線後，每次排查問題除了節省使用者上報日誌時間 10-15 分鐘，還杜絕了因為儲存空間不足而拿不到使用者日誌的情況。

　　日誌資料分析：美團到店某團隊使用 Logan 實時日誌分析前後端互動過程中的請求頭、請求引數、響應體等資料是否符合標準化規範。經過一個多月時間的試執行，一期版本上線後共覆蓋 300+ 前端頁面和 500+ 前端介面，共計發現 1000+ 規範問題。

　　 5 未來規劃

　　Logan 實時日誌經過半年的建設與推廣，已經完成了系統基礎能力的建設，能滿足使用者對於實時日誌的基本訴求。但是對於日誌資料深加工與清洗、日誌統計與告警等高階需求還不支援，因此為了更好地發揮日誌價值，提升終端故障排查效率，Logan 實時日誌有以下幾個方面的規劃：

　　完善功能：支援更多終端型別，建設日誌加工與清洗、日誌統計與告警、全鏈路追蹤等功能。

　　提升效能：支援百萬併發 QPS、日誌上報成功率提升至 99.9% 等。

　　提升穩定性：建設限流熔斷機制、應急響應與故障處理預案等。