如何設(shè)計(jì)一個(gè)高效的分布式日志服務(wù)平臺(tái)

本文首先介紹了分布式服務(wù)下日志服務(wù)建設(shè)的挑戰(zhàn)，然后介紹了下業(yè)內(nèi)ELK的通用解決方案及與天眼日志服務(wù)的差異性，接下來(lái)詳細(xì)介紹了天眼日志服務(wù)平臺(tái)的整體架構(gòu)，如何做采集、傳輸、檢索、隔離、清理等機(jī)制的，最后對(duì)日志服務(wù)與大模型進(jìn)行結(jié)合，不斷探索效能的提升。

GEEK TALK

01

分布式服務(wù)下日志服務(wù)挑戰(zhàn)

分布式服務(wù)系統(tǒng)中，每個(gè)服務(wù)有大量的服務(wù)器，而每臺(tái)服務(wù)器每天都會(huì)產(chǎn)生大量的日志。我們面臨的主要挑戰(zhàn)有：

1、日志量巨大：在分布式服務(wù)環(huán)境中，日志分散在多個(gè)節(jié)點(diǎn)上，每個(gè)服務(wù)都會(huì)產(chǎn)生大量的日志，因此需要一種可靠的機(jī)制來(lái)收集和聚合日志數(shù)據(jù)。

2、多樣化的日志格式：不同的服務(wù)可能使用不同的日志格式，例如日志輸出的字段、順序和級(jí)別等，這會(huì)增加日志服務(wù)的開(kāi)發(fā)和維護(hù)難度。

3、日志服務(wù)的可擴(kuò)展性和可靠性：隨著分布式服務(wù)數(shù)量的增加和規(guī)模的擴(kuò)大，日志服務(wù)需要能夠進(jìn)行橫向擴(kuò)展和縱向擴(kuò)展，以保證其性能和可靠性。

所以我們?cè)撊绾翁峁┓植际较到y(tǒng)下高效、低延遲、高性能的日志服務(wù)呢？

GEEK TALK

02

業(yè)內(nèi)ELK通用解決方案

2.1 Elastic Stack發(fā)展歷程

2.2 Elastic Stack組件架構(gòu)圖

2.2.1 Ingest組件

Ingest是獲取日志數(shù)據(jù)的相關(guān)組件。

shippers和sources是收集的原始日志組件，承接著原始日志（log文件日志、系統(tǒng)日志、網(wǎng)絡(luò)日志等）采集和發(fā)送，其中Elastic Agent、APM、Beats 收集和發(fā)送日志、指標(biāo)和性能數(shù)據(jù)。

queues和processors是原始日志數(shù)據(jù)的處理管道，使用這些組件可以定制化的對(duì)原始日志數(shù)據(jù)進(jìn)行處理和轉(zhuǎn)換，在存儲(chǔ)之前可以模板化數(shù)據(jù)格式，方便elasticsearch更好的承接存儲(chǔ)和檢索功能。

Elastic Agent是一種使用單一、統(tǒng)一的方式，為主機(jī)添加對(duì)日志、指標(biāo)和其他類型數(shù)據(jù)的監(jiān)控。它還可以保護(hù)主機(jī)免受安全威脅、從操作系統(tǒng)查詢數(shù)據(jù)、從遠(yuǎn)程服務(wù)或硬件轉(zhuǎn)發(fā)數(shù)據(jù)等等。每個(gè)代理都有一個(gè)策略，可以向其中添加新數(shù)據(jù)源、安全保護(hù)等的集成。

Fleet能夠集中管理Elastic Agent及其策略。使用 Fleet 可以監(jiān)控所有 Elastic Agent 的狀態(tài)、管理agent策略以及升級(jí) Elastic Agent 二進(jìn)制文件或集成。

Elastic APM是一個(gè)基于 Elastic Stack 構(gòu)建的應(yīng)用程序性能監(jiān)控系統(tǒng)。通過(guò)收集有關(guān)傳入請(qǐng)求、數(shù)據(jù)庫(kù)查詢、緩存調(diào)用、外部 HTTP 請(qǐng)求等響應(yīng)時(shí)間的詳細(xì)性能信息，實(shí)時(shí)監(jiān)控軟件服務(wù)和應(yīng)用程序。

Beats是在服務(wù)器上作為代理安裝的數(shù)據(jù)發(fā)送器，用于將操作數(shù)據(jù)發(fā)送到 Elasticsearch。Beats 可用于許多標(biāo)準(zhǔn)的可觀察性數(shù)據(jù)場(chǎng)景，包括審計(jì)數(shù)據(jù)、日志文件和日志、云數(shù)據(jù)、可用性、指標(biāo)、網(wǎng)絡(luò)流量和 Windows 事件日志。

Elasticsearch Ingest Pipelines可以在將數(shù)據(jù)存儲(chǔ)到 Elasticsearch 之前對(duì)數(shù)據(jù)執(zhí)行常見(jiàn)的轉(zhuǎn)換。將一個(gè)或多個(gè)“處理器”任務(wù)配置為按順序運(yùn)行，在將文檔存儲(chǔ)到 Elasticsearch 之前對(duì)文檔進(jìn)行特定更改。

Logstash是一個(gè)具有實(shí)時(shí)數(shù)據(jù)收集引擎。它可以動(dòng)態(tài)地統(tǒng)一來(lái)自不同來(lái)源的數(shù)據(jù)，并將數(shù)據(jù)規(guī)范化到目的地。Logstash 支持豐富的輸入、過(guò)濾器和輸出插件。

