在生產環境中，我們為了更好的服務于業務，通常會通過優化的手段來實現服務對外的性能最大化，節省系統性能開支；關注我的朋友們都知道，前段時間一直在搞ELK，同時也記錄在了個人的博客篇章中，從部署到各個服務應用的采集都做了詳細的介紹，但是并沒有關于ELK方面的優化，那么，我們對于這些日志分析平臺，我們如何去優化呢？優化的手段又有哪些呢？下面請聽我娓娓道來~

【ES優化】

ES在前面的部署環節(https://www.cnblogs.com/bixiaoyu/p/9460554.html)已經簡單了提到調優，但是不全；Elasticsearch作為數據持久化存儲環節，主要就是接受采集端發送過來的數據，執行寫磁盤，建立索引庫，最后將結構化的數據存儲到ES集群上，這是ES所需要完成的工作

1.1:JVM內存的優化

首先我們需要了解什么是jvm內存？作用是什么？

jvm內存其實就是java內存堆，也是jvm需要管理的最大的一塊內存空間，主要就是存放各種類型的實例對象；在java中，堆的概念被劃分為，新生代和老年代，這樣更有利于jvm管理內存堆中的對象，分配和回收

我們設置堆內存主要就是創建實例對象，讓所有對象實例和數據都在堆上進程分配，可以動態的分配內存大小；

-Xms1g? ? ?#設置堆最小的內存

-Xmx1g? ? #設置堆最大的內存

如何設置最合理呢？

首先我們要知道堆內存設置的越大，ES可用的堆就越大，同時呢，可用的緩存空間就越大，但是不能無限大，因為這樣會浪費大量的內存，太多的堆內存可能會系統垃圾回收機制異常；

優化準則：

將最小堆(xms)和最大堆(xmx)設置為相同值即可，這樣可以防止內存堆運行的有所變動；

內存堆的值不要超過系統物理內存的50%(可以等于實際物理內存的一半)，以確保有足夠的物理內存給內核文件系統使用；

ES堆內存大小為什么不能超過物理 內存的50%？

除了堆內存設置過大會造成資源浪費之后，還有一個原因，

堆內存對于ES來說是個不可缺少的部分，能夠對提高數據的執行效率，還有一個內存使用者，那就是是-lucene

Lucene是一個開源的全文檢索引擎工具 ，而我們的ES底層是基于Lucene來實現的豐富的檢索功能；Lucene的性能依賴于操作系統之間的交互，如何說我們把可用的內存都給了ES的話，那么Lucene還有剩余的內存空間嗎？這將會嚴重的影響性能；因此，我們最多只能將50%的可用內存資源分配給ES堆內存，剩下的50%留給Lucene了

ps：這里注意一下，我們的Luceen使用的是物理內存剩余的50%，它并不使用堆內存；切記不要與ES堆內存混淆

1.2：ES所在操作系統的內存優化

可通過禁用swap·分區，如果是混合服務器的話可通過減低swap分區的使用積極性；

/dev/mapper/centos-swap swap swap defaults 0 0? ? #進入/etc/fstab/.將其注釋，永久生效；臨時生效直接swapoff -a即可

降低swao分區使用積極性，這句話是什么意思呢？首先我們要知道，系統的內存使用空間到達一定的閥值時候，便會占用swap空間，這個時候我們是可以控制這個閥值的；swappiness=0表示最大限度使用物理內存，也就是說，當物理內存使用100%之后，才去使用swap交換分區；

如何設置呢？

比如說，我們現在需要設置系統內存大小閥值，當物理內存使用90%的時候，只剩10%的物理內存，再去使用swap空間

100-10=90%

# vim /etc/sysctl.conf

vm.swappiness = 10

#修改之后執行sysctl -p生效

#cat /proc/sys/vm/swappiness

10

1.3：·硬件優化(硬盤類型/raid類型)

服務器硬盤選用SSD硬盤，配置成raid 0陣列以獲得更佳的IO性能；

【Logstash優化】

logstash.yml配置優化：

1)pipline.workers：控制output或filter插件的工作線程數(只能設置為正整數)，因為logstash中的grok正則及其消耗系統計算字眼，同時filte也會存在瓶頸，此時增加工作線程，以提高性能

2)pipeline.batch.size：批量執行event的最大值，該值用于input批量處理事件值，再打包發送給filter和output.可以提高性能，但是會增加額外的內存開銷

