以前在不少场合浅度使用过 Fluentd，将日志汇聚到一个地方。它给我的大体印象是
简单且能解决问题
直到最近遇到一个业务量稍大、逻辑较复杂的场景，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 的插件质量也不够好，第三方插件大多是使用者根据自己业务需要编写，只为实现特定需求，没有足够的泛化，也没有足够的测试和性能评估。不少常用的插件也以额外安装的方式添加，带来不必要的麻烦。
另外就是配置文件，一个 filter 里只能做一个转换，比如：
<filter a.tag>
@type parse
...
</filter>
<filter a.tag>
@type transform_record
...
</filter>总觉得没有下面这样来的干脆
<filter a.tag>
<item>
@type parse
...
</item>
<item>
@type stransform_record
...
</item>
</filter>最后
我觉得 Fluentd 在数据量不大的场景下还是很不错的，省心省事。
如果转换逻辑简单数据量很大，那可以考虑 Fluentd 的小伙伴 Fluent Bit，性能更高，占用资源少很多，但插件少一点。
如果转换逻辑较复杂，数据量很大，可以在采集端使用 Fluentd/Fluent Bit，数据汇聚处自己写程序。
