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)全面上云的背景下，進(jìn)行了基于容器化OpenSearch的全棧云日志平臺(tái)設(shè)計(jì)與實(shí)踐，并開展了一系列性能優(yōu)化，探索適合全棧云的日志處理、數(shù)據(jù)分析與數(shù)據(jù)搜索替換路線。下文詳細(xì)介紹G行基于OpenSearch開展的日志平臺(tái)設(shè)計(jì)與優(yōu)化工作。

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

2.1原則

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

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

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

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

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

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

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

2.2架構(gòu)

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

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

3 性能優(yōu)化

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

3.1問題分析

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

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

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

3.2kafka的優(yōu)化

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

??num.partitions

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

??auto.create.topics.enable

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

??log.segment.bytes

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

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

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

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

3.3logstash的優(yōu)化

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

??pipeline.batch.size

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

??pipeline.workers

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

??consumer_threads

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

??partition_assignment_strategy

logstash.conf中對(duì)于kafka input plugin的配置，當(dāng)使用topics_pattern匹配topic進(jìn)行消費(fèi)時(shí)，默認(rèn)的partition_assignment_strategy為Range，該策略容易帶來(lái)部分消費(fèi)者過載的情況，建議指定為round_robin策略進(jìn)行分區(qū)分配。

3.4OpenSearch的優(yōu)化

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

• 索引模板設(shè)置

??index.refresh_interval

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

??index.number_of_shards

索引的分片數(shù)，增加分片可以提升寫入性能，但分片太多會(huì)增加集群管理壓力，帶來(lái)負(fù)面影響，根據(jù)索引數(shù)據(jù)大小（建議單個(gè)分片大小小于50GB）、數(shù)據(jù)節(jié)點(diǎn)數(shù)靈活配置。

??index.translog.durability

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

• 讀寫分離

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

• ISM

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

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

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

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

4 改進(jìn)與優(yōu)化

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

??提高日志處理性能

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

??優(yōu)化對(duì)象存儲(chǔ)索引設(shè)計(jì)

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

??提升平臺(tái)可靠性

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

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