Flume 監控
一共分爲兩種監控
http監控
Flume作爲一個強大的數據收集工具，雖然功能非常強大實用，但是卻無法看到flume收集數據的詳細信息，所以我們需要一個能展示flume實時收集數據動態信息的界面，包括flume成功收集的日誌數量、成功發送的日誌數量、flume啓動時間、停止時間、以及flume一些具體的配置信息，像通道容量等，於是順利成章的監控能幫我們做到這些，有了這些數據，在遇到數據收集瓶頸或者數據丟失的時候，通過分析監控數據來分析、解決問題。
使用這種監控方式，只需要在啓動flume的時候在啓動參數上面加上監控配置，例如這樣：
bin/flume-ng agent --conf conf --conf-file conf/flume_conf.properties --name collect -Dflume.monitoring.type=http -Dflume.monitoring.port=1234
其中-Dflume.monitoring.type=http表示使用http方式來監控，後面的-Dflume.monitoring.port=1234表示我們需要啓動的監控服務的端口號爲1234，這個端口號可以自己隨意配置。然後啓動flume之後，通過http://ip:1234/metrics就可以得到flume的一個json格式的監控數據。
ganglia監控
這種監控方式需要先安裝ganglia然後啓動ganglia，然後再啓動flume的時候加上監控配置，例如
bin/flume-ng agent --conf conf --conf-file conf/producer.properties --name collect -Dflume.monitoring.type=ganglia -Dflume.monitoring.hosts=ip:port
其中-Dflume.monitoring.type=ganglia表示使用ganglia的方式來監控，而-Dflume.monitoring.hosts=ip:port表示ganglia安裝的ip和啓動的端口號。
flume監控還可以使用zabbix，但是這種方式需要在flume源碼中添加監控模塊，相對比較麻煩，由於不是flume自帶的監控方式，這裏不討論這種方式。
因此，flume自帶的監控方式其實就是http、ganglia兩種，http監控只能通過一個http地址訪問得到一個json格式的監控數據，而ganglia監控是拿到這個數據後用界面的方式展示出來了，相對比較直觀。
Flume的事務
一：Flume的事務機制
Flume的事務機制（類似數據庫的事務機制）：Flume使用兩個獨立的事務分別負責從soucrce到channel，以及從channel到sink的事件傳遞。比如以上面一篇博客中的事例爲例：spooling directory source 爲文件的每一行創建一個事件，一旦事務中所有的事件全部傳遞到channel且提交成功，那麼source就將該文件標記爲完成。同理，事務以類似的方式處理從channel到sink的傳遞過程，如果因爲某種 原因使得事件無法記錄，那麼事務將會回滾。且所有的事件都會保持到channel中，等待重新傳遞。
二:Flume的At-least-once提交方式
Flume的事務機制，總的來說，保證了source產生的每個事件都會傳送到sink中。但是值得一說的是，實際上Flume作爲高容量並行採集系統採用的是At-least-once（傳統的企業系統採用的是exactly-once機制）提交方式，這樣就造成每個source產生的事件至少到達sink一次，換句話說就是同一事件有可能重複到達。這樣雖然看上去是一個缺陷，但是相比爲了保證Flume能夠可靠地將事件從source,channel傳遞到sink,這也是一個可以接受的權衡。如上博客中spooldir的使用，Flume會對已經處理完的數據進行標記。
三：Flume的批處理機制
爲了提高效率，Flume儘可能的以事務爲單位來處理事件，而不是逐一基於事件進行處理。比如上篇博客提到的spooling directory source以100行文本作爲一個批次來讀取（BatchSize屬性來配置，類似數據庫的批處理模式）。批處理的設置尤其有利於提高file channle的效率，這樣整個事務只需要寫入一次本地磁盤，或者調用一次fsync，速度回快很多。
Channel的選擇
Flume1.4.0中，其官方提供常用的MemoryChannel和FileChannel供大家選擇。其優劣如下：
MemoryChannel: 所有的events被保存在內存中。優點是高吞吐。缺點是容量有限並且Agent死掉時會丟失內存中的數據。
FileChannel: 所有的events被保存在文件中。優點是容量較大且死掉時數據可恢復。缺點是速度較慢。
上述兩種Channel，優缺點相反，分別有自己適合的場景。然而，對於大部分應用來說，我們希望Channel可以同提供高吞吐和大緩存。基於此，我們開發了DualChannel。
DualChannel：基於 MemoryChannel和 FileChannel開發。當堆積在Channel中的events數小於閾值時，所有的events被保存在MemoryChannel中，Sink從MemoryChannel中讀取數據； 當堆積在Channel中的events數大於閾值時， 所有的events被自動存放在FileChannel中，Sink從FileChannel中讀取數據。這樣當系統正常運行時，我們可以使用MemoryChannel的高吞吐特性；當系統有異常時，我們可以利用FileChannel的大緩存的特性。