ELK群集分層優(yōu)化策略

■ 河南 許紅軍

編者按：ELK由Elasticsearch、Logstash和Kibana等部分組件組成，可以將各種日志進行過濾和集中化存放，便于用戶對其進行實時檢索和分析。Elasticsearch是實時的分布式搜索和分析引擎，支持群集和分片功能。Logstash是輕量級的開源的日志收集處理框架，Kibana是開源的數(shù)據(jù)分析可視化平臺，可以為對得到的日志數(shù)據(jù)進行搜索、匯總和多維度分析。

ELK集群的分層部署

對于實際的ELK群集來說，其實際上是分層部署的，大體分為數(shù)據(jù)采集層、消息隊列層、數(shù)據(jù)分析層、數(shù)據(jù)持久化存儲層和數(shù)據(jù)查詢顯示層。在數(shù)據(jù)采集層部署的是Web服務(wù)器，在其上安裝了Filebeat組件，用來收集Web日志信息。使用Filebeat的優(yōu)點在于降低了收集日志對業(yè)務(wù)系統(tǒng)資源的消耗。這些Filebeat組件實際上是作為第一級的Logstash使用，其將收集到的日志信息發(fā)送給Kafka消息隊列。

在消息隊列層部署了Kafka和Zookeeper群集，用來管理消息隊列，這可以保證ELK收集日志數(shù)據(jù)的安全性和穩(wěn)定性，降低了網(wǎng)絡(luò)閉塞和丟失數(shù)據(jù)的可能。在數(shù)據(jù)分析層部署了Logstash服務(wù)器，從消息隊列層實時拉取原始日志，按照預(yù)設(shè)規(guī)則對其進行分析和過濾，之后將其發(fā)送給Elasticsearch集群。

在數(shù)據(jù)持久化層部署Elasticsearch集群，用來對接收的日志進行結(jié)構(gòu)化處理和存儲操作，即在接收到logstash發(fā)送的數(shù)據(jù)后，執(zhí)行寫磁盤、建索引庫等操作。因為Elasticsearch要存儲和索引大量數(shù)據(jù)，將其配置成群集模式，從整體上提高了ELK的高效性、擴展性和吞吐量能力。在數(shù)據(jù)查詢顯示層上部署了Kibana服務(wù)器，根據(jù)Elasticsearch集群存儲的日志信息，提供可視化數(shù)據(jù)查詢和展示服務(wù)。

優(yōu)化數(shù)據(jù)采集層

使用Filebeat這一文本日志收集器,可以從目標(biāo)服務(wù)器上收集各種日志信息，并將其發(fā)送給Logsta、Elasticsearch、Kafka等對象。Filebeat具有易于使用，消耗資源較少以及功能實用等特點。Filebeat主要由Prospector（探測器）和Harvester（收集器）組成。Filebeat作為日志采集工具，部署到生產(chǎn)服務(wù)器上，如果對其配置不當(dāng)，就會造成其占用過多的系統(tǒng)資源，影響生產(chǎn)服務(wù)器的正常運行。

因為在日志量很大或者日志突發(fā)異常等情況下，F(xiàn)ilebeat必然會占用大量的系統(tǒng)資源。例如，其當(dāng)單條日志過大時，F(xiàn)ilebeat可能會占用幾百兆甚至十幾GB的內(nèi)存。Filebeat提供了內(nèi)存模式和文件緩存模式兩種內(nèi)存限制方法，可以根據(jù)實際情況進行選擇。一般來說，使用內(nèi)存模式即可。進入“/opt/app/filebeat”目錄，打開其中的“filebeat.yml”文件，可以修改其配置信息，這里假設(shè)Filebeat安裝在“/opt/app/filebeat”目錄中。

對于內(nèi)存模式來說，所有事件（Events）都是保存在內(nèi)存中的，該模式只能限制事件數(shù)，無法限制最大使用內(nèi)存，這意味著可能會因為日志長度導(dǎo)致內(nèi)存使用大為增加。在配置文件中的“queue.mem:”欄中的“events:4096”行中可以修改隊列可以存儲的事件數(shù)量。默認(rèn)為4096個事件。

在“flush.min_ events:512”欄中可以修改發(fā)布所需的最小事件數(shù)量，默認(rèn)值為0，表示無需額外的等待時間就可以直接輸出發(fā)布事件。這里設(shè)置為“512”，表示必須滿足指定的事件數(shù)量后才能輸出發(fā)布事件。

