基於ELK的大數據平台實踐分享

08-11

基於ELK的大數據平台實踐分享

來自專欄我是程序員10 人贊了文章

在2018年Elastic Meetup 南京交流會中，來自雲利來科技的塗海波為現場的聽眾帶來了題為《南京雲利來基於ELK的大數據平台》的精彩分享。在本次分享中，他首先進行了公司簡介，然後介紹了數據分類，包括數據採集及數據類型等；然後重點闡述了運維之路，最後進行了告警分析。

直播視頻請點擊

PPT下載請點擊

以下內容根據現場分享整理而成。

南京雲利來有限公司主要專註於以下三個方面：實時網路使用分析，具備世界領先20Gbps分析能力；為數據中心搭建大數據分析平台，數據中心主要是給運維團隊、安全團隊和開發團隊做跨部門協作；提供智能運維、網路安全和預警分析能力。產品主要應用的行業包括電商、政府、證券等。

數據分類

數據採集

數據採集主要分為網路類和日誌類。網路類主要為旁路部署，用小盒子部署在機房內不同的點，包括出口入口。日誌類主要包括Nagios (filebeat)和Zabbix (mysqlexporter)。

數據類型

上圖為主要數據類型，網路協議里也有資料庫，是一些協議解析，還有一些交易的解析。可以從網路層面和日誌層面分開來比對。

數據量

每天數據量至少2TB，記錄數22億，不含副本；高峰數據量每秒6萬條記錄；單個索引最快處理12萬條記錄每秒。

使用場景

主要有三個使用場景：查詢聚合；大屏分析，預測告警；網路指標，業務指標安全指標。

網路業務安全是基於一些不同的團隊，定製個性化的指標，進行一些對比分析。

運維之路

集群演變

在使用ELK的整個過程中，我們使用過Vmware、Docker，跟美國的第三方公司的一些合作。我們自己用的最多的是單節點單實例和單節點雙實例。基本是用於功能測試小公司一些測試部署。

冷熱分離

我們做的冷熱分離，開始採用的是flashcache模式，每台物理機上面都配備了一個SSD的小盤，主要是為了抵消傳統的機械式硬碟尋到的一個LPS。LPS比較慢，延遲比較高，所以分散式集群每一塊都配備一個小盤。在這種模式下，磁碟IO連續小塊讀，負載高，IOwait高，分析發現存在抖動。採用單機雙實例冷熱分離模式，充分利用1.6TB的SSD，只保存每天的熱數據，隔夜遷移到HDD Raid0。

升級的主要目的有兩個：內存隔離，當天和歷史JAVA對象分離在不同的JVM里；IO隔離，當天和歷史數據的磁碟IO分離在不同的磁碟上。

上圖為運維前後對比效果圖。左邊是運維之前，右邊是運維之後。升級後，有效減少了cpu wait和磁碟讀，降低了系統負載，有效提升了查詢和寫入性能。

上圖為在單個索引上做的測試。之前做了許多積壓，可以發現索引的速度是上升的。單個索引最高速度從之前的60000條每秒提升到120000條記錄每秒，平均10萬條每秒。聚合查詢性能提升1倍。

重要選型

重要選型首先從cpu介紹，我們推薦使用Xeon E5-2600 V4系列。官方測試顯示，它比V3系列提升JAVA性能60％，我們進行了一些設置，包括指令預取，cache line預取，Numa Set。結合雙路cpu，它的內存和節點有一個就近讀取的原則。我們根據單個機器的實例進行cpu的綁定。設置以後可以提高cpu的命中率，減少內存的切換。

在內存方面，每台物理機配備的是128TB，SSD是1.6TB，HDD是40TB～48TB。具有大內存的特點，我們還進行了Cache加速，寫負載高的時候上SSD，定期做Trim優化，利用SSD,SAS和SATA盤分級存儲。

OS file system用的最多的是xfs。針對HDD、SSD 4k對齊優化，確保每個分區的start Address能被8整除，解決跨扇區訪問，減少讀寫次數和延遲。

Shard和Replica個數是基於測試的經驗，可以作為參考，還基於負載、性能等。節點數設置為1.5。Shard size 控制在30GB以內，Shard docs 控制在5百萬記錄以內，Replica至少為1。

可靠性

由上圖可以看到每個角色都有A、B、C三個點，然後做了冷熱分離，Client多個點做了負載均衡。

性能分析

高負載
高負載主要採用IO負載型，主要關注Sar，Vmstat，IOstat，Dstat和Systemtap，Perf。
線程池

線程池這裡主要關注Index，Query，Merge，Bulk，包括Thread，Queue Size和Active，Queue。
內存佔用
內存佔用主要看各個節點的內存佔用大小，Fielddata設置為10％，也有的設置為1％，大部分場景都是精確查詢。
查詢
用慢查詢作為告警，然後進行請求、響應、延時、峰值統計。隨著資源使用率的提升，我們會發現在80%的點位，延時會特別大，於是會有多個監工。單個監工是沒問題的，但是多個監工可能是有問題的。Query profile用來定位各個階段的時間。Cache filling用來觀看命中率如何,可以做一些cache的設置。然後會進行日誌埋點採集，query replay，做一些測試。
集群健康
集群健康這裡主要是對以下幾項進行指標監控。 _cluster/health：active, reallocating, initializing,unassigned；Ping timeout；Shard allocation,recover latency。
GC效率
GC效率主要關注以下幾點：GC時長佔比，GC回收量佔比；內存增長速率，內存回收速率；各代回收耗時，頻率；Dump profile；Jstack，Jmap，Jstat。

存儲規劃

上圖為基於不同業務做的存儲規劃。

性能提升

合理設計
首先我們會考慮每個域的意義，沒有意義的域是不允許插進來的。然後要考慮需要存儲搜索還是聚合，思考每一個域的價值所在。它是字元串型的還是數值型的？然後我們會對模板進行動態的設置。當字元串過長的時候，我們是否要做一個截取？是否要做一個Hash？
批處理

適當調大處理時間，Translog適當把頻率降低。

上圖做了一個按需隔離，分表分級分組。

規劃計算
提前聚合後插入；因為空間不夠，所以超過生命周期後只保留基線，然後做壓縮，做合併；隨後可以做Pipeline拆分。

集群監控

監控這裡用了一些工具。Netdata用來做一些系統資源的升級， _cat api是官方自帶的，Cerebro是用的比較多的一個插件，Prometheus可以開箱即用。

告警分析

用Sql語法做一些包裝、抽象，告警模型基於從工作日開始的迭代、同比環比、平均值及標準差，基線學習。

我們發現問題，解決問題，需要不停的去思考。不斷迭代，嚴苛細節，最終性能是否滿足?是否可接受?這些都是需要思考的問題。

本文作者：雲跡九州

原文鏈接

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎

本文為雲棲社區原創內容，未經允許不得轉載。