Flume日誌採集應用架構升級與重構

轉眼新的一年又快要來了，趁着這段時間總結下這一年的工做經驗，避免重複踩坑。MOB數據採集平臺升級也快經歷了半年時間，目前重構後線上運行穩定，在這過程當中挖過坑，填過坑，爲後續業務的實時計算需求打下了很好的基礎。

1、升級與重構的緣由

上圖爲舊有架構，主要服務於Hadoop2.x離線計算(T+1)以及Spark的實時計算（T+0），但在數據採集、數據流動、做業調度以及平臺監控等幾個環節存在的一些問題和不足。

• 數據採集：

  • 數據採集平臺與數據統計分析系統分離，不能統一管理數據流向，而且消耗服務資源
  • 數據收集接口衆多，數據格式雜亂：基本每一個業務都有本身的上報接口，存在較大的重複開發成本，不能彙總上報，消耗客戶端資源，以及網絡流量，每一個接口收集數據項和格式不統一，加大後期數據統計分析難度。
  • Flume採集單一channel的使用，可能致使高峯期隊列堵塞，數據丟失的問題

• 平臺監控：

  • 只有系統層面的監控，數據平臺方面的監控等於空白

針對以上問題，結合在大數據中，數據的時效性越高，數據越有價值的理念，所以，開始大重構數據採集平臺架構。

2、升級後的架構設計

這張圖是升級後的數據採集架構圖，從圖中能夠了解到大數據採集過程以及數據走向：數據源，數據緩存，存儲計算等環節。
將原來數據採集與數據計算架構進行聚合解耦，節省了服務資源，增強了數據採集的數據流的監管，對文件傳輸及數據完整性監控都有所補充，有利於後期離線或實時運算的可插拔接入。

• Flume channel升級
  

數據傳輸上，將Flume Memory channel改成Kafka channel，能夠緩存數據的同時，彌補日誌高峯期，原來Memory channel隊列不夠的問題，減小重啓Flume帶來的數據丟失問題

3、監控

- 文件傳輸監控

Flume: 定製的zabbix監控，在flume裏添加了zabbix監控模塊

Kafka: 經過監控kafka consumer消費狀態，當Lag達到必定值時，進行告警

• 數據完整監控
  好比源數據與目標數據之差，相差超過1%,告警針對告警信息，採起數據補償措施

4、參數優化

• 根據業務場景作節點參數調優

  • 調大FlumeServer MemoryChannel的capacity，儘可能利用MemoryChannel快速的處理能力；
  • 調大HdfsSink的batchSize，增長吞吐量，減小hdfs的flush次數；
  • 適當調大HdfsSink的callTimeout，避免沒必要要的超時錯誤（固然Hdfs也要作配合）
  • 接收消息參數調優
• 內存調優
  修改conf/flume-env.sh文件

5、結語

一個健壯強大的分佈式日誌採集系統無疑是整個大數據業務的重要樞紐，在實踐中的一些關鍵的設計和思想，但願能拋磚引玉，在將來之路越走越好。