2.2.2 Store組件

Store 是承接日志存儲(chǔ)和檢索組件，這里是使用的Elasticsearch承接該功能。Elasticsearch 是 Elastic Stack 核心的分布式搜索和分析引擎。它為所有類型的數(shù)據(jù)提供近乎實(shí)時(shí)的搜索和分析。無(wú)論結(jié)構(gòu)化或非結(jié)構(gòu)化文本、數(shù)字?jǐn)?shù)據(jù)還是地理空間數(shù)據(jù)，Elasticsearch 都可以以支持快速搜索的方式高效地存儲(chǔ)和索引這些數(shù)據(jù)。Elasticsearch 提供了一個(gè) REST API，使您能夠在 Elasticsearch 中存儲(chǔ)和檢索數(shù)據(jù)。REST API 還提供對(duì) Elasticsearch 的搜索和分析功能的訪問(wèn)。

2.2.3 Consumer組件

Consumer是消費(fèi)store存儲(chǔ)數(shù)據(jù)的組件，這里組要有可視化的kibana和Elasticsearch Client。Kibana 是利用 Elasticsearch 數(shù)據(jù)和管理 Elastic Stack 的工具。使用它可以分析和可視化存儲(chǔ)在 Elasticsearch 中的數(shù)據(jù)。

Elasticsearch Client提供了一種方便的機(jī)制來(lái)管理來(lái)自語(yǔ)言（如 Java、Ruby、Go、Python 等）的 Elasticsearch 的 API 請(qǐng)求和響應(yīng)。

2.3天眼對(duì)比ELK差異

1、接入便捷性

ELK：方案依賴完整流程部署準(zhǔn)備，操作配置復(fù)雜，接入跑通耗時(shí)長(zhǎng)。

天眼：只需簡(jiǎn)單三步配置，頁(yè)面申請(qǐng)產(chǎn)品線接入、頁(yè)面獲取產(chǎn)品線appkey、依賴管理中增加天眼SDK依賴并配置appkey到系統(tǒng)配置中。

2、資源定制化

ELK：資源修改、配置每次都需要重啟才能生效，不支持多資源配置化選擇。

天眼：產(chǎn)品線接入時(shí)可以選擇使用業(yè)務(wù)自身傳輸、存儲(chǔ)資源或自動(dòng)使用系統(tǒng)默認(rèn)資源，資源切換只需頁(yè)面簡(jiǎn)單配置并即時(shí)自動(dòng)生效。

3、擴(kuò)容成本與效率

ELK：方案僅支持單個(gè)業(yè)務(wù)產(chǎn)品線，其他業(yè)務(wù)產(chǎn)線接入需重新部署一套，資源無(wú)法共享，擴(kuò)容需手動(dòng)增加相應(yīng)實(shí)例等。

天眼：資源集中管理，產(chǎn)品線動(dòng)態(tài)接入，資源動(dòng)態(tài)配置即時(shí)生效，大部分資源自動(dòng)共享同時(shí)又支持資源獨(dú)享配置；擴(kuò)容直接通過(guò)平臺(tái)頁(yè)面化操作，簡(jiǎn)單便捷。

4、日志動(dòng)態(tài)清理

ELK：依賴人工發(fā)現(xiàn)、手動(dòng)清理和處理資源占用。

天眼：自動(dòng)化監(jiān)測(cè)ES集群概況，自動(dòng)計(jì)算資源占用情況，當(dāng)達(dá)到監(jiān)控閾值時(shí)自動(dòng)執(zhí)行時(shí)間最早的索引資源清理。

5、自適應(yīng)存儲(chǔ)

ELK：傳統(tǒng)方案受限于存儲(chǔ)資源空間和成本，存儲(chǔ)成本高、可保存的數(shù)據(jù)量有限。

天眼：實(shí)現(xiàn)了日志轉(zhuǎn)存文件及從文件自動(dòng)化恢復(fù)，日志存儲(chǔ)成本低，存儲(chǔ)周期長(zhǎng)。

天眼通過(guò)自建分布式日志平臺(tái)，有效的解決ELK日志方案下存在的缺陷問(wèn)題；當(dāng)前天眼日志量級(jí)：日均10TB日志量，并發(fā)QPS：10w+，接入產(chǎn)品線數(shù)：1000+。

GEEK TALK

03

天眼

3.1 天眼系統(tǒng)架構(gòu)

上圖為完整的天眼核心系統(tǒng)架構(gòu)，概述如下：

1、天眼日志采集支持SDK及監(jiān)聽(tīng)日志文件兩種方式，其中SDK主要通過(guò)實(shí)現(xiàn)日志插件接口獲得完整日志結(jié)構(gòu)信息，并傳輸至天眼日志傳輸管道；獲得的日志信息LogEvent結(jié)構(gòu)完整，同時(shí)基于LogEvent增加了產(chǎn)品線標(biāo)識(shí)等字段，為日志隔離和檢索提供核心依據(jù)；監(jiān)聽(tīng)日志文件方式實(shí)現(xiàn)業(yè)務(wù)方0開(kāi)發(fā)成本接入，僅需簡(jiǎn)單配置即可實(shí)現(xiàn)日志接入，支持產(chǎn)品線字段標(biāo)識(shí)的同時(shí)，日志消息體解析也實(shí)現(xiàn)了正則匹配規(guī)則自動(dòng)化匹配。

