flume的memeryChannel中transactionCapacity和sink的batchsize需要注意事项

一.

fluem中出现，transactionCapacity查询一下，得出一下这些：

最近在做flume的实时日志收集，用flume默认的配置后，发现不是完全实时的，于是看了一下，原来是memeryChannel的transactionCapacity在作怪，因为他默认是100，也就是说收集端的sink会在收集到了100条以后再去提交事务（即发送到下一个目的地），于是我修改了transactionCapacity到10，想看看是不是会更加实时一点，结果发现收集日志的agent启动的时候报错了。

16/04/29 09:36:15 ERROR sink.AbstractRpcSink: Rpc Sink avro-sink: Unable to get event from channel memoryChannel. Exception follows.
org.apache.flume.ChannelException: Take list for MemoryTransaction, capacity 10 full, consider committing more frequently, increasing capacity, or increasing thread count
at org.apache.flume.channel.MemoryChannel$MemoryTransaction.doTake(MemoryChannel.Java:96)
at org.apache.flume.channel.BasicTransactionSemantics.take(BasicTransactionSemantics.java:113)
at org.apache.flume.channel.BasicChannelSemantics.take(BasicChannelSemantics.java:95)
at org.apache.flume.sink.AbstractRpcSink.process(AbstractRpcSink.java:354)
at org.apache.flume.sink.DefaultSinkProcessor.process(DefaultSinkProcessor.java:68)
at org.apache.flume.SinkRunner$PollingRunner.run(SinkRunner.java:147)
at java.lang.Thread.run(Thread.java:745)

于是很纳闷，为什么默认值100可以，而设置10就会说小了呢，于是查阅资料，发现原来是sink的batchsize参数在作怪，下面，我就来理一理这个来龙去脉，这个sink的batchsize是什么意思呢，就是sink会一次从channel中取多少个event去发送，而这个发送是要最终以事务的形式去发送的，因此这个batchsize的event会传送到一个事务的缓存队列中（takeList），这是一个双向队列，这个队列可以在事务失败时进行回滚（也就是把取出来的数据吐memeryChannel的queue中），它的初始大小就是transactionCapacity定义的大小，源码中有： takeList = new LinkedBlockingDeque<Event>(transCapacity); 源码来自https://segmentfault.com/a/1190000003586635的分享。

再看这个错误抛出的地方：

 if(takeList.remainingCapacity() == 0) {
        throw new ChannelException("Take list for MemoryTransaction, capacity " +
            takeList.size() + " full, consider committing more frequently, " +
            "increasing capacity, or increasing thread count");
    }

在上面的情况中，sink一次取100个events，塞到takelist中，在塞了10个后，就会引发上述异常，因此，这个错误的解决办法就是：在sink中，channel的transactionCapacity参数不能小于sink的batchsize。

二.

Flume-ng出现HDFS IO error,Callable timed out异常

目前解决方案：

• 根据http://blog.csdn.net/yangbutao/article/details/8845025，修改flume hdfs客户端超时时间。
• 修改hdfs.callTimeout从默认的10秒改成:40秒

三

记Flume-NG一些注意事项

一、关于Source：

1、spool-source：适合静态文件，即文件本身不是动态变化的；

2、avro source可以适当提高线程数量来提高此source性能；

3、ThriftSource在使用时有个问题需要注意，使用批量操作时出现异常并不会打印异常内容而是"Thrift source %s could not append events to the channel."，这是因为源码中在出现异常时，它并未捕获异常而是获取组件名称，这是源码中的一个bug，也可以说明thrift很少有人用，否则这个问题也不会存在在很多版本中；

4、如果一个source对应多个channel，默认就是每个channel是同样的一份数据，会把这批数据复制N份发送到N个channel中，所以如果某个channel满了会影响整体的速度的哦；

5、ExecSource官方文档已经说明是异步的，可能会丢数据哦，尽量使用tail -F，注意是大写的；

二、关于Channel：

