大数据系统之监控系统(二)Flume的扩展

　　一些需求是原生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，你就会一目了然：

 public enum EventDeserializerType {

 LINE(LineDeserializer.Builder.class),

 AVRO(AvroEventDeserializer.Builder.class),

 OTHER(null);

 private final Class<? extends EventDeserializer.Builder> builderClass;

 EventDeserializerType(Class<? extends EventDeserializer.Builder> builderClass) {

 this.builderClass = builderClass;

 }

 public Class<? extends EventDeserializer.Builder> getBuilderClass() {

 return builderClass;

 }

 }

　　必须显式在这里定义deserializer的枚举，然后指定其builder的Class实例，并在agent里的deserializer配置项中填写你这里的枚举名称才行。

系统的管理问题

　　Flume的启动加载配置文件的方式有两种：conf配置文件方式和Zookeeper方式。Flume对conf或者Zookeeper进行监控。当配置信息发生变化时，重新初始化配置参数，并进行重启。目前系统，flume参数统一存储在Zookeeper上。通过翻看源码，发现解决这个问题需要重写大量的源码，任务巨大，目前还在思考结合实际情况如何巧妙的解决这个问题。

　　实际项目实施中，整个flume的架构，分为两层agent和collector。

源码参看https://github.com/bigdatafly/flume