1 引言

Elasticsearch（后稱ES）作為日志管理、數(shù)據(jù)搜索與分析工具，在各行各業(yè)都有廣泛且深入的應(yīng)用，2021年初Elastic公司不再提供ES的Apache license開源版本，AWS為此推出了基于ES 7.10.2開發(fā)的OpenSearch。OpenSearch自2022年發(fā)布至今，在DB-Engine的搜索引擎分類的排名迅速攀升到第4，由于與ES同源，OpenSearch成為ES完美的商業(yè)替代產(chǎn)品。

圖1 DB-Engines搜索引擎分類排名

G行在應(yīng)用系統(tǒng)全面上云的背景下，進行了基于容器化OpenSearch的全棧云日志平臺設(shè)計與實踐，并開展了一系列性能優(yōu)化，探索適合全棧云的日志處理、數(shù)據(jù)分析與數(shù)據(jù)搜索替換路線。下文詳細介紹G行基于OpenSearch開展的日志平臺設(shè)計與優(yōu)化工作。

2  設(shè)計原則與架構(gòu)

2.1原則

G行全棧云日志平臺以收集并處理全棧云底座管理服務(wù)日志為目標，并對管理員提供日志查詢視圖、日志分析看板等功能?？紤]到接入組件服務(wù)多、日志量分時差異大、日志查詢時間長等實際情況，平臺需滿足如下幾點要求：

• 數(shù)據(jù)緩存不丟失

在日志量大且集中的時段，OpenSearch可能無法及時處理所有數(shù)據(jù)，通過日志緩存確保未及時處理的數(shù)據(jù)可以在后期追溯。

• 日志數(shù)據(jù)讀寫分離

避免直接對客戶端服務(wù)暴露寫入端口，降低對OpenSearch集群的沖擊，確保平臺的運行穩(wěn)定性。開放適當權(quán)限的數(shù)據(jù)查詢視圖。

• 數(shù)據(jù)冷熱分離

持續(xù)寫入的索引作為熱數(shù)據(jù)存放在熱節(jié)點，不再更新的索引作為溫數(shù)據(jù)存放在溫節(jié)點，不需查詢的數(shù)據(jù)作為備份存放在對象存儲。確保數(shù)據(jù)讀寫性能得到保障。

2.2架構(gòu)

通過kafka實現(xiàn)日志的集中接入與緩存，并且實現(xiàn)對OpenSearch的平滑寫入；通過logstash實現(xiàn)日志數(shù)據(jù)的集中處理，對數(shù)據(jù)流開展解析與二次加工工作；通過OpenSearch的ISM(Index State Management，索引狀態(tài)管理)機制實現(xiàn)索引數(shù)據(jù)的熱、溫、冷自動化處理，冷數(shù)據(jù)存儲備份于對象存儲中；通過Dashboard實現(xiàn)可視化數(shù)據(jù)查詢與看板定制。下圖為日志平臺架構(gòu)展示。

圖2 全棧云日志平臺服務(wù)架構(gòu)

3 性能優(yōu)化

基于上述架構(gòu)實現(xiàn)日志處理平臺后，隨著服務(wù)接入變多，接入日志量變大，平臺出現(xiàn)kafka端消息積壓的情況，經(jīng)過調(diào)試分析，分別從kafka、logstash和OpenSearch三個部分開展優(yōu)化，并實現(xiàn)了消息數(shù)據(jù)的實時消費與寫入。

3.1問題分析

通過kafka集群節(jié)點的磁盤io曲線可以看出磁盤的寫入速度約是讀取速度的8倍，即消息的消費速度明顯跟不上消息的生產(chǎn)速度，這也符合kafka消息積壓的現(xiàn)象。

圖3 kafka節(jié)點的磁盤io曲線

通過logstash節(jié)點的監(jiān)控曲線，發(fā)現(xiàn)logstash的cpu利用率和出入站流量較低，而OpenSearch的cpu利用率和吞吐量同樣不高。為此考慮從日志平臺的整個路徑上開展優(yōu)化以提升消息處理性能。

3.2kafka的優(yōu)化

kafka通過磁盤順序?qū)懭搿⒉僮飨到y(tǒng)頁緩存、零拷貝、消息批量處理和壓縮等一系列精妙設(shè)計，確保了服務(wù)的高性能，但仍需做一些配置調(diào)整以應(yīng)對實際使用環(huán)境。如下列出一些當前環(huán)境下所做的配置調(diào)整。

??num.partitions

需要針對topic的實際消息大小、以及kafka集群的規(guī)模（避免出現(xiàn)數(shù)據(jù)傾斜）進行配置，以達到生產(chǎn)和消費的平衡。

??auto.create.topics.enable

將自動創(chuàng)建消息配置為false，確保集群管理topic可控。

??log.segment.bytes

__consumer_offsets是kafka自行創(chuàng)建的內(nèi)部topic，用于保存集群內(nèi)consumer對所有topic的消費位移信息。kafka通過對消費者組group id的哈希值進行求模運算（groupID.hashCode()%numPartitions），從而將消息存儲在不同的分區(qū)，意味著同一消費者組的消費位移信息會同時更新到同一個分區(qū)。

__consumer_offsets的log.segment.bytes默認是100MB。當topic足夠多帶來的partition數(shù)量龐大，可能導(dǎo)致集群更新__consumer_offsets失敗從而使得當前消費者無法消費數(shù)據(jù)，即上圖報錯。為此，需要適當擴大__consumer_offsets的log.segment.bytes，本環(huán)境將其擴大到了1GB。

