輕量級日誌收集技術方案

1.     傳統架構

1.1. Rsync方式

說明：

在生產環境上部署rsync傳輸腳本並設置定時，按天或按小時將日誌傳輸到日誌收集服務器

 

1） 優勢

• 對生產服務器和日誌收集服務器形成的壓力較小

• 數據較精確，且能夠比較方便的重複運行

2） 缺點

• 不能實時或者方便的獲得想要的統計數據

• 不方便實施分佈式

• 須要對每種日誌正價同步腳本和設置定時，維護起來比較麻煩

• Flume方式

說明：

         Flume是一個分佈式、可靠、和高可用的海量日誌聚合的系統，支持在系統中定製各種數據發送方。

         採用了分層架構：分別爲agent，collector和storage。其中，agent和collector均由兩部分組成：source和sink，source是數據來源，sink是數據去向。

Flume使用兩個組件：Master和Node，Node根據在Master shell或web中動態配置，決定其是做爲Agent仍是Collector。

 

1） 優勢

• Agent和Collector，Collector和Store之間有容錯機制，且提供了三種級別的可靠性保證

• 方便分佈式部署

• 直接支持HDFS

2） 缺點

• 日誌收集先後處理不夠靈活，不方便處理成各週期的彙總日誌

• 部署比較重量級，適合於T級別數據量的處理

 

2.     新輕量級架構

2.1. 消息隊列方式

說明：

         實線表示日誌數據，虛線表示心跳和告警數據。

在生產服務器上增長agent數據監控服務，在日誌收集服務器上部署beanstalkd隊列服務，agent負責把生產服務器產生的日誌實時寫入到隊列中去。

         在日誌收集服務器上部署Collector數據代理服務，負責將隊列中的數據取出進行處理彙總。

         Master和Collector能夠部署在同一臺服務器。

1） 優勢

• 可以實時獲得數據

• 使用php開發，日誌收集先後處理靈活，能夠根據須要編寫php腳本進行個性化處理

• 統一使用master進行配置管理，很是方便進行部署，監控和維護

• 核心的agent，collector服務能夠對其中的處理彙總進行分拆，易於分佈式部署

2） 缺點

• 對系統的穩定性要求較高，若是agent異常退出，可能會丟失日誌

• 對collector的性能要求較高，直接影響到日誌收集服務器的負載

2.2. 將來方案

1）  引入實時流計算框架storm，更好地對大數據進行實時分析處理；

2）  直接傳輸至HDFS，進行離線大數據計算，主要對一些日期久遠的日誌及不須要實時計算的日誌進行統計分析。