同事遇到點問題，拋出來了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的數據少點
有不對的地方，請多多指教