目錄
寫在最前：爲什麼做日誌收集系統❓
首先，什麼是日誌？日誌就是程序產生的，遵循一定格式（通常包含時間戳）的文本數據。
通常日誌由服務器生成，輸出到不同的文件中，一般會有系統日誌、應用日誌、安全日誌。這些日誌分散地存儲在不同的機器上。
當系統發生故障時，工程師就需要登錄到各個服務器上，使用 grep / sed / awk 等 Linux 腳本工具去日誌裏查找故障原因。在沒有日誌系統的情況下，首先需要定位處理請求的服務器，如果這臺服務器部署了多個實例，則需要去每個應用實例的日誌目錄下去找日誌文件。每個應用實例還會設置日誌滾動策略（如：每天生成一個文件或日誌文件達到某給定大小後生成一個文件），還有日誌壓縮歸檔策略等。
這樣一系列流程下來，對於我們排查故障以及及時找到故障原因，造成了比較大的麻煩。因此，如果我們能把這些日誌集中管理，並提供集中檢索功能，不僅可以提供高診斷效率，同時對系統情況有個全面的理解，避免事後救火的被動。
個人認爲，日誌數據在以下幾個方面具有非常重要的作用：
- 數據查找：通過檢索日誌信息，定位相應的 bug，找出解決方案；
- 服務診斷：通過對日誌信息進行統計、分析，瞭解服務器的負荷和服務運行狀態；
- 數據分析：可以做進一步的數據分析。
一、多種日誌收集工具比較
1、背景介紹
許多公司的平臺每天會產生大量的日誌（一般爲流式數據，如搜索引擎 pv、uv，查詢等），處理這些日誌需要特定的日至系統，一般而言，這些系統需要具備以下特徵：
- 構建應用系統和分析系統的橋樑，並將它們之間的關聯解耦合；
- 支持近時時的在線分析系統和類似於 Hadoop 之類的離線分析系統；
- 具有高可擴展性。即：當數據量增加時，可以通過增加節點進行水平擴展。
👇下面將從設計架構、負載均衡、可擴展性和容錯性等方面對比當今開源的日誌系統，包括 Facebook 的 scribe，Apache 的 chukwa，LinkedIn 的 kafka 和 Cloudera 的 flume 等。
2、Facebook 的 Scribe
scribe 主頁：https://github.com/facebook/scribe
scribe 是 Facebook 開源的日誌收集系統，在 Facebook 內部已經得到大量的應用。它能夠從各種日誌源上收集日誌，存儲到一箇中央存儲系統（可以是 NFS，分佈式文件系統等）上，以便於進行集中統計分析處理。它爲日誌的“分佈式收集，統一處理”提供了一個可擴展的、高容錯的方案。
它最重要的特點是容錯性好。當後端的存儲系統 crash 時，scribe 會將數據寫到本地磁盤上，當存儲系統恢復正常後，scribe 將日誌重新加載到存儲系統中。
架構：
scribe 的架構比較簡單，主要包括三部分，分別爲 scribe agent，scribe 和存儲系統。
（1）scribe agent
scribe agent 實際上是一個 thrift client。向 scribe 發送數據的唯一方法是使用 thrift client，scribe 內部定義了一個 thrift 接口，用戶使用該接口將數據發送給 server。
（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 主頁：http://incubator.apache.org/chukwa/
chukwa 是一個非常新的開源項目，由於其屬於 hadoop 系列產品，因而使用了很多 hadoop 的組件（用 HDFS 存儲，用 MapReduce 處理數據），它提供了很多模塊以支持 hadoop 集羣日誌分析。
需求：
- 靈活性，動態可控的數據源
- 高性能，高可擴展的存儲系統
- 合適的架構，用於對收集到的大規模數據進行分析
架構：
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 主頁：http://kafka.apache.org
kafka 是 2010 年 12 月份開源的項目，採用 Scala 語言編寫，使用了多種效率優先機制，整體架構比較新穎（push / pull），更適合異構集羣。
設計目標：
- 數據在磁盤上存取代價爲 0（1）
- 高吞吐率，在普通的服務器上每秒也能處理幾十萬條消息
- 分佈式架構，能夠對消息分區
- 支持將數據並行的加載到 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 在以下情況下會被喚醒：
- 添加一個 broker
- 刪除一個 broker
- 註冊新的 topic
- broker 註冊已存在的 topic
當 producer 得知以上事件時，可以根據需要採取一定行動。
（2）broker
broker 採取多種策略提高數據處理效率，包括 sendfile 和 zero copy 等技術。
（3）consumer
consumer 的作用是將日誌信息加載到中央存儲系統上。kafka 提供了兩種 consumer 接口，一種是 low_level 接口，它維護到某一個 broker 連接，並且這個連接是無狀態的，即，每次從 broker 上 push 數據時，都要告訴 broker 數據的偏移量。另一種是 high_level 接口，它隱藏了 broker的細節，運行 consumer 從 broker 上 push 數據而不必關係網絡拓撲結構。更重要的是，對於大部分日誌系統而言，consumer 已經獲取的數據信息都由 broker 保存，而 kafka 中，由 consumer 自己維護所取數據信息。
5、Cloudera 的 Flume OG
flume-og 主頁：https://github.com/cloudera/flume/
Flume OG 是 Cloudera 於 2009 年 7 月開源的日誌系統。它內置的各種組件非常齊全，用戶幾乎不必進行任何額外的開發即可使用。
設計目標：
（1）可靠性
當節點出現故障時，日誌能夠被傳送到其它節點上而不會丟失。flume-og 提供了三種級別的可靠性保障，從強到弱依次分別爲：end-to-end（收到數據 agent 首先將 event 寫到磁盤上，當數據傳送成功後，再刪除；如果數據發送失敗，可以重新發送），store-on-failure（這也是 scribe 採用的策略，當數據接收方 crash 時，將數據寫到本地，待恢復後，繼續發送），best-effort（數據發送到接收方後，不會進行確認）。
（2）可擴展性
flume-og 採用三層架構，分別爲 agent，collector 和 storage，每一層均可以水平擴展。其中，所有 agent 和 collector 由 master 統一管理，這使得系統容易監控和維護，且 master 允許有多個（使用 zookeeper 進行管理和負載均衡），這就避免了單點故障問題。
（3）可管理性
所有 agent 和 collector 由 master 統一管理，這使得系統便於維護。用戶可以在 master 上查看各個數據源或者數據流執行情況，且可以對各個數據源配置和動態加載。flume-og 提供了 web 和 shell script command 兩種形式對數據流進行管理。
（4）功能可擴展性
用戶可以更具需要添加自己的 agent，collector 或者 storage。此外，flume 自帶了很多組件，包括各種 agent（file，syslog 等），collector 和 storage（file，HDFS 等）。
Flume OG 架構：
FLUM OG 有三種角色的節點：代理節點（agent）、收集節點（collector）、主節點（master）。
- agent 從各個數據源收集日誌數據，將收集到的數據集中到 collector，然後由收集節點彙總存入 hdfs。master 負責管理 agent，collector 的活動。
- agent、collector 都稱爲 node，node 的角色根據配置的不同分爲 logical node（邏輯節點）、physical node（物理節點）。對 logical nodes 和 physical nodes 的區分、配置、使用一直以來都是使用者最頭疼的地方。
- agent、collector 由 source、sink 組成，代表在當前節點數據是從 source 傳送到 sink。
正如上面提到的，flume-og 採用了分層架構，由三層組成，分別爲 agent，collector 和 storage。其中，agent 和 collector 均由兩部分組成：source 和 sink，source 是數據來源，sink 是數據去向。
（1）agent
agent 的作用是將數據源的數據發送給 collector，flume-og 自帶了很多直接可用的數據源（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 類似。
（3）storage
storage 是存儲系統，可以是一個普通 file，也可以是 HDFS，HIVE，HBASE 等。
6、“星星”小結
根據這四個系統的架構設計，可以總結出典型的日至系統需具備三個基本組件，分別爲 agent（封裝數據源，將數據源中的數據發送給 collector），collector（接收多個 agent 的數據，並進行彙總後導入後端的 store 中），store（中央存儲系統，應該具有可擴展性和可靠性，應該支持當前非常流行的 HDFS）。
下面👇對比了這四個系統：
7、衆星捧月之 Apache 的 Flume NG
- flume-ng 官網地址：http://flume.apache.org
- 用戶文檔：http://flume.apache.org/FlumeUserGuide.html
- 開發文檔： http://flume.apache.org/FlumeDeveloperGuide.html
NG 只有一種角色的節點：代理節點（agent）：
- 沒有 collector、master 節點。這是核心組件最核心的變化。
- 去除了 physical nodes、logical nodes 的概念和相關內容。
- agent 節點的組成也發生了變化。NG agent 由 source、sink、channel 組成。
Flume NG 架構：
Flume NG 特性：
Flume NG 是一個分佈式、可靠、高可用的海量日誌聚合系統，支持在系統中定製各類數據發送方，用於收集數據；同時，Flume NG 提供對數據進行簡單處理，並寫到各種數據接收方。
（1）高可靠性：Flume NG 提供了end to end的數據可靠性機制；
（2）易於擴展：Agent 爲分佈式架構，可水平擴展；
（3）易於恢復：Channel 中保存了與數據源有關的事件，用於失敗時的恢復；
（4）功能豐富：Flume NG 內置了多種組件，包括不同數據源和不同存儲方式；
Flume NG 節點組成圖：
Flume NG 常用組件
（1）Source：數據源，簡單的說就是 agent 獲取數據的入口；
（2）Channel：管道，數據流通和存儲的通道。一個 source 必須至少和一個 channel 關聯；
（3）Sink：用來接收 channel 傳輸的數據並將之傳送到指定的地方，成功後從 channel 中刪除；
從整體上講，NG 在覈心組件上進行了大規模的調整，核心組件的數目由 7 刪減到 4。由於 Flume 的使用涉及到衆多因素，如 avro、thrift、hdfs、jdbc、zookeeper 等，而這些組件和 Flume 的整合都需要關聯到所有組件。所以核心組件的改革對整個 Flume 的使用影響深遠：
- 大大降低了對用戶的要求，如核心組件的變化使得 Flume 的穩定使用不再依賴 zookeeper，用戶無需去搭建 zookeeper 集羣；另外用戶也不再糾結於 OG 中的模糊概念（尤其是 physical nodes、logical nodes，agent、collector）。
- 有利於 Flume 和其他技術、hadoop 周邊組件的整合，比如在 NG 版本中，Flume 輕鬆實現了和 jdbc、hbase 的集成。
- 將 OG 版本中複雜、大規模、不穩定的標籤移除，Flume 實現了向靈活、輕便的轉變，而且在功能上更加強大、可擴展性更高，這一點主要表現在用戶使用 Flume 搭建日誌收集集羣的過程中，後面的章節會詳細介紹。
刪減節點角色，脫離 zookeeper
- Zookeeper 是針對大型分佈式系統的可靠協調系統，適用於有多類角色集羣管理。比如在 hbase 中，對 HMaster、HRegionServer 的管理。
- 在 OG 版本中，Flume 的使用穩定性依賴 zookeeper。它需要 zookeeper 對其多類節點（agent、collector、master）的工作進行管理，尤其是在集羣中配置多個 master 的情況下。當然，OG 也可以用內存的方式管理各類節點的配置信息，但是需要用戶能夠忍受在機器出現故障時配置信息出現丟失。所以說 OG 的穩定行使用是依賴 zookeeper 的。
- 而在 NG 版本中，節點角色的數量由 3 縮減到 1，不存在多類角色的問題，所以就不再需要 zookeeper 對各類節點協調的作用了，由此脫離了對 zookeeper 的依賴。由於 OG 的穩定使用對 zookeeper 的依賴表現在整個配置和使用過程中，這就要求用戶掌握對 zookeeper 集羣的搭建極其使用（尤其是要熟悉 zookeeper 數據文件夾 data，Flume 節點配置信息存放在此文件夾中）；掌握 Flume 中和 zookeeper 相關的配置。對初次接觸 Flume 的用戶來講，這是非常痛苦的事。
用戶配置變化之安裝
OG 在安裝時：
- 在 flume-env.sh 中設置$JAVA_HOME。
- 需要配置文件 flume-conf.xml。其中最主要的、必須的配置與 master 有關。集羣中的每個 Flume 都需要配置 master 相關屬性（如 flume.master.servers、flume.master.store、flume.master.serverid）。
- 如果想穩定使用 Flume 集羣，還需要安裝 zookeeper 集羣，這需要用戶對 zookeeper 有較深入的瞭解。
- 安裝 zookeeper 之後，需要配置 flume-conf.xml 中的相關屬性，如 flume.master.zk.use.external、flume.master.zk.servers。
- 在使用 OG 版本傳輸數據之前，需要啓動 master、agent。
NG 在安裝時，只需要在 flume-env.sh 中設置$JAVA_HOME。
用戶配置變化之數據傳輸配置
OG 版本的配置途徑有兩個：
- shell 命令：需要用戶掌握 Flume shell 命令；
- master console 頁面：這是 OG 用戶最常用的配置方式；弊端在於，除非用戶熟悉複雜的各類 source，sink 配置函數以及格式（source：大約 25 個，sink：大約 46 個），否則在複雜的集羣環境下，用戶每次只能配置一個節點（指定 source、sink）來保證配置的準確性；
NG 的配置只需要一個配置文件，這個配置文件中存放 source、sink、channel 的配置。然後在啓動 agent 時，使用一下命令指定這個配置文件。
結束語
- 從核心組件和用戶的角度，Flume NG 給 Flume 帶來的第一次革命。從核心組件來講，NG 簡化核心組件，移除了 OG 版本代碼工程臃腫、核心組件設計不合理、核心配置不標準等缺點；
- 另外 NG 脫離了 Flume 穩定性對 zookeeper 的依賴。從用戶角度來講，NG 版本對用戶要求大大降低：
- 安裝過程除了 java 無需配置複雜的 Flume 相關屬性，也無需搭建 zookeeper 集羣，安裝過程幾乎零工作量；
- 數據流的配置過程更加簡單、合理，只需要實現 source、sink、channel 的簡單配置即可。