本文從設計架構，負載均衡，可擴展性和容錯性等方面對比了當今開源的日誌系統，包括facebook的scribe，apache的chukwa，linkedin的kafka和cloudera的flume等。node
2. FaceBook的Scribelinux
Scribe是facebook開源的日誌收集系統，在facebook內部已經獲得大量的應用。它可以從各類日誌源上收集日誌，存儲到一箇中央存 儲系統 （能夠是NFS，分佈式文件系統等）上，以便於進行集中統計分析處理。它爲日誌的「分佈式收集，統一處理」提供了一個可擴展的，高容錯的方案。git
它最重要的特色是容錯性好。當後端的存儲系統crash時，scribe會將數據寫到本地磁盤上，當存儲系統恢復正常後，scribe將日誌從新加載到存儲系統中。github
架構：web
scribe的架構比較簡單，主要包括三部分，分別爲scribe agent， scribe和存儲系統。shell
(1) scribe agent數據庫
scribe agent其實是一個thrift client。 向scribe發送數據的惟一方法是使用thrift client， scribe內部定義了一個thrift接口，用戶使用該接口將數據發送給server。apache
(2) scribe後端
scribe接收到thrift client發送過來的數據，根據配置文件，將不一樣topic的數據發送給不一樣的對象。scribe提供了各類各樣的store，如 file， HDFS等，scribe可將數據加載到這些store中。服務器
(3) 存儲系統
存儲系統實際上就是scribe中的store，當前scribe支持很是多的store，包括file（文件），buffer（雙層存儲，一個主 儲存， 一個副存儲），network（另外一個scribe服務器），bucket（包含多個 store，經過hash的將數據存到不一樣store中），null(忽略數據)，thriftfile（寫到一個Thrift TFileTransport文件中）和multi（把數據同時存放到不一樣store中）。
3. Apache的Chukwa
chukwa是一個很是新的開源項目，因爲其屬於hadoop系列產品，於是使用了不少hadoop的組件（用HDFS存儲，用mapreduce處理數據），它提供了不少模塊以支持hadoop集羣日誌分析。
需求：
(1) 靈活的，動態可控的數據源
(2) 高性能，高可擴展的存儲系統
(3) 合適的框架，用於對收集到的大規模數據進行分析
架構：
Chukwa中主要有3種角色，分別爲：adaptor，agent，collector。
(1) Adaptor 數據源
可封裝其餘數據源，如file，unix命令行工具等
目前可用的數據源有：hadoop logs，應用程序度量數據，系統參數數據（如linux cpu使用流率）。
(2) HDFS 存儲系統
Chukwa採用了HDFS做爲存儲系統。HDFS的設計初衷是支持大文件存儲和小併發高速寫的應用場景，而日誌系統的特色剛好相反，它需支持高並 發低速 率的寫和大量小文件的存儲。須要注意的是，直接寫到HDFS上的小文件是不可見的，直到關閉文件，另外，HDFS不支持文件從新打開。
(3) Collector和Agent
爲了克服(2)中的問題，增長了agent和collector階段。
Agent的做用：給adaptor提供各類服務，包括：啓動和關閉adaptor，將數據經過HTTP傳遞給Collector；按期記錄adaptor狀態，以便crash後恢復。
Collector的做用：對多個數據源發過來的數據進行合併，而後加載到HDFS中；隱藏HDFS實現的細節，如，HDFS版本更換後，只需修改collector便可。
(4) Demux和achieving
直接支持利用MapReduce處理數據。它內置了兩個mapreduce做業，分別用於獲取data和將data轉化爲結構化的log。存儲到data store（能夠是數據庫或者HDFS等）中。
4. LinkedIn的Kafka
Kafka是2010年12月份開源的項目，採用scala語言編寫，使用了多種效率優化機制，總體架構比較新穎（push/pull），更適合異構集羣。
設計目標：
(1) 數據在磁盤上的存取代價爲O(1)
(2) 高吞吐率，在普通的服務器上每秒也能處理幾十萬條消息
(3) 分佈式架構，可以對消息分區
(4) 支持將數據並行的加載到hadoop
架構：
Kafka其實是一個消息發佈訂閱系統。producer向某個topic發佈消息，而consumer訂閱某個topic的消息，進而一旦有新 的關於 某個topic的消息，broker會傳遞給訂閱它的全部consumer。 在kafka中，消息是按topic組織的，而每一個topic又會分爲多個partition，這樣便於管理數據和進行負載均衡。同時，它也使用了 zookeeper進行負載均衡。
Kafka中主要有三種角色，分別爲producer，broker和consumer。
(1) Producer
Producer的任務是向broker發送數據。Kafka提供了兩種producer接口，一種是low_level接口，使用該接口會向特定 的 broker的某個topic下的某個partition發送數據；另外一種那個是high level接口，該接口支持同步/異步發送數據，基於zookeeper的broker自動識別和負載均衡（基於Partitioner）。
其中，基於zookeeper的broker自動識別值得一說。producer能夠經過zookeeper獲取可用的broker列表，也能夠在zookeeper中註冊listener，該listener在如下狀況下會被喚醒：
a．添加一個broker
b．刪除一個broker
c．註冊新的topic
d．broker註冊已存在的topic
當producer得知以上時間時，可根據須要採起必定的行動。
(2) Broker
Broker採起了多種策略提升數據處理效率，包括sendfile和zero copy等技術。
(3) Consumer
consumer的做用是將日誌信息加載到中央存儲系統上。kafka提供了兩種consumer接口，一種是low level的，它維護到某一個broker的鏈接，而且這個鏈接是無狀態的，即，每次從broker上pull數據時，都要告訴broker數據的偏移 量。另外一種是high-level 接口，它隱藏了broker的細節，容許consumer從broker上push數據而沒必要關心網絡拓撲結構。更重要的是，對於大部分日誌系統而 言，consumer已經獲取的數據信息都由broker保存，而在kafka中，由consumer本身維護所取數據信息。
5. Cloudera的Flume
Flume是cloudera於2009年7月開源的日誌系統。它內置的各類組件很是齊全，用戶幾乎沒必要進行任何額外開發便可使用。
設計目標：
(1) 可靠性
當節點出現故障時，日誌可以被傳送到其餘節點上而不會丟失。Flume提供了三種級別的可靠性保障，從強到弱依次分別爲：end-to-end（收 到數據 agent首先將event寫到磁盤上，當數據傳送成功後，再刪除；若是數據發送失敗，能夠從新發送。），Store on failure（這也是scribe採用的策略，當數據接收方crash時，將數據寫到本地，待恢復後，繼續發送），Best effort（數據發送到接收方後，不會進行確認）。
(2) 可擴展性
Flume採用了三層架構，分別問agent，collector和storage，每一層都可以水平擴展。其中，全部agent和 collector由 master統一管理，這使得系統容易監控和維護，且master容許有多個（使用ZooKeeper進行管理和負載均衡），這就避免了單點故障問題。
(3) 可管理性
全部agent和colletor由master統一管理，這使得系統便於維護。用戶能夠在master上查看各個數據源或者數據流執行狀況，且能夠對各 個數據源配置和動態加載。Flume提供了web 和shell script command兩種形式對數據流進行管理。
(4) 功能可擴展性
用戶能夠根據須要添加本身的agent，colletor或者storage。此外，Flume自帶了不少組件，包括各類agent（file， syslog等），collector和storage（file，HDFS等）。
架構：
正如前面提到的，Flume採用了分層架構，由三層組成，分別爲agent，collector和storage。其中，agent和collector均由兩部分組成：source和sink，source是數據來源，sink是數據去向。
(1) agent
agent的做用是將數據源的數據發送給collector，Flume自帶了不少直接可用的數據源（source），如：
text(「filename」)：將文件filename做爲數據源，按行發送
tail(「filename」)：探測filename新產生的數據，按行發送出去
fsyslogTcp(5140)：監聽TCP的5140端口，而且接收到的數據發送出去
同時提供了不少sink，如：
console[("format")] ：直接將將數據顯示在桌面上
text(「txtfile」)：將數據寫到文件txtfile中
dfs(「dfsfile」)：將數據寫到HDFS上的dfsfile文件中
syslogTcp(「host」,port)：將數據經過TCP傳遞給host節點
(2) collector
collector的做用是將多個agent的數據彙總後，加載到storage中。它的source和sink與agent相似。
下面例子中，agent監聽TCP的5140端口接收到的數據，併發送給collector，由collector將數據加載到HDFS上。
|
1
2
|
host : syslogTcp(5140) | agentSink("localhost",35853) ;
collector : collectorSource(35853) | collectorSink("hdfs://namenode/user/flume/ ","syslog");
|
一個更復雜的例子以下：有6個agent，3個collector，全部collector均將數據導入HDFS中。agent A，B將數據發送給collector A，agent C，D將數據發送給collectorB，agent C，D將數據發送給collectorB。同時，爲每一個agent添加end-to-end可靠性保障（Flume的三種可靠性保障分別由 agentE2EChain, agentDFOChain, and agentBEChain實現），如，當collector A出現故障時，agent A和agent B會將數據分別發給collector B和collector C。
下面是簡寫的配置文件片斷：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
agentA : src | agentE2EChain("collectorA:35853","collectorB:35853");
agentB : src | agentE2EChain("collectorA:35853","collectorC:35853");
agentC : src | agentE2EChain("collectorB:35853","collectorA:35853");
agentD : src | agentE2EChain("collectorB:35853","collectorC:35853");
agentE : src | agentE2EChain("collectorC:35853","collectorA:35853");
agentF : src | agentE2EChain("collectorC:35853","collectorB:35853");
collectorA : collectorSource(35853) | collectorSink("hdfs://...","src");
collectorB : collectorSource(35853) | collectorSink("hdfs://...","src");
collectorC : collectorSource(35853) | collectorSink("hdfs://...","src");
|
此外，使用autoE2EChain，當某個collector 出現故障時，Flume會自動探測一個可用collector，並將數據定向到這個新的可用collector上。
(3) storage
storage是存儲系統，能夠是一個普通file，也能夠是HDFS，HIVE，HBase等。
6. 總結
根據這四個系統的架構設計，能夠總結出典型的日誌系統需具有三個基本組件，分別爲agent（封裝數據源，將數據源中的數據發送給 collector），collector（接收多個agent的數據，並進行彙總後導入後端的store中），store（中央存儲系統，應該具備可擴 展性和可靠性，應該支持當前很是流行的HDFS）。
下面表格對比了這四個系統：
7. 參考資料
scribe主頁：https://github.com/facebook/scribe
chukwa主頁：http://incubator.apache.org/chukwa/
kafka主頁：http://sna-projects.com/kafka/
Flume主頁：https://github.com/cloudera/flume/
本文來自：http://my.oschina.net/sunzy/blog/183795