一： 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+Kafka+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的架構演變，於是自己錄製了視頻在51cto上，分享給大家。點擊下面的超鏈接即可。