借鑑開源框架自研日誌收集系統

踏浪無痕 豈安科技高級架構師

十餘年數據研發經驗，擅長數據處理領域工做，如爬蟲、搜索引擎、大數據應用高併發等。擔任過架構師，研發經理等崗位。曾主導開發過大型爬蟲，搜索引擎及大數據廣告DMP系統目前負責豈安科技數據平臺開發與搭建。

項目背景

公司項目須要將分佈在多臺機器中的日誌統一收集管理。筆者前後使用logstash，flume等開源項目。並最終自研一套基於Java語言的日誌收集系統 Bloodhound。如下從項目關注的角度對開源系統與自研進行分析。

1開源日誌收集系統特徵

Logstash 和 Flume 都是很成熟的日誌收集平臺，結構清晰，插件豐富，文檔簡明易懂，示例代碼很是多。其中 Logstash 側重對字段的預處理，Flume 側重不一樣的網絡拓撲中日誌的傳遞，經過Agent打通各個網絡結點。

2關於日誌收集系統的考量

開發語言的選擇

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

性能的考慮

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

① 單線程。
Flume 每一個 Agent 分爲 source,channel,sink 等插件。每一個插件都只啓用單線程處理。若是任務是寫數據庫等 IO 操做，性能必然會被拖累。

②source的Timer機制
Source 線程在檢測有新的更新，會一直讀取推向 Channel，當全部的更新處理完畢，線程會退出。啓動一個 Timer 線程。按期3秒從新啓動，如此反覆。在這個過程當中，沒有充分利用 Java 的多線程通知機制，每次啓動都有一些調度，排隊，檢測及任務初始化過程。影響性能。

③Flume事務機制
Flume 自己已對事各進行了優化，容許批量提交事件。但本質上仍是須要檢測Sink的處理結果，再進行 Commit 或 Roolback。

管理的考慮

若是將一個 agent 的任務處理串，source->channel->sink 理解爲一個任務(這個任務是個抽象的概念，Flume 裏並無這個概念)，那麼 Flume 從業務腳度上看，就是單任務收集系統。若是須要同時處理兩個任務，必須開啓兩個 Flume Agent 進程。隨着收集任務的增長，必然會大大增長管理成本。

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

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

此外，咱們還有監控需求，統計需求，任務管理等。這些任務須要和咱們的 grafana 平臺打通。綜合考慮下，咱們選擇自研日誌收集系統。

BloodHound系統

項目名稱來源

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.

嗅覺最靈敏的獵犬，寓意是能從包括流量在內的各類粗糙的原始數據中提煉中初步有價值的信息。

項目需求

• 多任務管理系統
• 強擴展性
• 任務監控
• 高性能

項目架構

系統分層

核心框架層

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

時序圖

source 層

source爲數據輸入，一般爲文件，消息系統等。示例中的Source爲Redis，Source爲單獨運行的線程，從Redis中指定的隊列中獲取輸入，讀取完成後則推向 Channel。當 Channel 中隊列已滿時，則 source 線程則進入等待。

Channel 層

Channel 做爲樞鈕,鏈接 Source 和 Channel，主要功能以下：

• 維護一個隊列，接受 source 的 put，向 Sink 發送處理。
• 管理一個線程池，調度 Sink 任務。因爲 Sink 一般較慢，所以整個核心模塊中，只有 Sink 爲多線程處理，其他均爲單線程執行。
• 控制QPS，可使用令牌或漏斗，主要目的是保護高併發寫入的環境下，Sink 對應的數據庫或 Redis。不至於壓力過大，影響正常業務請求。
• 發送 Metrics，提供實時監控數據來源。

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

Sink 層

Sink 層爲一個 Runnable，接受 Events，被 Channel 調度，執行最終的落地邏輯。
以上三層中，Channel 層有 MemoryChannel 和 FileChannel，若是任務比較重要，應該選擇 FileChannel，能夠保證進程中斷後，Event 不會被丟失。MemoryChannel 管理一個 Queue，性能相對比較高。Source 和 Sink 能夠大量複用Flume中的插件代碼。

任務管理器

任務管理器，故名思義是管理整個日誌收集系統的管理模塊。

1任務管理

任務註冊接口

可經過任務註冊接口向整個進程提交一個任務，如配置所示，任務註冊接口是經過一個 http post 方法提供註冊並啓動一個新的任務。

數據提交接口

默認狀況下，Source 是 pull 模式，從文件中，隊列中拉取日誌。同時也支持 http 方式提交。數據提交接口須要傳遞兩個參數，jobName 和 events 。

2任務監控

查看任務執行狀況

在grafana中查看各個任務執行狀況，這個數據由核心框架層提供。

查看任務運行狀況

提供列表，查看任務狀態，啓動，中止任務。

系統運維層

進程管理

使用supervisor管理進程。

調度器

根據各個業務狀況，使用調度任務對任務進行管理。調用任務管理中的任務啓動，中止等。這一塊和日誌收集核心不太相關，就再也不贅述。

結語

筆者從事過多個項目須要使用日誌收集，同時也使用了 logstash, flume 等開源系統，整體感受開源系統比較成熟，有大量插件，事務管理。但和自已業務系統結合不夠緊密。自研框架工做量較大，也會有不少坑，優點是較好的和業務接軌。