這裡只考慮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

七、關於interceptor：

請看我的關於這個元件的部落格，傳送門；

八、關於Flume-NG叢集網路拓撲方案：

1、在每臺採集節點上部署一個flume agent，然後做一到多個彙總flume agent(loadbalance)，採集只負責收集資料發往彙總，彙總可以寫HDFS、HBase、spark、本地檔案、kafka等等，這樣一般修改會只在彙總，agent少，維護工作少；
2、採集節點沒有部署flume agent，可能發往mongo、redis等，這時你需要自定義source或者使用sdk來將其中的資料取出併發往flume agent，這樣agent就又可以充當“採集節點”或者彙總節點了，但是這樣在前面相當於加了一層控制，就又多了一層風險；
3、由於能力有限，其它未知，上面兩種，第一種好些，這裡看看美團的架構————傳送門；

東西比較簡單，容易消化。

未完，待續。。。歡迎補充