一些需求是原生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