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

1 背景

1.1 Logan 簡(jiǎn)介

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

1.2 Logan 工作流程

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

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

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

1.3 為什么需要實(shí)時(shí)日志？

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

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

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

1.4 Logan 實(shí)時(shí)日志是什么？

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

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

2 設(shè)計(jì)實(shí)現(xiàn) 2.1 整體架構(gòu)

圖3 Logan 實(shí)時(shí)日志整體架構(gòu)圖

如上圖所示，整體架構(gòu)主要分為五個(gè)部分，它們分別是：

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

2.2 采集端

通用采集端架構(gòu)，解決跨平臺(tái)復(fù)用

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

圖4 采集端SDK架構(gòu)圖

重點(diǎn)模塊介紹：

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

落盤緩存 + 上報(bào)恢復(fù)，防止日志丟失

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

圖5 采集端SDK流程圖

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

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

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

圖6 接入層流程圖

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

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

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

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

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

圖7 日志處理層流程圖

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

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

2.5 數(shù)據(jù)消費(fèi)層

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

圖8 數(shù)據(jù)消費(fèi)層設(shè)計(jì)圖

數(shù)據(jù)消費(fèi)層的一些典型的應(yīng)用場(chǎng)景：

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

2.6 日志平臺(tái)

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

圖9 日志查詢流程設(shè)計(jì)圖

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

3 穩(wěn)定性保障

3.1 核心監(jiān)控

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

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

3.2 藍(lán)綠發(fā)布

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

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

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

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

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

4 落地成果

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

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

5 未來規(guī)劃

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

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

6 本文作者

洪坤、徐博、陳成、少星等，均來自美團(tuán)-基礎(chǔ)技術(shù)部-前端技術(shù)中心。

| 本文系美團(tuán)技術(shù)團(tuán)隊(duì)出品，著作權(quán)歸屬美團(tuán)。歡迎出于分享和交流等非商業(yè)目的轉(zhuǎn)載或使用本文內(nèi)容，敬請(qǐng)注明“內(nèi)容轉(zhuǎn)載自美團(tuán)技術(shù)團(tuán)隊(duì)”。本文未經(jīng)許可，不得進(jìn)行商業(yè)性轉(zhuǎn)載或者使用。任何商用行為，請(qǐng)發(fā)送郵件至tech@meituan.com申請(qǐng)授權(quán)。

冷鏈服務(wù)業(yè)務(wù)聯(lián)系電話：19937817614

華鼎冷鏈?zhǔn)且患覍Ｗ⒂跒椴惋嬤B鎖品牌、工廠商貿(mào)客戶提供專業(yè)高效的冷鏈物流服務(wù)企業(yè)，已經(jīng)打造成集冷鏈倉儲(chǔ)、冷鏈零擔(dān)、冷鏈到店、信息化服務(wù)、金融為一體的全國(guó)化食品凍品餐飲火鍋食材供應(yīng)鏈冷鏈物流服務(wù)平臺(tái)。

標(biāo)簽:

食品安全網(wǎng)

上一篇：星巴克牽手美團(tuán)，透露了“定制化”外賣服務(wù)的新趨勢(shì)

下一篇：智氪 | 本地業(yè)務(wù)凸顯韌性，美團(tuán)Q3扭虧為盈