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

轉自：http://www.aboutyun.com/thread-8317-1-1.html

問題導讀：

1.Flume-NG與Scribe對比，Flume-NG的優點在什麼地方？
2.架構設計考慮須要考慮什麼問題？
3.Agent死機該如何解決？
4.Collector死機是否會有影響？
5.Flume-NG可靠性(reliability)方面作了哪些措施？

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

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

第一部分架構和設計，將主要着眼於日誌收集系統總體的架構設計，以及爲何要作這樣的設計。

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

1 日誌收集系統簡介

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

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

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

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

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

[td]

對比項	Flume-NG	Scribe
使用語言	Java	c/c++
容錯性	Agent和Collector間，Collector和Store間都有容錯性，且提供三種級別的可靠性保證；	Agent和Collector間, Collector和Store之間有容錯性；
負載均衡	Agent和Collector間，Collector和Store間有LoadBalance和Failover兩種模式	無
可擴展性	好	好
Agent豐富程度	提供豐富的Agent，包括avro/thrift socket, text, tail等	主要是thrift端口
Store豐富程度	能夠直接寫hdfs, text, console, tcp；寫hdfs時支持對text和sequence的壓縮；	提供buffer, network, file(hdfs, text)等
代碼結構	系統框架好，模塊分明，易於開發	代碼簡單

3 美團日誌收集系統架構

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

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

<ignore_js_op>  

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的關係。

<ignore_js_op>  

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轉移。

<ignore_js_op>  

其次，數據流中 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的速度截圖：

<ignore_js_op>  

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

<ignore_js_op>  

5.2 flume寫hfds狀態的監控

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

5.3 日誌大小異常監控

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

經過上述的講解，咱們能夠看到，基於Flume的美團日誌收集系統已是具有高可用性，高可靠性，可擴展等特性的分佈式服務。

下一篇：
基於Flume的美團日誌收集系統(二)改進和優化