在生產環境中，我們為了更好的服務於業務，通常會通過優化的手段來實現服務對外的性能最大化，節省系統性能開支；關注我的朋友們都知道，前段時間一直在搞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：本章可能還有很多優化策略沒有寫到，歡迎大佬填坑補充~）