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

若想要從一堆伺服器中蒐集資訊回後端分析,稍微有追新技術的應該會從 Logstash / Flume / Fluentd 這些熱門套件中選一個 (當然還有另幾派)。

怎麼選?很多技術分享簡報都是從語法談起,但我覺得沒談到真正的癢處;另外也有人用程式語言來選擇,例如喜歡 Ruby 的就會選 Logstash / Fluentd,若再不喜歡 Java 就會只剩下 Fluentd。

但重點還是依實際業務需求而定。例如,資訊需不需要傳遞保證 (能不能忍受原本應該要送出的資訊在傳遞過程中不見了)?如果不行,則不該選擇 Fluentd,而應該選 Logstash 或 Flume。

我相信很少人會因為 Fluentd 不支援此功能就特別 Hack,而且即使辛苦改到完善後,也無法吸引 Fluentd 團隊收納該功能,因為官方有表示過為了效能而不考慮傳遞保證。

不過,Logstash / Flume 的傳遞保證有個缺點,同樣的訊息可能會收到兩份以上。所以業務能不能接受重複訊息?或者說,用戶明明只處理一次,後端卻收到兩個訊息?如果不行,這下可連 Logstash / Flume 都不合格了。

怎麼辦?

這就是為什麼我們有時候會看到一些較複雜混用 (當然還可以完全走另一套思路),例如 Fluentd + Kafka + Storm + MySQL。有時是為了補足 Fluentd 的缺點,而必須依賴其它的軟體來達到業務需求

(有時也是為了其它業務需求,例如分布式)。

結束了嗎?

為什麼這裡要用 Kafka?以前述的需求來說,Kafka 無法用 RabbitMQ / Beanstalkd / Akka 取代,當然更不用說在此場景下功能更少的 Redis / ZeroMQ / Nsq。但 Kafka 卻可能用 ActiveMQ / Qpid 取代。

再來,可以用 Spark / Samza 取代 Storm 嗎?以前述的需求來說,Spark 可以,但 Samza 不行。

有點複雜,但其實不難懂。