針對原生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 |
| memory-channel |
1800 |
| file-channel |
1400 |
2.2. 支持單實例多目錄多topic采集方式
目前支持單topic的日志采集，待支持類似向上多topic多目錄的並行采集，配置初步設計如下：
| agent.sources.s1.topicGroups = t1 t2 agent.sources.s1.topicGroups.t2.topic = topic2 |
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 |
readByBlock |
| 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. 支持配置中心的統一程序包分發與部署