2、天眼日志傳輸采用高并發(fā)性能隊(duì)列Disruptor，并且二次采用高性能隊(duì)列Bigpipe實(shí)現(xiàn)日志傳輸異步解耦，解決了傳統(tǒng)隊(duì)列因加鎖和偽共享等問(wèn)題帶來(lái)的性能缺陷；同時(shí)在傳輸過(guò)程中提供日志過(guò)濾和日志告警規(guī)則配置化自動(dòng)化執(zhí)行。

3、天眼日志存儲(chǔ)通過(guò)輪詢消費(fèi)Bigpipe日志消息，最終寫入ES的BulkProcessor，由ES自動(dòng)調(diào)度并發(fā)寫入ES進(jìn)行存儲(chǔ)；在日志傳輸和存儲(chǔ)過(guò)程中實(shí)現(xiàn)了日志傳輸資源與存儲(chǔ)資源隔離，根據(jù)產(chǎn)品線配置自動(dòng)化選擇傳輸與存儲(chǔ)資源。

4、天眼自動(dòng)化清理實(shí)現(xiàn)在存儲(chǔ)資源有限的情況下自適應(yīng)存儲(chǔ)，自動(dòng)化轉(zhuǎn)存與恢復(fù)實(shí)現(xiàn)了在ES資源有限情況下低成本長(zhǎng)時(shí)間存儲(chǔ)解決方案。

3.2 天眼日志采集

日志平臺(tái)核心目的是采集分布式場(chǎng)景下的業(yè)務(wù)日志進(jìn)行集中處理和存儲(chǔ)，采集方式主要包含如下：

1、借助常見(jiàn)日志框架提供的插件接口，在生成日志事件的同時(shí)執(zhí)行其他自定義處理邏輯，例如log4j2提供的Appender等。

2、通過(guò)各種攔截器插件在固定位置攔截并主動(dòng)生成和打印業(yè)務(wù)日志，將這類日志信息主動(dòng)發(fā)送至日志消息傳輸隊(duì)列中供消費(fèi)使用，常見(jiàn)的如http、rpc調(diào)用鏈請(qǐng)求與返回信息打印，以及mybatis執(zhí)行過(guò)程SQL明細(xì)打印等。

3、監(jiān)聽(tīng)日志文件寫入，從文件系統(tǒng)上的一個(gè)文件進(jìn)行讀取，工作原理有些類似UNIX的tail -0F命令，當(dāng)日志寫入本地文件時(shí)捕獲寫入行內(nèi)容并進(jìn)行其他自定義處理，例如將日志行信息發(fā)送至消息隊(duì)列供下游使用。

4、syslog：監(jiān)聽(tīng)來(lái)自514端口的syslog消息，并將其轉(zhuǎn)換為RFC3164格式。

更多可用的日志采集實(shí)現(xiàn)方式，可以參考：Input Plugins

下面以天眼日志采集為例詳細(xì)介紹日志采集實(shí)現(xiàn)過(guò)程：

天眼平臺(tái)供支持兩類日志采集實(shí)現(xiàn)方式，一類是SDK、一類是minos（百度自研的新一代的流式日志傳輸系統(tǒng)）。

3.2.1 天眼SDK日志采集

天眼SDK日志采集方式為通過(guò)Java SDK方式向業(yè)務(wù)方提供日志采集組件實(shí)現(xiàn)，達(dá)到自動(dòng)收集業(yè)務(wù)日志并自動(dòng)傳輸?shù)哪康模缓诵姆譃閙essage日志流和trace日志流兩大塊：

1、message日志流主要通過(guò)日志框架提供的Appender接口實(shí)現(xiàn)，共支持log4j、logback、log4j2等主流日志框架。

以logback為例，通過(guò)繼承并實(shí)現(xiàn)AppenderBase抽象類提供的append方法，在logback日志框架生成LogEvent后獲取日志事件對(duì)象并提交給LogbackTask執(zhí)行任務(wù)處理，在LogbackTask中可以對(duì)日志事件內(nèi)容進(jìn)行進(jìn)一步包裝完善，并執(zhí)行一些日志過(guò)濾策略等，最終得到的日志事件信息將直接發(fā)送至日志傳輸隊(duì)列進(jìn)行傳輸處理；

复制public class LogClientAppender<E> extends AppenderBase<E> {
    
    private static final Logger LOGGER = LoggerFactory.getLogger(LogClientAppender.class);
    
    @Override
    protected void append(E eventObject) {
        
        ILoggingEvent event = filter(eventObject);
        if (event != null) {
            MessageLogSender.getExecutor().submit(new LogbackTask(event, LogNodeFactory.getLogNodeSyncDto()));
        }
        
    }
}

2、trace日志流主要通過(guò)各類攔截器攔截業(yè)務(wù)請(qǐng)求調(diào)用鏈及業(yè)務(wù)執(zhí)行鏈路，通過(guò)獲取調(diào)用鏈詳細(xì)信息主動(dòng)生成調(diào)用鏈日志事件，并發(fā)送至日志傳輸隊(duì)列進(jìn)行消費(fèi)使用，常見(jiàn)的調(diào)用鏈日志包含http與rpc請(qǐng)求及響應(yīng)日志、mybatis組件SQL執(zhí)行日志等；

下圖為trace日志流實(shí)現(xiàn)類圖，描述了trace日志流抽象實(shí)現(xiàn)過(guò)程：

以mybatis為例，trace日志流核心攔截器實(shí)現(xiàn)類為IlogMybatisPlugin，實(shí)現(xiàn)ibatis Interceptor接口

