美團高性能終端實時日志系統(tǒng)建設實踐

時間：2023-01-10 18:52:04來源：food欄目：餐飲美食新聞閱讀：

你是否經(jīng)常遇到線上需要日志排查問題但遲遲聯(lián)系不上用戶上報日志的情況？或者是否經(jīng)常陷入由于存儲空間不足而導致日志寫不進去的囧境？本文介紹了美團是如何從0到1搭建高性能終端實時日志系統(tǒng)，從此徹底解決日志丟失和寫滿問題的。希望能為大家?guī)硪恍椭蛦l(fā)。

1 背景

1.1 Logan 簡介

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

1.2 Logan 工作流程

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

主動上報日志：終端設備在需要上報日志時，可以通過 HTTPS 接口主動上傳日志到 Logan 接收服務，接收服務再把原始日志文件轉存到對象存儲平臺。日志解密與解析：當研發(fā)人員想要查看主動上報的日志時會觸發(fā)日志下載與解析流程，原始加密日志從對象存儲平臺下載成功后進行解密、解析等操作，然后再投遞到日志存儲系統(tǒng)。日志查詢與檢索：日志平臺支持對單設備所有日志進行日志類型、標簽、進程、關鍵字、時間等維度的篩選，同時也支持對一些特定類型的日志進行可視化展示。

圖1 Logan 系統(tǒng)工作流程圖

1.3 為什么需要實時日志？

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

部分場景上報日志受限：由于在 Web 與小程序上用戶一般的使用場景是用完即走，當線上出現(xiàn)問題時再聯(lián)系用戶主動上報日志，整個處理周期較長，有可能會錯過最佳排查時間。缺少實時分析和告警能力：當前缺少實時分析和告警的能力，用戶曾多次提到過想要對線上異常日志進行監(jiān)控，當有符合規(guī)則的異常日志出現(xiàn)時能收到告警信息。缺少全鏈路追蹤能力：當前多端的日志散落在各個系統(tǒng)中，研發(fā)人員在定位問題時需要手動去關聯(lián)日志，操作起來很不方便，美團內(nèi)部缺乏一個通用的全鏈路追蹤方案。

針對以上痛點問題，我們提出了建設 Logan 實時日志，旨在提供統(tǒng)一的、高性能的實時日志服務，以解決美團現(xiàn)階段不同業(yè)務系統(tǒng)想要日志上云的需求。

1.4 Logan 實時日志是什么？

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

圖2 Logan 實時日志產(chǎn)品功能圖

2 設計實現(xiàn) 2.1 整體架構

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

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

采集端：負責端上日志數(shù)據(jù)的采集、加密、壓縮、聚合和上報等。接入層：負責提供日志上報接口，接收日志上報數(shù)據(jù)，并將數(shù)據(jù)轉發(fā)到數(shù)據(jù)處理層。數(shù)據(jù)處理層：負責日志數(shù)據(jù)的解密、拆分、加工和清洗等。數(shù)據(jù)消費層：負責日志數(shù)據(jù)的過濾、格式化、投遞等。日志平臺：負責日志數(shù)據(jù)查詢與分析、業(yè)務系統(tǒng)接入配置、統(tǒng)計與告警等。

2.2 采集端

通用采集端架構，解決跨平臺復用

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

圖4 采集端SDK架構圖

重點模塊介紹：

配置管理：采集端初始化完成后，首先啟動配置管理模塊，拉取和刷新配置信息，包括上報限流配置、指標采樣率、功能開關等，支持對關鍵配置進行灰度發(fā)布。加密：所有記錄的日志都使用 ECDH + AES 方案加密，確保日志信息不泄漏。Web 版加密模塊使用瀏覽器原生加密 API 進行適配，可實現(xiàn)高性能異步加密，其他平臺則使用純 JS 實現(xiàn)。存儲管理：線上數(shù)據(jù)表明，由于頁面關閉導致的日志丟失占比高達 1%，因此我們設計了日志落盤功能，當日志上傳失敗后會先緩存在本地磁盤，等到頁面下一次啟動時再重新恢復上傳。隊列管理：需要發(fā)送的日志首先進行分組聚合，如果等待分組過多則需要丟棄一部分請求，防止在弱網(wǎng)環(huán)境或者日志堆積太多時造成內(nèi)存持續(xù)上漲而影響用戶。

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

為了方便讀者更好地理解端上日志采集過程，下面將具體介紹下采集端流程設計。當采集端初始化 API 開始調(diào)用時，先創(chuàng)建 Logger、Encryptor、Storage 等實例對象，并異步拉取環(huán)境配置文件。初始化完成之后，先檢查是否有成功落盤，但是上報失敗的日志，如果有的話立即開始恢復上傳流程。當正常調(diào)用寫日志 API 時，原始日志被加密后加入當前上報組，等到有上報事件（時間、條數(shù)、導航等）觸發(fā)時，當前上報組內(nèi)的所有日志被加入上報隊列并開始上傳。采集端詳細流程圖如下：

