雲原生環境下的日誌採集、儲存、分析實踐

談到日誌系統，首先要從日誌說起，日誌在 IT 系統裡無處不在，也是 IT系統大資料的關鍵來源。日誌的種類和樣式非常多，以線上教育系統為例，日誌包括客戶端日誌、服務端日誌。服務端日誌又包括業務的執行/運維日誌以及業務使用的雲產品產生的日誌。要管理諸多型別的日誌，就需要一套統一的日誌系統，對日誌進行採集、加工、儲存、查詢、分析、視覺化、告警以及消費投遞，將日誌的生命週期進行閉環。

Kubernetes 下日誌採集的開源自建方案

開源自建

火山引擎早期為了快速上線業務，各團隊基於開源專案搭建了自己的日誌系統，以滿足基本的日誌查詢需求，例如使用典型的開源日誌平臺 Filebeat+Logstash+ES+Kibana 的方案。但是在使用過程中，我們發現了開源日誌系統的不足：

各業務模組自己搭建日誌系統，造成重複建設。

以 ES 為中心的日誌架構可以利用 ES 查詢便利的優勢，但是資源開銷大、成本高。而且 ES 與 Kibana 在介面上強繫結，不利於功能擴充套件。

開源方案一般採用單機 yaml 做採集配置，當節點數很多的時候，配置非常繁瑣。

開源系統的採集配置難以管理，資料來源也比較單一。

Kubernetes 下的日誌採集

Kubernetes 下如何採集日誌呢?官方推薦了四種日誌採集方案：

DaemonSet：在每臺宿主機上搭建一個 DaemonSet 容器來部署 Agent。業務容器將容器標準輸出儲存到宿主機上的檔案，Agent 採集對應宿主機上的檔案。

Streaming Sidecar：有一些業務系統的日誌不是標準輸出，而是檔案輸出。Streaming Sidecar 的方式可以把這些檔案輸出透過 Sidecar 容器轉換成容器的標準輸出，然後採集。

Sidecar Logging Agent：業務 Pod 內單獨部署 Agent 的 Sidecar 容器。這種方式的資源隔離性強。

API/SDK：直接在容器內使用 API 或 SDK 介面將日誌採集到後端。

以上前三種採集方案都只支援採集容器的標準輸出，第四種方案需要改造業務程式碼，這幾種方式對採集容器檔案都不友好。但使用者對於日誌檔案有分類的需求，標準輸出將所有日誌混在一起，不利於使用者進行分類。如果使用者要把所有日誌都轉到標準輸出上，還需要開發或者配置，難以推廣。因此 Kubernetes 官方推薦的方案無法完全滿足使用者需求，給我們的實際使用帶來了很多不便。

自建日誌採集系統的困境與挑戰

雲原生場景下日誌種類多、數量多、動態非永久，開源系統在採集雲原生日誌時面臨諸多困難，主要包括以下問題：

一、採集難

配置複雜：系統規模越來越大，節點數越來越多，每個節點的配置都不一樣，手工配置很容易出錯，系統的變更變得非常困難。

需求不滿足：開源系統無法完全滿足實際場景的使用者需求，例如不具備多行日誌採集、完整正則匹配、過濾、時間解析等功能，容器檔案的採集也比較困難。

運維難度高：大規模場景下大量 Agent 的升級是個挑戰，系統無法實時監控 Agent 的狀態，當Agent 狀態異常時也沒有故障告警。

二、產品化能力不足

可用性低：因為缺少流控，突發的業務容易使後端系統過載，業務之間容易相互影響。

資源使用效率低：如果配置的資源是固定的，在突發場景下容易造成效能不足的問題;但如果配置的資源過多，普通場景下資源利用率就會很低;不同的元件配置不均衡還會導致效能瓶頸浪費資源。ES 的原始資料和索引使用相同的資源配置，也會導致高成本。

功能不足：比如 ES 的投遞和消費能力弱、分析能力固化、沒有告警能力、視覺化能力有限。

火山引擎統一日誌平臺 TLS

在遇到這些問題以後，我們研發了一套統一的日誌管理平臺——火山引擎日誌服務(Tinder Log Service，簡稱為 TLS)。TLS 的整體架構如下：

