1 引言

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

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

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

2  設計原則與架構

2.1原則

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

• 數據緩存不丟失

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

• 日志數據讀寫分離

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

• 數據冷熱分離

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

2.2架構

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

圖2 全棧云日志平臺服務架構

3 性能優化

基于上述架構實現日志處理平臺后，隨著服務接入變多，接入日志量變大，平臺出現kafka端消息積壓的情況，經過調試分析，分別從kafka、logstash和OpenSearch三個部分開展優化，并實現了消息數據的實時消費與寫入。

3.1問題分析

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

圖3 kafka節點的磁盤io曲線

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

3.2kafka的優化

kafka通過磁盤順序寫入、操作系統頁緩存、零拷貝、消息批量處理和壓縮等一系列精妙設計，確保了服務的高性能，但仍需做一些配置調整以應對實際使用環境。如下列出一些當前環境下所做的配置調整。

??num.partitions

需要針對topic的實際消息大小、以及kafka集群的規模（避免出現數據傾斜）進行配置，以達到生產和消費的平衡。

??auto.create.topics.enable

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

??log.segment.bytes

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

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

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

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

3.3logstash的優化

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

??pipeline.batch.size

logstash.yml的配置參數，用于設置logstash批量處理的消息總量，以及單次發往OpenSearch的批量請求大小，默認值為125，應當根據OpenSearch性能及logstash資源占用情況盡可能調大。

??pipeline.workers

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

??consumer_threads

logstash.conf中對于kafka input plugin的配置，消費者線程數。可以根據消費的分區數以及logstash資源實際使用情況綜合設置，理想配置是與消息分區數保持一致。

??partition_assignment_strategy

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

3.4OpenSearch的優化

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

• 索引模板設置

??index.refresh_interval

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

??index.number_of_shards

索引的分片數，增加分片可以提升寫入性能，但分片太多會增加集群管理壓力，帶來負面影響，根據索引數據大小（建議單個分片大小小于50GB）、數據節點數靈活配置。

??index.translog.durability

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

• 讀寫分離

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

• ISM

ISM（Index State Management）可通過策略實現對索引的生命周期管理，及索引數據的狀態切換。通過ISM實現索引從創建、備份到刪除的自動化處理。

圖5 優化前后logstash的CPU利用率曲線對比

圖6 優化后kafka節點的磁盤io曲線

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

4 改進與優化

經過一系列實踐與優化，全棧云日志平臺已能平穩處理云底座管理服務日志。在后續過程中，平臺計劃在以下方面進一步完善和改進，包括：

??提高日志處理性能

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

??優化對象存儲索引設計

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

??提升平臺可靠性

由于整個日志處理鏈路較長，需要對每個階段的狀態進行監控并配置告警，以確保平臺的可靠性，及時發現問題并預警。

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