??max.incremental.fetch.session.cache.slots

用于限制每個broker上的最大fetch session數(shù)量，當集群的partition數(shù)量足夠大且消費線程足夠多時，會導(dǎo)致消費者session搶占，使消費者組不斷rebalance，影響消費性能。該配置默認值為1000，需要根據(jù)環(huán)境的消費者線程數(shù)、分區(qū)數(shù)等實際情況進行配置調(diào)整。

3.3logstash的優(yōu)化

logstash充當連通kafka和OpenSearch的管道，并對管道中的消息進行加工處理。除了對不同消息進行分組消費，如下列為幾個關(guān)鍵參數(shù)的配置調(diào)整，用于提高logstash的資源利用率和數(shù)據(jù)吞吐。

??pipeline.batch.size

logstash.yml的配置參數(shù)，用于設(shè)置logstash批量處理的消息總量，以及單次發(fā)往OpenSearch的批量請求大小，默認值為125，應(yīng)當根據(jù)OpenSearch性能及l(fā)ogstash資源占用情況盡可能調(diào)大。

??pipeline.workers

logstash.yml的配置參數(shù)，單個logstash實例運行時用于處理消息數(shù)據(jù)的線程數(shù)，根據(jù)logstash資源配置（CPU配額）調(diào)整。

??consumer_threads

logstash.conf中對于kafka input plugin的配置，消費者線程數(shù)?？梢愿鶕?jù)消費的分區(qū)數(shù)以及l(fā)ogstash資源實際使用情況綜合設(shè)置，理想配置是與消息分區(qū)數(shù)保持一致。

??partition_assignment_strategy

logstash.conf中對于kafka input plugin的配置，當使用topics_pattern匹配topic進行消費時，默認的partition_assignment_strategy為Range，該策略容易帶來部分消費者過載的情況，建議指定為round_robin策略進行分區(qū)分配。

3.4OpenSearch的優(yōu)化

從索引寫入配置、索引存儲管理以及集群節(jié)點資源調(diào)整等方面提升OpenSearch的寫入性能，同時優(yōu)化平臺的使用體驗。

• 索引模板設(shè)置

??index.refresh_interval

索引數(shù)據(jù)刷新落盤的周期，根據(jù)索引數(shù)據(jù)需要呈現(xiàn)的時效性進行配置，對于允許推遲查詢的數(shù)據(jù)，加大配置值，比如增加至30s或60s。

??index.number_of_shards

索引的分片數(shù)，增加分片可以提升寫入性能，但分片太多會增加集群管理壓力，帶來負面影響，根據(jù)索引數(shù)據(jù)大?。ńㄗh單個分片大小小于50GB）、數(shù)據(jù)節(jié)點數(shù)靈活配置。

??index.translog.durability

對于極端情況下（比如數(shù)據(jù)節(jié)點宕機）允許部分數(shù)據(jù)丟失的情況，將translog同步刷盤調(diào)整為異步，提高集群處理性能。

• 讀寫分離

通過配置節(jié)點角色（熱/溫/冷）以及索引的分配屬性，將有數(shù)據(jù)寫入的索引分配到熱節(jié)點，沒有數(shù)據(jù)寫入的索引分配到溫節(jié)點。

• ISM

ISM（Index State Management）可通過策略實現(xiàn)對索引的生命周期管理，及索引數(shù)據(jù)的狀態(tài)切換。通過ISM實現(xiàn)索引從創(chuàng)建、備份到刪除的自動化處理。

圖5 優(yōu)化前后logstash的CPU利用率曲線對比

圖6 優(yōu)化后kafka節(jié)點的磁盤io曲線

通過前述優(yōu)化配置處理，日志平臺已經(jīng)實現(xiàn)全棧云底座管理服務(wù)的全量日志收集與呈現(xiàn)，并解決了消息積壓問題。圖5展示了logstash優(yōu)化前后的CPU利用率占比，從10%不到提升至約70%。圖6為某kafka節(jié)點的磁盤讀寫曲線，寫入帶寬約為讀取帶寬的2倍，考慮到kafka消息的多副本配置，屬于合理預(yù)期。

4 改進與優(yōu)化

經(jīng)過一系列實踐與優(yōu)化，全棧云日志平臺已能平穩(wěn)處理云底座管理服務(wù)日志。在后續(xù)過程中，平臺計劃在以下方面進一步完善和改進，包括：

??提高日志處理性能

fluent-bit / filebeat / fluentd / logstash等不同語言架構(gòu)的組件，配置與性能差異均較大，后續(xù)將探索使用vector提高日志處理性能。

??優(yōu)化對象存儲索引設(shè)計

由于每天都有索引通過ISM轉(zhuǎn)移到對象存儲中，需要對對象存儲中的索引快照進行管理設(shè)計，以提升索引恢復(fù)效率、清理不再需要的快照。

??提升平臺可靠性

由于整個日志處理鏈路較長，需要對每個階段的狀態(tài)進行監(jiān)控并配置告警，以確保平臺的可靠性，及時發(fā)現(xiàn)問題并預(yù)警。

作為全棧云平臺可觀測能力的關(guān)鍵組成部分，日志記錄了系統(tǒng)發(fā)生的所有行為。其不僅可用于系統(tǒng)排錯、產(chǎn)品優(yōu)化，還可為審計、取證等工作提供素材。下一步，全棧云日志平臺將以統(tǒng)一日志采集、處理、治理和分析為目標，打造全棧云可觀測數(shù)據(jù)底座，為G行可觀測能力建設(shè)添磚加瓦。