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

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

1 背景

1.1 Logan 簡介

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

1.2 Logan 工作流程

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

圖 1 Logan 系統工作流程圖

1.3 爲什麼需要實時日誌？

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

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

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

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

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

1.4 Logan 實時日誌是什麼？

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

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

2 設計實現

2.1 整體架構

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

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

2.2 採集端

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

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

圖 4 採集端 SDK 架構圖

重點模塊介紹：

落盤緩存 + 上報恢復，防止日誌丟失

爲了方便讀者更好地理解端上日誌採集過程，下面將具體介紹下采集端流程設計。當採集端初始化 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 數據處理引擎，主要負責日誌數據的解析、日誌內容的解密以及拆分到下游等。

  1. 元數據解析：通過實時作業能力完成原始日誌數據解析爲 JSON 對象數據。

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

  3. 服務維度拆分：通過 topic 字段把日誌分發到各業務系統所屬的 topic 裏面，從而實現業務日誌相互隔離。

  4. 數據自定義加工：根據用戶自定義的加工語法模版，從服務 topic 實時消費並加工數據到自定義 topic 中。

2.5 數據消費層

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

圖 8 數據消費層設計圖

數據消費層的一些典型的應用場景：

  1. 網絡全鏈路追蹤：現階段前後端的日誌可能分佈在不同的系統中，前端日誌系統記錄的主要是代碼級日誌、端到端日誌等，後端日誌系統記錄的是鏈路關係、服務耗時等信息。通過 Logan 實時日誌開放的數據消費能力，用戶可以根據自己的需求來串聯多端日誌，從而實現網絡全鏈路追蹤。

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

  3. 離線數據分析：如果在一些需求場景下需要對數據進行長期化保存或者離線分析，就可以將數據導入到 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 等大體量業務。下面是一些業務系統接入的典型使用場景，供大家參考：

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

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

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

5 未來規劃

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

6 本文作者

洪坤、徐博、陳成、少星等，均來自美團 - 基礎技術部 - 前端技術中心。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/BAcB_LQ1Nr00Y7RxjRDK1g

猜你喜歡