flume 与 logstash 的比较

1、flume的介绍

flume是一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统。flume的一个Agent主要由source、channel、sink三个组件组成。
source负责从数据发生器接收数据；
channel相当于持久层，用于暂时存储数据；
sink负责将数据传送到目的地（hdfs、es等）。
flume支持开发者定制，可以自己进行开发。

2、logstash的介绍

logstash是一个接收、处理、转发日志的工具，与elasticsearch与kibana同属一个公司，ELK的组合兼容性强。logstash由input、Filter、output三个部分组成。
input负责数据的输入（产生或搜集，以及解码decode）；
filter负责对采集的日志进行分析，提取字段（一般都是提取关键的字段，存储到elasticsearch中进行检索分析）；
output负责把数据输出到指定的存储位置（kafka、es等）。

3、功能上的比较

flume比较注重于数据的传输，数据的产生后封装成event进行传输。传输的时候数据会持久化在channel中（一般有两种可以选择，memoryChannel存在内存中,FileChannel存储在文件中）。
数据只有sink完成后，才会从当前的channel中删除。这个过程是通过事务控制的，这样就保证了数据的可靠性。
但是这里也会产生一个问题：内存如果超过一定的量，也会造成数据丢失；如果使用文件存储，性能会变差。
logstash比较注重于字段的预处理，logstash有几十个插件，配置灵活。相比较而言，flume则是强调用户的自定义开发（source和sink的种类不多，功能也比较单一）。

4、操作上的比较

结合实际业务，我简单尝试了一下flume的几种配置：

1）flume使用avro source 可以实时读到控制台输出的日志，暂未尝试加上拦截器之后读取速度是否会变慢。
需要使用Apache下对应的log包以及配置一个log4j.properties文件：

2）flume使用spool source可以读取.log日志文件，但是被读取过的文件会有complete的标记，并不适用现有的日志滚动生成机制。

3）flume使用taildir source可以读取指定文件夹下的日志文件，这个是1.8版本中的实验性功能，目前只支持linux系统。
（原因：taildir会生成一个json文件来记录每个日志的消费偏移量，使得宕机后能从偏移量继续消费，解决数据重复发送的问题，但是这个偏移量在windows系统中无法使用）。

4）flume连接es(sink.type = elasticsearch)报错。目前问题定位在flume1.8版本无法连接到es5.4版本。
（网上给出的解决方案：1、将es版本降低至1.7；2、修改源码）

5、部署的比较

flume与logstash都需要单独安装在服务器上，通过配置文件控制其采集的数据源与数据接收方。

6、现阶段给出的方案

目前logstash存在的问题：
1、读取速度跟不上日志产生速度时会出现数据丢失问题——已有解决方案
2、需要单独安装——flume目前的资料来看也是需要单独安装的

若要使用flume需要：
定制source，定义日志过滤的逻辑等，出jar包，放置lib目录下；
修改es sink的源码，使其能够连接成功，出jar包，放置lib目录下；
channel的逻辑是否需要定制、选择内存or文件的持久化方式需结合实际场景。