核心代碼：

复制TraceFactory.getSqltracer().end(returnObj, className, methodName, realParams, dbType, sqlType, sql, sqlUrl)

在end方法中將SQL執(zhí)行過(guò)程中產(chǎn)生的各類信息通過(guò)參數(shù)傳入，并組裝成SqlLogNode（繼承至通用日志節(jié)點(diǎn)LogNode）發(fā)布到隊(duì)列。

使用時(shí)需要業(yè)務(wù)方手動(dòng)將插件注冊(cè)到SqlSessionFactory，以生效插件：

复制sqlSessionFactory.getConfiguration().addInterceptor(new IlogMybatisPlugin());

3.2.2 天眼minos日志采集

minos日志采集主要是借助百度自研的minos數(shù)據(jù)傳輸平臺(tái)，實(shí)現(xiàn)機(jī)器實(shí)例上的日志文件信息實(shí)時(shí)傳輸至目的地，常見(jiàn)傳輸目的地有Bigpipe、HDFS、AFS等；目前天眼主要是通過(guò)將minos采集到的日志發(fā)送到Bigpipe實(shí)現(xiàn)，并由后續(xù)的Bigpipe消費(fèi)者統(tǒng)一消費(fèi)和處理；同時(shí)針對(duì)日志來(lái)源為minos的日志在消費(fèi)過(guò)程中增加了日志解析與轉(zhuǎn)換策略，確保采集到的日志格式和SDK方式生成的日志格式基本一致；

在日志采集過(guò)程中，天眼如何解決平臺(tái)化標(biāo)識(shí)：

1、在產(chǎn)品線接入天眼時(shí)，天眼給對(duì)應(yīng)產(chǎn)品線生成產(chǎn)品線唯一標(biāo)識(shí)；

2、SDK接入方式下，產(chǎn)品線服務(wù)端通過(guò)系統(tǒng)變量配置產(chǎn)品線標(biāo)識(shí)，SDK在運(yùn)行過(guò)程中會(huì)自動(dòng)讀取該變量值并設(shè)置到LogNode屬性中；

3、LogNode作為日志完整信息對(duì)象，在傳輸過(guò)程中最終存儲(chǔ)到ES，同時(shí)ES在建索引時(shí)為產(chǎn)品線唯一標(biāo)識(shí)分配字段屬性；

4、產(chǎn)品線唯一標(biāo)識(shí)貫穿整個(gè)分布式日志鏈路并和日志內(nèi)容強(qiáng)綁定。

3.3 高并發(fā)數(shù)據(jù)傳輸和存儲(chǔ)

在ELK方案中，生成的日志信息直接發(fā)送給logstash進(jìn)行傳輸，并寫入到es，整個(gè)過(guò)程基本為同步操作，并發(fā)性能完全依賴logstash服務(wù)端及ES服務(wù)端性能；

天眼則是通過(guò)異步方式解耦日志傳輸過(guò)程，以及在日志入口處引入Disruptor高性能隊(duì)列，并發(fā)性能直奔千萬(wàn)級(jí)別；同時(shí)在Disruptor本地隊(duì)列之后再設(shè)計(jì)Bigpipe離線隊(duì)列，用來(lái)長(zhǎng)效存儲(chǔ)和傳輸日志消息；以及引入兜底文件隊(duì)列BigQueue解決方案，處理在極少數(shù)異常情況下寫本地隊(duì)列或離線隊(duì)列失敗時(shí)的兜底保障，如下圖所示：

Disruptor是一個(gè)高性能的用于線程間消息處理的開(kāi)源框架。Disruptor內(nèi)部使用了RingBuffer，它是Disruptor的核心的數(shù)據(jù)結(jié)構(gòu)。Disruptor隊(duì)列設(shè)計(jì)特性：固定大小數(shù)組：由于數(shù)組占用一塊連續(xù)的內(nèi)存空間，可以利用CPU的緩存策略，預(yù)先讀取數(shù)組元素附近的元素；數(shù)組預(yù)填充：避免了垃圾回收代來(lái)的系統(tǒng)開(kāi)銷；緩存行填充：解決偽共享問(wèn)題；位操作：加快系統(tǒng)的計(jì)算速度；使用數(shù)組+系列號(hào)的這種方法最大限度的提高了速度。因?yàn)槿绻褂脗鹘y(tǒng)的隊(duì)列的話，在多線程環(huán)境下對(duì)隊(duì)列頭和隊(duì)列尾的鎖競(jìng)爭(zhēng)是一種很大的系統(tǒng)開(kāi)銷。 Bigpipe是一個(gè)分布式中間件系統(tǒng)，支持Topic和Queue模型，不僅可以完成傳統(tǒng)消息隊(duì)列可以實(shí)現(xiàn)的諸如消息、命令的實(shí)時(shí)傳輸，也可以用于日志數(shù)據(jù)的實(shí)時(shí)傳輸。Bigpipe能夠幫助模塊間的通信實(shí)現(xiàn)解耦，并能保證消息的不丟不重；BigQueue是基于內(nèi)存映射文件的大型、快速和持久隊(duì)列；

1、快: 接近直接內(nèi)存訪問(wèn)的速度，enqueue和dequeue都接近于O(1)內(nèi)存訪問(wèn)。

2、大：隊(duì)列的總大小僅受可用磁盤空間的限制。

3、持久：隊(duì)列中的所有數(shù)據(jù)都持久保存在磁盤上，并且是抗崩潰的。

