聊聊Flume和Logstash的那些事兒

本文適合有必定大數據基礎的讀者朋友們閱讀，但若是你沒有技術基礎，照樣能夠繼續看（這就比如你看《葵花寶典》第一頁：欲練此功，必先自宮，而後翻到第二頁：若不自宮，也可練功，沒錯就是這種感受→_→）。

大數據的數據採集工做是大數據技術中很是重要、基礎的部分，數據不會無緣無故地跑到你的數據平臺軟件中，你得用什麼東西把它從現有的設備（好比服務器，路由器、交換機、防火牆、數據庫等）採集過來，再傳輸到你的平臺中，而後纔會有後面更加複雜高難度的處理技術。

目前，Flume和Logstash是比較主流的數據採集工具（主要用於日誌採集），可是不少人還不太明白二者的區別，特別是對用戶來講，具體場景使用合適的採集工具，能夠大大提升效率和可靠性，並下降資源成本。

---

嗑瓜子羣衆：喂喂，上面全都是沒用的廢話，說好的故事呢=。=

咳咳，好吧，如今咱們開始講正事。首先咱們給出一個通用的數據採集模型，主要是讓不太懂計算機或者通訊的讀者們瞭解一下。

 

普適環境的數據採集

其中，數據採集和存儲是必要的環節，其餘並不必定須要。是否是很簡單？原本編程其實就是模塊化的東西，沒有那麼難。可是這畢竟只是一個粗略的通用模型，不一樣開源社區或者商業廠家開發的時候都會有本身的考慮和目的。咱們在本文要討論的Flume和Logstash原則上都屬於數據採集這個範疇，儘管二者在技術上或多或少都自帶了一些緩衝、過濾等等功能。

---

好，咱們先來看Logstash，而後看Flume，等你所有看完你就知道我爲何這麼安排了。

Logstash是ELK組件中的一個。所謂ELK就是指，ElasticSearch、Logstash、Kibana這三個組件。那麼爲何這三個組件要合在一塊兒說呢？第一，這三個組件每每是配合使用的（ES負責數據的存儲和索引，Logstash負責數據採集和過濾轉換，Kibana則負責圖形界面處理）；第二，這三個組件又前後被收購於Elastic.co公司名下。是否是很巧合？這裏說個題外話，原ELK Stack在5.0版本加入Beats（一種代理）套件後改稱爲Elastic Stack，這兩個詞是一個意思，只不過由於增長了Beats代理工具，改了個名字。

Logstash誕生於2009年8有2日，其做者是世界著名的虛擬主機託管商DreamHost的運維工程師喬丹 西塞（Jordan Sissel）。Logstash的開發很早，對比一下，Scribed誕生於2008年，Flume誕生於2010年，Graylog2誕生於2010年，Fluentd誕生於2011年。2013年，Logstash被ElasticSearch公司收購。這裏順便提一句，Logstash是喬丹的做品，因此帶着獨特的我的性格，這一點不像Facebook的Scribe，Apache的Flume開源基金項目。

你說的沒錯，以上都是廢話。（手動滑稽→_→）

Logstash的設計很是規範，有三個組件，其分工以下：

一、Shipper 負責日誌收集。職責是監控本地日誌文件的變化，並輸出到 Redis 緩存起來；二、Broker 能夠看做是日誌集線器，能夠鏈接多個 Shipper 和多個 Indexer；三、Indexer 負責日誌存儲。在這個架構中會從 Redis 接收日誌，寫入到本地文件。

這裏要說明，由於架構比較靈活，若是不想用 Logstash 的存儲，也能夠對接到 Elasticsearch，這也就是前面所說的 ELK 的套路了。

 

Flume結構圖

若是繼續細分，Logstash也能夠這麼解剖來看

 

Logstash三個工做階段

貌似到這裏。。。好像就講完了。。。讀者朋友們不要罵我，由於Logstash就是這麼簡約，所有將代碼集成，程序員不須要關內心面是如何運轉的。

Logstash最值得一提的是，在Filter plugin部分具備比較完備的功能，好比grok，能經過正則解析和結構化任何文本，Grok 目前是Logstash最好的方式對非結構化日誌數據解析成結構化和可查詢化。此外，Logstash還能夠重命名、刪除、替換和修改事件字段，固然也包括徹底丟棄事件，如debug事件。還有不少的複雜功能供程序員本身選擇，你會發現這些功能Flume是絕對沒有（以它的輕量級線程也是不可能作到的）。固然，在input和output兩個插件部分也具備很是多相似的可選擇性功能，程序員能夠自由選擇，這一點跟Flume是比較類似的。

大大的分割線，讀者朋友們能夠去上個廁所，而後再買一包瓜子了。

---

Logstash由於集成化設計，因此理解起來其實不難。如今咱們講講Flume，這塊內容就有點多了。

最先Flume是由Cloudrea開發的日誌收集系統，初始的發行版本叫作Flume OG（就是original generation的意思），做爲開源工具，一經公佈，實際上是很受關注的一套工具，可是後面隨着功能的拓展，暴露出代碼工程臃腫、核心組件設計不合理、核心配置不標準等各類缺點。尤爲是在Flume OG的最後一個發行版本0.94.0中，日誌傳輸不穩定的現象特別嚴重。咱們來看看Flume OG到底有什麼問題。

 

Flume OG架構圖

直到如今，你在網絡上搜索Flume相關資料的時候還會常常出現Flume OG的結構圖，這對新人來講是很不友好的，很容易引發誤導，請讀者朋友們必定要注意！咱們能夠看到Flume OG有三種角色的節點：代理節點（agent）、收集節點（collector）、主節點（master）。

流程理解起來也並不困難：agent 從各個數據源收集日誌數據，將收集到的數據集中到 collector，而後由收集節點彙總存入 hdfs。master 負責管理 agent，collector 的活動。agent、collector 都稱爲 node，node 的角色根據配置的不一樣分爲 logical node（邏輯節點）、physical node（物理節點）。對logical nodes和physical nodes的區分、配置、使用一直以來都是使用者最頭疼的地方。

 

Flume OG中節點的構成

agent、collector 由 source、sink 組成，表明在當前節點數據是從 source 傳送到 sink。

就算是外行人，看到這裏也以爲很頭大，這尼瑪是誰設計出來的破玩意？

各類問題的暴露，迫使開發者痛下決心，拋棄原有的設計理念，完全重寫Flume。因而在2011 年 10 月 22 號，Cloudera 完成了 Flume-728，對 Flume 進行了里程碑式的改動：重構核心組件、核心配置以及代碼架構，重構後的版本統稱爲 Flume NG（next generation下一代的意思）；改動的另外一緣由是將 Flume 歸入 apache 旗下，Cloudera Flume 更名爲 Apache Flume，因此如今Flume已是Apache ETL工具集中的一員。

這裏說個題外話，你們都知道，一般狀況下大公司，特別是大型IT公司是比較排斥使用一些不穩定的新技術的，也不喜歡頻繁變換技術，這很簡單，由於變化很容易致使意外。舉個例子，Linux發展了二十多年了，大部分公司都在使用RedHat、CentOS和Ubuntu這類旨在提供穩定、兼容好的版本，若是你看到一家公司用的是Linux新內核，那多半是一家新公司，須要用一些新技術在競爭中處於上風。

好，瞭解了一些歷史背景，如今咱們能夠放上Flume NG的結構圖了

 

Flume NG結構圖

臥槽，是否是很簡單？！對比一下OG的結構，外行人都會驚歎：so easy！

此次開發者吸收了OG的血淋林教訓，將最核心的幾塊部分作了改動：

一、NG 只有一種角色的節點：代理節點（agent），而不是像OG那麼多角色；

二、沒有collector，master節點。這是核心組件最核心的變化；

三、去除了physical nodes、logical nodes的概念和相關內容；

四、agent 節點的組成也發生了變化，NG agent由source、sink、channel組成。

那麼這麼作有什麼好處呢？簡單歸納有這麼三點：

一、NG 簡化核心組件，移除了 OG 版本代碼工程臃腫、核心組件設計不合理、核心配置不標準等缺點，使得數據流的配置變得更簡單合理，這是比較直觀的一個改進點；

二、NG 脫離了 Flume 穩定性對 zookeeper 的依賴。在早期的OG版本中，Flume 的使用穩定性依賴 zookeeper。它須要 zookeeper 對其多類節點（agent、collector、master）的工做進行管理，尤爲是在集羣中配置多個 master 的狀況下。固然，OG 也能夠用內存的方式管理各種節點的配置信息，可是須要用戶可以忍受在機器出現故障時配置信息出現丟失。因此說 OG 的穩定行使用是依賴 zookeeper 的。

三、NG 版本對用戶要求大大下降：安裝過程除了java無需配置複雜的Flume相關屬性，也無需搭建zookeeper集羣，安裝過程幾乎零工做量。

有人很不解，怎麼忽然冒出來一個Zookeeper這個概念，這是個啥玩意？簡單的說，Zookeeper 是針對大型分佈式系統的可靠協調系統，適用於有多類角色集羣管理。你能夠把它理解爲整個Hadoop的總管家，負責整個系統全部組件之間的協調工做管理。這個組件平時很不起眼，但很是重要。比如一支籃球隊，五個隊員個個都是巨星，因此咱們平時都習慣關注這五我的，可是整個球隊的獲勝缺不了教練的協調組織、戰術安排，Zookeeper就比如是整個Hadoop系統的教練。比喻雖然有些生硬，只是想說明Zookeeper的重要性，也側面說明NG在擺脫了Zookeeper的依賴後變得更加輕便，靈活。

說個題外話，OG版本的使用文檔有90多頁，而NG只用 20 多頁的內容就完成了新版 Flume 的使用說明。可見在科學研究領域，人類老是在追求真理，而真理老是能夠用最簡單的語言描述出來。

到這裏差很少Flume就講的差很少了，由於這個線程工具從原理上講真的很簡單，三段式的結構：源（Source輸入）——存儲（Channel管道）——出口（Sink目標輸出）。但也由於涉及到這三個結構，因此作配置就比較複雜，這裏舉個例子，咱們看看Flume在一些場景下是如何搭建佈置的。

 

Flume集羣部署

這裏要糾正幾個不少初學Flume朋友們的誤區。首先，Flume已經能夠支持一個Agent中有多個不一樣類型的channel和sink，咱們能夠選擇把Source的數據複製，分發給不一樣的目的端口，好比：

 

Flume的多重複用

其次，Flume還自帶了分區和攔截器功能，所以不是像不少實驗者認爲的沒有過濾功能（固然我認可Flume的過濾功能比較弱）。

讀者可能會隱約感受到，Flume在集羣中最擅長的事情就是作路由了，由於每個Flume Agent相連就構成了一條鏈路，這也是衆多采集工具中Flume很是出色的亮點。可是也正由於如此，若是有一個Flume Agent出了問題，那麼整個鏈路也會出現問題，因此在集羣中須要設計分層架構等來實現冗餘備份。但這麼一來，配置又會變得很麻煩。

最後一個大大的分隔線

---

把Logstash和Flume都講完了，咱們最後能夠對比總結一下了。

首先從結構對比，咱們會驚人的發現，二者是多麼的類似！Logstash的Shipper、Broker、Indexer分別和Flume的Source、Channel、Sink各自對應！只不過是Logstash集成了，Broker能夠不須要，而Flume須要單獨配置，且缺一不可，但這再一次說明了計算機的設計思想都是通用的！只是實現方式會不一樣而已。

從程序員的角度來講，上文也提到過了，Flume是真的很繁瑣，你須要分別做source、channel、sink的手工配置，並且涉及到複雜的數據採集環境，你可能還要作多個配置，這在上面提過了，反過來講Logstash的配置就很是簡潔清晰，三個部分的屬性都定義好了，程序員本身去選擇就行，就算沒有，也能夠自行開發插件，很是方便。固然了，Flume的插件也不少，但Channel就只有內存和文件這兩種（其實如今不止了，但經常使用的也就兩種）。讀者能夠看得出來，二者其實配置都是很是靈活的，只不過看場景取捨罷了。

其實從做者和歷史背景來看，二者最初的設計目的就不太同樣。Flume自己最初設計的目的是爲了把數據傳入HDFS中（並非爲了採集日誌而設計，這和Logstash有根本的區別），因此理所應當側重於數據的傳輸，程序員要很是清楚整個數據的路由，而且比Logstash還多了一個可靠性策略，上文中的channel就是用於持久化目的，數據除非確認傳輸到下一位置了，不然不會刪除，這一步是經過事務來控制的，這樣的設計使得可靠性很是好。相反，Logstash則明顯側重對數據的預處理，由於日誌的字段須要大量的預處理，爲解析作鋪墊。

回過來看我當初爲何先講Logstash而後講Flume？這裏面有幾個考慮，其一：Logstash其實更有點像通用的模型，因此對新人來講理解起來更簡單，而Flume這樣輕量級的線程，可能有必定的計算機編程基礎理解起來更好；其二：目前大部分的狀況下，Logstash用的更加多，這個數據我本身沒有統計過，可是根據經驗判斷，Logstash能夠和ELK其餘組件配合使用，開發、應用都會簡單不少，技術成熟，使用場景普遍。相反Flume組件就須要和其餘不少工具配合使用，場景的針對性會比較強，更不用提Flume的配置過於繁瑣複雜了。

最後總結下來，咱們能夠這麼理解他們的區別：Logstash就像是買來的臺式機，主板、電源、硬盤，機箱（Logstash）把裏面的東西所有裝好了，你能夠直接用，固然也能夠本身組裝修改；Flume就像提供給你一套完整的主板，電源、硬盤，Flume沒有打包，只是像說明書同樣指導你如何組裝，才能運行的起來。

做者：南宮蓉 連接：https://www.jianshu.com/p/349ed5ee6419 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。