這篇文章給大家分享的是把ELK日志系統(tǒng)改進(jìn)成ELFK的方法，相信大部分人都還沒學(xué)會這個技能，為了讓大家學(xué)會，給大家總結(jié)了以下內(nèi)容，話不多說，一起往下看吧。

專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)麒麟免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

一： ELK日志系統(tǒng)初期

剛來公司的時候，我們公司的日志收集系統(tǒng)ELK經(jīng)常會出現(xiàn)查詢不了最新的日志的情況，后面去查發(fā)現(xiàn) ES的節(jié)點(diǎn)經(jīng)常也是yellow或者red的情況。有時候會收到開發(fā)的投訴。這一套ELK系統(tǒng)也是另外一個同事搭建的，

架構(gòu)圖解如下:

其中ElasticSearch 是三臺服務(wù)器構(gòu)成的集群，

其中ElasticSearch的版本為 6.2.x 的版本，Logstash跑在每個服務(wù)器上，各種日志通過Logstash搜集，Grok，Geoip等插件進(jìn)行處理然后統(tǒng)一送到ElasticSearch的集群。

Kibana做圖形化的展示。

我們之前的elk架構(gòu)比較簡單，也存在一些問題：

1、Logstash依賴Java虛擬機(jī)占用系統(tǒng)的內(nèi)存和CPU都比較大，

2、Logstash在數(shù)據(jù)量較大的時候容易導(dǎo)致其他業(yè)務(wù)應(yīng)用程序崩潰，影響業(yè)務(wù)正常使用

3、隨著時間的積累，es空間不能滿足現(xiàn)狀

4、Kibana沒有安全管控機(jī)制，沒有權(quán)限審核，安全性較差。

5、ElasticSearch 主節(jié)點(diǎn)也是數(shù)據(jù)節(jié)點(diǎn)，導(dǎo)致有時候查詢較慢

二： ELK日志系統(tǒng)改進(jìn)之引入Filebeat

ElasticSearch的版本，我們還是選擇原來的 6.2.x的版本，然后重新搭建了一套ELK的日志系統(tǒng)。

ElasticSearch 6.x 的版本如果要做用于鑒權(quán)的話，必須依賴X-Pack，但是X-pack是付費(fèi)的產(chǎn)品，于是我們在網(wǎng)上尋找破解補(bǔ)丁，然后對ElasticSearch 6.x 進(jìn)行破解。

架構(gòu)圖解如下:

整個架構(gòu)的具體的改進(jìn)方法如下:

1、客戶端選用更輕量化的Filebeat，F(xiàn)ilebeat 采用 Golang 語言進(jìn)行編寫的，優(yōu)點(diǎn)是暫用系統(tǒng)資源小，收集效率高。

2、Filebeat 數(shù)據(jù)收集之后統(tǒng)一送到多個 Logstatsh進(jìn)行統(tǒng)一的過濾，然后將過濾后的數(shù)據(jù)寫入ElasticSearch集群。

3、將原有的3個es節(jié)點(diǎn)增加至6個節(jié)點(diǎn)，其中3個ES節(jié)點(diǎn)是master節(jié)點(diǎn)，其余的節(jié)點(diǎn)是數(shù)據(jù)節(jié)點(diǎn)，如果磁盤不夠用可以橫向擴(kuò)展數(shù)據(jù)節(jié)點(diǎn)。

4、引入x-pack，實現(xiàn) Index 級別的權(quán)限管控，確保數(shù)據(jù)安全。

5、ElasticSearch集群的硬盤采用 SSD的硬盤

到此，我們的日志系統(tǒng)算暫時是正常并且能滿足日志查日志的需求了，也很少出現(xiàn)卡頓的現(xiàn)象了，并且服務(wù)器的資源使用率直接下降了一半。

但是要查幾個月之前的數(shù)據(jù)還是會慢，于是我們在上面的基礎(chǔ)上又做了下面幾個優(yōu)化:

6、ElasticSearch 做冷熱數(shù)據(jù)分離

7、60天之前的索引數(shù)據(jù)進(jìn)行關(guān)閉，有需要用的時候手工打開

8、ElasticSearch的版本采用ElasticSearch 7.x的版本，用戶鑒權(quán)采用其免費(fèi)的 basic 認(rèn)證實現(xiàn)（因為7.x的新版本在性能上優(yōu)化，查詢和寫入速度會更快）

 三： ELK日志系統(tǒng)改進(jìn)之ELFK

因為我們的主要業(yè)務(wù)的開發(fā)語言是PHP，PHP產(chǎn)生的 日志并不多，但是PHP畢竟是解釋性的語言，運(yùn)行效率并不高，但是我們公司業(yè)務(wù)并發(fā)卻非常高。并發(fā)至少有10萬以上。有些業(yè)務(wù)是Java，比如位置上報的業(yè)務(wù)，微服務(wù)也是公司自己開發(fā)的，可能是框架也不完善，不像Spring Boot那樣成熟，打出的日志特別多，一個Java的微服務(wù)每天就要產(chǎn)生就幾個T的數(shù)據(jù)。有些微服務(wù)的日志還是info級別的。

隨著時間的積累，日志量有幾百T以及有PB級別的日志量了。

同時大數(shù)據(jù)部門也是查ElasticSearch集群的接口，導(dǎo)致ElasticSearch的壓力特別大。這樣導(dǎo)致有時候查詢歷史日志會很慢。

目前采用的 Filbeat + Logstash+ ElasticSearch+ Kibana的架構(gòu)已經(jīng)無法滿足需求了。于是我們想到使用MQ進(jìn)行緩沖，消息隊列進(jìn)行緩沖那應(yīng)該選哪個產(chǎn)品了，消息中間件考慮的幾個軟件又 redis，Rabitmq，ActiveMq，Kafka等，對于這幾個的考慮我們毫不猶豫的選擇了Kafka，因為Kafak的吞吐量比其他都高，Kafka性能遠(yuǎn)超過ActiveMQ、RabbitMQ等。

架構(gòu)圖解如下:

整個架構(gòu)的具體的改進(jìn)方法如下:

1、Filebeat數(shù)據(jù)收集之后存放于kafka，然后用 Logstash來逐條消費(fèi)，寫入es，確保數(shù)據(jù)的完整性。

2、Logstash 跑多個節(jié)點(diǎn)多個進(jìn)程以及多線程進(jìn)行消費(fèi)。

3、Kafka 多Topic 多分區(qū)存儲，從而保證吞吐量。

4、大數(shù)據(jù)部門從開始的直接查ElasticSearch集群的接口，改成直接消費(fèi)Kafka的數(shù)據(jù)，這樣ElasticSearch的壓力降低了不少。

到此，就目前的架構(gòu)已經(jīng)滿足企業(yè)的PB級的日志需求了，查歷史日志也不卡了，也能滿足日常的需求。

當(dāng)我們通過 Kafka—Manager 去監(jiān)控和 管理 Kafka 的狀態(tài)信息的時候，發(fā)現(xiàn)在業(yè)務(wù)高峰期的時候，Kafka的topic有很少量的堆積，

但是并不影響開發(fā)和運(yùn)維查日志。于是愛折騰的我，決定自己手工寫程序代替 Logstash消費(fèi)，于是有了下面的內(nèi)容。

四：  Filbeat+Go+ElasticSearch+Kibana 日志收集系統(tǒng)架構(gòu)

如果自己寫程序代替 Logstash消費(fèi)，自己熟悉的語言是Python 和 Golang，于是決定用這兩者中的其中一個進(jìn)行編寫，考慮到Python是解釋性語言，有全局鎖的限制。而 Golang 是編譯型語言，而且天生支持協(xié)程。支持并發(fā)。所以采用 Golang進(jìn)行kafka消費(fèi)

架構(gòu)圖解如下:

整個架構(gòu)的具體的操作方法如下:

1、不同的日志類型建立不同的 topic

2、Filebat打不同的tag采集數(shù)據(jù)到不同的 topic

3、Golang 開啟協(xié)程消費(fèi)不同的 topic發(fā)送到ElasticSearch集群

到此我們再使用 Kafak-Manager去查看Kafka的狀態(tài)信息之后，即便再高峰期也不會出現(xiàn)消息少量堆積的情況了

關(guān)于把ELK日志系統(tǒng)改進(jìn)成ELFK的方法就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果喜歡這篇文章，不如把它分享出去讓更多的人看到。