圖5 采集端SDK流程圖

2.3 數(shù)據(jù)接入層

對于實時日志系統(tǒng)來講，接入層需要滿足以下幾點要求：（1）支持公網(wǎng)上報域名；（2）支持高并發(fā)處理；（3）具備高實時性，延遲是分鐘級；（4）支持投遞數(shù)據(jù)到 Kafka 消息隊列。

經(jīng)過對比，美團內(nèi)的統(tǒng)一日志收集通道均滿足以上需求，因此我們選用了統(tǒng)一日志收集通道作為接入層。采集端SDK通過獨立的公網(wǎng)域名上報日志后，收集通道將日志數(shù)據(jù)匯總好并投遞到指定的Kafka消息隊列。如果讀者公司沒有類似的日志收集通道，那么可以參考以下流程搭建實時日志系統(tǒng)接入層。

圖6 接入層流程圖

2.4 數(shù)據(jù)處理層

在數(shù)據(jù)處理框架的技術選型上，我們先后考慮了三種方案，分別是傳統(tǒng)架構（Java 應用）、Storm 架構、Flink 架構，這三種方案在不同維度的對比數(shù)據(jù)如下：

綜合來看，雖然傳統(tǒng)架構有比較好的成熟度與靈活性，但是在擴展性、容錯性以及性能上均不能滿足系統(tǒng)要求，而 Flink 架構與 Storm 架構都有比較優(yōu)秀的擴展性與容錯性，但是 Flink 架構在延遲與吞吐量上表現(xiàn)要更好，因此我們最終選擇了使用 Flink 架構作為數(shù)據(jù)處理框架。

Flink：業(yè)內(nèi)領先的流式計算引擎，具有高吞吐、低延遲、高可靠和精確計算等優(yōu)點，對事件窗口有很好的支持，被業(yè)內(nèi)很多公司作為首選的流式計算引擎。

在日志處理流程設計上，日志數(shù)據(jù)通過接入層處理后被投遞到匯總 topic 里面，然后再通過 Flink 作業(yè)的邏輯處理后分發(fā)到下游。處理流程如下圖所示：

圖7 日志處理層流程圖

匯總后的日志數(shù)據(jù)處理和分發(fā)依賴于實時計算平臺的實時作業(yè)能力，底層使用 Flink 數(shù)據(jù)處理引擎，主要負責日志數(shù)據(jù)的解析、日志內(nèi)容的解密以及拆分到下游等。

元數(shù)據(jù)解析：通過實時作業(yè)能力完成原始日志數(shù)據(jù)解析為 JSON 對象數(shù)據(jù)。內(nèi)容解密：對加密內(nèi)容進行解密，此處使用非對稱協(xié)商計算出對稱加密密鑰，然后再進行解密。服務維度拆分：通過 topic 字段把日志分發(fā)到各業(yè)務系統(tǒng)所屬的 topic 里面，從而實現(xiàn)業(yè)務日志相互隔離。數(shù)據(jù)自定義加工：根據(jù)用戶自定義的加工語法模版，從服務 topic 實時消費并加工數(shù)據(jù)到自定義 topic 中。

2.5 數(shù)據(jù)消費層

對大部分用戶來說 Logan 實時日志提供的日志采集、加工、檢索能力已經(jīng)能滿足大部分需求。但是在與用戶溝通過程中我們發(fā)現(xiàn)還有一些更高階的需求，比如指標監(jiān)控、前后端鏈路串聯(lián)、離線數(shù)據(jù)計算等。于是我們將 Logan 標準化后的日志統(tǒng)一投遞到 Kafka 流處理平臺，并提供一些通用的數(shù)據(jù)轉換能力，方便用戶按需接入到不同的第三方系統(tǒng)。數(shù)據(jù)消費層設計如下圖所示：

圖8 數(shù)據(jù)消費層設計圖

數(shù)據(jù)消費層的一些典型的應用場景：

網(wǎng)絡全鏈路追蹤：現(xiàn)階段前后端的日志可能分布在不同的系統(tǒng)中，前端日志系統(tǒng)記錄的主要是代碼級日志、端到端日志等，后端日志系統(tǒng)記錄的是鏈路關系、服務耗時等信息。通過 Logan 實時日志開放的數(shù)據(jù)消費能力，用戶可以根據(jù)自己的需求來串聯(lián)多端日志，從而實現(xiàn)網(wǎng)絡全鏈路追蹤。指標聚合統(tǒng)計&告警：實時日志也是一種實時的數(shù)據(jù)流，可以作為指標數(shù)據(jù)上報的載體，如果把日志數(shù)據(jù)對接到數(shù)據(jù)統(tǒng)計平臺就能實現(xiàn)指標監(jiān)控和告警了。離線數(shù)據(jù)分析：如果在一些需求場景下需要對數(shù)據(jù)進行長期化保存或者離線分析，就可以將數(shù)據(jù)導入到 Hive 中來實現(xiàn)。

