基於Flume的美團日誌收集系統(一)架構和設計

美團的日誌收集系統負責美團的所有業務日誌的收集，並分別給Hadoop平臺提供離線數據和Storm平臺提供實時數據流。美團的日誌收集系統基於Flume設計和搭建而成。

《基於Flume的美團日誌收集系統》將分兩部分給讀者呈現美團日誌收集系統的架構設計和實戰經驗。

第一部分架構和設計，將主要著眼於日誌收集系統整體的架構設計，以及為什麼要做這樣的設計。

第二部分改進和優化，將主要著眼於實際部署和使用過程中遇到的問題，對Flume做的功能修改和優化等。

1 日誌收集系統簡介

日誌收集是大數據的基石。

許多公司的業務平臺每天都會產生大量的日誌數據。收集業務日誌數據，供離線和線上的分析系統使用，正是日誌收集系統的要做的事情。高可用性，高可靠性和可擴展性是日誌收集系統所具有的基本特征。

目前常用的開源日誌收集系統有Flume, Scribe等。Flume是Cloudera提供的一個高可用的，高可靠的，分散式的海量日誌採集、聚合和傳輸的系統，目前已經是Apache的一個子項目。Scribe是Facebook開源的日誌收集系統，它為日誌的分散式收集，統一處理提供一個可擴展的，高容錯的簡單方案。

2 常用的開源日誌收集系統對比

下麵將對常見的開源日誌收集系統Flume和Scribe的各方面進行對比。對比中Flume將主要採用Apache下的Flume-NG為參考對象。同時，我們將常用的日誌收集系統分為三層（Agent層，Collector層和Store層）來進行對比。

3 美團日誌收集系統架構

美團的日誌收集系統負責美團的所有業務日誌的收集，並分別給Hadoop平臺提供離線數據和Storm平臺提供實時數據流。美團的日誌收集系統基於Flume設計和搭建而成。目前每天收集和處理約T級別的日誌數據。

下圖是美團的日誌收集系統的整體框架圖。

a. 整個系統分為三層：Agent層，Collector層和Store層。其中Agent層每個機器部署一個進程，負責對單機的日誌收集工作；Collector層部署在中心伺服器上，負責接收Agent層發送的日誌，並且將日誌根據路由規則寫到相應的Store層中；Store層負責提供永久或者臨時的日誌存儲服務，或者將日誌流導向其它伺服器。

b. Agent到Collector使用LoadBalance策略，將所有的日誌均衡地發到所有的Collector上，達到負載均衡的目標，同時並處理單個Collector失效的問題。

c. Collector層的目標主要有三個：SinkHdfs, SinkKafka和SinkBypass。分別提供離線的數據到Hdfs，和提供實時的日誌流到Kafka和Bypass。其中SinkHdfs又根據日誌量的大小分為SinkHdfs_b，SinkHdfs_m和SinkHdfs_s三個Sink，以提高寫入到Hdfs的性能，具體見後面介紹。

d. 對於Store來說，Hdfs負責永久地存儲所有日誌；Kafka存儲最新的7天日誌，並給Storm系統提供實時日誌流；Bypass負責給其它伺服器和應用提供實時日誌流。

下圖是美團的日誌收集系統的模塊分解圖，詳解Agent, Collector和Bypass中的Source, Channel和Sink的關係。

a. 模塊命名規則：所有的Source以src開頭，所有的Channel以ch開頭，所有的Sink以sink開頭；

b. Channel統一使用美團開發的DualChannel，具體原因後面詳述；對於過濾掉的日誌使用NullChannel，具體原因後面詳述；

c. 模塊之間內部通信統一使用Avro介面；

4 架構設計考慮

下麵將從可用性，可靠性，可擴展性和相容性等方面，對上述的架構做細緻的解析。

4.1 可用性(availablity)

對日誌收集系統來說，可用性(availablity)指固定周期內系統無故障運行總時間。要想提高系統的可用性，就需要消除系統的單點，提高系統的冗餘度。下麵來看看美團的日誌收集系統在可用性方面的考慮。

4.1.1 Agent死掉

Agent死掉分為兩種情況：機器死機或者Agent進程死掉。

對於機器死機的情況來說，由於產生日誌的進程也同樣會死掉，所以不會再產生新的日誌，不存在不提供服務的情況。

