實時統一日誌採集Flume平臺化

      針對原生Flume在生產環境中暴露的問題，在開源Flume1.6.0版本上作了深度定製和部門內部統一推廣：

  1.  與開源版本區別

模塊	Flume1.6	Flumex-Agent
功能	1.低侵入性: 會對業務方日誌文件重命名	1.無侵入性
	2.休眠輪詢: 佔用線程&&限制採集文件的並行度	2.輕量級：基於Linux的inotify機制採集
	3.數據不完整性：基於file的full-name採集	3.數據完整性：基於inode的日誌採集
	4.不支持目錄遞歸	4.支持目錄遞歸
性能(單文件吞吐)	2M/s: 按行或byte採集，效率低	10M/s: 根據採集進度按byte或block動態採集
運營	1.狀態被動收集：自身基於server端服務的定向請求	1.狀態主動推送：基於client端的狀態心跳推送
	2.無採集元數據備份	2.採集日誌元數據備份： 能夠記錄和查詢歷史任一時間段內採集的文件列表、 文件數及採集文件的size、offset信息

2. 功能擴展

   2.1. 支持file-channel可靠性採集模式

      目前因爲file-channel採集性能瓶頸， 因此採用memory-channel模式，二者採集能力對好比下：但memory-channel是會在服務異常中斷或宕機場景時存在着日誌丟失的風險。產品線上計劃數據可靠性優先，因此會採用file-channel模式，其次對採集效率進行優化。

channel方式	readByByte (events/s)
memory-channel	1800
file-channel	1400

   2.2. 支持單實例多目錄多topic採集方式

        目前支持單topic的日誌採集，待支持相似向上多topic多目錄的並行採集，配置初步設計以下：

agent.sources.s1.topicGroups = t1 t2 agent.sources.s1.topicGroups.t1.topic = topic1 agent.sources.s1.topicGroups.t1.files = /home/logs/14505/^stat\.log*,/home/logs/stat/^monitor.log$ agent.sources.s1.topicGroups.t2.topic = topic2 agent.sources.s1.topicGroups.t2.files = /home/14505-1/^stat\.log$

   2.3 支持採集消息的定製字段追加，如host、appid等

       因爲上游agent採集的業務應用方較多，爲了方便下游離線或實時地對消息進行分類統計分析，對採集消息的內容，agent具備進行有約束的制定字段增長功能。 增長的定製字段有：a既定的變量, 如appid、t、host。

        a. 配置樣例以下：

            %{appid}%{t}%{host}%{data}

        b. 相應消息樣例以下：

            appid= test- product` t=1479089921875`host=localhost`deviceId=VSMjTvvy9CgDAE`messageId=`action=register_dt`logTime=1477911600905`msgCount=1`

3. 性能改善

   3.1. 目的

      a.  採用可靠性file-channel採集模式,保證採集數據的穩定性、日誌可靠性(不丟失)；

      b.  提高file-channel採集模式日誌採集效率，提高5倍。 目前測試單日誌文件memory模式採集能力1800行/S；

      c. 支持異步memory-channel性能採集模式，提高20倍採集效率。

   3.2. 目前現狀

       採集的方式與flume原生的tail-log採集方式相似，按Byte逐行讀取的採集模式； 當 file-offset ≈ file-size時，即日誌文件的消費速率與其內容的生產效率至關時，這樣能夠保證log採集的實時性； 實測其性能  1500Events/s。

   3.3. 存在問題 
      但其存在性能瓶頸：假設機械磁盤的一次順序讀時間0.01ms，每行消息內容100個Bytes，則其IOPS性能上限：100000個Bytes/s = 1000Events/s; 因此當file-offset << file-size時,特別是在採集業務高峯時nginx運營日誌情景時，會出現日誌文件的消費速率會遠小於其內容的生產效率，致使採集消息嚴重滯後。

   3.4. 修改策略
         採用實時動態調整採集方式的策略：
         a. 當file-offset ≈ file-size時，採用readByByte採集模式；
         b. 當file-offset << file-size時，採用readByBlock採集模式，提升採集吞吐量。
   3.5. 優化後結果對比

channel方式	readByByte (events/s)	readByBlock (events/s)
memory-channel	1800	20000
file-channel	1400	15000

    3.6.  支持同步/異步兩種採集模式

        另外，採集每批消息耗時主要由三部分組成: read-log(1ms) + write-channel(1ms) + write-metaDB(4ms)。爲了保證數據可靠性：每一批讀取日誌數據後的遊標元信息會sync同步到sqlite中，其耗時佔比達60%，因此每批消息的大頭在write-metaDB操做上。

        爲了支持不一樣的業務場景需求，服務支持」性能模式」，支持write-metaDB的異步寫模式，同時會在異常關機狀況時的數據丟失。下面是兩種採集模式的採集效率對比：                                   

採集模式	採集效率	吞吐能力
可靠模式(同步)	15000行/s	1.5M/s
性能模式(異步)	100000行/s	10M/s

  3.7. 消息大小與採集能力關係圖

      線上服務已「可靠性」優先，因此會採用可靠模式。下面實驗可靠模式下：不一樣消息字節大小與服務採集能力的關係圖： 

4. 產品服務化

 4.1. 監控模塊

      支持source輸入與sink輸出兩維度信息的狀態內容彙報，採集agent週期性地彙報採集狀態給dashboard服務中心, 上傳字段內容以Json格式上報。心跳週期：1min；傳輸協議：http-post。上報字段說明以下：

       a. 彙報狀態字段說明

字段	說明
host	採集點的機器名或ip名
appId	採集日誌的業務標示
receivedEventCount	探測接收到的事件數
acceptedEventCount	成功錄入的事件數
receivedBatchCount	探測接收到的事件批次數
acceptedBatchCount	成功錄入的事件批次數
attemptSendEventCount	嘗試下游發送的事件數
successSendEventCount	成功下游發送的事件數
acceptedWindowEventCount	一個時間窗口接收到的事件數
sendWindowEventCount	一個時間窗口發送出的事件數

         b. 彙報狀態字段樣例 

{
     "host":"uaerouter5-vm01",
     "appId":"test-new-product",
     "receivedEventCount":"137136",
     "acceptedEventCount":"137136",
     "receivedBatchCount":"4073",
     "acceptedBatchCount":"4073",
     "attemptSendEventCount":"137136",
     "successSendEventCount":"137136",                
     "acceptedWindowEventCount": "11000",     
     "sendWindowEventCount": "10000「
}

   4.2. 配置與部署

     a. 支持本地配置的參數變化&動態監聽&程序模塊級別重啓 

     b. 支持配置中心的統一程序包分發與部署