7月安卓手機性能榜：紅魔8S Pro再奪榜首
7月份的手機市場風平浪靜，除了紅魔和努比亞帶來了兩款搭載驍龍8Gen2領先版處理器的新機之外，別的也想不到有什么新品了，這也正常，通常6月7月都是手機廠商修整的時間，進入8月份之
Elasticsearch（后稱ES）作為日志管理、數(shù)據(jù)搜索與分析工具，在各行各業(yè)都有廣泛且深入的應用，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行在應用系統(tǒng)全面上云的背景下，進行了基于容器化OpenSearch的全棧云日志平臺設計與實踐，并開展了一系列性能優(yōu)化，探索適合全棧云的日志處理、數(shù)據(jù)分析與數(shù)據(jù)搜索替換路線。下文詳細介紹G行基于OpenSearch開展的日志平臺設計與優(yōu)化工作。
G行全棧云日志平臺以收集并處理全棧云底座管理服務日志為目標，并對管理員提供日志查詢視圖、日志分析看板等功能。考慮到接入組件服務多、日志量分時差異大、日志查詢時間長等實際情況，平臺需滿足如下幾點要求：
在日志量大且集中的時段，OpenSearch可能無法及時處理所有數(shù)據(jù)，通過日志緩存確保未及時處理的數(shù)據(jù)可以在后期追溯。
避免直接對客戶端服務暴露寫入端口，降低對OpenSearch集群的沖擊，確保平臺的運行穩(wěn)定性。開放適當權限的數(shù)據(jù)查詢視圖。
持續(xù)寫入的索引作為熱數(shù)據(jù)存放在熱節(jié)點，不再更新的索引作為溫數(shù)據(jù)存放在溫節(jié)點，不需查詢的數(shù)據(jù)作為備份存放在對象存儲。確保數(shù)據(jù)讀寫性能得到保障。
通過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ù)查詢與看板定制。下圖為日志平臺架構展示。
圖2 全棧云日志平臺服務架構
基于上述架構實現(xiàn)日志處理平臺后，隨著服務接入變多，接入日志量變大，平臺出現(xiàn)kafka端消息積壓的情況，經(jīng)過調(diào)試分析，分別從kafka、logstash和OpenSearch三個部分開展優(yōu)化，并實現(xiàn)了消息數(shù)據(jù)的實時消費與寫入。
通過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)化以提升消息處理性能。
kafka通過磁盤順序?qū)懭搿⒉僮飨到y(tǒng)頁緩存、零拷貝、消息批量處理和壓縮等一系列精妙設計，確保了服務的高性能，但仍需做一些配置調(diào)整以應對實際使用環(huán)境。如下列出一些當前環(huán)境下所做的配置調(diào)整。
本文鏈接：http://m.www897cc.com/showinfo-26-79301-0.htmlG行基于OpenSearch的日志平臺設計與實踐
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 我們一起聊聊什么是正向代理和反向代理
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號