ELK 不是一款軟件,而是 Elasticsearch、Logstash 和 Kibana 三種軟件產品的首字母縮寫。這三者都是開源軟件,一般配合使用,並且又前後歸於 Elastic.co 公司名下,因此被簡稱爲 ELK Stack。根據 Google Trend 的信息顯示,ELK Stack 已經成爲目前最流行的集中式日誌解決方案。安全
若是您對 ELK Stack 還尚不瞭解,或是想了解更多,請點擊集中式日誌系統 ELK 協議棧詳解,查看具體介紹。服務器
ELK 經常使用架構及使用場景介紹網絡
在這個章節中,咱們將介紹幾種經常使用架構及使用場景。架構
最簡單架構負載均衡
在這種架構中,只有一個 Logstash、Elasticsearch 和 Kibana 實例。Logstash 經過輸入插件從多種數據源(好比日誌文件、標準輸入 Stdin 等)獲取數據,再通過濾插件加工數據,而後經 Elasticsearch 輸出插件輸出到 Elasticsearch,經過 Kibana 展現。詳見圖 1。分佈式
圖 1. 最簡單架構性能
這種架構很是簡單,使用場景也有限。初學者能夠搭建這個架構,瞭解 ELK 如何工做。搜索引擎
Logstash 做爲日誌蒐集器加密
這種架構是對上面架構的擴展,把一個 Logstash 數據蒐集節點擴展到多個,分佈於多臺機器,將解析好的數據發送到 Elasticsearch server 進行存儲,最後在 Kibana 查詢、生成日誌報表等。詳見圖 2。spa
圖 2. Logstash 做爲日誌搜索器
這種結構由於須要在各個服務器上部署 Logstash,而它比較消耗 CPU 和內存資源,因此比較適合計算資源豐富的服務器,不然容易形成服務器性能降低,甚至可能致使沒法正常工做。
Beats 做爲日誌蒐集器
這種架構引入 Beats 做爲日誌蒐集器。目前 Beats 包括四種:
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 自己具備負載均衡的做用,可以提升系統訪問性能。