在生產(chǎn)環(huán)境中，我們?yōu)榱烁玫姆?wù)于業(yè)務(wù)，通常會(huì)通過優(yōu)化的手段來實(shí)現(xiàn)服務(wù)對(duì)外的性能最大化，節(jié)省系統(tǒng)性能開支；關(guān)注我的朋友們都知道，前段時(shí)間一直在搞ELK，同時(shí)也記錄在了個(gè)人的博客篇章中，從部署到各個(gè)服務(wù)應(yīng)用的采集都做了詳細(xì)的介紹，但是并沒有關(guān)于ELK方面的優(yōu)化，那么，我們對(duì)于這些日志分析平臺(tái)，我們?nèi)绾稳?yōu)化呢？優(yōu)化的手段又有哪些呢？下面請(qǐng)聽我娓娓道來~

【ES優(yōu)化】

ES在前面的部署環(huán)節(jié)(https://www.cnblogs.com/bixiaoyu/p/9460554.html)已經(jīng)簡(jiǎn)單了提到調(diào)優(yōu)，但是不全；Elasticsearch作為數(shù)據(jù)持久化存儲(chǔ)環(huán)節(jié)，主要就是接受采集端發(fā)送過來的數(shù)據(jù)，執(zhí)行寫磁盤，建立索引庫(kù)，最后將結(jié)構(gòu)化的數(shù)據(jù)存儲(chǔ)到ES集群上，這是ES所需要完成的工作

1.1:JVM內(nèi)存的優(yōu)化

首先我們需要了解什么是jvm內(nèi)存？作用是什么？

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

我們?cè)O(shè)置堆內(nèi)存主要就是創(chuàng)建實(shí)例對(duì)象，讓所有對(duì)象實(shí)例和數(shù)據(jù)都在堆上進(jìn)程分配，可以動(dòng)態(tài)的分配內(nèi)存大小；

-Xms1g? ? ?#設(shè)置堆最小的內(nèi)存

-Xmx1g? ? #設(shè)置堆最大的內(nèi)存

如何設(shè)置最合理呢？

首先我們要知道堆內(nèi)存設(shè)置的越大，ES可用的堆就越大，同時(shí)呢，可用的緩存空間就越大，但是不能無限大，因?yàn)檫@樣會(huì)浪費(fèi)大量的內(nèi)存，太多的堆內(nèi)存可能會(huì)系統(tǒng)垃圾回收機(jī)制異常；

優(yōu)化準(zhǔn)則：

將最小堆(xms)和最大堆(xmx)設(shè)置為相同值即可，這樣可以防止內(nèi)存堆運(yùn)行的有所變動(dòng)；

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

ES堆內(nèi)存大小為什么不能超過物理 內(nèi)存的50%？

除了堆內(nèi)存設(shè)置過大會(huì)造成資源浪費(fèi)之后，還有一個(gè)原因，

堆內(nèi)存對(duì)于ES來說是個(gè)不可缺少的部分，能夠?qū)μ岣邤?shù)據(jù)的執(zhí)行效率，還有一個(gè)內(nèi)存使用者，那就是是-lucene

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

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

1.2：ES所在操作系統(tǒng)的內(nèi)存優(yōu)化

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

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

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

如何設(shè)置呢？

比如說，我們現(xiàn)在需要設(shè)置系統(tǒng)內(nèi)存大小閥值，當(dāng)物理內(nèi)存使用90%的時(shí)候，只剩10%的物理內(nèi)存，再去使用swap空間

100-10=90%

# vim /etc/sysctl.conf

vm.swappiness = 10

#修改之后執(zhí)行sysctl -p生效

#cat /proc/sys/vm/swappiness

10

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

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

【Logstash優(yōu)化】

logstash.yml配置優(yōu)化：

1)pipline.workers：控制output或filter插件的工作線程數(shù)(只能設(shè)置為正整數(shù))，因?yàn)閘ogstash中的grok正則及其消耗系統(tǒng)計(jì)算字眼，同時(shí)filte也會(huì)存在瓶頸，此時(shí)增加工作線程，以提高性能

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

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

Logstash同樣運(yùn)行在JVM內(nèi)存中，關(guān)于jvm內(nèi)存的配置原則不在述說和，和上述ES一樣；

堆內(nèi)存一般要求初始值和最大值設(shè)置一致，防止動(dòng)態(tài)調(diào)整堆內(nèi)存大小的消耗；jvm內(nèi)存的分配設(shè)置太大會(huì)拖慢系統(tǒng)，浪費(fèi)資源，設(shè)置太小的話Logstash無法啟動(dòng)

【Kafka的性能優(yōu)化】

