分布式日誌收集系統： Facebook Scribe之日誌收集方案

 

我的獨立部落格網址是：http://wuyouqiang.sinaapp.com/。

我的新浪微博：http://weibo.com/freshairbrucewoo。

歡迎大家相互交流，共同提高技術。

寫入日誌到Scribe的解決方案

1.概述

Scribe日誌收集伺服器只負責收集主動寫入它的日誌，它本身不會去主動抓取某一個日誌，所以為了把日誌寫入到scribe伺服器，我們必須主動向scribe伺服器發送日誌資訊。由於scribe伺服器是基於thrift架構實現的，並且thrift支援多種程式設計語言的通訊，所以對於寫入scribe伺服器的用戶端實現也可以使用多種語言，這就為把寫入日誌的用戶端整合到各種應用系統中提供了很好的支援。把寫入日誌到scribe伺服器的功能整合到應用系統是一種可行的解決方案，但是不是唯一的解決方案，我們還可以現實一個單獨的用戶端，專門用來抓取應用系統產生的記錄檔，然後寫入到scribe伺服器。下面就針對這兩種方案具體說明。

2.scribe日誌寫入與應用系統整合

（1）與java應用系統整合

與java系統整合有兩種解決方案，一是通過scribe提供的開發API自己開發，另一種是通過與log4j整合（網上有開源的實現）。

對應用系統的影響：因為這種方式是作為應用系統的一個功能模組加入，所以需要加入額外的jar和需要額外的佔用應用系統開銷，除了這些還需要考慮scribe伺服器不能正常連結時的異常處理。

（2）與C#應用系統整合

與C#系統整合是通過把scribe提供的開發API封裝到一個dll檔案裡面，然後C#應用系統匯入dll檔案，利用提供的API開發寫入scribe日誌的功能模組。

對應用系統的影響：需要匯入dll檔案，增加應用系統的額外執行開銷，存在連結scribe伺服器的異常處理。

（3）與其他應用系統整合

由於thrift架構支援多做語言，而且scribe是基於thrift實現的，所以只要thrift支援的開發語言都可以與相應的應用系統整合開發。

3.單獨的抓取記錄檔的用戶端

寫一個單獨的用戶端是一種適用於任何應用系統的解決方案，前提是應用系統需要產生相應的記錄檔。這個單獨的用戶端可以用thrift支援的任何一種語言實現，不過通常採用python實現，方便修改、擴充和部署。

這種解決方案實現的方式有兩種：一是迴圈的去檢測記錄檔或檔案夾，如果有新的日誌產生就讀取記錄檔並上傳到scribe伺服器；二是通過事件響應的機制來監控檔案或檔案夾。

4.兩種解決方案的比較

首先可以肯定的是兩種解決方案都能夠達到向scribe寫入日誌的目的。

兩者的區別就是：

（1）與應用系統整合的方案寫入日誌的效率更高，因為不需要在通過一個轉寄的環節，通過應用系統直接寫入，而且這種方案降低了出錯的可能性，不需要單獨去維護一個程式了。但是這種解決方案會對應用系統有一定的影響，前面以前描述具體的影響，還有就是不具有通用性，每一個應用系統需要單獨開發一個這樣的功能模組（開發的思路和方法基本相同）。

（2）單獨的抓取記錄檔用戶端：具有很好的通用性，不需要每一個應用系統單獨開發日誌寫入模組，只需要應用系統組建記錄檔檔案。而且這種方案對應用系統沒有影響。當然這種解決方案的效率會低一些，因為需要通過一個檔案來中轉日誌資訊，還會因為單獨的程式也可能會掛掉。

5.兩種方案都需要解決的問題

（1）單點故障問題

（2）日誌丟失問題