面對各種日誌源，TLS 透過自研的 LogCollector/SDK/API，可支援專有協議、 OpenTelemetry 和 Kafka 協議上傳日誌。支援多種型別的終端、多種開發語言以及開源生態標準協議。

採集到的日誌首先會存入高速緩衝叢集，削峰填谷，隨後日誌會勻速流入儲存叢集，根據使用者配置再流轉到資料加工叢集進行日誌加工，或者到索引叢集建立索引。建立索引後使用者可以進行實時查詢和分析。TLS 提供標準的 Lucene 查詢語法、SQL 92 分析語法、視覺化儀表盤以及豐富的監控告警能力。

當日志儲存達到一定週期，不再需要實時分析之後，使用者可以把日誌投遞到成本更低的火山引擎物件儲存服務中，或者透過 Kafka 協議投遞到其他雲產品。如果使用者有更高階的分析需求，TLS 也支援把日誌消費到實時計算、流式計算或離線計算進行更深入的分析。

TLS 的系統設計遵循高可用、高效能、分層設計的原則。

高可用：透過存算分離，所有服務都是無狀態的，故障快速恢復。

高效能：所有叢集都可橫向擴充套件，沒有熱點。

分層設計：各模組之間低耦合，模組之間定義標準介面，元件可替換。

以上就是火山引擎自研的日誌儲存平臺 TLS 的系統架構，下面將詳細介紹 TLS 相較於開源系統做的最佳化。

系統最佳化

中心化白屏化的配置管理

當日志系統中採集 Agent 數量較多時，不再適合在每臺機器上手工配置，因此我們開發了中心化、白屏化的配置管理功能，支援動態下發採集配置，並支援檢視 Agent 執行狀態監控、支援客戶端自動升級。

中心化配置的實現流程如下：

客戶端主動向服務端發起心跳，攜帶自身版本資訊。

服務端收到心跳，檢查版本。

服務端判斷是否需要下發配置資訊給客戶端。

客戶端收到配置資訊，熱載入到本地配置，以新的配置進行採集。

中心化配置管理的優勢在於：

可靠：中心化管理，配置不丟失，白屏化配置不容易出錯。

高效：各種環境下所有的配置都是統一處理，無論 LogCollector 部署在移動端、容器還是物理機上，使用者都可以在服務端相同的介面上配置，配置以機器組為單位批次下發，快速高效。

輕鬆運維：使用者可以在服務端檢視客戶端的執行狀態，對客戶端的異常發出告警。透過中心化配置，TLS 可以向客戶端推送最新版本，自動升級。

CRD 雲原生配置方式

中心化、白屏化的配置方式是適合運維人員的配置方式。在開發測試自動化的場景下，最優的方式是 CRD。傳統的方式透過 API 介面去做採集配置，使用者通常需要寫數千行程式碼來實現。TLS 提供了雲原生 CRD 的方式來進行配置，使用者只需要在 yaml 檔案裡配置要採集的容器、容器內的日誌路徑以及採集規則即可完成採集配置。因為不再需要編寫程式碼，CRD 方式大幅提高了日誌接入效率。

CRD 的配置流程如下：

使用 Kubectl 命令建立 TLS LogConfig CRD;

TLS Controller 監聽到 CRD 配置更新;

TLS Controller 根據 CRD 配置向 TLS Server 傳送命令，建立 topic、建立機器組，建立日誌採集配置;

LogCollector 定期請求 TLS Server，獲取新的採集配置並進行熱載入;

LogCollector 根據採集配置採集各個容器上的標準輸出或文字日誌;

LogCollector 將採集到的日誌傳送給 TLS Server。

適合大規模、多租戶場景的客戶端

開源日誌採集客戶端一般只支援一個 Output，多個 Input 採用相同的 Pipeline，相互影響。為了適應大規模、多租戶場景，火山引擎自研了日誌採集的客戶端 LogCollector。LogCollector 對不同的 Input 採用不同的 Pipeline 做資源隔離，減少多租戶之間的相互影響。一個 LogCollector 支援多個 Output，可以根據不同的 Output 單獨做租戶鑑權。同時我們還在 LogCollector 內實現了自適應反壓機制，如果服務端忙碌，LogCollector 會自動延遲退避，服務端空閒時再傳送，減少算力負擔。

