因为之前使用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