怎樣把ELK日志系統改進成ELFK

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

一： ELK日志系統初期

剛來公司的時候，我們公司的日志收集系統ELK經常會出現查詢不了最新的日志的情況，后面去查發現 ES的節點經常也是yellow或者red的情況。有時候會收到開發的投訴。這一套ELK系統也是另外一個同事搭建的，

架構圖解如下:

其中ElasticSearch 是三臺服務器構成的集群，

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

Kibana做圖形化的展示。

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

1、Logstash依賴Java虛擬機占用系統的內存和CPU都比較大，

2、Logstash在數據量較大的時候容易導致其他業務應用程序崩潰，影響業務正常使用

3、隨著時間的積累，es空間不能滿足現狀

4、Kibana沒有安全管控機制，沒有權限審核，安全性較差。

5、ElasticSearch 主節點也是數據節點，導致有時候查詢較慢

二： ELK日志系統改進之引入Filebeat

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

ElasticSearch 6.x 的版本如果要做用于鑒權的話，必須依賴X-Pack，但是X-pack是付費的產品，于是我們在網上尋找破解補丁，然后對ElasticSearch 6.x 進行破解。

架構圖解如下:

整個架構的具體的改進方法如下:

1、客戶端選用更輕量化的Filebeat，Filebeat 采用 Golang 語言進行編寫的，優點是暫用系統資源小，收集效率高。

2、Filebeat 數據收集之后統一送到多個 Logstatsh進行統一的過濾，然后將過濾后的數據寫入ElasticSearch集群。

3、將原有的3個es節點增加至6個節點，其中3個ES節點是master節點，其余的節點是數據節點，如果磁盤不夠用可以橫向擴展數據節點。

4、引入x-pack，實現 Index 級別的權限管控，確保數據安全。

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

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

但是要查幾個月之前的數據還是會慢，于是我們在上面的基礎上又做了下面幾個優化:

6、ElasticSearch 做冷熱數據分離

7、60天之前的索引數據進行關閉，有需要用的時候手工打開

8、ElasticSearch的版本采用ElasticSearch 7.x的版本，用戶鑒權采用其免費的 basic 認證實現（因為7.x的新版本在性能上優化，查詢和寫入速度會更快）

 三： ELK日志系統改進之ELFK

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

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

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

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

架構圖解如下:

整個架構的具體的改進方法如下:

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

2、Logstash 跑多個節點多個進程以及多線程進行消費。

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

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

到此，就目前的架構已經滿足企業的PB級的日志需求了，查歷史日志也不卡了，也能滿足日常的需求。

當我們通過 Kafka—Manager 去監控和 管理 Kafka 的狀態信息的時候，發現在業務高峰期的時候，Kafka的topic有很少量的堆積，

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

四：  Filbeat+Go+ElasticSearch+Kibana 日志收集系統架構

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

架構圖解如下:

整個架構的具體的操作方法如下:

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

2、Filebat打不同的tag采集數據到不同的 topic

3、Golang 開啟協程消費不同的 topic發送到ElasticSearch集群

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

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