4、可靠：即使您的進(jìn)程崩潰，操作系統(tǒng)也將負(fù)責(zé)保留生成的消息。

5、實(shí)時(shí)：生產(chǎn)者線程產(chǎn)生的消息將立即對(duì)消費(fèi)者線程可見(jiàn)。

6、內(nèi)存高效：自動(dòng)分頁(yè)和交換算法，只有最近訪問(wèn)的數(shù)據(jù)保留在內(nèi)存中。

7、線程安全：多個(gè)線程可以同時(shí)入隊(duì)和出隊(duì)而不會(huì)損壞數(shù)據(jù)。

8、簡(jiǎn)單輕量：目前源文件個(gè)數(shù)12個(gè)，庫(kù)jar不到30K。

在采集到日志事件后，進(jìn)入傳輸過(guò)程中，天眼SDK中支持日志過(guò)濾規(guī)則策略匹配，針對(duì)命中策略的日志進(jìn)行過(guò)濾，實(shí)現(xiàn)過(guò)程如下圖所示：

未命中過(guò)濾規(guī)則的日志消息事件將繼續(xù)發(fā)送至Bigpipe，至此日志生產(chǎn)階段即完成，后續(xù)通過(guò)天眼消費(fèi)者模塊訂閱Bigpipe消費(fèi)并批量推送至ES。

3.4天眼日志檢索

基于天眼鏈路最終存儲(chǔ)到ES的日志數(shù)據(jù)，天眼平臺(tái)提供了可視化日志檢索頁(yè)面，能夠根據(jù)產(chǎn)品線唯一標(biāo)識(shí)（日志源ID）指定業(yè)務(wù)范圍進(jìn)行檢索，同時(shí)支持各種檢索條件，效果如下圖所示：

3.4.1 檢索條件詳解

日志源id列表：獲取日志源對(duì)應(yīng)的日志

檢索時(shí)間范圍：日志的時(shí)間范圍

排序類型：日志的存入時(shí)間/日志存入的算分

查詢數(shù)量：查詢出多少數(shù)量的日志

日志級(jí)別：查詢什么級(jí)別的日志，如：DEBUG / INFO / WARN / ERROR

算分條件：支持五種算分查詢，文本查詢、等值查詢、短語(yǔ)查詢、前綴查詢、邏輯查詢；五選一

過(guò)濾條件：?只顯示符合過(guò)濾條件信息的日志

3.4.2 算分條件檢索詳細(xì)說(shuō)明

支持五種算分查詢：文本查詢、等值查詢、短語(yǔ)查詢、前綴查詢、邏輯查詢。五選一

搜索內(nèi)容字段：message、exception

复制"message": {
  "type": "text",
  "fields": {
    "raw": {
      "type": "keyword",
      "ignore_above": 15000
    }
  },
  "analyzer": "my_ik_max_word",
  "search_analyzer": "my_ik_smart"
},
"exception": {
  "type": "text",
  "analyzer": "my_ik_max_word",
  "search_analyzer": "my_ik_smart"
}

說(shuō)明：

• "analyzer": "my_ik_max_word"：底層使用ik_max_word，message和exception信息在存儲(chǔ)是會(huì)以最細(xì)粒度拆詞進(jìn)行存儲(chǔ)；

• "search_analyzer": "my_ik_smart"：底層使用ik_smart，在查詢內(nèi)容是，會(huì)將查詢內(nèi)容以最粗粒度拆分進(jìn)行查詢。

3.4.2.1 文本查詢

底層實(shí)現(xiàn)原理

复制{
  "query": {
    "bool": {
      "must": [{
        "multi_match": {
          "query": "searchValue",
          "fields": ["message", "exception"],
          "type": "best_fields"
        }
      }]
    }
  }
}

天眼管理端對(duì)應(yīng)圖

使用說(shuō)明：

• multi_match中的best_fields會(huì)將任何與查詢匹配的文檔作為結(jié)果返回，但是只使用最佳字段的 _score 評(píng)分作為評(píng)分結(jié)果返回

3.4.2.2 等值查詢

底層實(shí)現(xiàn)原理

复制{
  "query": {
    "bool": {
      "must": [{
        "multi_match": {
          "query": "searchValue",
          "fields": ["message", "exception"],
          "type": "best_fields",
          "analyzer": "keyword"
        }
      }]
    }
  }
}

天眼管理端對(duì)應(yīng)圖

使用說(shuō)明：

• multi_match中的best_fields會(huì)將任何與查詢匹配的文檔作為結(jié)果返回，但是只使用最佳字段的 _score 評(píng)分作為評(píng)分結(jié)果返回

• 設(shè)置 analyzer 參數(shù)來(lái)定義查詢語(yǔ)句時(shí)對(duì)其中詞條執(zhí)行的分析過(guò)程

• KeywordAnalyzer - 不分詞，直接將輸入當(dāng)做輸出

3.4.2.3 短語(yǔ)查詢

底層實(shí)現(xiàn)原理

复制{
    "query": {
        "bool": {
            // 短語(yǔ)查詢
      "must": [{
        "multi_match": {
          "query": "searchValue",
          "fields": ["message", "exception"],
          "type": "phrase",
          "slop": 2
        }
      }]
        }
    }
}

天眼管理端對(duì)應(yīng)圖

使用說(shuō)明：

• phrase在fields中的每個(gè)字段上均執(zhí)行match_phrase查詢，并將最佳字段的 _score 作為結(jié)果返回

