不斷迭代，嚴苛細節，最終性能如何知足? 基於ELK的大數據平臺實踐分享

在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語法作一些包裝、抽象，告警模型基於從工做日開始的迭代、同比環比、平均值及標準差，基線學習。

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

本文做者：雲跡九州

閱讀原文

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