而系統的 log,其實就是眾多的 event,我們必須設法將散落在不同地方的內部或外部 log 收集並儲存起來,集中到某個系統進行管理及分析,才能簡化處理異質環境訊息處理的問題。而 Fluentd, Logstash, LogHub, Flume, Kafka 這些技術,是以不同的方式解決問題。
在營運網路服務時,可能會遇到下面這些問題
- 在不同的廣告通路上,取得的使用者,要評估不同的廣告得到的收益結果
- 使用者抱怨服務的速度太慢,但要分析是在哪一個部分出問題
- 發送優惠券時,要如何評估優惠券的效益
- 要分析什麼時候該儲備多一點貨品,或是要調配更多人力
- 客戶在使用過程中發生問題,要如何分析是在哪個步驟出錯
由於網路服務的系統,可能會有這些特性,連帶造成使用者在處理某個工作時,必須跨越多種異質環境。
- 多個促銷或銷售管道
- 多個使用介面,如網頁、手機或是 APP
- 多台雲端機器
- 多種開發程式語言或環境
- 多個作業系統平台
通常會將 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)橫評
沒有留言:
張貼留言