3)pipeline.batch.delay:批量處理事件的最大等待值(input需要按照batch處理的最大發送到消息隊列，需要設置一個超時事件)

Logstash同樣運行在JVM內存中，關于jvm內存的配置原則不在述說和，和上述ES一樣；

堆內存一般要求初始值和最大值設置一致，防止動態調整堆內存大小的消耗；jvm內存的分配設置太大會拖慢系統，浪費資源，設置太小的話Logstash無法啟動

【Kafka的性能優化】

既然我們在ELK中用到了Kafka，那么優化也是必須的，先來回顧一下，kafka是一個高吞吐分布式消息系統，并且提供了持久化，高性能主要表現在以下兩點：

第一，磁盤的連續讀寫性能遠遠高于隨機讀寫

第二：拆分一個topic主題分配多個partition分區，這樣可以提供并發和吞吐量；

另外，我們的kafka消息讀寫為什么這么高效？原因何在？

我們要知道linux系統內核為文件設置一個緩存機制，所有對文件讀寫的數據內容都會存在著緩存中，稱之為：page cache(頁緩存)

緩存 機制：

當一個文件發生讀操作時，系統會先去page cache頁緩存中讀取，如果找到，便會直接返回，沒有緩存中沒有需要讀取的數據內容，那么會去磁盤中讀取，此時系統寫入一份到緩存中。，最終返回數據；

當有寫操作時，亦是如此，數據會首先寫入緩存并進行標識，等待批量保存到文件系統，減少了磁盤的操作次數和系統額外開銷

我們的kafka就是依賴于這種機制，數據的讀寫交互便是在緩存中完成接力，不會因為kafka寫入磁盤數據影響吞吐量，這就是為什么kafka非常高效的根本原因

降低文件系統頁面緩存

主要針對于下面兩個參數

vm.dirty_background_ratio：? #指定了當文件系統緩存頁數量達到系統內存的百分比閥值的時候，便會觸發pdflush/flush/kdmflush后臺運行寫進程，將一定的緩存數據寫入磁盤中

vm.dirty_ratio:? ? ? ? ? ? ?#指定了當文件系統緩存頁熟練達到系統設定的百分比閥值時候，為了保證避免數據丟失，系統不得不開始處理緩存頁面，在這個過程中，可能很多應用會因為系統刷新內存數據，導致應用IO進程阻塞；這個時候呢，系統就會轉入同時處理頁緩存和堵塞應用

ps:建議將vm.dirty_background_ratio設置為5%，vm.diry_ratio設置為10%；根據不同環境，需要進行測試而定

topic的拆分：

kafka讀寫單位是partition，將一個topic分配到多個partition可以提高系統的吞吐量，但前提是將不同的partition分配到不同的磁盤上，如果多個partition位于一個磁盤上就會出現多個進程同時對磁盤上多個文件進行讀寫，這樣造成了磁盤的頻繁調度，破壞了磁盤讀寫的連續性

如何實現將不同的partition分配到不同的磁盤上呢？

我們可以將磁盤上的多個目錄配置到broker的log.dirs上

# vim /usr/local/kafka/config/server.properties

log.dirs=/disk1/logs,/disk2/logs/,/disk3/logs#kafaka在新建partition時，會將partition分布在paritition最少的目錄上面，因此，不能將同一個磁盤上的多個目錄設置到logs.dirs上

kafka配置參數優化：

num.network.threads=3? #broker處理消息的最大線程數

num.io.threads=8? ? ?#broker處理磁盤IO的線程數

一般num.network.threads主要就是處理網絡IO，讀寫緩沖區數據，基本沒有IO等待，配置線程數量為CPU核數n+1

num.io.threads主要進行磁盤IO操作，高峰期可以能有些等待，因此配置較大一點，配置線程數量為CPU核數的2~3倍即可

日志保留策略優化：

kafka被打量的寫入日志消息后，會生成打量的數據文件，也就是日志消息，這樣會占用大量的磁盤空間。

減少日志保留時間，通過log.retention.hours設置，單位是小時

log.retention.hours=72? ? #保留日志數據的時間范圍，過后便會刪除

段文件大小優化

段文件配置大小為1GB，這樣有利于快速的回收磁盤空間，重啟kafka加載也會更快，如果說文件過小，那么文件數量就會較多，kafka啟動的時候回單線掃描(log.dir)下的所有文件，文件較多啟動較慢，會影響性能，

