日更挑战当前排名：第135天，第2450名，较昨日前进3名。

Flume之秉性

之前对Flume了解不是很深，只是知道它是一个日志收集工具，但实际上并不仅限于收集日志，它的多个source-channel-sink机制可以采集多种数据信息。

Flume简单的结构

公司使用Flume用于收集原始数据，source就是普通文件，channel用的文件系统，而sink则是Kafka。在最近处理历史数据过程中，较多了解了如何检查Flume的运行情况，其中还有一则事故的处理。

Flume运行状态，是通过内部的http服务器暴露的，地址如下

 curl http://{ip}:56012/metrics

返回结果是一个Json串，其中比较重要的是看channel是否被沾满。由于是本地存储的channel（相当持久化，防止内存意外断电导致丢失），所以channel的占用百分比是必看的。

例子

此例中，channel已经达到了70%的饱和度，具体计算是用ChannelSize/ChannelCapacity的比值，这两个数据都在图中。

当这个值很高时，将不能继续处理source指定的目录，所以考虑要让source的解析等等。公司的Flume定制版本会有一个delay的单独包，目的就是只处理channel，而source暂停。

至于如何知道source是否停止。使用的方法是看源文件目录还没有COMPLETED的文件。

# ls出文件名不包含COMPLETED字样，且以.result结尾的文件，最后统计行数
ls result/ -R --hide=*COMPLETED | grep '\.result' | wc -l

当channel多的时候，会在文件临时目录中占用大量空间，所以也要经常监控这个目录，目录地址是在配置文件中配置的。

至于为什么会堆积，目前不得而知。似乎source中文件少的时候不会，当到一定程度时，channel就会逐步堆积。这可能是和Kafka的吞吐量有关，也可能是Flume的bug。

一则事故

在处理某个数据集时发现，最后channel都被撑得很满，硬盘空间屡屡告急。后来发现硬盘占用过高，例如正常的channel在80%时，只有不到200GB，而在这批数据中，能达到2.6T。这样经常要腾空间，很不正常。

特别是这个数据集本身数量并不多。开始不知道检查非COMPLETED文件，导致反复了2次，最后这一次通过shell一查，只有几个文件反复处理不掉。

找到这几个文件，忽然恍然大悟。原来这几个文件和处理后的文件同时存在，所以Flume并没有干掉原始文件，而反复在处理他们，类似造成了死循环。把同名的，以COMPLETED结尾的文件删除后，瞬间几个文件转换成功，全部channel腾空，不再莫名其妙增长。

总结

Flume目前使用比较正常，主要关注的就是file的channel占用情况。目前这部分没有找到堆积的原因；另外要特别注意source一定不要有文件名相同，一个以COMPLETED结尾，一个没有，会造成重复处理的死循环。

Flume不是一个活跃的项目，目前不知道是否有替代？