• 默認(rèn)使用match_phrase時(shí)會(huì)精確匹配查詢的短語(yǔ)，需要全部單詞和順序要完全一樣，標(biāo)點(diǎn)符號(hào)除外

• slop指查詢?cè)~條相隔多遠(yuǎn)時(shí)仍然能將文檔視為匹配 什么是相隔多遠(yuǎn)？意思是說(shuō)為了讓查詢和文檔匹配你需要移動(dòng)詞條多少次？以 "I like swimming and riding!" 的文檔為例，想匹配 "I like riding"，只需要將 "riding" 詞條向前移動(dòng)兩次，因此設(shè)置 slop 參數(shù)值為 2， 就可以匹配到。

3.4.2.4 前綴查詢

底層實(shí)現(xiàn)原理

复制{
  "size": 50,
  "query": {
    "bool": {
      // 前綴查詢
      "must": [{
        "multi_match": {
          "query": "searchValue",
          "fields": ["message", "exception"],
          "type": "phrase_prefix",
          "max_expansions": 2
        }
      }]
    }
  }
}

天眼管理端對(duì)應(yīng)圖

使用說(shuō)明：

• phrase_prefix在fields中的字段上均執(zhí)行match_phrase_prefix查詢，并將每個(gè)字段的分?jǐn)?shù)進(jìn)行合并

• match_phrase_prefix 和 match_phrase 用法是一樣的，區(qū)別就在于它允許對(duì)最后一個(gè)詞條前綴匹配，例如：查詢 I like sw 就能匹配到I like swimming and riding。

• max_expansions 說(shuō)的是參數(shù) max_expansions 控制著可以與前綴匹配的詞的數(shù)量，默認(rèn)值是 50。以 I like swi 查詢?yōu)槔鼤?huì)先查找第一個(gè)與前綴 swi 匹配的詞，然后依次查找搜集與之匹配的詞（按字母順序），直到?jīng)]有更多可匹配的詞或當(dāng)數(shù)量超過(guò) max_expansions 時(shí)結(jié)束。

• match_phrase_prefix 用起來(lái)非常方便，能夠?qū)崿F(xiàn)輸入即搜索的效果，但是也會(huì)出現(xiàn)問(wèn)題。假如說(shuō)查詢 I like s 并且想要匹配 I like swimming ，結(jié)果是默認(rèn)情況下它會(huì)搜索出前 50 個(gè)組合，如果前 50 個(gè)沒(méi)有 swimming ，那就不會(huì)顯示出結(jié)果。只能是用戶繼續(xù)輸入后面的字母才可能匹配出結(jié)果。

3.4.2.5 邏輯查詢

底層實(shí)現(xiàn)原理

复制{
  "query": {
    "bool": {
      // 邏輯查詢
      "must": [{
        "simple_query_string": {
          "query": "searchValue",
          "fields": ["message", "exception"]
        }
      }]
    }
  }
}

天眼管理端對(duì)應(yīng)圖：

simple_query_string查詢支持以下操作符（默認(rèn)是OR），用于解釋查詢字符串中的文本:

• +AND

• |OR

• -非

• "包裝許多標(biāo)記以表示要搜索的短語(yǔ)

• *在術(shù)語(yǔ)的末尾表示前綴查詢

• (and)表示優(yōu)先級(jí)

• ~N在一個(gè)單詞之后表示編輯距離(模糊)

• ~N在短語(yǔ)后面表示溢出量

官方使用文檔：https://www.elastic.co/guide/en/elasticsearch/reference/6.8/query-dsl-simple-query-string-query.html

使用示例解釋：