1、采集节点建议使用新的复合类型的SpillableMemoryChannel，汇总节点建议采用memory channel，具体还要看实际的数据量，一般每分钟数据量超过120MB大小的flume agent都建议用memory channel(自己测的file channel处理速率大概是2M/s，不同机器、不同环境可能不同，这里只提供参考)，因为一旦此agent的channel出现溢出情况，将会导致大多数时间处于file channel(SpillableMemoryChannel本身是file channel的一个子类，而且复合channel会保证一定的event的顺序的使得读完内存中的数据后，再需要把溢出的拿走，可能这时内存已满又会溢出。。。)，性能大大降低，汇总一旦成为这样后果可想而知；

2、调整memory 占用物理内存空间，需要两个参数byteCapacityBufferPercentage(默认是20)和byteCapacity(默认是JVM最大可用内存的0.8)来控制，计算公式是：byteCapacity = (int)((context.getLong("byteCapacity", defaultByteCapacity).longValue() * (1 - byteCapacityBufferPercentage * .01 )) /byteCapacitySlotSize)，很明显可以调节这两个参数来控制，至于byteCapacitySlotSize默认是100，将物理内存转换成槽(slot)数，这样易于管理，但是可能会浪费空间，至少我是这样想的。。。；

3、还有一个有用的参数"keep-alive"这个参数用来控制channel满时影响source的发送，channel空时影响sink的消费，就是等待时间，默认是3s，超过这个时间就甩异常，一般不需配置，但是有些情况很有用，比如你得场景是每分钟开头集中发一次数据，这时每分钟的开头量可能比较大，后面会越来越小，这时你可以调大这个参数，不至于出现channel满了得情况；

三、关于Sink：

1、avro sink的batch-size可以设置大一点，默认是100，增大会减少RPC次数，提高性能；

2、内置hdfs sink的解析时间戳来设置目录或者文件前缀非常损耗性能，因为是基于正则来匹配的，可以通过修改源码来替换解析时间功能来极大提升性能，稍后我会写一篇文章来专门说明这个问题；

3、RollingFileSink文件名不能自定义，而且不能定时滚动文件，只能按时间间隔滚动，可以自己定义sink，来做定时写文件；

4、hdfs sink的文件名中的时间戳部分不能省去，可增加前缀、后缀以及正在写的文件的前后缀等信息；"hdfs.idleTimeout"这个参数很有意义，指的是正在写的hdfs文件多长时间不更新就关闭文件，建议都配置上，比如你设置了解析时间戳存不同的目录、文件名，而且rollInterval=0、rollCount=0、rollSize=1000000，如果这个时间内的数据量达不到rollSize的要求而且后续的写入新的文件中了，就是一直打开，类似情景不注意的话可能很多；"hdfs.callTimeout"这个参数指的是每个hdfs操作(读、写、打开、关闭等)规定的最长操作时间，每个操作都会放入"hdfs.threadsPoolSize"指定的线程池中得一个线程来操作；

5、关于HBase sink(非异步hbase sink：AsyncHBaseSink)，rowkey不能自定义，而且一个serializer只能写一列，一个serializer按正则匹配多个列，性能可能存在问题，建议自己根据需求写一个hbase sink；

6、avro sink可以配置failover和loadbalance，所用的组件和sinkgroup中的是一样的，而且也可以在此配置压缩选项，需要在avro source中配置解压缩；

四、关于SinkGroup：

1、不管是loadbalance或者是failover的多个sink需要共用一个channel；

2、loadbalance的多个sink如果都是直接输出到同一种设备，比如都是hdfs，性能并不会有明显增加，因为sinkgroup是单线程的它的process方法会轮流调用每个sink去channel中take数据，并确保处理正确，使得是顺序操作的，但是如果是发送到下一级的flume agent就不一样了，take操作是顺序的，但是下一级agent的写入操作是并行的，所以肯定是快的；

3、其实用loadbalance在一定意义上可以起到failover的作用，生产环境量大建议loadbalance；

五、关于监控monitor：

1、监控我这边做得还是比较少的，但是目前已知的有以下几种吧：cloudera manager（前提是你得安装CDH版本）、ganglia(这个天生就是支持的)、http(其实就是将统计信息jmx信息，封装成json串，使用jetty展示在浏览器中而已)、再一个就是自己实现收集监控信息，自己做(可以收集http的信息或者自己实现相应的接口实现自己的逻辑，具体可以参考我以前的博客)；

