flume1.8 使用指南學習感悟（一）
1. 系統要求
1. Java運行環境 —— Java 1.8及以上
2. 內存 —— 足夠的內存供配置的sources，channels 或者sinks使用
3. 硬盤空間 —— 足夠的硬盤空間供配置的channels或者sinks使用
4. 文件權限 —— agent使用的文件夾讀寫權限
2. 架構及數據流模型
模型介紹詳情參考：http://www.cnblogs.com/swordfall/p/8093464.html
3. 創建
3.1 創建一個Agent
Flume agent配置存儲在一個本地的配置文件。這個text文件遵循Java配置文件格式。配置一個或多個agents可以在同一配置文件中。配置文件包含一個agent裏的每一個source，sink和channel，以及它們怎樣連接在一起，形成數據流。在流中每個組件（source，sink或者channel）有名字，類型和一系列配置。如，Avro source有hostname和port。內存channel可以有最大隊列值（如capacity），HDFS sink有文件系統URI路徑。
3.1.1 啟動一個agent
agent需要使用flume-ng shell腳本啟動運行，該腳本位於Flume文件夾的bin目錄下。你需要在命令中指定agent名，config目錄和config文件：
3.1.2 一個簡單示例
下述是單節點Flume部署配置文件。該配置文件讓用戶生成Events並隨後在控制臺記錄出來。
這個配置定義了一個簡單agent，叫a1。a1 有一個source監聽數據端口44444，一個channel在內存中緩存event數據，還有一個sink在控制臺記錄event日誌。配置文件命名變量組件，然後描述組件的類型和配置屬性。一個配置好的文件可能定義了幾個不同的agent；當一個Flume進程運行時需要說明啟動哪個agent。查看如下命令：
註意：一個完整部署應該包含多一個option：--conf=<conf-dir>。<conf-dir>目錄包含flume-env.sh shell腳本和log4j配置文件。在這個例子中，我們通過Java選擇強制Flume在控制臺打印日誌，沒有通過傳統的環境腳本。
通過一個獨立終端，我們可以telnet port 44444 並給Flume發送一個event：
Flume原來的終端在log消息中打印event：
3.1.3 在配置文件中使用環境變量
這要實現需要設置 propertiesImplementation = org.apache.flume.node.EnvVarResolverProperties
Flume啟動命令例如：
$ NC_PORT=44444 bin/flume-ng agent –conf conf –conf-file example.conf –name a1 -Dflume.root.logger=INFO,console -DpropertiesImplementation=org.apache.flume.node.EnvVarResolverProperties
註意環境變量也可以在conf/flume-env.sh文件中配置
3.1.4 記錄原始數據
在許多生產環境不期望記錄攝取通道上的原始數據流，因為這也許導致Flume日誌文件泄漏敏感數據或者安全相關的配置，如密鑰。默認的，Flume不會記錄這類信息。另一方面，如果數據通道被打斷，Flume會嘗試提供調試問題的線索。
調試event管道上的問題的方法是去設置一個額外Memory Channel連接Logger Sink，這會在Flume logs上輸出所有event 數據。在一些情況下，然而，這方法是不夠的。
為了能記錄event-和配置相關的數據，一些Java系統屬性必須設置在log4j配置上。
啟用配置相關的日誌記錄，設置Java系統屬性 -Dorg.apache.flume.log.printconfig=true。這可以在命令行設置或者在flume-env.sh文件Java_OPTS變量設置。
啟用數據日誌記錄，在上面描述的同樣方法中設置-Dorg.apache.flume.log.rawdata=true。對於大多數組件，為了使event特定的日誌出現在Flume日誌中，log4j日誌級別設置為DEBUG或者TRACE。下面例子，當設置Log4j 日誌級別為DEBUG時，控制臺能同時打印出配置日誌和原始數據日誌：
bin/flume-ng agent --conf conf --conf-file example.conf --name a1 -Dflume.root.logger=DEBUG,console -Dorg.apache.flume.log.printconfig=true -Dorg.apache.flume.log.rawdata=true
3.1.5 基於Zookeeper的配置
Flume通過Zookeeper支持Agent配置。這是實驗性功能。配置文件需要上傳到Zookeeper，有可配置的前綴。配置文件保存在Zookeeper Node data節點上。
一旦配置文件上傳，啟動帶有下述選項的agent：
$ bin/flume-ng agent –conf conf -z zkhost:2181,zkhost1:2181 -p /flume –name a1 -Dflume.root.logger=INFO,console
| Argument Name | Default | Description |
|---|---|---|
| z | – | Zookeeper connection string. Comma separated list of hostname:port |
| p | /flume | Base Path in Zookeeper to store Agent configurations |
3.2 提取數據
3.2.1 RPC方式
Flume distribution包含的Avro客戶端可以通過使用avro RPC機制發送文件到Flume Avro source.
上面命令將會在41414端口發送/usr/log.10文件內容發送到Flume source.
3.2.2 Network streams
FLume支持下面機制去從log流類型讀取數據, 如: 1. Avro 2. Thrift 3. Syslog 4. Netcat
3.2.3 設置多個agent流
為了使數據流通多個agents或者hops, 前一個agent的sink和當前hop的source需要是avro類型, 同時sink指向source的hostname(或者IP地址)和port.
3.2.4 合並
大量的日誌生成客戶端發送數據到幾個消費者agents, 這些agents連接著存儲系統.例如, 幾百個web servers收集的日誌發送到多個agents, 最後agents寫進HDFS集群.
通過配置多個帶有avro sink的一級agents, 然後全部指向單獨agent的avro source(或者使用thrift sources/sinks/clients), 這在Flume上是可以實現的.二級agent的source合並接收的events進一個單獨channel, 這個channel裏面的events會被一個sink消費後進入到最終目的地.
3.2.5 多路復用流程
Flume支持復用event流向一個或多個目的地。通過定義可復制或者選擇性地將event路由到一個或多個channels的流復用器實現。
上述例子展示了一個agent "foo"的source把流量分散到三個不同的channels。這分散可以被復制或復用。在復制流量的情況下，每個event都被發送到三個channels。對於復用情況，當一個event的屬性匹配到預配置的值時，該event被傳遞到可用channels的子集。例如，如果一個event屬性“txnType” 被設置為“customer”，然後它應該去channel1和channel3，如果它是“vendor”，然後它應該去channel2，否則channel3。這個映射可以設置在agent的配置文件中。
4. 配置
4.1 定義flow
在一個簡單agent中定義流程，你需要通過一個channel連接sources和sinks。你需要為給出的agent列出sources，sinks和channels，然後j將source和sink指向channel。一個source實例可以指定多個channels，但是一個sink實例只能指定一個channel。格式為下述：
舉例，一個名叫agent_foo的agent從外部avro client讀取數據，然後通過一個memory channel發送數據到HDFS。配置文件類似如下：
這個將會使events通過memory channel mem-channel-1從avro-AppSrv-source流向hdfs-sink-1。
4.2 配置單個組件
定義流程之後，你需要設置每個source、sink和channel的配置。在相同的階級式名稱空間中，你可以為每個組件特定的屬性設置組件類型和其他值。
Flume的每個組件都需要設置類型“type”，為了指明組件需要成為哪種對象類型。每個source、sink和channel類型各自有一系列功能屬性。當需要時，它們需要被設置出來。上一個例子，我們有通過memory channel mem-channel-1從avro-AppSrv-Source到hdfs-Cluster1-sink的流程。下面例子展示那些組件的配置：
4.3 在一個agent中添加多個流程
一個簡單Flume agent可以包含多個獨立的流程。你可以在配置中列出多個sources、sinks和channels。這些組件可以鏈接形成多個流程：
你可以將sources和sinks鏈接到它們相應的channels，建立兩個不同的流程。例如，如果你需要在一個agent建立兩個流程，一個從外部avro client到外部HDFS，另一個從tail輸出到avro sink，配置如下：
4.4 配置一個多agent流程
為了建立一個多層流程，你需要第一層的avro/thrift sink 指向下一層的avro/thrift source。這將會導致第一個Flume agent的events轉發給下一個Flume agent。例如，你正在用avro client定期發送文件（一個文件即為event）到本地的Flume agent，然後這個本地agent會把文件轉發給另一個有存儲功能的agent。
Weblog agent配置：
HDFS agent配置：
這裏，我們將weblog agent的avro-forward-sink鏈接到hdfs agent的avro-collection-source。這導致來自外部appserver source的events最終存儲在HDFS中。
4.5 分散流程
如上節討論的那樣，Flume支持從一個source到多個channels的分散流程。分散有兩種模式，復制(replicating)和復用(multiplexing)。在復制流程中，event將會被發送到全部配置的channels。在復用情況下，event只會被發送到符合要求的channels。在分散流程中，需要指定source的channels列表和分散規則。添加一個channel "selector"，可以是replicating或者multiplexing，然後指定選擇規則，如果你沒有指定一個selector，默認replicating：
復用選擇有一系列屬性去分流流程。這要求在channel設置指定event屬性的mapping。selector在event的header檢查每個配置的屬性。如果匹配到指定的值，該event會被發送到映射該值的channels。如果沒有匹配到，event將會發送到配置好默認的channels。
下面的例子展示，一個簡單流程多路復用到兩條路徑。名叫agent_foo的agent有一個簡單avro source和兩個鏈接到兩個sinks的channels：
selector檢查叫“State”的header。如果值為“CA”，然後它所屬的event將會被發送到mem-channel-1，如果值為“AZ”則發送到file-channel-2，或者值為“NY”則兩個channels都發送。如果“State“ header沒有設置或者匹配不到三個值中的一個，則event被發送到默認的mem-channel-1。
selector也支持可選的channel。為header指定可選的channels，配置屬性‘optional’可以像下面那樣使用：
selector第一次將會嘗試向要求的channels發送events，如果這些channels消費events失敗，則提交事務失敗，事務將會再次向這些channels提交。一旦要求的channels消費完這些events，selector將會向可選的channels發送events。如果這些可選channels消費失敗，將會被忽略，不會再次提交事務。
註意：如果header沒有要求的channels，events將會寫進默認channels，也會試圖寫進可選的channels。如果沒有要求channels指定，指定可選的channels將會同樣造成event被寫進默認channels。如果沒有默認的和要求的channels，selector將會把events試圖寫進可選channels。在這種情況下，失敗將會被忽略。
4.6 Flume Sources
4.6.1 Avro Source
監聽Avro端口，從Avro client streams接收events。要求屬性是粗體字。
agent a1例子：
ipFilterRules例子：
ipFilterRules=allow:ip:127.*, allow:name:localhost,deny:ip:*
4.6.2 Thrift Source
監聽Thrift端口和從外部Thrift client streams接收events。要求屬性為粗體字：
agent a1 例子：
4.6.3 Exec Source
Exec Source在啟動時運行一個Unix命令行，並期望這過程在標準輸出上連續生產數據。要求屬性為粗體字：
agent a1例子：
‘shell‘配置被用來通過一個命令shell調用‘command’。
4.6.4 JMS Source
JMS Source從JMS目標（如隊列或者主題）讀取消息。JMS應用程序應該可以與任何JMS提供程序一起工作，但是只能使用ActiveMQ進行測試。要求屬性是粗體字。
agent a1例子：
4.6.5 Spooling Directory Source
該source讓你通過放置被提取文件在磁盤”spooling“目錄下這一方式，提取數據。該source將會監控指定目錄的新增文件，當新文件出現時解析event。event解析邏輯是可插入的。當一個給定文件被全部讀取進channel之後，它被重命名，以標識為已完成（或者可選擇deleted）。
agent-1例子：
4.6.6 Taildir Source
註意：該source不能用於windows。
agent a1例子：
4.6.7 Twitter 1% firehose Source(試驗)
略
4.6.8 Kafka Source
Kafka Source是Apache Kafka消費者，從Kfaka topics讀取消息。如果你有多個Kafka source在跑，你可以配置它們在相同的Consumer Group，以使它們每個讀取topics獨特的分區。
以逗號分隔的topic列表進行topic訂閱的例子：
通過正則表達式進行topic訂閱的例子：
安全和Kafka Source
Kafka 0.9.0支持SASL/GSSAPI 或者 SSL 協議。
設置 kafka.consumer.security.protocol的值：
①SASL_PLAINTEXT - Kerberos or plaintext authentication with no data encryption
②SASL_SSL - Kerberos or plaintext authentication with data encryption
③SSL - TLS based encryption with optional authentication.
TLS和Kafka Source
帶有服務端認證和數據加密配置的例子：
註意：屬性ssl.endpoint.identification.algorithm沒有定義，因此沒有hostname驗證，為了是hostname驗證，可以設置屬性：
如果要求有客戶端認證，在Flume agent配置中添加下述配置。每個Flume agent必須有它的客戶端憑證，以便被Kafka brokers信任。
如果keystore和key使用不用的密碼保護，那麽ssl.key.password屬性需要提供出來：
Kerberos和Kafka Soure:
kerberos配置文件可以在flume-env.sh通過JAVA_OPTS指定：
使用SASL_PLAINTEST的安全配置示例：
使用SASL_SSL的安全配置示例：
JAAS文件實例（暫時沒看懂）：
4.6.9 NetCat TCP Source
netcat source監聽一個給定的端口，然後把text文件的每一行轉換成一個event。要求屬性是粗體字。
agent a1示例：
4.6.10 NetCat UDP Source
netcat source監聽一個給定的端口，然後把text文件的每一行轉換成一個event。要求屬性是粗體字。
agent a1的示例：
4.6.11 Sequence Generator Source
一個簡單的序列生成器可以不斷生成events，帶有counter計數器，從0開始，以1遞增，在totalEvents停止。當不能發送events到channels時會不斷嘗試。
agent a1示例：
4.6.12 Syslog Sources
讀取系統日誌，並生成Flume events。UDP source以整條消息作為一個簡單event。TCP source以新一行”n“分割的字符串作為一個新的event。
4.6.12.1 Syslog TCP Source
原始的，可靠的Syslog TCP source。
agent a1的syslog TCP source示例：
4.6.12.2 Multiport Syslog TCP Source
這是一個新的，更快的，多端口的Syslog TCP source版本。註意ports配置替代port。
agent a1的multiport syslog TCP source示例：
4.6.12.3 Syslog UDP Source
agent a1的syslog UDP source示例：
4.6.13 HTTP Source
source 通過HTTP POST 和 GET，接收Flume events。GET只能用於試驗。HTTP requests通過 必須實現 HTTPSourceHandler接口的 ”handler“ 轉換成flume events。該handler獲取HttpServletRequest，然後返回一系列的flume events。
agent a1的http source示例：
Handler屬性有兩種，一是JSONHandler，一是BlobHandler。
BlobHandler用於處理請求參數帶有比較大的對象（Binary Large Object），如PDF或者JPG。
4.6.14 Stress Source
StressSource 是內部負載生成source的實現，這對於壓力測試是非常有用的。它允許用戶配置Event有效載荷的大小。
agent a1的示例：
4.6.15 Legacy Sources
legacy sources允許Flume 1.x agent接收來自Flume 0.9.4 agents的events。
legacy source 支持Avro和Thrift RPC 連接。為了使用兩個Flume 版本搭建的橋梁，你需要開始一個帶有avroLegacy或者thriftLegacy source的Flume 1.x agent。0.9.4agent應該有agent Sink指向1.x agent的host/port。
4.6.15.1 Avro Legacy Source
agent a1的示例：
4.6.15.2 Thrift Legacy Source
agent a1的示例：
4.6.16 Custom Source(自定義Source)
自定義Source是你實現Source接口。當啟動Flume agent時，一個自定義source類和它依賴項必須在agent的classpath中。
agent a1的示例：
4.6.17 Scrible Source
Scribe是另一種類型的提取系統。采用現有的Scribe提取系統，Flume應該使用基於Thrift的兼容傳輸協議的ScribeSource。
agent a1示例：
參考資料：
https://flume.apache.org/FlumeUserGuide.html
flume1.8 使用指南學習感悟（一）