對於Agent進程死掉的情況來說，確實會降低系統的可用性。對此，我們有下麵三種方式來提高系統的可用性。首先，所有的Agent在supervise的方式下啟動，如果進程死掉會被系統立即重啟，以提供服務。其次，對所有的Agent進行存活監控，發現Agent死掉立即報警。最後，對於非常重要的日誌，建議應用直接將日誌寫磁碟，Agent使用spooldir的方式獲得最新的日誌。

4.1.2 Collector死掉

由於中心伺服器提供的是對等的且無差別的服務，且Agent訪問Collector做了LoadBalance和重試機制。所以當某個Collector無法提供服務時，Agent的重試策略會將數據發送到其它可用的Collector上面。所以整個服務不受影響。

4.1.3 Hdfs正常停機

我們在Collector的HdfsSink中提供了開關選項，可以控制Collector停止寫Hdfs，並且將所有的events緩存到FileChannel的功能。

4.1.4 Hdfs異常停機或不可訪問

假如Hdfs異常停機或不可訪問，此時Collector無法寫Hdfs。由於我們使用DualChannel，Collector可以將所收到的events緩存到FileChannel，保存在磁碟上，繼續提供服務。當Hdfs恢復服務以後，再將FileChannel中緩存的events再發送到Hdfs上。這種機制類似於Scribe，可以提供較好的容錯性。

4.1.5 Collector變慢或者Agent/Collector網路變慢

如果Collector處理速度變慢（比如機器load過高）或者Agent/Collector之間的網路變慢，可能導致Agent發送到Collector的速度變慢。同樣的，對於此種情況，我們在Agent端使用DualChannel，Agent可以將收到的events緩存到FileChannel，保存在磁碟上，繼續提供服務。當Collector恢復服務以後，再將FileChannel中緩存的events再發送給Collector。

4.1.6 Hdfs變慢

當Hadoop上的任務較多且有大量的讀寫操作時，Hdfs的讀寫數據往往變的很慢。由於每天，每周都有高峰使用期，所以這種情況非常普遍。

對於Hdfs變慢的問題，我們同樣使用DualChannel來解決。當Hdfs寫入較快時，所有的events只經過MemChannel傳遞數據，減少磁碟IO，獲得較高性能。當Hdfs寫入較慢時，所有的events只經過FileChannel傳遞數據，有一個較大的數據緩存空間。

4.2 可靠性(reliability)

對日誌收集系統來說，可靠性(reliability)是指Flume在數據流的傳輸過程中，保證events的可靠傳遞。

對Flume來說，所有的events都被保存在Agent的Channel中，然後被髮送到數據流中的下一個Agent或者最終的存儲服務中。那麼一個Agent的Channel中的events什麼時候被刪除呢？當且僅當它們被保存到下一個Agent的Channel中或者被保存到最終的存儲服務中。這就是Flume提供數據流中點到點的可靠性保證的最基本的單跳消息傳遞語義。

那麼Flume是如何做到上述最基本的消息傳遞語義呢？

首先，Agent間的事務交換。Flume使用事務的辦法來保證event的可靠傳遞。Source和Sink分別被封裝在事務中，這些事務由保存event的存儲提供或者由Channel提供。這就保證了event在數據流的點對點傳輸中是可靠的。在多級數據流中，如下圖，上一級的Sink和下一級的Source都被包含在事務中，保證數據可靠地從一個Channel到另一個Channel轉移。

其次，數據流中 Channel的持久性。Flume中MemoryChannel是可能丟失數據的（當Agent死掉時），而FileChannel是持久性的，提供類似mysql的日誌機制，保證數據不丟失。

4.3 可擴展性(scalability)

對日誌收集系統來說，可擴展性(scalability)是指系統能夠線性擴展。當日誌量增大時，系統能夠以簡單的增加機器來達到線性擴容的目的。

對於基於Flume的日誌收集系統來說，需要在設計的每一層，都可以做到線性擴展地提供服務。下麵將對每一層的可擴展性做相應的說明。

4.3.1 Agent層

對於Agent這一層來說，每個機器部署一個Agent，可以水平擴展，不受限制。一個方面，Agent收集日誌的能力受限於機器的性能，正常情況下一個Agent可以為單機提供足夠服務。另一方面，如果機器比較多，可能受限於後端Collector提供的服務，但Agent到Collector是有Load Balance機制，使得Collector可以線性擴展提高能力。

4.3.2 Collector層

