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開展的日志平臺設計與優化工作。
G行全棧云日志平臺以收集并處理全棧云底座管理服務日志為目標,并對管理員提供日志查詢視圖、日志分析看板等功能。考慮到接入組件服務多、日志量分時差異大、日志查詢時間長等實際情況,平臺需滿足如下幾點要求:
在日志量大且集中的時段,OpenSearch可能無法及時處理所有數據,通過日志緩存確保未及時處理的數據可以在后期追溯。
避免直接對客戶端服務暴露寫入端口,降低對OpenSearch集群的沖擊,確保平臺的運行穩定性。開放適當權限的數據查詢視圖。
持續寫入的索引作為熱數據存放在熱節點,不再更新的索引作為溫數據存放在溫節點,不需查詢的數據作為備份存放在對象存儲。確保數據讀寫性能得到保障。
通過kafka實現日志的集中接入與緩存,并且實現對OpenSearch的平滑寫入;通過logstash實現日志數據的集中處理,對數據流開展解析與二次加工工作;通過OpenSearch的ISM(Index State Management,索引狀態管理)機制實現索引數據的熱、溫、冷自動化處理,冷數據存儲備份于對象存儲中;通過Dashboard實現可視化數據查詢與看板定制。下圖為日志平臺架構展示。
圖2 全棧云日志平臺服務架構
基于上述架構實現日志處理平臺后,隨著服務接入變多,接入日志量變大,平臺出現kafka端消息積壓的情況,經過調試分析,分別從kafka、logstash和OpenSearch三個部分開展優化,并實現了消息數據的實時消費與寫入。
通過kafka集群節點的磁盤io曲線可以看出磁盤的寫入速度約是讀取速度的8倍,即消息的消費速度明顯跟不上消息的生產速度,這也符合kafka消息積壓的現象。
圖3 kafka節點的磁盤io曲線
通過logstash節點的監控曲線,發現logstash的cpu利用率和出入站流量較低,而OpenSearch的cpu利用率和吞吐量同樣不高。為此考慮從日志平臺的整個路徑上開展優化以提升消息處理性能。
kafka通過磁盤順序寫入、操作系統頁緩存、零拷貝、消息批量處理和壓縮等一系列精妙設計,確保了服務的高性能,但仍需做一些配置調整以應對實際使用環境。如下列出一些當前環境下所做的配置調整。
本文鏈接:http://www.www897cc.com/showinfo-26-79301-0.htmlG行基于OpenSearch的日志平臺設計與實踐
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 我們一起聊聊什么是正向代理和反向代理