logstash
logstash基于JRuby实现，可以跨平台运行在JVM上
优点：
主要的优点就是它的灵活性，这还主要因为它有很多插件。然后它清楚的文档已经直白的配置格式让它可以再多种场景下应用。这样的良性循环让我们可以在网上找到很多资源，几乎可以处理任何问题。
劣势：
Logstash 致命的问题是它的性能以及资源消耗（默认的堆大小是 1GB）。尽管它的性能在近几年已经有很大提升，与它的替代者们相比还是要慢很多的。因为logstash是jvm跑的，资源消耗比较大，所以后来作者又用golang写了一个功能较少但是资源消耗也小的轻量级的logstash-forwarder。不过作者只是一个人，elastic.co公司以后，因为es公司本身还收购了另一个开源项目packetbeat，而这个项目专门就是用golang的，有整个团队，所以es公司干脆把logstash-forwarder的开发工作也合并到同一个golang团队来搞，于是新的项目就叫filebeat了。logstash 和filebeat都具有日志收集功能，filebeat更轻量，占用资源更少，但logstash 具有filter功能，能过滤分析日志。一般结构都是filebeat采集日志，然后发送到消息队列，redis，kafaka。然后logstash去获取，利用filter功能过滤分析，然后存储到elasticsearch中。
Filebeat
工作原理：
Filebeat可以保持每个文件的状态，并且频繁地把文件状态从注册表里更新到磁盘。这里所说的文件状态是用来记录上一次Harvster读取文件时读取到的位置，以保证能把全部的日志数据都读取出来，然后发送给output。如果在某一时刻，作为output的ElasticSearch或者Logstash变成了不可用，Filebeat将会把最后的文件读取位置保存下来，直到output重新可用的时候，快速地恢复文件数据的读取。在Filebaet运行过程中，每个Prospector的状态信息都会保存在内存里。如果Filebeat出行了重启，完成重启之后，会从注册表文件里恢复重启之前的状态信息，让FIlebeat继续从之前已知的位置开始进行数据读取。
Prospector会为每一个找到的文件保持状态信息。因为文件可以进行重命名或者是更改路径，所以文件名和路径不足以用来识别文件。对于Filebeat来说，都是通过实现存储的唯一标识符来判断文件是否之前已经被采集过。
如果在你的使用场景中，每天会产生大量的新文件，你将会发现Filebeat的注册表文件会变得非常大
优势：
Filebeat 只是一个二进制文件没有任何依赖。它占用资源极少，尽管它还十分年轻，正式因为它简单，所以几乎没有什么可以出错的地方，所以它的可靠性还是很高的。它也为我们提供了很多可以调节的点，例如：它以何种方式搜索新的文件，以及当文件有一段时间没有发生变化时，何时选择关闭文件句柄。开始时，它只能将日志发送到 Logstash 和 Elasticsearch，而现在它可以将日志发送给 Kafka 和 Redis，在 5.x 版本中，它还具备过滤的能力。这也就意味着可以将数据直接用 Filebeat 推送到 Elasticsearch，并让 Elasticsearch 既做解析的事情，又做存储的事情。也不需要使用缓冲，因为 Filebeat 也会和 Logstash 一样记住上次读取的偏移。
filebeat只需要10来M内存资源；
典型应用场景
Filebeat 在解决某些特定的问题时：日志存于文件，我们希望
将日志直接传输存储到 Elasticsearch。这仅在我们只是抓去（grep）它们或者日志是存于 JSON 格式（Filebeat 可以解析 JSON）。或者如果打算使用 Elasticsearch 的 Ingest 功能对日志进行解析和丰富。
将日志发送到 Kafka/Redis。所以另外一个传输工具（例如，Logstash 或自定义的 Kafka 消费者）可以进一步丰富和转发。这里假设选择的下游传输工具能够满足我们对功能和性能的要求
flume
Flume 是Apache旗下使用JRuby来构建，所以依赖Java运行环境。Flume本身最初设计的目的是为了把数据传入HDFS中（并不是为了采集日志而设计，这和Logstash有根本的区别.
Flume设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个Agent的网络，支持数据路由。
每一个agent都由Source，Channel和Sink组成。
Source：Source负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。
Channel：Channel 存储，缓存从source到Sink的中间数据。可使用不同的配置来做Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。
Sink：Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不同目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。
优势：
Flume已经可以支持一个Agent中有多个不同类型的channel和sink，我们可以选择把Source的数据复制，分发给不同的目的端口，比如：
Flume还自带了分区和拦截器功能，因此不是像很多实验者认为的没有过滤功能
缺点：
Luentd和其插件都是由Ruby开发
logagent
优势：
可以获取 /var/log 下的所有信息，解析各种格式（Elasticsearch，Solr，MongoDB，Apache HTTPD等等），它可以掩盖敏感的数据信息，例如，个人验证信息（PII），出生年月日，信用卡号码，等等。它还可以基于 IP 做 GeoIP 丰富地理位置信息（例如，access logs）。同样，它轻量又快速，可以将其置入任何日志块中。在新的 2.0 版本中，它以第三方 node.js 模块化方式增加了支持对输入输出的处理插件。重要的是 Logagent 有本地缓冲，所以不像 Logstash ，在数据传输目的地不可用时会丢失日志。
劣势：
尽管 Logagent 有些比较有意思的功能（例如，接收 Heroku 或 CloudFoundry 日志），但是它并没有 Logstash 灵活。
典型应用场景：
Logagent 作为一个可以做所有事情的传输工具是值得选择的（提取、解析、缓冲和传输）
Fluentd
fluentd基于CRuby实现，并对性能表现关键的一些组件用C语言重新实现，整体性能不错。
fluentd设计简洁，pipeline内数据传递可靠性高。相较于logstash，其插件支持相对少一些。
开源社区中流行的日志收集工具，所以支持相对较好
逻辑较复杂的场景，Fluentd 的优点和缺点明显地展现了出来。
优点
它的日志采集方式非常丰富，有 tail、http、命令等等。方便地将日志采集起来。特别是 tail，考虑到了文件名包含日期的日志，日志的轮转等方面，让人觉得十分放心。
Fluentd 中 tag，label 两个概念使得可以实现灵活的处理逻辑。比如通过 rewrite_tag_filter 插件实现根据数据内容修改此数据的 tag，这条数据后续进入对应 tag 的处理逻辑，相当于路由功能；通过第三方插件 record_splitter 可用于拆分包含批量操作的日志；通过 copy 与 relabel 插件可将一条数据复制到两条流水线上。
作为一个日志传输工具，Fluentd 考虑到了传输过程中的很多问题，比如接收方跟不上时的可以设置缓存，接收方不可达时的可设置候选接收方（secondary），可设置多个接收方。
Fluentd 有丰富的插件，基本上想要的功能都有插件实现。因为插件都是 Ruby 脚本，编写的门槛很低，所以即使没有现成插件很多人也敢自己编写。
缺点
首先是性能。Fluentd 的宣传里有高性能这一项，可能相对于 logstash 的确好很多，但还是不太够。在实际使用中，解析 -> 转换 -> 入库 整个过程性能并不理想。比如实现上面提及的 rewrite_tag, split, copy 然后写入数据库，单进程每秒 2000 条日志，CPU 100%，内存占用 2-3GB。而且受限于 Ruby 的 GIL，它并不能真正多线程。多进程也受限于插件是否支持。
总之，Fluentd 的性能既因为 Ruby 消耗过多计算和内存资源，又因为 Ruby 难以受益与多核。对数据吞吐量大的业务来说它是很昂贵的。灵活和性能并不完全冲突，比如 Nginx 足够灵活，性能也足够强。
除了性能，Fluentd 的插件质量也不够好，第三方插件大多是使用者根据自己业务需要编写，只为实现特定需求，没有足够的泛化，也没有足够的测试和性能评估。不少常用的插件也以额外安装的方式添加，带来不必要的麻烦。
总结：
Fluentd 在数据量不大的场景下还是很不错的，省心省事。
如果转换逻辑简单数据量很大，那可以考虑 Fluentd 的小伙伴 Fluent Bit，性能更高，占用资源少很多，但插件少一点。
如果转换逻辑较复杂，数据量很大，可以在采集端使用 Fluentd/Fluent Bit，数据汇聚处自己写程序。
rsyslog
优势：
rsyslog 是经测试过的最快的传输工具。如果只是将它作为一个简单的 router/shipper 使用，几乎所有的机器都会受带宽的限制，但是它非常擅长处理解析多个规则。它基于语法的模块（mmnormalize）无论规则数目如何增加，它的处理速度始终是线性增长的。这也就意味着，如果当规则在 20-30 条时，如解析 Cisco 日志时，它的性能可以大大超过基于正则式解析的 grok ，达到 100 倍（当然，这也取决于 grok 的实现以及 liblognorm 的版本）。
它同时也是我们能找到的最轻的解析器，当然这也取决于我们配置的缓冲。
劣势：
rsyslog 的配置工作需要更大的代价（这里有一些例子），这让两件事情非常困难：
文档难以搜索和阅读，特别是那些对术语比较陌生的开发者。
5.x 以上的版本格式不太一样（它扩展了 syslogd 的配置格式，同时也仍然支持旧的格式），尽管新的格式可以兼容旧格式，但是新的特性（例如，Elasticsearch 的输出）只在新的配置下才有效，然后旧的插件（例如，Postgres 输出）只在旧格式下支持。
尽管在配置稳定的情况下，rsyslog 是可靠的（它自身也提供多种配置方式，最终都可以获得相同的结果），它还是存在一些 bug
syslog-ng
可以将 syslog-ng 当作 rsyslog 的替代品（尽管历史上它们是两种不同的方式）。它也是一个模块化的 syslog 守护进程，但是它可以做的事情要比 syslog 多。它可以接收磁盘缓冲并将 Elasticsearch HTTP 作为输出。它使用 PatternDB 作为语法解析的基础，作为 Elasticsearch 的传输工具，它是一个不错的选择。
优势
和 rsyslog 一样，作为一个轻量级的传输工具，它的性能也非常好。它曾经比 rsyslog 慢很多，但是 2 年前能达到 570K Logs/s 的性能并不差。并不像 rsyslog ，它有着明确一致的配置格式以及完好的文档。
劣势
Linux 发布版本转向使用 rsyslog 的原因是 syslog-ng 高级版曾经有很多功能在开源版中都存在，但是后来又有所限制。我们这里只关注与开源版本，所有的日志传输工具都是开源的。现在又有所变化，例如磁盘缓冲，曾经是高级版存在的特性，现在开源版也有。但有些特性，例如带有应用层的通知的可靠传输协议（reliable delivery protocol）还没有在开源版本中。
logtail
阿里云日志服务的生产者，目前在阿里集团内部机器上运行，经过3年多时间的考验，目前为阿里公有云用户提供日志收集服务。
采用C++语言实现，对稳定性、资源控制、管理等下过很大的功夫，性能良好。相比于logstash、fluentd的社区支持，logtail功能较为单一，专注日志收集功能。
| Flume | LogStash | Fluentd | Kafka | Filebeta | Apache Chukwa | |
|---|---|---|---|---|---|---|
| 版本 | 1.8.0 | 6.3 | 6.3 | |||
| 开发语言 | Java1.8 | JRuby | CRuby | Java | go | |
| 简介 | JSON作为数据格式。，易于解析 | 一个成熟的高性能消息队列 | 轻量级的日志传输工具，支持对接logstash，elsearch。 性能非常好，部署简单 | 活跃度很低 | ||
| 成本 | 开源 | 免费 | 开源 | 开源 | 开源 | 开源 |
| 架构 | Agent由source，channel、sink组成。多个Agent可以组成调用链 | input、Filter、output组成。 | Input：完成输入数据的读取，由source部分配置 Parser：解析插件 Output：完成输出数据的操作，由match部分配置 Formatter：消息格式化的插件，属于filter类型 Buffer：缓存插件，用于缓存数据 | Filebeta | ||
| 容错性 | 优秀，消息发送事务和重试、下游崩溃时消息磁盘存档 | 假如 Logstash 节点发生故障，Logstash 会通过持久化队列来保证运行中的事件至少一次被送达（at-least-once delivery）。那些未被正常处理的消息会被送往死信队列（dead letter queue）以便做进一步处理。由于具备了这种吸收吞吐量的能力，现在您无需采用额外的队列层，Logstash 就能平稳度过高峰期 | 缓冲，负载平衡，超时和重试的支持。 | 优秀 | 无 | |
| 负载均衡 | 支持sink端故障转移和负载均衡策略，博客。 | 支持 | 支持 | 支持 | 支持 | |
| 性能拓展 | 单个Agent配置多个sink提高性能 | 比较注重性能的地方采用C编写 | 高性能，高吞吐量 | |||
| 功能拓展 | 1. 可以下载源代码拓展 2.支持开发插件 | ruby拓展开发插件 | 需要自己开发各种采集端 | |||
| 采集插件 | Exec、JMS、Directory、 Tail、Syslog、Http、自定义 | file、syslog、http、kafka、snmp、rabbitmq | 多种，支持SNMP | 无 | 适用于文件日志的采集端，替代 logstash-input-file 。 | |
| 缓存队列（缓存通道） | Memory、Jdbc、Kafka、File、自定义 | 无，只发送至Redis或Kafka | 支持缓存通道 | 本身有一个很好的存储机制，支持内存和磁盘可靠性 | ||
| 日志过滤 | 需要自定义采集插件实现日志过滤 | 多种Filter插件：grok、json、drop、mutate、date、clone等，支持结构化解析文本、事件克隆、丢弃、字段转换 | 支持多种过滤插件和解析插件 | 无 | ||
| 发送插件 | HDFS、Hive、File、Null、Hbase、Kafka、Http、自定义 | 多种 | 多种 | 无 | ||
| 性能 | Flume1.4报告 | logstash及filebeat内存占用对比 ，Logstash性能优化 | 测试 | |||
| 缺点 | 没有snmp插件 | 性能和资源消耗较大。推荐logbeat采集数据，Logstash过滤日志。日志的容错性没有flume和fluentd号 | 输入输出插件没有logstash灵活。中文文档较少 | 没有可用的采集插件，更多的是用作消息缓存和转发 |