對於Collector這一層，Agent到Collector是有Load Balance機制，並且Collector提供無差別服務，所以可以線性擴展。其性能主要受限於Store層提供的能力。

4.3.3 Store層

對於Store這一層來說，Hdfs和Kafka都是分散式系統，可以做到線性擴展。Bypass屬於臨時的應用，只對應於某一類日誌，性能不是瓶頸。

4.4 Channel的選擇

Flume1.4.0中，其官方提供常用的MemoryChannel和FileChannel供大家選擇。其優劣如下：

• MemoryChannel: 所有的events被保存在記憶體中。優點是高吞吐。缺點是容量有限並且Agent死掉時會丟失記憶體中的數據。

• FileChannel: 所有的events被保存在文件中。優點是容量較大且死掉時數據可恢復。缺點是速度較慢。

上述兩種Channel，優缺點相反，分別有自己適合的場景。然而，對於大部分應用來說，我們希望Channel可以同提供高吞吐和大緩存。基於此，我們開發了DualChannel。

• DualChannel：基於 MemoryChannel和 FileChannel開發。當堆積在Channel中的events數小於閾值時，所有的events被保存在MemoryChannel中，Sink從MemoryChannel中讀取數據； 當堆積在Channel中的events數大於閾值時， 所有的events被自動存放在FileChannel中，Sink從FileChannel中讀取數據。這樣當系統正常運行時，我們可以使用MemoryChannel的高吞吐特性；當系統有異常時，我們可以利用FileChannel的大緩存的特性。

4.5 和scribe相容

在設計之初，我們就要求每類日誌都有一個category相對應，並且Flume的Agent提供AvroSource和ScribeSource兩種服務。這將保持和之前的Scribe相對應，減少業務的更改成本。

4.6 許可權控制

在目前的日誌收集系統中，我們只使用最簡單的許可權控制。只有設定的category才可以進入到存儲系統。所以目前的許可權控制就是category過濾。

如果許可權控制放在Agent端，優勢是可以較好地控制垃圾數據在系統中流轉。但劣勢是配置修改麻煩，每增加一個日誌就需要重啟或者重載Agent的配置。

如果許可權控制放在Collector端，優勢是方便進行配置的修改和載入。劣勢是部分沒有註冊的數據可能在Agent/Collector之間傳輸。

考慮到Agent/Collector之間的日誌傳輸並非系統瓶頸，且目前日誌收集屬內部系統，安全問題屬於次要問題，所以選擇採用Collector端控制。

4.7 提供實時流

美團的部分業務，如實時推薦，反爬蟲服務等服務，需要處理實時的數據流。因此我們希望Flume能夠導出一份實時流給Kafka/Storm系統。

一個非常重要的要求是實時數據流不應該受到其它Sink的速度影響，保證實時數據流的速度。這一點，我們是通過Collector中設置不同的Channel進行隔離，並且DualChannel的大容量保證了日誌的處理不受Sink的影響。

5 系統監控

對於一個大型複雜系統來說，監控是必不可少的部分。設計合理的監控，可以對異常情況及時發現，只要有一部手機，就可以知道系統是否正常運作。對於美團的日誌收集系統，我們建立了多維度的監控，防止未知的異常發生。

5.1 發送速度，擁堵情況，寫Hdfs速度

通過發送給zabbix的數據，我們可以繪製出發送數量、擁堵情況和寫Hdfs速度的圖表，對於超預期的擁堵，我們會報警出來查找原因。

下麵是Flume Collector HdfsSink寫數據到Hdfs的速度截圖：

下麵是Flume Collector的FileChannel中擁堵的events數據量截圖：

5.2 flume寫hfds狀態的監控

Flume寫入Hdfs會先生成tmp文件，對於特別重要的日誌，我們會每15分鐘左右檢查一下各個Collector是否都產生了tmp文件，對於沒有正常產生tmp文件的Collector和日誌我們需要檢查是否有異常。這樣可以及時發現Flume和日誌的異常.

5.3 日誌大小異常監控

對於重要的日誌，我們會每個小時都監控日誌大小周同比是否有較大波動，並給予提醒，這個報警有效的發現了異常的日誌，且多次發現了應用方日誌發送的異常，及時給予了對方反饋，幫助他們及早修複自身系統的異常。

通過上述的講解，我們可以看到，基於Flume的美團日誌收集系統已經是具備高可用性，高可靠性，可擴展等特性的分散式服務。