基於Flume+Log4j+Kafka的日誌採集架構方案（上）

Flume是一個完善、強大的日誌採集工具，關於它的配置，在網上有不少現成的例子和資料，這裏僅作簡單說明再也不詳細贅述。
Flume包含Source、Channel、Sink三個最基本的概念：

Source——日誌來源，其中包括：Avro Source、Thrift Source、Exec Source、JMS Source、Spooling Directory Source、Kafka Source、NetCat Source、Sequence Generator Source、Syslog Source、HTTP Source、Stress Source、Legacy Source、Custom Source、Scribe Source以及Twitter 1% firehose Source。

Channel——日誌管道，全部從Source過來的日誌數據都會以隊列的形式存放在裏面，它包括：Memory Channel、JDBC Channel、Kafka Channel、File Channel、Spillable Memory Channel、Pseudo Transaction Channel、Custom Channel。

Sink——日誌出口，日誌將經過Sink向外發射，它包括：HDFS Sink、Hive Sink、Logger Sink、Avro Sink、Thrift Sink、IRC Sink、File Roll Sink、Null Sink、HBase Sink、Async HBase Sink、Morphline Solr Sink、Elastic Search Sink、Kite Dataset Sink、Kafka Sink、Custom Sink。

基於Flume的日誌採集是靈活的，咱們能夠看到既有Avro Sink也有Avro Source，既有Thrift Sink也有Thrift Source，這意味着咱們能夠將多個管道處理串聯起來，以下圖所示

串聯的意義在於，咱們能夠將多個管道合併到一個管道中最終輸出到同一個Sink中去，以下圖：

上面講述了Source和Sink的做用，而Channel的做用在於處理不一樣的Sink，假設咱們一個Source要對應多個Sink，則只須要爲一個Source創建多個Channel便可，以下所示：

一個Source若是想要輸出到多個Sink中去，就須要創建多個Channel進行介入並最終輸出，經過上面這幾張圖，咱們能夠很好的理解Flume的運行機制，咱們在這裏也就點到爲止，詳細的配置能夠在官網或者在網上搜索到、查看到。

通常狀況下，咱們使用 Exec Source對log文件進行監控，這樣作確實是比較簡單，可是並不方便，咱們須要在每一臺要監控的服務器上部署Flume，對運維來說萬一目標日誌文件發生IO異常（例如格式改變、文件名改變、文件被鎖），也是很痛苦的，所以咱們最好能讓日誌直接經過Socket發送出去，而不是存放在本地，這樣一來，不只下降了目標服務器的磁盤佔用，還可以有效的防止文件IO異常，而Kafka就是一個比較好的解決方案，具體的架構以下圖所示：

由上圖能夠看到，日誌最終流向了兩個地方：HBase Persistence和Realtime Processor，而至於爲何不用Kafka直接與Storm進行通訊的緣由是爲了將Sotrm邏輯和日誌源經過Flume進行隔離，在Storm中對日誌進行簡單的分析後，將結果扔進 Rabbit MQ 中供 WEB APP消費。

HBase Persistence就是將原始的日誌記錄在HBase中以便回檔查詢，而Realtime Processor則包含了實時的日誌統計以及錯誤異常郵件提醒等功能。

下節咱們重點講述程序實現