Filebeat：ELK 協議棧的新成員，一個輕量級開源日誌文件數據蒐集器，基於 Logstash-Forwarder 源代碼開發，是對它的替代。在需要採集日誌數據的 server 上安裝 Filebeat，並指定日誌目錄或日誌文件後，Filebeat 就能讀取數據，迅速發送到 Logstash 進行解析，亦或直接發送到 Elasticsearch 進行集中式存儲和分析。
Beats 作爲日誌蒐集器
這種架構引入 Beats 作爲日誌蒐集器。目前 Beats 包括四種：
- Packetbeat（蒐集網絡流量數據）；
- Topbeat（蒐集系統、進程和文件系統級別的 CPU 和內存使用情況等數據）；
- Filebeat（蒐集文件數據）；
- Winlogbeat（蒐集 Windows 事件日誌數據）。
Beats 將蒐集到的數據發送到 Logstash，經 Logstash 解析、過濾後，將其發送到 Elasticsearch 存儲，並由 Kibana 呈現給用戶。詳見圖 3。
圖 3. Beats 作爲日誌蒐集器
這種架構解決了 Logstash 在各服務器節點上佔用系統資源高的問題。相比 Logstash，Beats 所佔系統的 CPU 和內存幾乎可以忽略不計。另外，Beats 和 Logstash 之間支持 SSL/TLS 加密傳輸，客戶端和服務器雙向認證，保證了通信安全。
因此這種架構適合對數據安全性要求較高，同時各服務器性能比較敏感的場景。
引入消息隊列機制的架構
到筆者整理本文時，Beats 還不支持輸出到消息隊列，所以在消息隊列前後兩端只能是 Logstash 實例。這種架構使用 Logstash 從各個數據源蒐集數據，然後經消息隊列輸出插件輸出到消息隊列中。目前 Logstash 支持 Kafka、Redis、RabbitMQ 等常見消息隊列。然後 Logstash 通過消息隊列輸入插件從隊列中獲取數據，分析過濾後經輸出插件發送到 Elasticsearch，最後通過 Kibana 展示。詳見圖 4。
圖 4. 引入消息隊列機制的架構
這種架構適合於日誌規模比較龐大的情況。但由於 Logstash 日誌解析節點和 Elasticsearch 的負荷比較重，可將他們配置爲集羣模式，以分擔負荷。引入消息隊列，均衡了網絡傳輸，從而降低了網絡閉塞，尤其是丟失數據的可能性，但依然存在 Logstash 佔用系統資源過多的問題。
基於 Filebeat 架構的配置部署詳解
前面提到 Filebeat 已經完全替代了 Logstash-Forwarder 成爲新一代的日誌採集器，同時鑑於它輕量、安全等特點，越來越多人開始使用它。這個章節將詳細講解如何部署基於 Filebeat 的 ELK 集中式日誌解決方案，具體架構見圖 5。
圖 5. 基於 Filebeat 的 ELK 集羣架構
因爲免費的 ELK 沒有任何安全機制，所以這裏使用了 Nginx 作反向代理，避免用戶直接訪問 Kibana 服務器。加上配置 Nginx 實現簡單的用戶認證，一定程度上提高安全性。另外，Nginx 本身具有負載均衡的作用，能夠提高系統訪問性能。