既然我們?cè)贓LK中用到了Kafka，那么優(yōu)化也是必須的，先來回顧一下，kafka是一個(gè)高吞吐分布式消息系統(tǒng)，并且提供了持久化，高性能主要表現(xiàn)在以下兩點(diǎn)：

第一，磁盤的連續(xù)讀寫性能遠(yuǎn)遠(yuǎn)高于隨機(jī)讀寫

第二：拆分一個(gè)topic主題分配多個(gè)partition分區(qū)，這樣可以提供并發(fā)和吞吐量；

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

我們要知道linux系統(tǒng)內(nèi)核為文件設(shè)置一個(gè)緩存機(jī)制，所有對(duì)文件讀寫的數(shù)據(jù)內(nèi)容都會(huì)存在著緩存中，稱之為：page cache(頁(yè)緩存)

緩存 機(jī)制：

當(dāng)一個(gè)文件發(fā)生讀操作時(shí)，系統(tǒng)會(huì)先去page cache頁(yè)緩存中讀取，如果找到，便會(huì)直接返回，沒有緩存中沒有需要讀取的數(shù)據(jù)內(nèi)容，那么會(huì)去磁盤中讀取，此時(shí)系統(tǒng)寫入一份到緩存中。，最終返回?cái)?shù)據(jù)；

當(dāng)有寫操作時(shí)，亦是如此，數(shù)據(jù)會(huì)首先寫入緩存并進(jìn)行標(biāo)識(shí)，等待批量保存到文件系統(tǒng)，減少了磁盤的操作次數(shù)和系統(tǒng)額外開銷

我們的kafka就是依賴于這種機(jī)制，數(shù)據(jù)的讀寫交互便是在緩存中完成接力，不會(huì)因?yàn)閗afka寫入磁盤數(shù)據(jù)影響吞吐量，這就是為什么kafka非常高效的根本原因

降低文件系統(tǒng)頁(yè)面緩存

主要針對(duì)于下面兩個(gè)參數(shù)

vm.dirty_background_ratio：? #指定了當(dāng)文件系統(tǒng)緩存頁(yè)數(shù)量達(dá)到系統(tǒng)內(nèi)存的百分比閥值的時(shí)候，便會(huì)觸發(fā)pdflush/flush/kdmflush后臺(tái)運(yùn)行寫進(jìn)程，將一定的緩存數(shù)據(jù)寫入磁盤中

vm.dirty_ratio:? ? ? ? ? ? ?#指定了當(dāng)文件系統(tǒng)緩存頁(yè)熟練達(dá)到系統(tǒng)設(shè)定的百分比閥值時(shí)候，為了保證避免數(shù)據(jù)丟失，系統(tǒng)不得不開始處理緩存頁(yè)面，在這個(gè)過程中，可能很多應(yīng)用會(huì)因?yàn)橄到y(tǒng)刷新內(nèi)存數(shù)據(jù)，導(dǎo)致應(yīng)用IO進(jìn)程阻塞；這個(gè)時(shí)候呢，系統(tǒng)就會(huì)轉(zhuǎn)入同時(shí)處理頁(yè)緩存和堵塞應(yīng)用

ps:建議將vm.dirty_background_ratio設(shè)置為5%，vm.diry_ratio設(shè)置為10%；根據(jù)不同環(huán)境，需要進(jìn)行測(cè)試而定

topic的拆分：

kafka讀寫單位是partition，將一個(gè)topic分配到多個(gè)partition可以提高系統(tǒng)的吞吐量，但前提是將不同的partition分配到不同的磁盤上，如果多個(gè)partition位于一個(gè)磁盤上就會(huì)出現(xiàn)多個(gè)進(jìn)程同時(shí)對(duì)磁盤上多個(gè)文件進(jìn)行讀寫，這樣造成了磁盤的頻繁調(diào)度，破壞了磁盤讀寫的連續(xù)性

如何實(shí)現(xiàn)將不同的partition分配到不同的磁盤上呢？

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

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

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

kafka配置參數(shù)優(yōu)化：

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

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

一般num.network.threads主要就是處理網(wǎng)絡(luò)IO，讀寫緩沖區(qū)數(shù)據(jù)，基本沒有IO等待，配置線程數(shù)量為CPU核數(shù)n+1

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

日志保留策略優(yōu)化：

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

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

log.retention.hours=72? ? #保留日志數(shù)據(jù)的時(shí)間范圍，過后便會(huì)刪除

段文件大小優(yōu)化

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

log.segment.bytes=1073741824? ? #段文件最大大小，超過該閥值，會(huì)自動(dòng)創(chuàng)建新的日志段

Logs數(shù)據(jù)文件寫盤策略優(yōu)化

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

每當(dāng)producer寫入10000條消息事，便會(huì)將數(shù)據(jù)寫入磁盤，

#log.flush.interval.messages=10000? ?#強(qiáng)行將數(shù)據(jù)刷新到磁盤之前所能接受的消息數(shù)

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

【Filebeat優(yōu)化】

還記得我們?yōu)槭裁匆褂胒ilebeat采集日志數(shù)據(jù)嗎？那是因?yàn)長(zhǎng)ogstash功能雖然強(qiáng)大，但是它依賴于java，在海量日志環(huán)境中，logstash進(jìn)程會(huì)消耗更多的系統(tǒng)資源，這將嚴(yán)重的影響業(yè)務(wù)系統(tǒng)的性能，而我們說的filebeat是基于go語言，沒有任何依賴，配置簡(jiǎn)單，占用系統(tǒng)資源少，比logstash更加的輕量級(jí)；但是有點(diǎn)還是需要注意。在日志量比較大的情況下或者日志異常突發(fā)時(shí)，filebeat也會(huì)占用大量的系統(tǒng)內(nèi)存開銷，所以說這方面的優(yōu)化，也是至關(guān)重要的

內(nèi)存優(yōu)化，Filebeat內(nèi)存收到兩種模式的限制，一種是內(nèi)存模式，第二種是文件緩存模式，任選其一即可

queue.mem:

events:4096#表示隊(duì)列可以存儲(chǔ)的事件數(shù)量。默認(rèn)值是4096個(gè)事件。

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

flush.timeout: 5s #表示最早的可用事件在隊(duì)列中等待的最長(zhǎng)時(shí)間，超過這個(gè)時(shí)間，立即輸出發(fā)布事件，默認(rèn)值是0s，表示立即可以輸出發(fā)布事件

配置含義：該隊(duì)列能夠存儲(chǔ)4096個(gè)事件數(shù)量，如果超過512個(gè)可用的事件則在隊(duì)列中等待5秒之后，將事件轉(zhuǎn)發(fā)至output輸出

文件緩存模式調(diào)優(yōu)

此模式可以限制最大的使用內(nèi)存

ueue.spool:

file:

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

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

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

write:

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

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

flush.events:1024 #緩沖事件的數(shù)量。一旦達(dá)到上限，就刷新寫緩沖區(qū)。

文件系統(tǒng)資源的優(yōu)化：

fliebeat對(duì)日志的采集有一個(gè)弊端，那就是只要發(fā)現(xiàn)日志就會(huì)堅(jiān)持把日志收集完，否則的話就會(huì)永久鎖住文件句柄不放手，就算日志文件被刪除，也不會(huì)放手，這就導(dǎo)致了文件系統(tǒng)大量的文件句柄被filebeat占用，導(dǎo)致收集日志異常，故此對(duì)其進(jìn)行優(yōu)化

1)close_inactive:1m? ?#表示沒有新日志采集后，多長(zhǎng)時(shí)間關(guān)閉文件句柄；(也就是說無數(shù)據(jù)采集時(shí)候，等待多長(zhǎng)時(shí)間便會(huì)自動(dòng)關(guān)閉文件句柄)，這里設(shè)置1分鐘

2)close_timeout:3h? ? #限定的數(shù)據(jù)傳輸時(shí)間，這里是指?jìng)鬏斄巳r(shí)就強(qiáng)行關(guān)閉文件句柄，該配置解決了文件句柄耗盡的問題，但也存在著數(shù)據(jù)丟失的風(fēng)險(xiǎn)，需要綜合考慮

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

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

[小結(jié)]

關(guān)于ELK綜合方面的優(yōu)化，也就介紹這么多了，其實(shí)ELK的優(yōu)化方面很少，我個(gè)人覺得已經(jīng)足夠了，主要就是針對(duì)不同的環(huán)境和業(yè)務(wù)需求進(jìn)行調(diào)參，調(diào)整適合自己的才是最好的，當(dāng)然前提是你要知參數(shù)的各個(gè)含義；優(yōu)化也是一個(gè)綜合的技術(shù)，

無論什么服務(wù)，我們能做到的優(yōu)化點(diǎn)無非就是硬件，系統(tǒng)以及服務(wù)配置的調(diào)參；逐步測(cè)試，一步步達(dá)到最優(yōu)的狀態(tài)；這是進(jìn)行優(yōu)化的基本策略和思路(ps：本章可能還有很多優(yōu)化策略沒有寫到，歡迎大佬填坑補(bǔ)充~)

總結(jié)

以上是生活随笔為你收集整理的logstash 吞吐量优化_1002-谈谈ELK日志分析平台的性能优化理念的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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