項目背景

公司項目需要將分布在多臺機器中的日志統(tǒng)一收集管理。筆者先后使用logstash，flume等開源項目。并最終自研一套基于Java語言的日志收集系統(tǒng) Bloodhound。以下從項目關(guān)注的角度對開源系統(tǒng)與自研進行分析。

1 開源日志收集系統(tǒng)特征

Logstash 和 Flume 都是很成熟的日志收集平臺，結(jié)構(gòu)清晰，插件豐富，文檔簡明易懂，示例代碼非常多。其中Logstash 側(cè)重對字段的預(yù)處理，F(xiàn)lume 側(cè)重不同的網(wǎng)絡(luò)拓撲中日志的傳遞，通過Agent打通各個網(wǎng)絡(luò)結(jié)點。

2 關(guān)于日志收集系統(tǒng)的考量

 開發(fā)語言的選擇

公司的開發(fā)團隊主要集中在 Java，Python。而 Logstash 的插件使用 Ruby，從團隊角度，不太具備擴展性。在使用 logstash 增加一個插件比較痛苦，同時幾個月使用下來，感覺性能偏低，啟動時較慢。

性能的考慮

Flume性能相對比較低，主要有以下幾點：

① 單線程。

Flume 每個 Agent 分為 source,channel,sink 等插件。每個插件都只啟用單線程處理。如果任務(wù)是寫數(shù)據(jù)庫等 IO 操作，性能必然會被拖累。

②source的Timer機制

Source 線程在檢測有新的更新，會一直讀取推向 Channel，當所有的更新處理完畢，線程會退出。啟動一個 Timer 線程。定期3秒重新啟動，如此反復(fù)。在這個過程中，沒有充分利用 Java 的多線程通知機制，每次啟動都有一些調(diào)度，排隊，檢測及任務(wù)初始化過程。影響性能。

③Flume事務(wù)機制

Flume 本身已對事各進行了優(yōu)化，允許批量提交事件。但本質(zhì)上還是需要檢測Sink的處理結(jié)果，再進行 Commit 或 Roolback。

管理的考慮

如果將一個 agent 的任務(wù)處理串，source->channel->sink 理解為一個任務(wù)(這個任務(wù)是個抽象的概念，F(xiàn)lume 里并沒有這個概念)，那么 Flume 從業(yè)務(wù)腳度上看，就是單任務(wù)收集系統(tǒng)。如果需要同時處理兩個任務(wù)，必須開啟兩個 Flume Agent 進程。隨著收集任務(wù)的增加，必然會大大增加管理成本。

(flume處理：多進程處理多任務(wù))

(Bloodhound處理：單進程處理多任務(wù))

此外，我們還有監(jiān)控需求，統(tǒng)計需求，任務(wù)管理等。這些任務(wù)需要和我們的 grafana 平臺打通。綜合考慮下，我們選擇自研日志收集系統(tǒng)。

BloodHound系統(tǒng)

項目名稱來源

From wikipedia:

The Bloodhound is a large scent hound, originally bred for hunting deer, wild boar, and since the Middle Ages for tracking people. Believed to be descended from hounds once kept at the Abbey of Saint-Hubert, Belgium, it is known to French speakers as the Chien de Saint-Hubert.

This breed is famed for its ability to discern human scent over great distances, even days later. Its extraordinarily keen sense of smell is combined with a strong and tenacious tracking instinct, producing the ideal scent hound, and it is used by police and law enforcement all over the world to track escaped prisoners, missing people, lost children and lost pets.

“嗅覺最靈敏的獵犬，寓意是能從包括流量在內(nèi)的各種粗糙的原始數(shù)據(jù)中提煉中初步有價值的信息�！�

項目需求

多任務(wù)管理系統(tǒng)

強擴展性

任務(wù)監(jiān)控

高性能

項目架構(gòu)

系統(tǒng)分層

核心框架層

為了充分利用Flume的功能特性，我們也將Bloodhound拆分層source->channel->sink三個層次。這個設(shè)計是為了充分利用Flume中的豐富插件資源，請參照以下配置文件。

時序圖

source 層

source為數(shù)據(jù)輸入，通常為文件，消息系統(tǒng)等。示例中的Source為Redis，Source為單獨運行的線程，從Redis中指定的隊列中獲取輸入，讀取完成后則推向 Channel。當 Channel 中隊列已滿時，則 source 線程則進入等待。

 Channel 層

Channel 作為樞鈕,連接 Source 和 Channel，主要功能如下：

維護一個隊列，接受 source 的 put，向 Sink 發(fā)送處理。

管理一個線程池，調(diào)度 Sink 任務(wù)。由于 Sink 通常較慢，因此整個核心模塊中，只有 Sink 為多線程處理，其余均為單線程執(zhí)行。

控制QPS，可以使用令牌或漏斗，主要目的是保護高并發(fā)寫入的環(huán)境下，Sink 對應(yīng)的數(shù)據(jù)庫或 Redis。不至于壓力過大，影響正常業(yè)務(wù)請求。

發(fā)送 Metrics，提供實時監(jiān)控數(shù)據(jù)來源。

Channel 層主要的方法有：popEvents, addEvents, notifyEvents, sendMetrics等。

Sink 層

Sink 層為一個 Runnable，接受 Events，被 Channel 調(diào)度，執(zhí)行最終的落地邏輯。

以上三層中，Channel 層有 MemoryChannel 和 FileChannel，如果任務(wù)比較重要，應(yīng)該選擇 FileChannel，可以保證進程中斷后，Event 不會被丟失。MemoryChannel 管理一個 Queue，性能相對比較高。Source 和 Sink 可以大量復(fù)用Flume中的插件代碼。

任務(wù)管理器

任務(wù)管理器，故名思義是管理整個日志收集系統(tǒng)的管理模塊。

1 任務(wù)管理

任務(wù)注冊接口：可通過任務(wù)注冊接口向整個進程提交一個任務(wù)，如配置所示，任務(wù)注冊接口是通過一個 http post 方法提供注冊并啟動一個新的任務(wù)。

數(shù)據(jù)提交接口：默認情況下，Source 是 pull 模式，從文件中，隊列中拉取日志。同時也支持 http 方式提交。數(shù)據(jù)提交接口需要傳遞兩個參數(shù)，jobName 和 events 。

2 任務(wù)監(jiān)控

查看任務(wù)執(zhí)行情況：在grafana中查看各個任務(wù)執(zhí)行情況，這個數(shù)據(jù)由核心框架層提供。

查看任務(wù)運行情況：提供列表，查看任務(wù)狀態(tài)，啟動，停止任務(wù)。

系統(tǒng)運維層

進程管理：使用supervisor管理進程。

調(diào)度器：根據(jù)各個業(yè)務(wù)情況，使用調(diào)度任務(wù)對任務(wù)進行管理。調(diào)用任務(wù)管理中的任務(wù)啟動，停止等。這一塊和日志收集核心不太相關(guān)，就不再贅述。

結(jié)語

筆者從事過多個項目需要使用日志收集，同時也使用了 logstash, flume 等開源系統(tǒng)，總體感覺開源系統(tǒng)比較成熟，有大量插件，事務(wù)管理。但和自已業(yè)務(wù)系統(tǒng)結(jié)合不夠緊密。自研框架工作量較大，也會有很多坑，優(yōu)勢是較好的和業(yè)務(wù)接軌。

來自：http://www.freebuf.com/sectool/168471.html

 

標簽： 代碼 數(shù)據(jù)庫 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。