Flume作為現在最常用的日誌收集工具之一，目前已經更新到了1.8.0版本，我們以最新版本開始進行我們的學習。整個學習過程以官方文件為主，輔助是參考了SteveHoffman編寫的《Flume日誌收集與MapReduce模式》一書。

首先要明確幾個定義： Source、Channel、Sink
Source：源；表示我們收集日誌的資料來源
Channel：通道；表示資料傳輸過程中途徑的通道，我們可以在源到Sink中間進行一些處理操作
Sink：目的地；表示我們需要最終要將收集到的日誌輸出到的地方

Flume官方支援的幾種常見Source的實現:（這裡面我只詳細寫了我應用過/測試過的Source型別）

1. Avro Source:Avro Netty RPC event source
2. exec Source:Execute a long-lived Unix process and read from stdout
3. Thrift Source
4. JMS Source
5. Spooling Directory Source:
6. Taildir Source
7. Twitter 1% firehose Source
8. Kafka Source
9. NetCat TCP Source
10. NetCat UDP Source
11. Sequence Generator Source
12. Syslog Sources
13. HTTP Source
14. Stress Source
15. Legacy Sources
16. Custom Source
17. Scribe Source

Flume官方支援的幾種常見Sink的實現:

1. Flume Sinks
2. HDFS Sink
3. Hive Sink
4. Logger Sink
5. Avro Sink
6. Thrift Sink
7. IRC Sink
8. File Roll Sink
9. Null Sink
10. HBaseSinks
11. HBaseSink
12. AsyncHBaseSink
13. MorphlineSolrSink
14. ElasticSearchSink
15. Kite Dataset Sink
16. Kafka Sink
17. HTTP Sink
18. Custom Sink

Flume官方支援的Channel的實現:

1. Flume Channels
2. Memory Channel
3. JDBC Channel
4. Kafka Channel
5. File Channel
6. Spillable Memory Channel
7. Pseudo Transaction Channel
8. Custom Channel

我用過的幾種組合:

• Spooldir / Exec / Avro Source + Memory Channel + Kafka Sink

瞭解Flume基本的組成之後，我以實際的業務場景為例來講述最終如何落地實踐，(關於Flume運維的知識我們放在最後講)我們現在就以單點為基礎，目的是讓大家快速的瞭解、實踐。

專案背景: 目前公司整體架構採用的微服務架構、分散式部署，各個業務由多個服務組成，由於業務的不斷迭代和複雜性日益加深，在各個服務呼叫的邏輯上越來越難梳理，排查問題也越來越困難（有人會說，不是可以做分散式跟蹤嗎？這個應該是微服務架構生態下所具備的一個功能啊），但是由於企業的快速發展，這部分建設並不完善，也就是沒有對應的平臺來支援，同時類似於阿里系的APM應用級的監控，也並不能完全解決我們日常迭代中的需要，因為們可能需要的時候更多的是業務日誌，也就是服務內部處理過程中對資料操作的日誌，這部分需要開發同學自主的去記錄。那麼我們現在就需要這樣一個平臺/環境來對這部分日誌進行收集、清洗、展示，來輔助我們開發同學定位、排查問題，幫助測試同學提升測試效率，做到儘可能的全面覆蓋。

技術選型：在方案調研期間，曾經考慮過多種，結合實際場景分析，期望對業務日誌直接使用，並且儘可能的減少對RD程式碼的修改工作。現有的日誌記錄分為兩種：1.log4j 2.IO寫檔案(不要追問為什麼…遺留問題…)；於是各種方案應運而生：

1. Flume基於檔案目錄的模式對日誌檔案進行收集
2. 使用Exec + tail 模式對日誌檔案監聽，實時收集
3. 使用log4j2直接分發至Flume的Avro源，實時收集

下面分析一下為什麼選擇了這幾種方案: (最終沒有采用Flume，後面會講，當前只是結合講解Flume的使用)
第一種方案是最直接的也就是不用動腦子的，也是最容易的；
參考配置:

第一種方案分析：此時Flume會監控指定的目錄檔案，也就是說當有日誌檔案產生的時候，Flume就會讀取資料，並在完成時修改檔案狀態或者刪除（加標識表示已經處理完成），但是這樣會影響真實業務的資料日誌記錄，如果說是隔日提取，這種方案是可以的，也就是說提取的是前一天或者N天的資料，原因是我們一般都是按天+檔案大小去記錄日誌的。所以這種方案想做實時被Pass了。

第二種方案是在第一種方案失敗後想到的，因為想做實時，那麼就用了tail -f的模式：
參考配置:

第二種方案分析：雖然表面上完成了實時日誌的收集，但是存在著大量的隱患工作，我們在查閱官方文件時方向，Flume已經摒棄了這種tail模式，從而衍生出了exec + tail 模式，但是這樣依舊會存線上程後臺存活的問題，也就是說當tail -f這個執行緒出現異常或者Flume代理關閉或者重啟時，派生出來的程序不能保證100%關閉，就會產生永不退出的孤立tail程序，那麼其佔用的系統資源就一直無法被釋放，根據定義，tail -f是沒有結束的，即使是刪掉了被tail的檔案，執行中的tail程序也會一直開啟該檔案控制代碼，直至系統資源被耗盡。在官方文件中，明確的指出：非常不建議使用該模式，可能會引發未知的災難。

第三種方案分析: 能否讓日誌直接寫入Flume的Agent呢？這樣就可以解決實時的問題，又不會帶來額外的風險。答案是可以的，Log4J2已經支援了這種模式，此時就需要在log4j2上做了配置了，這種方案的利弊又是如何呢？
log4j2參考配置如下：
A sample FlumeAppender configuration that is configured with a primary and a secondary agent using Flume configuration properties, compresses the body, formats the body using RFC5424Layout and passes the events to an embedded Flume Agent.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="error" name="MyApp" packages="">
  <Appenders>
    <Flume name="eventLogger" compress="true" type="Embedded">
      <Property name="channels">file</Property>
      <Property name="channels.file.type">file</Property>
      <Property name="channels.file.checkpointDir">target/file-channel/checkpoint</Property>
      <Property name="channels.file.dataDirs">target/file-channel/data</Property>
      <Property name="sinks">agent1 agent2</Property>
      <Property name="sinks.agent1.channel">file</Property>
      <Property name="sinks.agent1.type">avro</Property>
      <Property name="sinks.agent1.hostname">192.168.10.101</Property>
      <Property name="sinks.agent1.port">8800</Property>
      <Property name="sinks.agent1.batch-size">100</Property>
      <Property name="sinks.agent2.channel">file</Property>
      <Property name="sinks.agent2.type">avro</Property>
      <Property name="sinks.agent2.hostname">192.168.10.102</Property>
      <Property name="sinks.agent2.port">8800</Property>
      <Property name="sinks.agent2.batch-size">100</Property>
      <Property name="sinkgroups">group1</Property>
      <Property name="sinkgroups.group1.sinks">agent1 agent2</Property>
      <Property name="sinkgroups.group1.processor.type">failover</Property>
      <Property name="sinkgroups.group1.processor.priority.agent1">10</Property>
      <Property name="sinkgroups.group1.processor.priority.agent2">5</Property>
      <RFC5424Layout enterpriseNumber="18060" includeMDC="true" appName="MyApp"/>
    </Flume>
    <Console name="STDOUT">
      <PatternLayout pattern="%d [%p] %c %m%n"/>
    </Console>
  </Appenders>
  <Loggers>
    <Logger name="EventLogger" level="info">
      <AppenderRef ref="eventLogger"/>
    </Logger>
    <Root level="warn">
      <AppenderRef ref="STDOUT"/>
    </Root>
  </Loggers>
</Configuration>

上述的三種配置Channel都是基於記憶體的模式，這是為了保證傳輸速度，當然現在固態硬碟的速度已經很快了，用檔案的模式也是可以的，而我在使用的時候，由於偷懶，只使用了記憶體的通道。

​​​​​​​