2.6 日志平臺

日志平臺的核心功能是為用戶提供日志檢索支持，日志平臺提供了用戶標識、自定義標簽、關鍵字等多種檢索過濾方式。在日志底層存儲架構的選擇上，目前業(yè)界廣泛使用的是 Elasticsearch，考慮到計費與運維成本的關系，美團內(nèi)部已經(jīng)有一套統(tǒng)一的框架可以使用，所以我們也選用了 Elasticsearch 架構。同時，我們也支持通過單獨的接口層適配其他存儲引擎，日志查詢流程如下：

圖9 日志查詢流程設計圖

Elasticsearch：是一個分布式的開源搜索和分析引擎，具有接入成本低、擴展性高和近實時性等優(yōu)點，比較適合用來做大數(shù)據(jù)量的全文檢索服務，例如日志查詢等。

3 穩(wěn)定性保障

3.1 核心監(jiān)控

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

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

3.2 藍綠發(fā)布

實時日志依賴于實時作業(yè)的處理計算能力，但是目前實時作業(yè)的發(fā)布和部署不能無縫銜接，中間可能存在真空的情況。當重啟作業(yè)時，需要先停止原作業(yè)，再啟動新的作業(yè)。如果遇到代碼故障或系統(tǒng)資源不足等情況時則會導致作業(yè)啟動失敗，從而直接面臨消息積壓嚴重和數(shù)據(jù)延時升高的問題，這對于實時日志系統(tǒng)來說是不能忍受的。

藍綠發(fā)布（Blue Green Deployment）是一種平滑過渡的發(fā)布模式。在藍綠發(fā)布模式中，首先要將應用劃分為對等的藍綠兩個分組，藍組發(fā)布新產(chǎn)品代碼并引入少許線上流量，綠組繼續(xù)運行老產(chǎn)品代碼。當新產(chǎn)品代碼經(jīng)線上運行觀察沒有問題后，開始逐步引入更多線上流量，直至所有流量都訪問藍組新產(chǎn)品。因此，藍綠發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在產(chǎn)品發(fā)布前期就可以發(fā)現(xiàn)并解決問題，以保證其影響面可控。

目前美團已有的實時作業(yè)藍綠部署方案各不相同，由于 Logan 實時日志接入業(yè)務系統(tǒng)較多，且數(shù)據(jù)量較大，經(jīng)過綜合考量后，我們決定自己實現(xiàn)一套適合當前系統(tǒng)的藍綠部署方案。為了保證系統(tǒng)的穩(wěn)定性，在作業(yè)運行過程中，啟動另外一個相同的作業(yè)，當新作業(yè)運行沒有問題后，再完成新老作業(yè)切換。藍綠發(fā)布流程圖如下：

圖10 藍綠發(fā)布流程圖

使用藍綠部署后，徹底解決了由于資源不足或參數(shù)不對導致的上線失敗問題，平均部署切換耗時也保持在1分鐘以內(nèi)，基本避免了因發(fā)布帶來的日志消費延遲問題。

4 落地成果

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

核心鏈路還原：到家某 C 端小程序使用 Logan 實時日志記錄程序核心鏈路中的關鍵日志與異常日志，當線上有客訴問題發(fā)生時，可以第一時間查看實時日志并定位問題。項目上線后，平均客訴定位時間從之前的 10 分鐘減少到 3 分鐘以內(nèi)，排障效率有明顯提升。內(nèi)測階段排障：企業(yè)平臺某前端項目由于 2.0 改版改動較大，于是使用 Logan 實時日志在內(nèi)測階段添加更多的調(diào)試日志，方便定位線上問題。項目上線后，每次排查問題除了節(jié)省用戶上報日志時間 10-15 分鐘，還杜絕了因為存儲空間不足而拿不到用戶日志的情況。日志數(shù)據(jù)分析：美團到店某團隊使用 Logan 實時日志分析前后端交互過程中的請求頭、請求參數(shù)、響應體等數(shù)據(jù)是否符合標準化規(guī)范。經(jīng)過一個多月時間的試運行，一期版本上線后共覆蓋 300+ 前端頁面和 500+ 前端接口，共計發(fā)現(xiàn) 1000+ 規(guī)范問題。

5 未來規(guī)劃

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

完善功能：支持更多終端類型，建設日志加工與清洗、日志統(tǒng)計與告警、全鏈路追蹤等功能。提升性能：支持百萬并發(fā)QPS、日志上報成功率提升至 99.9% 等。提升穩(wěn)定性：建設限流熔斷機制、應急響應與故障處理預案等。