log.segment.bytes=1073741824? ? #段文件最大大小，超過該閥值，會自動創建新的日志段

Logs數據文件寫盤策略優化

為了大幅度提高producer寫入吞吐量，需要制定定期批量寫入文件磁盤的計劃

每當producer寫入10000條消息事，便會將數據寫入磁盤，

#log.flush.interval.messages=10000? ?#強行將數據刷新到磁盤之前所能接受的消息數

#log.flush.interval.ms=1000 ?#在強制刷新之前，消息可以停留在日志中最長的時間(單位毫秒，每間隔1秒時間，刷數據到磁盤中)

【Filebeat優化】

還記得我們為什么要使用filebeat采集日志數據嗎？那是因為Logstash功能雖然強大，但是它依賴于java，在海量日志環境中，logstash進程會消耗更多的系統資源，這將嚴重的影響業務系統的性能，而我們說的filebeat是基于go語言，沒有任何依賴，配置簡單，占用系統資源少，比logstash更加的輕量級；但是有點還是需要注意。在日志量比較大的情況下或者日志異常突發時，filebeat也會占用大量的系統內存開銷，所以說這方面的優化，也是至關重要的

內存優化，Filebeat內存收到兩種模式的限制，一種是內存模式，第二種是文件緩存模式，任選其一即可

queue.mem:

events:4096#表示隊列可以存儲的事件數量。默認值是4096個事件。

flush.min_events:512#發布所需的最小事件數量。 默認值是0，表示可以直接輸出發布事件，而無需額外的等待時間。 如果設置為非0，必須等待，在滿足指定的事件數量后才能輸出發布事件。

flush.timeout: 5s #表示最早的可用事件在隊列中等待的最長時間，超過這個時間，立即輸出發布事件，默認值是0s，表示立即可以輸出發布事件

配置含義：該隊列能夠存儲4096個事件數量，如果超過512個可用的事件則在隊列中等待5秒之后，將事件轉發至output輸出

文件緩存模式調優

此模式可以限制最大的使用內存

ueue.spool:

file:

path:"${path.data}/spool.dat"#Spool file的路徑

size: 512MiB #Spool file的大小，也就是緩沖區的大小。

page_size: 16KiB #文件的頁面大小。默認值為4096(4KiB)。

write:

buffer_size: 10MiB #寫緩沖區大小。一旦超過緩沖區大小，就刷新寫緩沖區。

flush.timeout: 5s #寫緩沖區中最舊事件的最長等待時間。如果設置為0，則在write.flush.events或write.buffer_size滿足時寫入緩沖區僅刷新一次。

flush.events:1024 #緩沖事件的數量。一旦達到上限，就刷新寫緩沖區。

文件系統資源的優化：

fliebeat對日志的采集有一個弊端，那就是只要發現日志就會堅持把日志收集完，否則的話就會永久鎖住文件句柄不放手，就算日志文件被刪除，也不會放手，這就導致了文件系統大量的文件句柄被filebeat占用，導致收集日志異常，故此對其進行優化

1)close_inactive:1m? ?#表示沒有新日志采集后，多長時間關閉文件句柄；(也就是說無數據采集時候，等待多長時間便會自動關閉文件句柄)，這里設置1分鐘

2)close_timeout:3h? ? #限定的數據傳輸時間，這里是指傳輸了三小時就強行關閉文件句柄，該配置解決了文件句柄耗盡的問題，但也存在著數據丟失的風險，需要綜合考慮

3)clean_inactive:72h? ?#表示多久會清理一次文件描述符在registry文件，默認值0表示不清理，如果不清理，registry會變大，帶來性能問題

4)ignore_older：70h? ? #設置了clean_inactive，就需要設置ignore_older,并且保證該值小于clean_inactive

[小結]

關于ELK綜合方面的優化，也就介紹這么多了，其實ELK的優化方面很少，我個人覺得已經足夠了，主要就是針對不同的環境和業務需求進行調參，調整適合自己的才是最好的，當然前提是你要知參數的各個含義；優化也是一個綜合的技術，

無論什么服務，我們能做到的優化點無非就是硬件，系統以及服務配置的調參；逐步測試，一步步達到最優的狀態；這是進行優化的基本策略和思路(ps：本章可能還有很多優化策略沒有寫到，歡迎大佬填坑補充~)