在“flush.timeout:5s”行中可以設(shè)置最早的可用事件在隊列中等待的最長時間，默認(rèn)為0 s，這里設(shè)置為5 s。超過這個時間立即輸出發(fā)布事件。對于文件緩存模式來說，可以限制最大使用內(nèi)存量。在配置文件中的“queue.spool:”小節(jié)的“file:”欄下的中“path:"${path.data}/spool.dat"”欄中可以設(shè)置Spool file的保存位置，在“size:512MiB”欄中可以修改緩沖區(qū)大小。在“page_size:16KiB”欄中可以設(shè)置文件的頁面大小，默認(rèn)為4 KiB。在“write:”欄下的“buffer_size:10MiB”欄中可以設(shè)置寫緩沖區(qū)大小，如果超過該值就刷新寫緩沖區(qū)。在“flush.timeout:5s”欄中可以設(shè)置寫緩沖區(qū)中最早事件的最長等待時間，默認(rèn)為0 s，意味著write.flush.events或write.buffer_size滿足時寫入緩沖區(qū)且僅刷新一次。

在“flush.events:1024”欄中可以修改緩沖事件的數(shù)量，如果超過該值就刷新寫緩沖區(qū)。上述配置的含義是將所有的事件存儲到磁盤的緩沖區(qū)中，如果寫入10 MiB內(nèi)容或達到1024個事件，則刷新寫入緩沖區(qū)。如果最早的可用事件在寫緩沖區(qū)中等待5 s，也會刷新寫入緩沖區(qū)。在“max_procs:4”欄中可以設(shè)置Filebeat可以使用的CPU最大核心數(shù)量，這里為4個CPU核心。

當(dāng)Filebeat在收集日志時，會占用文件系統(tǒng)的大量文件句柄。這很可能導(dǎo)致日志日志收集異常故障，因此必須對Filebeat的日志收集策略進行優(yōu)化處理。在配置文件中的“close_inactive:1m”行可以修改采集不到新日志后，多長時間關(guān)閉文件句柄，默認(rèn)5 min，這里將其設(shè)置為1 min，來加快文件句柄關(guān)閉操作。

在“close_timeout:3h”欄中可以修改在多長時間沒有傳輸完成的話，就強行關(guān)閉文件句柄，可以解決文件句柄耗盡的問題，這里設(shè)置為3 h。注意，這可能存在丟失數(shù)據(jù)的風(fēng)險。在“clean_inactive:72h”欄中可以設(shè)置經(jīng)過多長時間，才清理存儲在registry文件中的文件描述信息，采集過的日志文件會在registry保存描述信息。默認(rèn)值為0表示不清理，這會導(dǎo)致registry體積過大影響性能。啟用了該項后必須啟用“ignore_older:70h”項，而且要保證前者的值要大于后者。

優(yōu)化消息隊列層

Filebeat將日志實時的傳輸?shù)絢afka集群中，kafka消息隊列可以對其進行緩沖和存儲，即Filebeat作為生產(chǎn)者將日志推送到kafka集群。Kafka是高吞吐量的分布式發(fā)布/訂閱消息系統(tǒng)，能夠在生產(chǎn)者與消費者之間建立通信的橋梁，其實質(zhì)上是解決了在不同系統(tǒng)中如何傳遞消息的問題。

Kafka提供了持久化、高性能等特征，具有磁盤連續(xù)讀寫性能遠遠高于隨機讀寫的特點，可以將將一個Topic拆分多個Partition來提高并發(fā)和吞吐量。

對于Linux來說，針對文件系統(tǒng)設(shè)置了Page Cache，將文件讀寫的數(shù)據(jù)緩存起來。執(zhí)行“free”命令，會顯示Page Cache的容量。當(dāng)讀取文件時，會先在Page Cache中查找，如果沒有找到才會從磁盤讀取文件。當(dāng)寫文件時，系統(tǒng)先將數(shù)據(jù)寫入Page Cache中，并將該頁打上Dirty標(biāo)志，并會定期批量將Page Cache的數(shù)據(jù)保存到文件系統(tǒng)中。對于Kafka來說，非常依賴底層系統(tǒng)提供的Page Cache功能。

