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

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

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

數(shù)據(jù)分類

數(shù)據(jù)采集

數(shù)據(jù)采集主要分為網(wǎng)絡(luò)類和日志類。網(wǎng)絡(luò)類主要為旁路部署，用小盒子部署在機房內(nèi)不同的點，包括出口入口。日志類主要包括Nagios (filebeat)和Zabbix (mysqlexporter)。

數(shù)據(jù)類型

?

上圖為主要數(shù)據(jù)類型，網(wǎng)絡(luò)協(xié)議里也有數(shù)據(jù)庫，是一些協(xié)議解析，還有一些交易的解析。可以從網(wǎng)絡(luò)層面和日志層面分開來比對。

數(shù)據(jù)量

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

使用場景

主要有三個使用場景：查詢聚合；大屏分析，預(yù)測告警；網(wǎng)絡(luò)指標(biāo)，業(yè)務(wù)指標(biāo)安全指標(biāo)。
網(wǎng)絡(luò)業(yè)務(wù)安全是基于一些不同的團隊，定制個性化的指標(biāo)，進行一些對比分析。

運維之路

集群演變

在使用ELK的整個過程中，我們使用過Vmware、Docker，跟美國的第三方公司的一些合作。我們自己用的最多的是單節(jié)點單實例和單節(jié)點雙實例?；臼怯糜诠δ軠y試小公司一些測試部署。

冷熱分離

我們做的冷熱分離，開始采用的是flashcache模式，每臺物理機上面都配備了一個SSD的小盤，主要是為了抵消傳統(tǒng)的機械式硬盤尋到的一個LPS。LPS比較慢，延遲比較高，所以分布式集群每一塊都配備一個小盤。在這種模式下，磁盤IO連續(xù)小塊讀，負(fù)載高，IOwait高，分析發(fā)現(xiàn)存在抖動。采用單機雙實例冷熱分離模式，充分利用1.6TB的SSD，只保存每天的熱數(shù)據(jù)，隔夜遷移到HDD Raid0。
升級的主要目的有兩個：內(nèi)存隔離，當(dāng)天和歷史JAVA對象分離在不同的JVM里；IO隔離，當(dāng)天和歷史數(shù)據(jù)的磁盤IO分離在不同的磁盤上。

上圖為運維前后對比效果圖。左邊是運維之前，右邊是運維之后。升級后，有效減少了cpu wait和磁盤讀，降低了系統(tǒng)負(fù)載，有效提升了查詢和寫入性能。

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

重要選型

重要選型首先從cpu介紹，我們推薦使用Xeon E5-2600 V4系列。官方測試顯示，它比V3系列提升JAVA性能60％，我們進行了一些設(shè)置，包括指令預(yù)取，cache line預(yù)取，Numa Set。結(jié)合雙路cpu，它的內(nèi)存和節(jié)點有一個就近讀取的原則。我們根據(jù)單個機器的實例進行cpu的綁定。設(shè)置以后可以提高cpu的命中率，減少內(nèi)存的切換。
在內(nèi)存方面，每臺物理機配備的是128TB，SSD是1.6TB，HDD是40TB～48TB。具有大內(nèi)存的特點，我們還進行了Cache加速，寫負(fù)載高的時候上SSD，定期做Trim優(yōu)化，利用SSD,SAS和SATA盤分級存儲。
OS file system用的最多的是xfs。針對HDD、SSD 4k對齊優(yōu)化，確保每個分區(qū)的start Address能被8整除，解決跨扇區(qū)訪問，減少讀寫次數(shù)和延遲。
Shard和Replica個數(shù)是基于測試的經(jīng)驗，可以作為參考，還基于負(fù)載、性能等。節(jié)點數(shù)設(shè)置為1.5。Shard size 控制在30GB以內(nèi)，Shard docs 控制在5百萬記錄以內(nèi)，Replica至少為1。

可靠性

?

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

性能分析

• 高負(fù)載
  高負(fù)載主要采用IO負(fù)載型，主要關(guān)注Sar，Vmstat，IOstat，Dstat和Systemtap，Perf。
• 線程池
  線程池這里主要關(guān)注Index，Query，Merge，Bulk，包括Thread，Queue Size和Active，Queue。
• 內(nèi)存占用
  內(nèi)存占用主要看各個節(jié)點的內(nèi)存占用大小，Fielddata設(shè)置為10％，也有的設(shè)置為1％，大部分場景都是精確查詢。
• 查詢
  用慢查詢作為告警，然后進行請求、響應(yīng)、延時、峰值統(tǒng)計。隨著資源使用率的提升，我們會發(fā)現(xiàn)在80%的點位，延時會特別大，于是會有多個監(jiān)工。單個監(jiān)工是沒問題的，但是多個監(jiān)工可能是有問題的。Query profile用來定位各個階段的時間。Cache filling用來觀看命中率如何,可以做一些cache的設(shè)置。然后會進行日志埋點采集，query replay，做一些測試。
• 集群健康
  集群健康這里主要是對以下幾項進行指標(biāo)監(jiān)控。 _cluster/health：active, reallocating, initializing,unassigned；Ping timeout；Shard allocation,recover latency。
• GC效率
  GC效率主要關(guān)注以下幾點：GC時長占比，GC回收量占比；內(nèi)存增長速率，內(nèi)存回收速率；各代回收耗時，頻率；Dump profile；Jstack，Jmap，Jstat。

存儲規(guī)劃

?

上圖為基于不同業(yè)務(wù)做的存儲規(guī)劃。

性能提升

• 合理設(shè)計
  首先我們會考慮每個域的意義，沒有意義的域是不允許插進來的。然后要考慮需要存儲搜索還是聚合，思考每一個域的價值所在。它是字符串型的還是數(shù)值型的？然后我們會對模板進行動態(tài)的設(shè)置。當(dāng)字符串過長的時候，我們是否要做一個截取？是否要做一個Hash？
• 批處理
  適當(dāng)調(diào)大處理時間，Translog適當(dāng)把頻率降低。

?

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

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

集群監(jiān)控

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

告警分析

用Sql語法做一些包裝、抽象，告警模型基于從工作日開始的迭代、同比環(huán)比、平均值及標(biāo)準(zhǔn)差，基線學(xué)習(xí)。
我們發(fā)現(xiàn)問題，解決問題，需要不停的去思考。不斷迭代，嚴(yán)苛細(xì)節(jié)，最終性能是否滿足?是否可接受?這些都是需要思考的問題。

?

原文鏈接

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。