使用接入工具和緩存組件構建日誌採集方案時，我們需要考慮的三個要素：時效性、數量級、複雜度。
• 時效性就是日誌是否需要保障低時間延遲的傳輸，即我的設備和程序發生的事件需要在最短時間內拿到，還是可以允許有延遲，允許多長時間的延遲，幾分鐘還是幾小時、或者半天也行。在方案制定過程中，時效性決定了是否要選擇 Storm 實時流式方案。並作爲測試過程的硬指標發揮作用，在模擬測試環節判斷方案是否可用。
• 數量級是對於日誌條目數和空間大小的衡量要素。運行出錯才做事件記錄的程序日誌和每秒收集一次傳感器日誌在數據條目和文件佔用的磁盤空間上是有很大區別的，進行採集的時候對於採集組件的要求也是不同的。數量級影響採集工具和緩存組件的選擇，在方案制定過程中，每天採集的條目數超過百萬時候就需要增加緩存組件了，條目數過億時候就需要考慮如何平衡數據寫入和數據查詢的資源了。
• 最後一個要素就是複雜度，採集方案複雜度的產生主要由於原因：數量級、網絡環境和採集工具。在數量級要求下，我們不得不添加緩存組件，把日誌先寫到 Kafka，再把日誌寫到 ES，增加一個 Kafka，就需要考慮 Kafka 的高可用問題和數據丟失問題，方案複雜度就提升了。方案的複雜度會影響方案的實施難度和維護難度，複雜度太高的方案即使設計出來也比較難落地。
考慮到這三種因素，我們在選擇日誌採集方案的時候要考慮到四個原則。
• 時效性要求不高，數量級也不大的情況優先採集文件，因爲文件是最簡單的也是最好採集的。
• 在日誌生成的過程中解決解析問題，而不是在傳輸過程中，也就是在日誌生成的過程中就約束它的格式，而不是考慮在傳輸過程中統一它的格式。大部分的採集工具都支持中間改寫日誌信息，增加內容或者拆分內容，這些操作實際上增加了採集方案的複雜度，也使得替換採集工具的成本增加，需要儘量避免。
• 不同的日誌都有它的特點，那麼是不是我們每一個具體的場景，都要選擇不同的工具呢 ？我覺得是需要比較這個工具的特點帶來的收益和增加工具來的的複雜度變化，如果新增工具不會對於原來的組件產生影響，也不會新增開發內容，運維上也能接受；那麼是可以增加工具的，否則工具數量越少越好。
• 如果數據量比較大的話，就要考慮多級的緩存處理。引入緩存主要就是爲了分離上下游操作，在不影響 ES 性能的情況下，寫入更多的數據。
除了 Logstash 還有幾種常用日誌採集工具
• Rsyslog 一般用於收集系統的 syslog 日誌；
• Fluentd 主要用於容器日誌收集；
• Filebeat go 語言編寫，專注於文件日誌收集；
• Flume 在傳輸鏈路中增加了 Channel 組件作爲數據緩存，可以把數據保存到磁盤上以避免數據丟失。
收集日誌時除了收集工具還會用到緩存組件，主要的有 2 個：Kafka 消息隊列和 Redis 內存數據庫。
• Redis 主要用於小數據量低延遲要求的場景，多數情況下和 Storm 聯用來處理實時數據。
• Kafka 是通用的消息隊列組件，適合場景比較多，類似 Kafka 的消息隊列組件還有幾種。