即Kafka先將數(shù)據(jù)寫到PageCache的，如果消費者一直在消費，而且速度大于等于kafka的生產(chǎn)者發(fā)送數(shù)據(jù)的速度，那么消費者就會一直從Page Cache讀取數(shù)據(jù)，讀寫操作都在內(nèi)存中完成的，并不涉及到磁盤訪問，所以Kafka具有非常高效的運作能力。因此，對內(nèi)存進行優(yōu)化，對于保證Kafka的運行就很重要了。對于Page Cache進行優(yōu)化，主要包含“vm.dirty_background_ratio”和“vm.dirty_ratio”參數(shù)。

執(zhí)行“vim/etc/sysctl.conf”命令，在該文件中添加“vm.dirty_background_ratio=5”，“vm.dirty_ratio=10”行。

前者指定了當(dāng)文件系統(tǒng)緩存臟頁數(shù)量達到系統(tǒng)內(nèi)存百分之多少時（默認(rèn)10 %）就會觸發(fā)pdflush等后臺回寫進程運行，將一定緩存的臟頁異步地刷入磁盤。

后者指定了當(dāng)文件系統(tǒng)緩存臟頁數(shù)量達到系統(tǒng)內(nèi)存百分之多少時（默認(rèn)20 %），系統(tǒng)必須開始處理緩存臟頁，因為此時臟頁數(shù)量已經(jīng)比較多，為了避免數(shù)據(jù)丟失需要將一定臟頁刷入磁盤。因為Kafka需要的堆內(nèi)存比較小，所以可以將60 %以上的物理內(nèi)存給系統(tǒng)使用，便于分配Page Cache。

對于Kafka來說，讀寫的單位是Partition分區(qū)，將一個Topic拆分為多個Partition可以有效提高系統(tǒng)的吞吐量，但是不同的partition要分布在不同在磁盤上。否則將破壞磁盤讀寫的連續(xù)性。

進入“/opt/app/Kafka/config”目錄，打開“server.properties”文件，可以對Kafka的配置進行調(diào)整。

例如，在“l(fā)og.dirs”參數(shù)中設(shè)置Kafka保存數(shù)據(jù)的目錄。例如，將其修改為“l(fā)og.dirs=/xxx/logs,/yyy/logs,/zzz/logs”，將磁盤的多個目錄配置到Broker主機的不同位置。其中的“xxx”等表示具體的磁盤名稱。

這樣，當(dāng)Kafka新建Par tition時，就會將其分布在Partition最少的目錄上。在“num.network.threads”行中可以設(shè)置Broker處理消息的最大線程數(shù)，在“num.io.threads”欄中可以設(shè)置Broker處理磁盤IO的線程數(shù)。在優(yōu)化時可以將前者設(shè)置為CPU的數(shù)量加上1，對于后者可以設(shè)置為CPU數(shù)量的2到3倍。在“l(fā)og.retention.hours=72”欄中可以設(shè)置日志保留時間，例如將其設(shè)置為3天，避免大量日志消耗磁盤空間。在“l(fā)og.segment.bytes=2147483648”欄中可以修改段文件大小，這有利于快速回收磁盤空間，這里設(shè)置為2 GB。

在“l(fā)og.flush.interval.messages=10000”欄中可以修改當(dāng)Producer寫入多少條消息時，刷數(shù)據(jù)到磁盤，這里設(shè)置為10000。在“l(fā)og.flush.interval.ms=1000”欄中設(shè)置每隔多長時間刷數(shù)據(jù)到磁盤，這里為1 s。

在“num.replica.fetchers”欄中設(shè)置拉取線程數(shù)，將其增加可以提高follower的I/O并發(fā)度，單位時間內(nèi)leader持有更多請求。在“replica.fetch.min.bytes”欄中設(shè)置拉取最小字節(jié)數(shù)。在“replica.fetch.max.bytes”欄中設(shè)置拉取最大字節(jié)數(shù)，前者設(shè)置為1，后者設(shè)置為5比較合適。在“replica.fetch.wait.max.ms”欄中最大等待時間，表示follow拉取的頻率，如果拉取頻率過高會導(dǎo)致CPU占用率過高。

優(yōu)化數(shù)據(jù)分析層

