2017年12月11日

Fluentd, Logstash, LogHub, Flume, Kafka

而系統的 log,其實就是眾多的 event,我們必須設法將散落在不同地方的內部或外部 log 收集並儲存起來,集中到某個系統進行管理及分析,才能簡化處理異質環境訊息處理的問題。而 Fluentd, Logstash, LogHub, Flume, Kafka 這些技術,是以不同的方式解決問題。

在營運網路服務時,可能會遇到下面這些問題

  1. 在不同的廣告通路上,取得的使用者,要評估不同的廣告得到的收益結果
  2. 使用者抱怨服務的速度太慢,但要分析是在哪一個部分出問題
  3. 發送優惠券時,要如何評估優惠券的效益
  4. 要分析什麼時候該儲備多一點貨品,或是要調配更多人力
  5. 客戶在使用過程中發生問題,要如何分析是在哪個步驟出錯

由於網路服務的系統,可能會有這些特性,連帶造成使用者在處理某個工作時,必須跨越多種異質環境。

  1. 多個促銷或銷售管道
  2. 多個使用介面,如網頁、手機或是 APP
  3. 多台雲端機器
  4. 多種開發程式語言或環境
  5. 多個作業系統平台

通常會將 Fluentd, Logstash, LogHub 在一起比較,而將 Flume, Kafka 一起比較。

LogHub 是阿里雲的 Log Service,在別的環境中,可以先不考慮這個方案。

Fluentd, Logstash 是用 ruby,而 Flume 及 Kafka 是 Java。

Fluentd 有個基本的限制,他並不保證訊息一定會被傳送,如果不能容忍訊息遺失的狀況,就不要考慮 Fluentd。

但 Logstash 及 Flume,為了保證訊息一定會被傳遞,
同樣的訊息可能會收到兩次以上。

Flume 是訊息收集系統,而 Kafka 更接近於訊息cache系統,他可以儲存一定時間內的資訊。因此可以看到很多是採用 Fluentd + Kafka + Storm/ElasticSearch 這樣混搭使用狀況。

至於 Logstash 跟 Flume 的比較,可以看 logstash vs flume 以及 請對logstash與flume做比較 這篇文章。

Logstash 重視資料的預處理,多個 input 會把資料匯總到 input 和 filter 之間的 buffer中。filter則會從buffer中讀取數據,進行過濾解析,然後儲存在 filter 和 output 之間的Buffer中。當 buffer 滿足一定的條件時,會觸發output的刷新。

而 Flume 比較重視資料的傳輸,只有封裝 event 然後就傳送,沒有資料解析處理的部份,傳輸時比較重視資料的可靠性。

References

Fluentd vs. Logstash: A Comparison of Log Collectors

日誌客戶端(Logstash,Fluentd, Logtail)橫評

深度解讀:為何要使用日誌服務LogHub替換Kafka?

公網數據採集比較(LOGHUB VS 前端機+KAFKA)

Flume和Logstash的那些事兒

日誌採集系統flume和kafka有什麼區別及聯繫,它們分別在什麼時候使用,什麼時候又可以結合?

Kafka 與 Flume的區別

Logging 日誌記錄最佳實踐

你一定需要 六款大數據採集平台的架構分析

深夜實堂:從業務需求淺談 Log aggregators