一些需求是原生Flume无法满足的，因此，基于开源的Flume我们增加了许多功能。
EventDeserializer的缺陷
Flume的每一个source对应的deserializer必须实现接口EventDeserializer，该接口定义了readEvent/readEvents方法从各种日志源读取Event。
flume主要支持两种反序列化器：
（1）AvroEventDeserializer：解析Avro容器文件的反序列化器。对Avro文件的每条记录生成一个flume Event，并将基于avro编码的二进制记录存入event body中。
（2）LineDeserializer：它是基于日志文件的反序列化器，以“\n”行结束符将每行化分为一条日志。
当日志记录本身被分割成多行时（比如堆栈异常日志），就不能满足这种要求。
针对这种情况，针对实际项目重新实现了日志的解析。源码参看https://github.com/bigdatafly/flume里的FileEventReader。
题外话，最近翻看了morphlines，日志解析还可以用morphlines来实现。
另外，这里还有个需要注意的地方：LineDeserializer有一个参数（maxLineLength）用于定义一个日志行的最长字符数。如果某条日志超过这个长度，将不再读取。而一条日志占据多行情况下，该值需要适当增大，因为像异常日志的堆栈长度明显比普通日志长不少，这里你可以设置为8192。
ExecSource的缺陷
ExecSource tail -F 适合固定文件日志的读取，最大问题不支持文件断点续传的功能。为此，在源码的基础上实现了flume-filetailsource。
源码参看https://github.com/bigdatafly/flume里的FileTailSource.java
SpoolingDirSource的缺陷
用于监控文件目录变化的，但是会有以下两个问题：一是文件不能写，只能读。二是延迟比较高，需要等待日志定期归档。项目中没采用此方式。
这里有个小插曲，由于之前已定制了source/sink的缘故。原以为deserializer也可以用同样的方式进行定制。并在agent的deserializer配置中指定定制过的deserializer的完全限定名。但经过验证后发现，这条路走不通，会报错（貌似从flume官网上也找不到对deserializer定制的介绍）。因此，只能在源码上进行扩展，然后编译源码，重新生成jar。
从源码里你会发现为什么在第三方包内扩展deserializer是行不通的。参看org.apache.flume.serialization.EventDeserializerType，你就会一目了然：
1 public enum EventDeserializerType { 2 LINE(LineDeserializer.Builder.class), 3 AVRO(AvroEventDeserializer.Builder.class), 4 OTHER(null); 5 private final Class<? extends EventDeserializer.Builder> builderClass; 6 EventDeserializerType(Class<? extends EventDeserializer.Builder> builderClass) { 7 this.builderClass = builderClass; 8 } 9 public Class<? extends EventDeserializer.Builder> getBuilderClass() { 10 return builderClass; 11 } 12 }
必须显式在这里定义deserializer的枚举，然后指定其builder的Class实例，并在agent里的deserializer配置项中填写你这里的枚举名称才行。
系统的管理问题
Flume的启动加载配置文件的方式有两种：conf配置文件方式和Zookeeper方式。Flume对conf或者Zookeeper进行监控。当配置信息发生变化时，重新初始化配置参数，并进行重启。目前系统，flume参数统一存储在Zookeeper上。通过翻看源码，发现解决这个问题需要重写大量的源码，任务巨大，目前还在思考结合实际情况如何巧妙的解决这个问题。
实际项目实施中，整个flume的架构，分为两层agent和collector。
源码参看https://github.com/bigdatafly/flume
