记Flume-NG一些注意事项(不定时更新,欢迎提供信息)

 

这里只考虑flume本身的一些东西,对于JVM、HDFS、HBase等得暂不涉及。。。。

 

一、关于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"指定的线程池中得一个线程来操作;

  如果启用压缩,则rollSize指的是未压缩文件大小,压缩后大小未知。

  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、由于能力有限,其它未知,上面两种,第一种好些,这里看看美团的架构————传送门

 

东西比较简单,容易消化。 

未完,待续。。。欢迎补充

posted @ 2014-10-09 17:25  玖疯  阅读(...)  评论(...编辑  收藏