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

在2018年Elastic Meetup 南京交流會中，來自云利來科技的涂海波為現場的聽眾帶來了題為《南京云利來基于ELK的大數據平臺》的精彩分享。在本次分享中，他首先進行了公司簡介，然后介紹了數據分類，包括數據采集及數據類型等；然后重點闡述了運維之路，最后進行了告警分析。
數十款阿里云產品限時折扣中，趕快點擊這里，領券開始云上實踐吧
直播視頻請點擊
PPT下載請點擊
以下內容根據現場分享整理而成。

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

數據分類

數據采集

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

數據類型

?

上圖為主要數據類型，網絡協議里也有數據庫，是一些協議解析，還有一些交易的解析?？梢詮木W絡層面和日志層面分開來比對。

數據量

每天數據量至少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語法做一些包裝、抽象，告警模型基于從工作日開始的迭代、同比環比、平均值及標準差，基線學習。
我們發現問題，解決問題，需要不停的去思考。不斷迭代，嚴苛細節，最終性能是否滿足?是否可接受?這些都是需要思考的問題。

?

原文鏈接

總結

以上是生活随笔為你收集整理的不断迭代，严苛细节，最终性能如何满足? 基于ELK的大数据平台实践分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。