如何設計一個高效的分佈式日誌服務平臺
本文首先介紹了分佈式服務下日誌服務建設的挑戰,然後介紹了下業內 ELK 的通用解決方案及與天眼日誌服務的差異性,接下來詳細介紹了天眼日誌服務平臺的整體架構,如何做採集、傳輸、檢索、隔離、清理等機制的,最後對日誌服務與大模型進行結合,不斷探索效能的提升。
分佈式服務下日誌服務挑戰
分佈式服務系統中,每個服務有大量的服務器,而每臺服務器每天都會產生大量的日誌。我們面臨的主要挑戰有:
1、日誌量巨大:在分佈式服務環境中,日誌分散在多個節點上,每個服務都會產生大量的日誌,因此需要一種可靠的機制來收集和聚合日誌數據。
2、多樣化的日誌格式:不同的服務可能使用不同的日誌格式,例如日誌輸出的字段、順序和級別等,這會增加日誌服務的開發和維護難度。
3、日誌服務的可擴展性和可靠性:隨着分佈式服務數量的增加和規模的擴大,日誌服務需要能夠進行橫向擴展和縱向擴展,以保證其性能和可靠性。
所以我們該如何提供分佈式系統下高效、低延遲、高性能的日誌服務呢?
業內 ELK 通用解決方案
2.1 Elastic Stack 發展歷程
2.2 Elastic Stack 組件架構圖
2.2.1 Ingest 組件
Ingest 是獲取日誌數據的相關組件。
shippers 和 sources 是收集的原始日誌組件,承接着原始日誌(log 文件日誌、系統日誌、網絡日誌等)採集和發送,其中Elastic Agent、APM、Beats 收集和發送日誌、指標和性能數據。
queues 和 processors 是原始日誌數據的處理管道,使用這些組件可以定製化的對原始日誌數據進行處理和轉換,在存儲之前可以模板化數據格式,方便 elasticsearch 更好的承接存儲和檢索功能。
Elastic Agent 是一種使用單一、統一的方式,爲主機添加對日誌、指標和其他類型數據的監控。它還可以保護主機免受安全威脅、從操作系統查詢數據、從遠程服務或硬件轉發數據等等。每個代理都有一個策略,可以向其中添加新數據源、安全保護等的集成。
Fleet 能夠集中管理 Elastic Agent 及其策略。使用 Fleet 可以監控所有 Elastic Agent 的狀態、管理 agent 策略以及升級 Elastic Agent 二進制文件或集成。
Elastic APM 是一個基於 Elastic Stack 構建的應用程序性能監控系統。通過收集有關傳入請求、數據庫查詢、緩存調用、外部 HTTP 請求等響應時間的詳細性能信息,實時監控軟件服務和應用程序。
**Beats **是在服務器上作爲代理安裝的數據發送器,用於將操作數據發送到 Elasticsearch。Beats 可用於許多標準的可觀察性數據場景,包括審計數據、日誌文件和日誌、雲數據、可用性、指標、網絡流量和 Windows 事件日誌。
Elasticsearch Ingest Pipelines 可以在將數據存儲到 Elasticsearch 之前對數據執行常見的轉換。將一個或多個 “處理器” 任務配置爲按順序運行,在將文檔存儲到 Elasticsearch 之前對文檔進行特定更改。
Logstash 是一個具有實時數據收集引擎。它可以動態地統一來自不同來源的數據,並將數據規範化到目的地。Logstash 支持豐富的輸入、過濾器和輸出插件。
2.2.2 Store 組件
Store 是承接日誌存儲和檢索組件,這裏是使用的 Elasticsearch 承接該功能。
Elasticsearch 是 Elastic Stack 核心的分佈式搜索和分析引擎。它爲所有類型的數據提供近乎實時的搜索和分析。無論結構化或非結構化文本、數字數據還是地理空間數據,Elasticsearch 都可以以支持快速搜索的方式高效地存儲和索引這些數據。Elasticsearch 提供了一個 REST API,使您能夠在 Elasticsearch 中存儲和檢索數據。REST API 還提供對 Elasticsearch 的搜索和分析功能的訪問。
2.2.3 Consumer 組件
Consumer 是消費 store 存儲數據的組件,這裏組要有可視化的 kibana 和 Elasticsearch Client。
Kibana 是利用 Elasticsearch 數據和管理 Elastic Stack 的工具。使用它可以分析和可視化存儲在 Elasticsearch 中的數據。
Elasticsearch Client 提供了一種方便的機制來管理來自語言(如 Java、Ruby、Go、Python 等)的 Elasticsearch 的 API 請求和響應。
**2.3 **天眼對比 ELK 差異
1、接入便捷性
ELK:方案依賴完整流程部署準備,操作配置複雜,接入跑通耗時長。
天眼:只需簡單三步配置,頁面申請產品線接入、頁面獲取產品線 appkey、依賴管理中增加天眼 SDK 依賴並配置 appkey 到系統配置中。
2、資源定製化
ELK:資源修改、配置每次都需要重啓才能生效,不支持多資源配置化選擇。
天眼:產品線接入時可以選擇使用業務自身傳輸、存儲資源或自動使用系統默認資源,資源切換隻需頁面簡單配置並即時自動生效。
3、擴容成本與效率
ELK:方案僅支持單個業務產品線,其他業務產線接入需重新部署一套,資源無法共享,擴容需手動增加相應實例等。
天眼:資源集中管理,產品線動態接入,資源動態配置即時生效,大部分資源自動共享同時又支持資源獨享配置;擴容直接通過平臺頁面化操作,簡單便捷。
4、日誌動態清理
ELK:依賴人工發現、手動清理和處理資源佔用。
天眼:自動化監測 ES 集羣概況,自動計算資源佔用情況,當達到監控閾值時自動執行時間最早的索引資源清理。
5、自適應存儲
ELK:傳統方案受限於存儲資源空間和成本,存儲成本高、可保存的數據量有限。
天眼:實現了日誌轉存文件及從文件自動化恢復,日誌存儲成本低,存儲週期長。
天眼通過自建分佈式日誌平臺,有效的解決 ELK 日誌方案下存在的缺陷問題;當前天眼日誌量級:日均 10TB 日誌量,併發 QPS:10w+,接入產品線數:1000+。
天眼
3.1 天眼系統架構
上圖爲完整的天眼核心系統架構,概述如下:
1、天眼日誌採集支持 SDK 及監聽日誌文件兩種方式,其中 SDK 主要通過實現日誌插件接口獲得完整日誌結構信息,並傳輸至天眼日誌傳輸管道;獲得的日誌信息 LogEvent 結構完整,同時基於 LogEvent 增加了產品線標識等字段,爲日誌隔離和檢索提供核心依據;監聽日誌文件方式實現業務方 0 開發成本接入,僅需簡單配置即可實現日誌接入,支持產品線字段標識的同時,日誌消息體解析也實現了正則匹配規則自動化匹配。
2、天眼日誌傳輸採用高併發性能隊列 Disruptor,並且二次採用高性能隊列 Bigpipe 實現日誌傳輸異步解耦,解決了傳統隊列因加鎖和僞共享等問題帶來的性能缺陷;同時在傳輸過程中提供日誌過濾和日誌告警規則配置化自動化執行。
3、天眼日誌存儲通過輪詢消費 Bigpipe 日誌消息,最終寫入 ES 的 BulkProcessor,由 ES 自動調度併發寫入 ES 進行存儲;在日誌傳輸和存儲過程中實現了日誌傳輸資源與存儲資源隔離,根據產品線配置自動化選擇傳輸與存儲資源。
4、天眼自動化清理實現在存儲資源有限的情況下自適應存儲,自動化轉存與恢復實現了在 ES 資源有限情況下低成本長時間存儲解決方案。
3.2 天眼日誌採集
日誌平臺核心目的是採集分佈式場景下的業務日誌進行集中處理和存儲,採集方式主要包含如下:
1、藉助常見日誌框架提供的插件接口,在生成日誌事件的同時執行其他自定義處理邏輯,例如 log4j2 提供的 Appender 等。
2、通過各種攔截器插件在固定位置攔截並主動生成和打印業務日誌,將這類日誌信息主動發送至日誌消息傳輸隊列中供消費使用,常見的如 http、rpc 調用鏈請求與返回信息打印,以及 mybatis 執行過程 SQL 明細打印等。
3、監聽日誌文件寫入,從文件系統上的一個文件進行讀取,工作原理有些類似 UNIX 的 tail -0F 命令,當日志寫入本地文件時捕獲寫入行內容並進行其他自定義處理,例如將日誌行信息發送至消息隊列供下游使用。
4、syslog:監聽來自 514 端口的 syslog 消息,並將其轉換爲 RFC3164 格式。
更多可用的日誌採集實現方式,可以參考:Input Plugins
下面以天眼日誌採集爲例詳細介紹日誌採集實現過程:
天眼平臺供支持兩類日誌採集實現方式,一類是 SDK、一類是 minos(百度自研的新一代的流式日誌傳輸系統)。
3.2.1 天眼 SDK 日誌採集
天眼 SDK 日誌採集方式爲通過 Java SDK 方式向業務方提供日誌採集組件實現,達到自動收集業務日誌並自動傳輸的目的;核心分爲 message 日誌流和 trace 日誌流兩大塊:
1、message 日誌流主要通過日誌框架提供的 Appender 接口實現,共支持 log4j、logback、log4j2 等主流日誌框架。
以 logback 爲例,通過繼承並實現 AppenderBase 抽象類提供的 append 方法,在 logback 日誌框架生成 LogEvent 後獲取日誌事件對象並提交給 LogbackTask 執行任務處理,在 LogbackTask 中可以對日誌事件內容進行進一步包裝完善,並執行一些日誌過濾策略等,最終得到的日誌事件信息將直接發送至日誌傳輸隊列進行傳輸處理;
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 日誌流主要通過各類攔截器攔截業務請求調用鏈及業務執行鏈路,通過獲取調用鏈詳細信息主動生成調用鏈日誌事件,併發送至日誌傳輸隊列進行消費使用,常見的調用鏈日誌包含 http 與 rpc 請求及響應日誌、mybatis 組件 SQL 執行日誌等;
下圖爲 trace 日誌流實現類圖,描述了 trace 日誌流抽象實現過程:
以 mybatis 爲例,trace 日誌流核心攔截器實現類爲 IlogMybatisPlugin,實現 ibatis Interceptor 接口
核心代碼:
TraceFactory.getSqltracer().end(returnObj, className, methodName, realParams, dbType, sqlType, sql, sqlUrl)
在 end 方法中將 SQL 執行過程中產生的各類信息通過參數傳入,並組裝成 SqlLogNode(繼承至通用日誌節點 LogNode)發佈到隊列。
使用時需要業務方手動將插件註冊到 SqlSessionFactory,以生效插件:
sqlSessionFactory.getConfiguration().addInterceptor(new IlogMybatisPlugin());
3.2.2 天眼 minos 日誌採集
minos 日誌採集主要是藉助百度自研的 minos 數據傳輸平臺,實現機器實例上的日誌文件信息實時傳輸至目的地,常見傳輸目的地有 Bigpipe、HDFS、AFS 等;目前天眼主要是通過將 minos 採集到的日誌發送到 Bigpipe 實現,並由後續的 Bigpipe 消費者統一消費和處理;同時針對日誌來源爲 minos 的日誌在消費過程中增加了日誌解析與轉換策略,確保採集到的日誌格式和 SDK 方式生成的日誌格式基本一致;
在日誌採集過程中,天眼如何解決平臺化標識:
1、在產品線接入天眼時,天眼給對應產品線生成產品線唯一標識;
2、SDK 接入方式下,產品線服務端通過系統變量配置產品線標識,SDK 在運行過程中會自動讀取該變量值並設置到 LogNode 屬性中;
3、LogNode 作爲日誌完整信息對象,在傳輸過程中最終存儲到 ES,同時 ES 在建索引時爲產品線唯一標識分配字段屬性;
4、產品線唯一標識貫穿整個分佈式日誌鏈路並和日誌內容強綁定。
3.3 **高併發數據傳輸和存儲 **
在 ELK 方案中,生成的日誌信息直接發送給 logstash 進行傳輸,並寫入到 es,整個過程基本爲同步操作,併發性能完全依賴 logstash 服務端及 ES 服務端性能;
天眼則是通過異步方式解耦日誌傳輸過程,以及在日誌入口處引入 Disruptor 高性能隊列,併發性能直奔千萬級別;同時在 Disruptor 本地隊列之後再設計 Bigpipe 離線隊列,用來長效存儲和傳輸日誌消息;以及引入兜底文件隊列 BigQueue 解決方案,處理在極少數異常情況下寫本地隊列或離線隊列失敗時的兜底保障,如下圖所示:
Disruptor 是一個高性能的用於線程間消息處理的開源框架。Disruptor 內部使用了 RingBuffer,它是 Disruptor 的核心的數據結構。
Disruptor 隊列設計特性:
固定大小數組:由於數組佔用一塊連續的內存空間,可以利用 CPU 的緩存策略,預先讀取數組元素附近的元素;
數組預填充:避免了垃圾回收代來的系統開銷;
緩存行填充:解決僞共享問題;
位操作:加快系統的計算速度;
使用數組 + 系列號的這種方法最大限度的提高了速度。因爲如果使用傳統的隊列的話,在多線程環境下對隊列頭和隊列尾的鎖競爭是一種很大的系統開銷。
Bigpipe 是一個分佈式中間件系統,支持 Topic 和 Queue 模型,不僅可以完成傳統消息隊列可以實現的諸如消息、命令的實時傳輸,也可以用於日誌數據的實時傳輸。Bigpipe 能夠幫助模塊間的通信實現解耦,並能保證消息的不丟不重;
BigQueue 是基於內存映射文件的大型、快速和持久隊列;
1、快 : 接近直接內存訪問的速度,enqueue 和 dequeue 都接近於 O(1) 內存訪問。
2、大:隊列的總大小僅受可用磁盤空間的限制。
3、持久:隊列中的所有數據都持久保存在磁盤上,並且是抗崩潰的。
4、可靠:即使您的進程崩潰,操作系統也將負責保留生成的消息。
5、實時:生產者線程產生的消息將立即對消費者線程可見。
6、內存高效:自動分頁和交換算法,只有最近訪問的數據保留在內存中。
7、線程安全:多個線程可以同時入隊和出隊而不會損壞數據。
8、簡單輕量:目前源文件個數 12 個,庫 jar 不到 30K。
在採集到日誌事件後,進入傳輸過程中,天眼 SDK 中支持日誌過濾規則策略匹配,針對命中策略的日誌進行過濾,實現過程如下圖所示:
未命中過濾規則的日誌消息事件將繼續發送至 Bigpipe,至此日誌生產階段即完成,後續通過天眼消費者模塊訂閱 Bigpipe 消費並批量推送至 ES。
**3.4 ****天眼日誌檢索 **
基於天眼鏈路最終存儲到 ES 的日誌數據,天眼平臺提供了可視化日誌檢索頁面,能夠根據產品線唯一標識(日誌源 ID)指定業務範圍進行檢索,同時支持各種檢索條件,效果如下圖所示:
3.4.1 檢索條件詳解
日誌源 id 列表:獲取日誌源對應的日誌
檢索時間範圍:日誌的時間範圍
排序類型:日誌的存入時間 / 日誌存入的算分
查詢數量:查詢出多少數量的日誌
日誌級別:查詢什麼級別的日誌,如:DEBUG / INFO / WARN / ERROR
算分條件:支持五種算分查詢,文本查詢、等值查詢、短語查詢、前綴查詢、邏輯查詢;五選一
過濾條件:只顯示符合過濾條件信息的日誌
3.4.2 算分條件檢索詳細說明
支持五種算分查詢:文本查詢、等值查詢、短語查詢、前綴查詢、邏輯查詢。五選一
搜索內容字段: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"
}
說明:
-
"analyzer": "my_ik_max_word":底層使用 ik_max_word,message 和 exception 信息在存儲是會以最細粒度拆詞進行存儲;
-
"search_analyzer": "my_ik_smart":底層使用 ik_smart,在查詢內容是,會將查詢內容以最粗粒度拆分進行查詢。
3.4.2.1 文本查詢
底層實現原理
{
"query": {
"bool": {
"must": [{
"multi_match": {
"query": "searchValue",
"fields": ["message", "exception"],
"type": "best_fields"
}
}]
}
}
}
天眼管理端對應圖
使用說明:
- multi_match 中的 best_fields 會將任何與查詢匹配的文檔作爲結果返回,但是隻使用最佳字段的 _score 評分作爲評分結果返回
3.4.2.2 等值查詢
底層實現原理
{
"query": {
"bool": {
"must": [{
"multi_match": {
"query": "searchValue",
"fields": ["message", "exception"],
"type": "best_fields",
"analyzer": "keyword"
}
}]
}
}
}
天眼管理端對應圖
使用說明:
-
multi_match 中的 best_fields 會將任何與查詢匹配的文檔作爲結果返回,但是隻使用最佳字段的 _score 評分作爲評分結果返回
-
設置 analyzer 參數來定義查詢語句時對其中詞條執行的分析過程
-
Keyword Analyzer - 不分詞,直接將輸入當做輸出
3.4.2.3 短語查詢
底層實現原理
{
"query": {
"bool": {
// 短語查詢
"must": [{
"multi_match": {
"query": "searchValue",
"fields": ["message", "exception"],
"type": "phrase",
"slop": 2
}
}]
}
}
}
天眼管理端對應圖
使用說明:
-
phrase 在 fields 中的每個字段上均執行 match_phrase 查詢,並將最佳字段的 _score 作爲結果返回
-
默認使用 match_phrase 時會精確匹配查詢的短語,需要全部單詞和順序要完全一樣,標點符號除外
-
slop 指查詢詞條相隔多遠時仍然能將文檔視爲匹配 什麼是相隔多遠? 意思是說爲了讓查詢和文檔匹配你需要移動詞條多少次?以 "I like swimming and riding!" 的文檔爲例,想匹配 "I like riding",只需要將 "riding" 詞條向前移動兩次,因此設置 slop 參數值爲 2, 就可以匹配到。
3.4.2.4 前綴查詢
底層實現原理
{
"size": 50,
"query": {
"bool": {
// 前綴查詢
"must": [{
"multi_match": {
"query": "searchValue",
"fields": ["message", "exception"],
"type": "phrase_prefix",
"max_expansions": 2
}
}]
}
}
}
天眼管理端對應圖
使用說明:
-
phrase_prefix 在 fields 中的字段上均執行 match_phrase_prefix 查詢,並將每個字段的分數進行合併
-
match_phrase_prefix 和 match_phrase 用法是一樣的,區別就在於它允許對最後一個詞條前綴匹配,例如:查詢 I like sw 就能匹配到 I like swimming and riding。
-
max_expansions 說的是參數 max_expansions 控制着可以與前綴匹配的詞的數量,默認值是 50。以 I like swi 查詢爲例,它會先查找第一個與前綴 swi 匹配的詞,然後依次查找蒐集與之匹配的詞(按字母順序),直到沒有更多可匹配的詞或當數量超過 max_expansions 時結束。
-
match_phrase_prefix 用起來非常方便,能夠實現輸入即搜索的效果,但是也會出現問題。 假如說查詢 I like s 並且想要匹配 I like swimming ,結果是默認情況下它會搜索出前 50 個組合,如果前 50 個沒有 swimming ,那就不會顯示出結果。只能是用戶繼續輸入後面的字母纔可能匹配出結果。
3.4.2.5 邏輯查詢
底層實現原理
{
"query": {
"bool": {
// 邏輯查詢
"must": [{
"simple_query_string": {
"query": "searchValue",
"fields": ["message", "exception"]
}
}]
}
}
}
天眼管理端對應圖:
simple_query_string 查詢支持以下操作符(默認是 OR),用於解釋查詢字符串中的文本:
-
+ AND
-
| OR
-
- 非
-
" 包裝許多標記以表示要搜索的短語
-
* 在術語的末尾表示前綴查詢
-
(and) 表示優先級
-
~N 在一個單詞之後表示編輯距離 (模糊)
-
~N 在短語後面表示溢出量
官方使用文檔: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"
}
}
這個搜索的目的是隻返回包含 foo 或 bar 但不包含 baz 的文檔。然而,由於使用了 OR 的 default_operator,這個搜索實際上返回了包含 foo 或 bar 的文檔以及不包含 baz 的文檔。要按預期返回文檔,將查詢字符串更改爲 foo bar +-baz。
**3.5 **日誌資源隔離
在龐大的企業級軟件生產環境下,業務系統會產生海量日誌數據。一方面,隨着業務方的不斷增加,日誌系統有限的資源會被耗盡,導致服務不穩定甚至宕機。另一方面,不同業務的日誌量級、QPS 存在差異,極端情況下不同業務方會對共享資源進行競爭,導致部分業務的日誌查詢延時變高。這對日誌系統的資源管理帶來了挑戰。
天眼平臺採用資源隔離的方式解決此問題,來爲業務提供實時、高效、安全的存儲與查詢服務。
資源隔離主要圍繞着日誌的傳輸資源與日誌的存儲資源進行。業務方在接入天眼系統時,可以根據業務需要在平臺交互界面,進行傳輸資源與存儲資源的隔離配置,這種隔離資源的配置方式避免了共享資源競爭導致的日誌延遲增加與潛在的日誌丟失問題。
具體的隔離實現方案如圖 3.5.1 所示,主要包括以下步驟:
1、業務方生產日誌:如 3.2 介紹到的,業務方運行時產生的日誌可以通過 SDK 或 minos 的方式將日誌傳輸至分佈式隊列 BP 中;
2、天眼平臺訂閱日誌:在業務方通過天眼平臺進行 ES、BP 資源的配置之後,配置監聽器會監測到變更內容,再根據配置的變更類型管理日誌訂閱器、分發器的生命週期,包括 ES 客戶端、BP 客戶端的創建與銷燬;
3、平臺內部日誌處理:日誌訂閱器通過 BP 客戶端收到業務方的日誌後,首先會採用 3.3 中提到的業務方過濾規則進行過濾攔截,再將日誌轉換爲事件放入綁定的內存通道中;
4、天眼平臺分發日誌:日誌分發器會不斷從綁定的內存通道中拉取日誌事件,並通過 ES 客戶端對日誌進行存儲,如果存儲失敗則會觸發相應 backoff 策略,例如異常行爲記錄;
5、業務方日誌查詢:日誌存儲至 ES 集羣之後,業務方可以通過平臺界面便捷地進行日誌查詢。
△________3.5.1 天眼 - 資源隔離方案
可見在複雜的多應用場景下,隔離資源機制是一種高效管理日誌系統資源的方式。天眼日誌系統提供了靈活的資源配置來避免資源浪費,提供了共享資源的隔離來降低業務方日誌查詢的延遲、提升日誌查詢的安全性,進而推動業務的增長和運營效率。
**3.6 **日誌動態清理與存儲降級
隨着業務的長期運行與發展,日誌量級也在不斷增加。一方面,針對近期產生的日誌,業務方有迫切的查詢需求。針對產生較久的日誌,迫於監管與審計要求也有低頻率訪問的訴求。如何在成本可控並且保證平臺穩定的前提下,維護這些海量日誌並提供查詢服務對日誌系統而言也是一個挑戰。
天眼平臺通過資源清理機制和日誌存儲降級機制來解決這個問題。
資源清理機制主要用作 ES 集羣的索引清理。隨着日誌量的增加,集羣的資源佔用率也在增加,在極端情況下,過高的磁盤與內存佔用率會導致 ES 服務的性能下降,甚至服務的宕機。資源清理機制會定期查詢 ES 集羣的資源佔用情況,一旦集羣的磁盤資源超過業務方設定的閾值,會優先清理最舊的日誌,直到資源佔用率恢復正常水平。
存儲降級機制主要用作 ES 集羣的索引備份與恢復。將日誌長期存儲在昂貴的 ES 集羣中是一種資源浪費,也爲日誌系統增加了額外的開銷。存儲降級機制會定期對 ES 集羣進行快照,然後將快照轉存到更低開銷的大對象存儲服務(BOS)中,轉存之後的快照有 180 天的有效期以應對審查與監管。當業務方需要查詢降級存儲後的日誌時,只需要從大對象存儲服務中拉取快照,再恢復到 ES 集羣以提供查詢能力。
具體的資源清理機制與存儲降級機制如圖 3.6.1 所示,主要包括以下步驟:
1、集羣狀態查詢:資源清理任務通過定期查詢集羣信息的方式監測資源佔用率,當資源佔用率超過業務方設定的閾值時會觸發資源清理;
2、集羣索引清理:通過查詢索引信息並進行資源佔用情況計算,再根據時間倒序刪除依次最舊的索引,直到滿足設定的閾值;
3、集羣索引備份:存儲降級任務會定期對集羣進行快照請求,然後將快照文件轉存到低開銷的大文件存儲服務中完成存儲的降級;
4、集羣索引恢復:在業務方需要查詢降級存儲後的日誌時,服務會將快照文件從大文件存儲服務中拉取目標快照,再通過快照恢復請求對快照進行恢復,以提供業務方查詢。
△________3.6.1 天眼 - 日誌動態清理與存儲降級方案
可見在面對海量日誌的存儲與查詢,通過資源清理機制可以防止集羣資源過載同時提升日誌檢索效率,通過存儲降級機制可以提升資源利用率同時確保審計的合規性,從而在業務高速增長使用的同時保證日誌系統的健壯性。
3.7 最佳實踐
基於前面提到的天眼平臺設計思想,結合其中部分能力展開介紹天眼在運維管理方面的實踐。
3.7.1 天眼平臺化實踐
天眼通過抽象產品線概念,針對不同的接入方提供產品線接入流程,爲業務生成產品線唯一標識並與業務日誌綁定;產品線相關流程如下:
1、產品線日誌源申請流程
支持產品線選擇日誌採集方式包含 SDK、Minos 兩種方式,選擇 minos 接入時,bns 與日誌存儲路徑必選,方便系統根據配置自動執行日誌採集。
同時在 Bigpipe 資源與 ES 資源方面,平臺支持多種資源隔離獨立使用,不同的產品線可以配置各自獨有的傳輸和存儲資源,保障數據安全性和穩定性。
2、日誌源申請後,需要管理員審覈後才能進行使用(申請後無需操作,僅需等待管理員通過審覈後,進行 SDK 接入)
access_key 的值查看權限:僅日誌源綁定產品線的經理及接口人可查,access_key 將作爲產品線接入天眼鑑權的關鍵依據。
3.7.2 日誌過濾實踐
產品線接口人可以基於自身產品線新增日誌過濾規則配置,配置的規則將自動生效於日誌採集傳輸流程中:
選擇消息日誌後將彈出詳細過濾規則配置菜單,當前系統共支持三種過濾規則,分別是按日誌內容、按日誌名稱、按日誌內容和日誌名稱組合三種方式:
過濾規則配置完成後可以在列表管理每條規則:
思考與總結
隨着分佈式業務系統的日益複雜,爲業務方提供高效、低延遲、高性能的日誌服務系統顯得尤爲重要。本文介紹了天眼平臺是如何進行日誌採集、傳輸並支持檢索的,此外還通過支持日誌的資源隔離,解耦各業務方的日誌通路和存儲,從而實現業務日誌的高效查詢和業務問題的高效定位。此外通過對日誌進行監控可以主動發現系統問題,並通過告警日誌的 trace_id 快速定位問題,從而提升問題發現導解決的效率。
隨着大模型技術的不斷髮展,我們也通過大模型進行一些業務迭代,進而提升業務檢索和排查效率。例如:我們可以直接詢問,今天有幾筆異常覈銷訂單;訂單 7539661906 覈銷異常原因是什麼等等。通過與大模型的結合,我們縮短了業務方問題排查定位的路徑,提升了業務運維效率和交互體驗。後續我們也將不斷與大模型進行深入打磨和持續深耕,持續沉澱和輸出相關的通用方案。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/wQIjrwl2JsPQspFpTV6niw