從ELK到ELFK的轉變，知足企業PB級日誌系統的實踐之路

一： ELK日誌系統初期

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

架構圖解以下:

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

其中ElasticSearch的版本爲 6.2.x 的版本，Logstash跑在每一個服務器上，各類日誌經過Logstash蒐集，Grok，Geoip等插件進行處理而後統一送到ElasticSearch的集羣。

Kibana作圖形化的展現。

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

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

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

三、隨着時間的積累，es空間不能知足現狀

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

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

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

ElasticSearch的版本，咱們仍是選擇原來的 6.2.x的版本，而後從新搭建了一套ELK的日誌系統。

ElasticSearch 6.x 的版本若是要作用於鑑權的話，必須依賴X-Pack，可是X-pack是付費的產品，因而咱們在網上尋找破解補丁，而後對ElasticSearch 6.x 進行破解。

架構圖解以下:

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

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

二、Filebeat 數據收集以後統一送到多個 Logstatsh進行統一的過濾，而後將過濾後的數據寫入ElasticSearch集羣。

三、將原有的3個es節點增長至6個節點，其中3個ES節點是master節點，其他的節點是數據節點，若是磁盤不夠用能夠橫向擴展數據節點。

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

五、ElasticSearch集羣的硬盤採用 SSD的硬盤

到此，咱們的日誌系統算暫時是正常而且能知足日誌查日誌的需求了，也不多出現卡頓的現象了，而且服務器的資源使用率直接降低了一半。

可是要查幾個月以前的數據仍是會慢，因而咱們在上面的基礎上又作了下面幾個優化:

六、ElasticSearch 作冷熱數據分離

七、60天以前的索引數據進行關閉，有須要用的時候手工打開

八、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等。

架構圖解以下:

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

一、Filebeat數據收集以後存放於kafka，而後用 Logstash來逐條消費，寫入es，確保數據的完整性。

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

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

四、大數據部門從開始的直接查ElasticSearch集羣的接口，改爲直接消費Kafka的數據，這樣ElasticSearch的壓力下降了很多。

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

當咱們經過 Kafka—Manager 去監控和 管理 Kafka 的狀態信息的時候，發如今業務高峯期的時候，Kafka的topic有不多量的堆積，

可是並不影響開發和運維查日誌。因而愛折騰的我，決定本身手工寫程序代替 Logstash消費，因而有了下面的內容。

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

若是本身寫程序代替 Logstash消費，本身熟悉的語言是Python 和 Golang，因而決定用這二者中的其中一個進行編寫，考慮到Python是解釋性語言，有全局鎖的限制。而 Golang 是編譯型語言，並且天生支持協程。支持併發。因此採用 Golang進行kafka消費

架構圖解以下:

整個架構的具體的操做方法以下:

一、不一樣的日誌類型創建不一樣的 topic

二、Filebat打不一樣的tag採集數據到不一樣的 topic

三、Golang 開啓協程消費不一樣的 topic發送到ElasticSearch集羣

到此咱們再使用 Kafak-Manager去查看Kafka的狀態信息以後，即使再高峯期也不會出現消息少許堆積的狀況了

 

五： 經驗記錄

針對從ELK到ELFK的架構演變，因而本身錄製了視頻在51CTO上，分享給你們。點擊下面的超連接便可。

ELK/ELFK（7.3版本）企業PB級日誌系統實戰