ELK轉EFK

由於以前使用ES比較多，因此也認爲ELK是一個不錯的解決方案，ELK(Elasticsearch + Logstash + Kibana)來管理日誌。Logstash是一個具備實時渠道能力的數據收集引擎,但和fluentd相比，它在效能上表現略遜一籌，故而逐漸被fluentd取代，ELK也隨之變成EFK。

EFK由ElasticSearch、Fluentd和Kiabana三個開源工具組成。其中Elasticsearch是一款分佈式搜索引擎，可以用於日誌的檢索，Fluentd是一個實時開源的數據收集器,而Kibana 是一款可以爲Elasticsearch 提供分析和可視化的 Web 平臺。這三款開源工具的組合爲日誌數據提供了分佈式的實時蒐集與分析的監控系統。

• logstash支持全部主流日誌類型，插件支持最豐富，能夠靈活DIY，但性能較差，JVM容易致使內存使用量高。

• fluentd支持全部主流日誌類型，插件支持較多，性能表現較好。

• logtail佔用機器cpu、內存資源最少，結合阿里雲日誌服務的E2E體驗良好，但目前對特定日誌類型解析的支持較弱，後續須要把這一塊補起來。

參考日誌客戶端（Logstash,Fluentd, Logtail）橫評連接https://blog.csdn.net/yb223731/article/details/82424876

首先咱們來看一下業界的採集agent對於多租戶隔離方面主要採用的技術，這裏主要關注Logstash、Fluentd以及最近較火的Filebeat，咱們分別從以上5個特性對這三款產品進行對比和分析。

Logstash、Fluentd和Filebeat都屬於pipeline的架構，根據語言不一樣，分別使用獨立的線程/go runtime實現了pipeline功能，每一個pipeline內部順序執行，各個pipeline間互相獨立運行，此種方式隔離性較好，實現較爲簡單，在小規模場景下較爲適用。然而隨着配置數量增加，相應的線程數/go runtime呈等比上升，在採集配置較多的狀況下資源難以控制；並且因爲各個pipeline間徹底依賴底層（操做系統/go runtime）調度，當CPU資源沒法所有知足時，數據量較高的配置會佔用較多的執行時間，致使其餘數據較少的配置獲取資源的機率下降。

能夠看出filebeat相對logstash和fluentd有必定的優點(快10倍左右)；logtail的極簡模式（不對日誌解析，和filebeat相似）下的處理能力約爲150M/s，相對優化後的filebeat有8倍左右的性能提高。因爲filebeat達到18MB/s耗費了200%左右的cpu，logtail達到150MB/s只需消耗100%的cpu，因此若是從cpu的性價比上logtail相比filebeat有十多倍的優點。

參考Logtail技術分享(二) : 多租戶隔離技術+雙十一實戰效果連接出處https://www.jianshu.com/p/d15f5559597d?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation