一起來解讀分佈式日誌收集系統:Facebook Scribe

1.分佈式日誌收集系統:背景介紹

許多公司的平臺每天會產生大量的日誌(一般爲流式數據,如,搜索引擎的pv,查詢等),處理這些日誌需要特定的日誌系統,一般而言,這些系統需要具有以下特徵:

(1) 構建應用系統和分析系統的橋樑,並將它們之間的關聯解耦;

(2) 支持近實時的在線分析系統和類似於Hadoop之類的離線分析系統;

(3) 具有高可擴展性。即:當數據量增加時,可以通過增加節點進行水平擴展。

需要c/c++ Linux服務器高階知識視頻資料的朋友可以點擊鏈接加入羣聊【linux後臺服務架構交流】

知識點有C/C++,Linux,golang技術,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒體,CDN,P2P,K8S,Docker,TCP/IP,協程,DPDK等等。

分佈式日誌收集系統:Facebook Scribe

 

分佈式日誌收集系統:Facebook Scribe

 

2.分佈式日誌收集系統:Facebook Scribe主要內容

(1)Scribe簡介及系統架構

(2)Scribe技術架構

(3)Scribe部署結構

(4)Scribe主要功能和使用方案

(5)Scribe的具體應用實例

(6)Scribe的擴展

(7)Scribe研究體會

 

3.Scribe簡介

Scribe是facebook開源的日誌收集系統,在facebook內部已經得到大量的應用。 Scribe是基於一個使用非阻斷C++服務器的thrift服務的實現。它能夠從各種日誌源上收集日誌,存儲到一箇中央存儲系統 (可以是NFS,分佈式文件系統等)上,以便於進行集中統計分析處理。它爲日誌的“分佈式收集,統一處理”提供了一個可擴展的,高容錯的方案。

 

4.Scribe的系統架構

分佈式日誌收集系統:Facebook Scribe

 

如上圖所示:Scribe從各種數據源上收集數據,放到一個共享隊列上,然後push到後端的中央存儲系統上。當中央存儲系統出現故障時,scribe可以暫時把日誌寫到本地文件中,待中央存儲系統恢復性能後,scribe把本地日誌續傳到中央存儲系統上。

 

5.Scribe的技術架構

分佈式日誌收集系統:Facebook Scribe

 

如上圖所示:Scribe服務器底層數據通信框架是Thrift,Thrift也是Facebook開源的,並得到了廣泛的使用。也用到了C++的準標準庫boost,主要使用共享指針和文件相關的功能。Thrift也用到了libevent開發庫和socket編程技術。

 

6.Scribe部署結構

分佈式日誌收集系統:Facebook Scribe

 

7.Scribe的主要功能

1.支持多種存儲類型:7種並且可擴展

2.日誌自動切分功能:按文件大小和時間切分

3.靈活的客戶端:

(1)支持多種常用語言(Thrift提供支持);

(2)可與應用系統集成;可以作實現獨立客戶端

4.支持日誌分類功能(Facebook有上百種日誌分類)

5.其他功能

(1)連接池

(2)靈活的日誌緩存大小

(3)多線程功能(消息隊列)

(4)scribe服務器之間可以轉發日誌

6.以上功能都是可以通過配置文件來靈活配置

 

8.Scribe使用方案

(1)和產生日誌文件的應用系統集成

scribe能夠和各種應用系統很好的集成是因爲它提供幾乎所有的開發語言的開發包

(2)應用系統在本地產生日誌文件,使用一個獨立運行的客戶端程序同樣,獨立的客戶端也可以採用各種語言開發,我們採用的是python來開發客戶端

 

9.Scribe的具體應用實例

1.Facebook肯定大量的使用,主要用於處理Facebook級別日誌,一旦有新的日誌分類生成,Scribe將自動處理。(Facebook有上百個日誌分類)。

2. Twitter:一款分佈式實時統計系統Rainbird使用了scribe

3.我的公司:

(1)*****

(2)*****

(3)*****

(4)*****

(5)*****

(6)*****

4.其他

 

10.Scribe的擴展:存在的問題

雖然scribe系統是如此的優秀,但是也存在着一些不足和問題,針對存在的問題我們對scribe進行擴展。我們發現scribe存在的主要問題如下:

1、單點故障問題

有三個地方存在單點故障:

(1)中心服務器

(2)本地服務器

(3)收集日誌的客戶端程序

2、日誌丟失問題

當日志文件發生切分的時候可能導致日誌丟失

3、歷史日誌收集問題

4、scribe服務器掛了沒有及時通知

 

11.Scribe的擴展:問題解決方案

針對上面我們提出的問題,主要提供如下相應的解決方案:

1.中心服務器單點故障

可以部署多箇中心服務器,然後本地服務器通過配置文件可以自動在這些服務器之間進行切換

2.其餘的問題我們都是通過自己寫的python客戶端解決的

python客戶端我們是基於一個開源的項目進行二次開發的,因爲開源的python客戶端功能很簡單,只是跟蹤一個日誌文件並把日誌文件的數據讀取導入到scribe本地服務器

 

12.Scribe的擴展:python客戶端

我們開發的python客戶端主要實現瞭如下功能:

1、解決本地scribe服務器的單點故障

我們可以通過配置多個本地scribe服務器(通過配置文件配置,相當的靈活),python腳本會根據配置的這些服務器自動切換(當一個scribe掛掉之後自動切換,如果掛掉本地scribe服務器重新啓動以後又會自動切換回去。

2、解決日誌丟失的問題

開源的python客戶端是按照固定的時間間隔掃描日誌文件是否有變化,如果在這個時間段內發生日誌切換會導致日誌丟失。我們同樣是採用這個方式去檢測日誌文件,不過我們在發生日誌切分的時候會再次去檢測被切分走的日誌文件是否已經收集完畢。

3、解決歷史日誌收集

如果在我們運行python客戶端以前已經產生了日誌,這部分的日誌收集也是我們新增的一個功能

4、解決自身的單點故障問題

不排除我們的python客戶端也會掛掉的時候,當我們下次啓動怎樣保證我們收集的日誌不重複不丟失是需要解決的問題。我們的解決方案就是對已經收集的日誌文件的各種信息做序列化(主要是已經收集日誌文件的位置)

5、收集日誌文件怎樣保證按照日誌生成的順序收集

日誌的生成順序就是跟他們文件的建立時間是相關的,通過這一點我們可以實現。

6、及時通知機制

爲了及時的通知到scrib服務器掛掉的信息到相關人員,我們開發了郵件通知機制,就是當某一個本地scribe服務器掛掉以後會觸發郵件發送

 

13.Scribe研究體會

怎樣從我們工作的內容深入學習?

1.每個人在公司負責開發的內容都是很有限的,怎樣從我們開發的內容入手深入研究和學習更多的知識?

2.Scribe研究的例子!

分佈式日誌收集系統:Facebook Scribe

 

14.總結:以上內容有一些是來自互聯網,在加入了自己的一些理解,希望對需要的人有所幫助!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章