轉自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-NGScribe

使用語言Javac/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級別的日志數據。

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

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的美團日志收集系統已經是具備高可用性，高可靠性，可擴展等特性的分布式服務。