產品最佳化

可用性提升

在可用性方面，TLS 支援多級全域性流控，能杜絕因業務突發導致的故障擴散問題。

在日誌採集到高速緩衝叢集時，按照使用者的 Shard 數控制寫入高速緩衝區的流量。

當資料從高速緩衝區流向儲存叢集時，按儲存叢集控制單個儲存叢集的流量。

從儲存叢集到索引叢集，按索引叢集控制單個索引叢集的寫入流控以及查詢分析併發數。

效率提升

索引和原始資料分離

ES 的索引和資料存在一起，我們在設計過程發現索引和原始資料分離會更優，主要表現在：

提升資料流動性：儲存叢集支援批次消費介面，消費資料不經過索引叢集。相對於從索引叢集先查詢後消費的模式，直接從儲存叢集消費效能更高，有效提升資料流動性。

降低成本：索引和儲存可以採用不同成本的儲存，整體的儲存成本就會降低。使用者可以隨時按需建立索引，進一步降低索引成本。

提升可用性：索引可以非同步建立，流量突發時建立索引慢不會影響儲存寫入速率。

索引管理和排程

索引的流量是不可預測的，因此我們在效率方面的另一個最佳化是支援索引的管理和排程，實現彈性伸縮，從而提升可用性，解決規模問題。我們的解決方案是在多個索引叢集之間做資料流動，基於負載、資源、容量自動遷移索引，支援動態跨叢集線上遷移索引，平衡索引叢集負載。

功能最佳化

消費投遞：在消費投遞方面我們支援了豐富的消費投遞介面，包括：

消費者

消費組

Kafka 協議：透過 Kafka 協議進行標準協議的消費;

S3 協議：支援透過 S3 物件儲存的協議把日誌投遞到物件儲存。

查詢分析：支援先查詢過濾後分析，減少分析資料量提高效能。分析支援標準的 SQL 92，分析結果支援圖表視覺化。

日誌告警：透過實時監控日誌，基於使用者配置的監控規則組合以及告警觸發條件，滿足條件就可以透過簡訊、郵件、飛書等方式傳送告警給使用者或使用者組。

視覺化儀表盤：TLS 提供多種視覺化儀表盤，實現實時監測，且儀表盤可以關聯告警。

TLS 實踐案例

接下來為大家介紹兩個 TLS 的典型案例。

火山引擎內部業務及運維日誌採集

TLS 目前支撐了火山引擎全國多個 Region 運維日誌的採集分析。日誌型別包括業務的檔案日誌、容器標準輸出。業務分別部署在內網、外網以及混合雲，日誌都透過 TLS 平臺統一做採集和分析。

相較於前期各業務模組自己搭建日誌系統，採用 TLS 獲得瞭如下收益：

經濟高效：資源利用率由之前的 20% 提升到現在的 80%，大幅降低資源成本;

可用性較高：多級流控加快取，抗突發能力強，即使在索引系統故障的時候也不會影響原始資料的流量;

輕鬆運維：TLS 的統一運維提升了運維人員的能力，少量運維人員即可完成整個系統的運維。

快速接入：TLS 可以在一小時內完成一個新業務的採集、查詢、分析、消費的快速接入。

某教育行業頭部客戶日誌採集

該客戶的系統業務主要採集的日誌包括：

檔案日誌

App 日誌

Kubernetes 叢集后端業務的日誌

使用者行為日誌

TLS 把這幾個平臺的日誌統一採集到雲端，進行實時查詢分析以及進行告警。客戶自建有大資料分析平臺，TLS 可將日誌資料透過消費的方式流轉到該平臺進行線上、離線等更高階的大資料分析。對於時間長的歷史資料，則投遞到物件儲存進行歸檔，從而降低整個系統的成本。

使用者的管理員可在 TLS 上統一檢視所有平臺的各種日誌，整個系統的建設和運維成本也降低了。TLS 使用標準介面，可以相容雲上自建的分析平臺，使用者在快速上線的同時也能保證系統的高度相容。

展望未來

未來，TLS 平臺會不斷進行更深層次的最佳化：

雲產品的一鍵日誌採集

搜尋引擎的深度最佳化

資料清洗和加工的函式式介面

整合更多第三方平臺，火山引擎雲產品深度融合