Flume NG是Cloudera提供的一個分布式、可靠、可用的系統,它能夠将不同資料源的海量日志資料進行高效收集、聚合、移動,最後存儲到一個中心化資料存儲系統中。由原來的Flume OG到現在的Flume NG,進行了架構重構,并且現在NG版本完全不相容原來的OG版本。經過架構重構後,Flume NG更像是一個輕量的小工具,非常簡單,容易适應各種方式日志收集,并支援failover和負載均衡。
Flume 使用 java 編寫,其需要運作在 Java1.6 或更高版本之上。
- 官方網站:http://flume.apache.org/
- 使用者文檔:http://flume.apache.org/FlumeUserGuide.html
- 開發文檔:http://flume.apache.org/FlumeDeveloperGuide.html
1、flume架構:
Flume的架構主要有一下幾個核心概念:
- Event:一個資料單元,帶有一個可選的消息頭
- Flow:Event從源點到達目的點的遷移的抽象
- Client:操作位于源點處的Event,将其發送到Flume Agent
- Agent:一個獨立的Flume程序,包含元件Source、Channel、Sink
- Source:用來消費傳遞到該元件的Event
- Channel:中轉Event的一個臨時存儲,儲存有Source元件傳遞過來的Event
- Sink:從Channel中讀取并移除Event,将Event傳遞到Flow Pipeline中的下一個Agent(如果有的話)
Flume 的核心是把資料從資料源收集過來,再送到目的地。為了保證輸送一定成功,在送到目的地之前,會先緩存資料,待資料真正到達目的地後,删除自己緩存的資料。
Flume 傳輸的資料的基本機關是 Event,如果是文本檔案,通常是一行記錄,這也是事務的基本機關。Event 從 Source,流向 Channel,再到 Sink,本身為一個 byte 數組,并可攜帶 headers 資訊。Event 代表着一個資料流的最小完整單元,從外部資料源來,向外部的目的地去。
Flume 運作的核心是 Agent。它是一個完整的資料收集工具,含有三個核心元件,分别是 source、channel、sink。通過這些元件,Event 可以從一個地方流向另一個地方,如下圖所示。
- source 可以接收外部源發送過來的資料。不同的 source,可以接受不同的資料格式。比如有目錄池(spooling directory)資料源,可以監控指定檔案夾中的新檔案變化,如果目錄中有檔案産生,就會立刻讀取其内容。
- channel 是一個存儲地,接收 source 的輸出,直到有 sink 消費掉 channel 中的資料。channel 中的資料直到進入到下一個channel中或者進入終端才會被删除。當 sink 寫入失敗後,可以自動重新開機,不會造成資料丢失,是以很可靠。
- sink 會消費 channel 中的資料,然後送給外部源或者其他 source。如資料可以寫入到 HDFS 或者 HBase 中。
2、核心元件
1)source
Client端操作消費資料的來源,Flume 支援 Avro,log4j,syslog 和 http post(body為json格式)。可以讓應用程式同已有的Source直接打交道,如AvroSource,SyslogTcpSource。也可以 寫一個 Source,以 IPC 或 RPC 的方式接入自己的應用,Avro和 Thrift 都可以(分别有 NettyAvroRpcClient 和 ThriftRpcClient 實作了 RpcClient接口),其中 Avro 是預設的 RPC 協定。具體代碼級别的 Client 端資料接入,可以參考官方手冊。
對現有程式改動最小的使用方式是使用是直接讀取程式原來記錄的日志檔案,基本可以實作無縫接入,不需要對現有程式進行任何改動。 對于直接讀取檔案 Source,有兩種方式:
- ExecSource: 以運作 Linux 指令的方式,持續的輸出最新的資料,如
tail -F 檔案名
- 指令,在這種方式下,取的檔案名必須是指定的。 ExecSource 可以實作對日志的實時收集,但是存在Flume不運作或者指令執行出錯時,将無法收集到日志資料,無法保證日志資料的完整性。
- SpoolSource: 監測配置的目錄下新增的檔案,并将檔案中的資料讀取出來。需要注意兩點:拷貝到 spool 目錄下的檔案不可以再打開編輯;spool 目錄下不可包含相應的子目錄。
SpoolSource 雖然無法實作實時的收集資料,但是可以使用以分鐘的方式分割檔案,趨近于實時。
如果應用無法實作以分鐘切割日志檔案的話, 可以兩種收集方式結合使用。 在實際使用的過程中,可以結合 log4j 使用,使用 log4j的時候,将 log4j 的檔案分割機制設為1分鐘一次,将檔案拷貝到spool的監控目錄。
log4j 有一個 TimeRolling 的插件,可以把 log4j 分割檔案到 spool 目錄。基本實作了實時的監控。Flume 在傳完檔案之後,将會修改檔案的字尾,變為 .COMPLETED(字尾也可以在配置檔案中靈活指定)。
Flume Source 支援的類型:
Source類型 | 說明 |
Avro Source | 支援Avro協定(實際上是Avro RPC),内置支援 |
Thrift Source | 支援Thrift協定,内置支援 |
Exec Source | 基于Unix的command在标準輸出上生産資料 |
JMS Source | 從JMS系統(消息、主題)中讀取資料,ActiveMQ已經測試過 |
Spooling Directory Source | 監控指定目錄内資料變更 |
Twitter 1% firehose Source | 通過API持續下載下傳Twitter資料,試驗性質 |
Netcat Source | 監控某個端口,将流經端口的每一個文本行資料作為Event輸入 |
Sequence Generator Source | 序列生成器資料源,生産序列資料 |
Syslog Sources | 讀取syslog資料,産生Event,支援UDP和TCP兩種協定 |
HTTP Source | 基于HTTP POST或GET方式的資料源,支援JSON、BLOB表示形式 |
Legacy Sources | 相容老的Flume OG中Source(0.9.x版本) |
2)
Channel
目前有幾個 channel 可供選擇,分别是 Memory Channel, JDBC Channel , File Channel,Psuedo Transaction Channel。比較常見的是前三種 channel。
- MemoryChannel 可以實作高速的吞吐,但是無法保證資料的完整性。
- MemoryRecoverChannel 在官方文檔的建議上已經建義使用FileChannel來替換。
- FileChannel保證資料的完整性與一緻性。在具體配置FileChannel時,建議FileChannel設定的目錄和程式日志檔案儲存的目錄設成不同的磁盤,以便提高效率。
File Channel 是一個持久化的隧道(channel),它持久化所有的事件,并将其存儲到磁盤中。是以,即使 Java 虛拟機當掉,或者作業系統崩潰或重新開機,再或者事件沒有在管道中成功地傳遞到下一個代理(agent),這一切都不會造成資料丢失。Memory Channel 是一個不穩定的隧道,其原因是由于它在記憶體中存儲所有事件。如果 java 程序死掉,任何存儲在記憶體的事件将會丢失。另外,記憶體的空間收到 RAM大小的限制,而 File Channel 這方面是它的優勢,隻要磁盤空間足夠,它就可以将所有事件資料存儲到磁盤上。
Flume Channel 支援的類型:
Channel類型 | 說明 |
Memory Channel | Event資料存儲在記憶體中 |
JDBC Channel | Event資料存儲在持久化存儲中,目前Flume Channel内置支援Derby |
File Channel | Event資料存儲在磁盤檔案中 |
Spillable Memory Channel | Event資料存儲在記憶體中和磁盤上,當記憶體隊列滿了,會持久化到磁盤檔案(目前試驗性的,不建議生産環境使用) |
Pseudo Transaction Channel | 測試用途 |
Custom Channel | 自定義Channel實作 |
3)sink
Sink在設定存儲資料時,可以向檔案系統、資料庫、hadoop存資料,在日志資料較少時,可以将資料存儲在檔案系中,并且設定一定的時間間隔儲存資料。在日志資料較多時,可以将相應的日志資料存儲到Hadoop中,便于日後進行相應的資料分析。
Flume Sink支援的類型
Sink類型 | 說明 |
HDFS Sink | 資料寫入HDFS |
Logger Sink | 資料寫入日志檔案 |
Avro Sink | 資料被轉換成Avro Event,然後發送到配置的RPC端口上 |
Thrift Sink | 資料被轉換成Thrift Event,然後發送到配置的RPC端口上 |
IRC Sink | 資料在IRC上進行回放 |
File Roll Sink | 存儲資料到本地檔案系統 |
Null Sink | 丢棄到所有資料 |
HBase Sink | 資料寫入HBase資料庫 |
Morphline Solr Sink | 資料發送到Solr搜尋伺服器(叢集) |
ElasticSearch Sink | 資料發送到Elastic Search搜尋伺服器(叢集) |
Kite Dataset Sink | 寫資料到Kite Dataset,試驗性質的 |
Custom Sink | 自定義Sink實作 |
更多sink的内容可以參考官方手冊。(http://flume.apache.org/FlumeDeveloperGuide.html#sink)
3、可靠性
Flume 的核心是把資料從資料源收集過來,再送到目的地。為了保證輸送一定成功,在送到目的地之前,會先緩存資料,待資料真正到達目的地後,删除自己緩存的資料。
Flume 使用事務性的方式保證傳送Event整個過程的可靠性。Sink 必須在 Event 被存入 Channel 後,或者,已經被傳達到下一站agent裡,又或者,已經被存入外部資料目的地之後,才能把 Event 從 Channel 中 remove 掉。這樣資料流裡的 event 無論是在一個 agent 裡還是多個 agent 之間流轉,都能保證可靠,因為以上的事務保證了 event 會被成功存儲起來。而 Channel 的多種實作在可恢複性上有不同的保證。也保證了 event 不同程度的可靠性。比如 Flume 支援在本地儲存一份檔案 channel 作為備份,而memory channel 将 event 存在記憶體 queue 裡,速度快,但丢失的話無法恢複。
參考:
http://blog.javachen.com/2014/07/22/flume-ng.html
http://www.jianshu.com/p/50f384b86bdf
http://shiyanjun.cn/archives/915.html
http://shiyanjun.cn/archives/1497.html
https://tech.meituan.com/mt-log-system-arch.html
https://tech.meituan.com/mt-log-system-optimization.html