复制GET/_search
{
  "query": {
    "simple_query_string": {
      "fields": [ "content" ],
      "query": "foo bar -baz"
    }
}

這個(gè)搜索的目的是只返回包含foo或bar但不包含baz的文檔。然而，由于使用了OR的default_operator，這個(gè)搜索實(shí)際上返回了包含foo或bar的文檔以及不包含baz的文檔。要按預(yù)期返回文檔，將查詢字符串更改為foo bar +-baz。

3.5日志資源隔離

在龐大的企業(yè)級(jí)軟件生產(chǎn)環(huán)境下，業(yè)務(wù)系統(tǒng)會(huì)產(chǎn)生海量日志數(shù)據(jù)。一方面，隨著業(yè)務(wù)方的不斷增加，日志系統(tǒng)有限的資源會(huì)被耗盡，導(dǎo)致服務(wù)不穩(wěn)定甚至宕機(jī)。另一方面，不同業(yè)務(wù)的日志量級(jí)、QPS 存在差異，極端情況下不同業(yè)務(wù)方會(huì)對(duì)共享資源進(jìn)行競(jìng)爭(zhēng)，導(dǎo)致部分業(yè)務(wù)的日志查詢延時(shí)變高。這對(duì)日志系統(tǒng)的資源管理帶來(lái)了挑戰(zhàn)。

天眼平臺(tái)采用資源隔離的方式解決此問(wèn)題，來(lái)為業(yè)務(wù)提供實(shí)時(shí)、高效、安全的存儲(chǔ)與查詢服務(wù)。

資源隔離主要圍繞著日志的傳輸資源與日志的存儲(chǔ)資源進(jìn)行。業(yè)務(wù)方在接入天眼系統(tǒng)時(shí)，可以根據(jù)業(yè)務(wù)需要在平臺(tái)交互界面，進(jìn)行傳輸資源與存儲(chǔ)資源的隔離配置，這種隔離資源的配置方式避免了共享資源競(jìng)爭(zhēng)導(dǎo)致的日志延遲增加與潛在的日志丟失問(wèn)題。

具體的隔離實(shí)現(xiàn)方案如圖 3.5.1 所示，主要包括以下步驟：

1、業(yè)務(wù)方生產(chǎn)日志：如 3.2 介紹到的，業(yè)務(wù)方運(yùn)行時(shí)產(chǎn)生的日志可以通過(guò) SDK 或 minos 的方式將日志傳輸至分布式隊(duì)列 BP 中；

2、天眼平臺(tái)訂閱日志：在業(yè)務(wù)方通過(guò)天眼平臺(tái)進(jìn)行 ES、BP 資源的配置之后，配置監(jiān)聽(tīng)器會(huì)監(jiān)測(cè)到變更內(nèi)容，再根據(jù)配置的變更類型管理日志訂閱器、分發(fā)器的生命周期，包括ES 客戶端、BP 客戶端的創(chuàng)建與銷毀；

3、平臺(tái)內(nèi)部日志處理：日志訂閱器通過(guò) BP 客戶端收到業(yè)務(wù)方的日志后，首先會(huì)采用 3.3 中提到的業(yè)務(wù)方過(guò)濾規(guī)則進(jìn)行過(guò)濾攔截，再將日志轉(zhuǎn)換為事件放入綁定的內(nèi)存通道中；

4、天眼平臺(tái)分發(fā)日志：日志分發(fā)器會(huì)不斷從綁定的內(nèi)存通道中拉取日志事件，并通過(guò) ES 客戶端對(duì)日志進(jìn)行存儲(chǔ)，如果存儲(chǔ)失敗則會(huì)觸發(fā)相應(yīng) backoff 策略，例如異常行為記錄；

5、業(yè)務(wù)方日志查詢：日志存儲(chǔ)至 ES 集群之后，業(yè)務(wù)方可以通過(guò)平臺(tái)界面便捷地進(jìn)行日志查詢。

△3.5.1 天眼-資源隔離方案

可見(jiàn)在復(fù)雜的多應(yīng)用場(chǎng)景下，隔離資源機(jī)制是一種高效管理日志系統(tǒng)資源的方式。天眼日志系統(tǒng)提供了靈活的資源配置來(lái)避免資源浪費(fèi)，提供了共享資源的隔離來(lái)降低業(yè)務(wù)方日志查詢的延遲、提升日志查詢的安全性，進(jìn)而推動(dòng)業(yè)務(wù)的增長(zhǎng)和運(yùn)營(yíng)效率。

3.6日志動(dòng)態(tài)清理與存儲(chǔ)降級(jí)

隨著業(yè)務(wù)的長(zhǎng)期運(yùn)行與發(fā)展，日志量級(jí)也在不斷增加。一方面，針對(duì)近期產(chǎn)生的日志，業(yè)務(wù)方有迫切的查詢需求。針對(duì)產(chǎn)生較久的日志，迫于監(jiān)管與審計(jì)要求也有低頻率訪問(wèn)的訴求。如何在成本可控并且保證平臺(tái)穩(wěn)定的前提下，維護(hù)這些海量日志并提供查詢服務(wù)對(duì)日志系統(tǒng)而言也是一個(gè)挑戰(zhàn)。

天眼平臺(tái)通過(guò)資源清理機(jī)制和日志存儲(chǔ)降級(jí)機(jī)制來(lái)解決這個(gè)問(wèn)題。

資源清理機(jī)制主要用作 ES 集群的索引清理。隨著日志量的增加，集群的資源占用率也在增加，在極端情況下，過(guò)高的磁盤與內(nèi)存占用率會(huì)導(dǎo)致 ES 服務(wù)的性能下降，甚至服務(wù)的宕機(jī)。資源清理機(jī)制會(huì)定期查詢 ES 集群的資源占用情況，一旦集群的磁盤資源超過(guò)業(yè)務(wù)方設(shè)定的閾值，會(huì)優(yōu)先清理最舊的日志，直到資源占用率恢復(fù)正常水平。

存儲(chǔ)降級(jí)機(jī)制主要用作 ES 集群的索引備份與恢復(fù)。將日志長(zhǎng)期存儲(chǔ)在昂貴的 ES 集群中是一種資源浪費(fèi)，也為日志系統(tǒng)增加了額外的開(kāi)銷。存儲(chǔ)降級(jí)機(jī)制會(huì)定期對(duì) ES 集群進(jìn)行快照，然后將快照轉(zhuǎn)存到更低開(kāi)銷的大對(duì)象存儲(chǔ)服務(wù)（BOS）中，轉(zhuǎn)存之后的快照有 180 天的有效期以應(yīng)對(duì)審查與監(jiān)管。當(dāng)業(yè)務(wù)方需要查詢降級(jí)存儲(chǔ)后的日志時(shí)，只需要從大對(duì)象存儲(chǔ)服務(wù)中拉取快照，再恢復(fù)到 ES 集群以提供查詢能力。

具體的資源清理機(jī)制與存儲(chǔ)降級(jí)機(jī)制如圖 3.6.1 所示，主要包括以下步驟：

1、集群狀態(tài)查詢：資源清理任務(wù)通過(guò)定期查詢集群信息的方式監(jiān)測(cè)資源占用率，當(dāng)資源占用率超過(guò)業(yè)務(wù)方設(shè)定的閾值時(shí)會(huì)觸發(fā)資源清理；

2、集群索引清理：通過(guò)查詢索引信息并進(jìn)行資源占用情況計(jì)算，再根據(jù)時(shí)間倒序刪除依次最舊的索引，直到滿足設(shè)定的閾值；

3、集群索引備份：存儲(chǔ)降級(jí)任務(wù)會(huì)定期對(duì)集群進(jìn)行快照請(qǐng)求，然后將快照文件轉(zhuǎn)存到低開(kāi)銷的大文件存儲(chǔ)服務(wù)中完成存儲(chǔ)的降級(jí)；

4、集群索引恢復(fù)：在業(yè)務(wù)方需要查詢降級(jí)存儲(chǔ)后的日志時(shí)，服務(wù)會(huì)將快照文件從大文件存儲(chǔ)服務(wù)中拉取目標(biāo)快照，再通過(guò)快照恢復(fù)請(qǐng)求對(duì)快照進(jìn)行恢復(fù)，以提供業(yè)務(wù)方查詢。

△3.6.1天眼-日志動(dòng)態(tài)清理與存儲(chǔ)降級(jí)方案

可見(jiàn)在面對(duì)海量日志的存儲(chǔ)與查詢，通過(guò)資源清理機(jī)制可以防止集群資源過(guò)載同時(shí)提升日志檢索效率，通過(guò)存儲(chǔ)降級(jí)機(jī)制可以提升資源利用率同時(shí)確保審計(jì)的合規(guī)性，從而在業(yè)務(wù)高速增長(zhǎng)使用的同時(shí)保證日志系統(tǒng)的健壯性。

3.7最佳實(shí)踐

基于前面提到的天眼平臺(tái)設(shè)計(jì)思想，結(jié)合其中部分能力展開(kāi)介紹天眼在運(yùn)維管理方面的實(shí)踐。

3.7.1 天眼平臺(tái)化實(shí)踐

天眼通過(guò)抽象產(chǎn)品線概念，針對(duì)不同的接入方提供產(chǎn)品線接入流程，為業(yè)務(wù)生成產(chǎn)品線唯一標(biāo)識(shí)并與業(yè)務(wù)日志綁定；產(chǎn)品線相關(guān)流程如下：

1、產(chǎn)品線日志源申請(qǐng)流程

支持產(chǎn)品線選擇日志采集方式包含SDK、Minos兩種方式，選擇minos接入時(shí)，bns與日志存儲(chǔ)路徑必選，方便系統(tǒng)根據(jù)配置自動(dòng)執(zhí)行日志采集。

同時(shí)在Bigpipe資源與ES資源方面，平臺(tái)支持多種資源隔離獨(dú)立使用，不同的產(chǎn)品線可以配置各自獨(dú)有的傳輸和存儲(chǔ)資源，保障數(shù)據(jù)安全性和穩(wěn)定性。

2、日志源申請(qǐng)后，需要管理員審核后才能進(jìn)行使用（申請(qǐng)后無(wú)需操作，僅需等待管理員通過(guò)審核后，進(jìn)行SDK接入）

access_key的值查看權(quán)限：僅日志源綁定產(chǎn)品線的經(jīng)理及接口人可查，access_key將作為產(chǎn)品線接入天眼鑒權(quán)的關(guān)鍵依據(jù)。

3.7.2 日志過(guò)濾實(shí)踐

產(chǎn)品線接口人可以基于自身產(chǎn)品線新增日志過(guò)濾規(guī)則配置，配置的規(guī)則將自動(dòng)生效于日志采集傳輸流程中：

選擇消息日志后將彈出詳細(xì)過(guò)濾規(guī)則配置菜單，當(dāng)前系統(tǒng)共支持三種過(guò)濾規(guī)則，分別是按日志內(nèi)容、按日志名稱、按日志內(nèi)容和日志名稱組合三種方式：

過(guò)濾規(guī)則配置完成后可以在列表管理每條規(guī)則：

GEEK TALK

04

思考與總結(jié)

隨著分布式業(yè)務(wù)系統(tǒng)的日益復(fù)雜，為業(yè)務(wù)方提供高效、低延遲、高性能的日志服務(wù)系統(tǒng)顯得尤為重要。本文介紹了天眼平臺(tái)是如何進(jìn)行日志采集、傳輸并支持檢索的，此外還通過(guò)支持日志的資源隔離，解耦各業(yè)務(wù)方的日志通路和存儲(chǔ)，從而實(shí)現(xiàn)業(yè)務(wù)日志的高效查詢和業(yè)務(wù)問(wèn)題的高效定位。此外通過(guò)對(duì)日志進(jìn)行監(jiān)控可以主動(dòng)發(fā)現(xiàn)系統(tǒng)問(wèn)題，并通過(guò)告警日志的trace_id快速定位問(wèn)題，從而提升問(wèn)題發(fā)現(xiàn)導(dǎo)解決的效率。

隨著大模型技術(shù)的不斷發(fā)展，我們也通過(guò)大模型進(jìn)行一些業(yè)務(wù)迭代，進(jìn)而提升業(yè)務(wù)檢索和排查效率。例如：我們可以直接詢問(wèn)，今天有幾筆異常核銷訂單；訂單7539661906核銷異常原因是什么等等。通過(guò)與大模型的結(jié)合，我們縮短了業(yè)務(wù)方問(wèn)題排查定位的路徑，提升了業(yè)務(wù)運(yùn)維效率和交互體驗(yàn)。后續(xù)我們也將不斷與大模型進(jìn)行深入打磨和持續(xù)深耕，持續(xù)沉淀和輸出相關(guān)的通用方案。