2、简单说一下cloudera manager这种监控，最近在使用，确实很强大，可以查看实时的channel进出数据速率、channel实时容量、sink的出速率、source的入速率等等，图形化的东西确实很丰富很直观，可以提供很多flume agent整体运行情况的信息和潜在的一些信息；

六、关于flume启动：

1、flume组件启动顺序：channels——>sinks——>sources，关闭顺序：sources——>sinks——>channels；

2、自动加载配置文件功能，会先关闭所有组件，再重启所有组件；

3、关于AbstractConfigurationProvider中的Map<Class<? extends Channel>, Map<String, Channel>> channelCache这个对象，始终存储着agent中得所有channel对象，因为在动态加载时，channel中可能还有未消费完的数据，但是需要对channel重新配置，所以用以来缓存channel对象的所有数据及配置信息；

4、通过在启动命令中添加 "no-reload-conf"参数为true来取消自动加载配置文件功能；

七、关于interceptor：

请看我的关于这个组件的博客，传送门；

八、关于自定义组件：sink、source、channel：

1、channel不建议自定义哦，这个要求比较高，其他俩都是框架式的开发，往指定的方法填充自己配置、启动、关闭、业务逻辑即可，以后有机会单独写一篇文章来介绍；

2、关于自定义组件请相信github，上面好多好多好多，可以直接用的自定义组件....；

九、关于Flume-NG集群网络拓扑方案：

1、在每台采集节点上部署一个flume agent，然后做一到多个汇总flume agent(loadbalance)，采集只负责收集数据发往汇总，汇总可以写HDFS、HBase、spark、本地文件、kafka等等，这样一般修改会只在汇总，agent少，维护工作少；

2、采集节点没有部署flume agent，可能发往mongo、redis等，这时你需要自定义source或者使用sdk来将其中的数据取出并发往flume agent，这样agent就又可以充当“采集节点”或者汇总节点了，但是这样在前面相当于加了一层控制，就又多了一层风险；

3、由于能力有限，其它未知，上面两种，第一种好些，这里看看美团的架构———— 传送门；

四、

java.lang.NullPointerException: Expected timestamp in the Flume event headers, but it was null

sink是hdfs，然后使用目录自动生成功能。出现如题的错误，看官网文档说的是需要在每个文件记录行的开头需要有时间戳，但是时间戳的格式可能比较难调节，所以亦可设置hdfs.useLocalTimeStamp这个参数，比如以每个小时作为一个文件夹，那么配置应该是这样：

a1.sinks.k1.hdfs.path = hdfs://ubuntu:9000/flume/events/%y-%m-%d/%H
a1.sinks.k1.hdfs.filePrefix = events-
a1.sinks.k1.hdfs.round = true
a1.sinks.k1.hdfs.roundValue = 1
a1.sinks.k1.hdfs.roundUnit = hour
a1.sinks.k1.hdfs.useLocalTimeStamp = true

或者修改hdfs.timeZone这个参数使之可以和我们上传的log文件的日期格式一样应该就可以了，没有测试过。

五、flume学习（三）：flume将log4j日志数据写入到hdfs

、本次我们把log4j的日志直接采集输出到hdfs中去。需要修改flume.conf中sink的配置：

tier1.sources=source1
tier1.channels=channel1
tier1.sinks=sink1

tier1.sources.source1.type=avro
tier1.sources.source1.bind=0.0.0.0
tier1.sources.source1.port=44444
tier1.sources.source1.channels=channel1

tier1.channels.channel1.type=memory
tier1.channels.channel1.capacity=10000
tier1.channels.channel1.transactionCapacity=1000
tier1.channels.channel1.keep-alive=30

tier1.sinks.sink1.type=hdfs
tier1.sinks.sink1.channel=channel1
tier1.sinks.sink1.hdfs.path=hdfs://master68:8020/flume/events
tier1.sinks.sink1.hdfs.fileType=DataStream
tier1.sinks.sink1.hdfs.writeFormat=Text
tier1.sinks.sink1.hdfs.rollInterval=0
tier1.sinks.sink1.hdfs.rollSize=10240
tier1.sinks.sink1.hdfs.rollCount=0
tier1.sinks.sink1.hdfs.idleTimeout=60