當(dāng)Filebeat將數(shù)據(jù)推送到kafka后，kafka不會主動將數(shù)據(jù)推送到logstash，Logstash必須主動從kafka集群拉取日志信息，因此Logstash相當(dāng)于Kafka的消費者。

對于數(shù)據(jù)收集層來說，部署了Logstash服務(wù)器，其主要實現(xiàn)日志的收集和分析工作，主要實現(xiàn)數(shù)據(jù)的接收、過濾分析和轉(zhuǎn)換操作、并將其輸出到指定的位置。

進入“/opt/app/logsta sh/”目錄，在其中打來名為“l(fā)ogstash.yml”的配置文件，在“pipeline.workers”欄中設(shè)置控制Output或Filter插件的工作線程數(shù)。

因為Logstash的GROK正則解析非常消耗計算資源，所以增加Filter插件的工作線程數(shù)，可以有效以提高性能。例如，將該線程數(shù)設(shè)置大于或者等于CPU的核心數(shù)。在“pipeline.batch.size”欄中設(shè)置批量執(zhí)行Event的最大值，適當(dāng)增加該值，可以在一定程序上提高其性能。

當(dāng)然，這需要消耗一定的內(nèi)存資源。在“pipeline.batch.delay”欄中可以設(shè)置批量處理事件的最大等待值，Input插件需要按照批量執(zhí)行事件最大值，來將數(shù)據(jù)發(fā)送到消息隊列，因此需要為其設(shè)置最大超時時間。

打開Logstash配置目錄中的“jvm.options”文件，在其中的“-Xms1g”，“-Xmx1g”中顯示JVM堆內(nèi)存的最大值和最小值均為1 GB。這是默認(rèn)的配置，可能無法滿足實際的需要。

因此，一般將其設(shè)置為實際物理內(nèi)存的一般即可，兩者大小要保持一致。當(dāng)然，如果堆內(nèi)存設(shè)置的太大，會對系統(tǒng)正常運行造成不利影響，如果設(shè)置的太小，也會造成其性能降低。例如，將其設(shè)置為“-Xms16g”，“-Xmx16g”，建議最大不要超過32 GB，對于JVM堆內(nèi)存的調(diào)試需要依次添加，最終找到最合適的內(nèi)存量為止。

優(yōu)化數(shù)據(jù)持久化存儲層

對于Elasticsearch來說，其本身作為Java應(yīng)用，需要使用到JVM堆內(nèi)存，對其進行優(yōu)化調(diào)整，可以保證Elasticsearch順暢運作。在Java中堆被劃分成兩個新生代和老年代區(qū)域，這樣便于JVM更好的管理堆內(nèi)存中的對象。JVM堆內(nèi)存的重要作用就是創(chuàng)建對象實例，所有的對象實例和數(shù)組都要在堆上分配。堆是由垃圾回收GC機制負(fù)責(zé)，垃圾回收采用分代算法，JVM堆可以動態(tài)地分配內(nèi)存大小，GC會自動回收不再使用的數(shù)據(jù)。

進入Elasticsearch安裝路徑下的“config”目錄，打開其中的“jvm.options”文件，顯示其默認(rèn)的JVM堆內(nèi)存最大值和最小值均為1GB，這樣的配置肯定不符合實際要求，可以根據(jù)實際情況進行調(diào)整。

注意，需要將兩者的值設(shè)置為相同，可以避免無謂的性能消耗。一般來說，將堆內(nèi)存設(shè)置為物理內(nèi)存的一般即可，不要超過32 GB。

為了保證Elasticsearch的性能，最好禁用系統(tǒng)的SWAP交換分區(qū)的使用，執(zhí)行“swapoff -a”命令禁用該功能。

執(zhí)行“cat/proc/sys/vm/swappiness”命令，可以查看swappiness參數(shù)值，該值控制操作系統(tǒng)嘗試交換內(nèi)存的積極性。如果其值為0，表示最大限度使用物理內(nèi)存，如果為100表示積極的使用Swap交換分區(qū)。系統(tǒng)默認(rèn)配置為60，表示當(dāng)內(nèi)存使用到40%的時候，開始出現(xiàn)有交換分區(qū)?？梢詧?zhí)行“sysctl vm.swappiness=10”命令，降低該參數(shù)的值，讓系統(tǒng)盡可能的使用使用內(nèi)存。