同事遇到点问题，抛出来了4个问题，如下
1 flume的source是kafka，sink是hdfs，怎样判断flume是否堆积，或者是说怎么样保证落地的速度和消费的速度是平衡的
2 怎么判断flume的agent程序是否挂掉
3 挂掉时tmp文件爱呢怎么处理（hdfs上的tmp文件）
4 我遇到一个问题，当agent是6个时，一小时约生成26.5G文件，当有3个agent时，一小时16.9G，按我的理解，1个agent相当于一个consumer，这6个agent是同一个consumer group，那么3个和6个agent1小时都应该生成那么多的文件，但实际不是，怎么回事？
先说第4个问题，其实同事理解的不错，kafka的consumer必须归于一个group，以group为单位去消费topic上的数据，group内的consumer不论多或少，最终输出的数据量按理应该是一样多的。至于为啥当consumer多时消费量多，consumer少时消费少，那就说明了，每个consumer都到了它所能处理的上限了，而topic中整体的数据量太大。我的建议是增大consumer的数量，果然当增大consumer的数量后，消费的总量也上去了，说明consumer的数量还有提高的空间，当然，不论消费的多少，数据是不会丢的
再来说第一个问题，因为数据量很大了，conusmer的处理能力达到上限，然后flume作为kafka 的consumer，出现了消息的积压（这哥们在flume中加了个interceptor），按理说，我flume消费多少，我就从kafka中pull多少，根据我的消费能力我来消费数据，如果真是这样就不会有堆积了，kafkasource 默认batchsize 是1000条数据，而且auto.commit.enable 可能设置为true，所以，在flume往channel写的中间，一个interceptor处理能力上不去的话，kafkasource不停的pull数据过来，就导致了数据的来不及处理，有积压的出现。我的理解kafkasource 和 interceptor 之间或许没有建立一种ack机制，kafkasource 根据自己的batchsize和commit设置去不断的拉取数据，在interceptor处出现了瓶颈，如果source和interceptor能统一起来，就解决问题了。或者治标的办法是，降低batchsize 的大小，设置为500，auto.commit.enable = false 。在没改设置之前，出现了kafkasource的内存溢出，报的是由于GC导致的OOM，我分析了他自定义的interceptor代码，发现，它在event processor处理方法内，new 对象过多，对代码进行了优化后，问题暂时解决。治本的方法就是在可以在batch event processor中加上offset的处理，例如在init方法中初始化一个zookeeper的客户端，在batch event processor中对offset更新到zookeeper中，或者是更新到kafka的一个topic中。kafkasource根据offset来pull数据（或者是ack机制，当处理完这一批数据后，ack后，kafkasource再去拉取下一批数据，当数据没有处理成功的话，超时的话，也直接拉取下一批数据，有数据丢失的情况）
第二个问题，如何判断agent挂掉，可以在interceptor中做文章，例如在init方法中初始化一个zookeeper客户端，然后在zk上注册一个watch，当agent挂掉后，interceptor也就挂掉了，zookeeper就能监测到。
第三个问题，tmp文件是因为当sink往hdfs写的过程中，正常写入的文件被命名为tmp文件，当agent当掉后，tmp不会自动改名字，但是tmp中也会有部分数据存在，所以可以写个程序将文件名中的tmp去掉。如果agent重启后，可以续传，就保证数据连接上了。
前面说过了，同事加了一个interceptor后，会导致flume的性能下降。
同时有报了如下的错误
org.apache.flume.source.kafka.KafkaSource.doProcess(KafkaSource.java:314)] KafkaSource EXCEPTION, {}
org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed due to group rebalance
at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler.handle(ConsumerCoordinator.java:552)
at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator$OffsetCommitResponseHandler.handle(ConsumerCoordinator.java:493)
at org.apache.kafka.clients.consumer.internals.AbstractCoordinator$CoordinatorResponseHandler.onSuccess(AbstractCoordinator.java:665)
at org.apache.kafka.clients.consumer.internals.AbstractCoordinator$CoordinatorResponseHandler.onSuccess(AbstractCoordinator.java:644)
我的理解是interceptor，当时处理时间过长，consumer 等待下一次pull的时间间隔过长，导致发送hearbeat时间间隔过长，coordinator认为comsumer死了，就发生了rebalance。
增大参数 hearbeat.interval.ms
缩小参数 max.partition.fetch.bytes 让每次pull的数据少点
有不对的地方，请多多指教