轉自：http://blog.csdn.net/lively1982/article/details/50678657
ELK是Elasticsearch、Logstash、Kibana的簡稱，這三者是核心套件，但並非全部。后文的四種基本架構中將逐一介紹應用到的其它套件。
-
Elasticsearch是實時全文搜索和分析引擎，提供搜集、分析、存儲數據三大功能；是一套開放REST和JAVA API等結構提供高效搜索功能，可擴展的分布式系統。它構建於Apache Lucene搜索引擎庫之上。
-
Logstash是一個用來搜集、分析、過濾日志的工具。它支持幾乎任何類型的日志，包括系統日志、錯誤日志和自定義應用程序日志。它可以從許多來源接收日志，這些來源包括 syslog、消息傳遞（例如 RabbitMQ）和JMX，它能夠以多種方式輸出數據，包括電子郵件、websockets和Elasticsearch。
-
Kibana是一個基於Web的圖形界面，用於搜索、分析和可視化存儲在 Elasticsearch指標中的日志數據。它利用Elasticsearch的REST接口來檢索數據，不僅允許用戶創建他們自己的數據的定制儀表板視圖，還允許他們以特殊的方式查詢和過濾數據。
我們先談談第一種ELK架構，如圖1，這是最簡單的一種ELK架構方式。優點是搭建簡單，易於上手。缺點是Logstash耗資源較大，運行占用CPU和內存高。另外沒有消息隊列緩存，存在數據丟失隱患。建議供學習者和小規模集群使用。
此架構首先由Logstash分布於各個節點上搜集相關日志、數據，並經過分析、過濾后發送給遠端服務器上的Elasticsearch進行存儲。Elasticsearch將數據以分片的形式壓縮存儲並提供多種API供用戶查詢，操作。用戶亦可以更直觀的通過配置Kibana Web Portal方便的對日志查詢，並根據數據生成報表（詳細過程和配置在此省略）。
圖1 ELK架構一
第二種架構（圖2）引入了消息隊列機制，位於各個節點上的Logstash Agent先將數據/日志傳遞給Kafka（或者Redis），並將隊列中消息或數據間接傳遞給Logstash，Logstash過濾、分析后將數據傳遞給Elasticsearch存儲。最后由Kibana將日志和數據呈現給用戶。因為引入了Kafka（或者Redis）,所以即使遠端Logstash server因故障停止運行，數據將會先被存儲下來，從而避免數據丟失。
圖2 ELK架構二
這種架構適合於較大集群的解決方案，但由於Logstash中心節點和Elasticsearch的負荷會比較重，可將他們配置為集群模式，以分擔負荷，這種架構的優點在於引入了消息隊列機制，均衡了網絡傳輸，從而降低了網絡閉塞尤其是丟失數據的可能性，但依然存在Logstash占用系統資源過多的問題。
第三種架構（圖3）引入了Logstash-forwarder。首先，Logstash-forwarder將日志數據搜集並統一發送給主節點上的Logstash，Logstash分析、過濾日志數據后發送至Elasticsearch存儲，並由Kibana最終將數據呈現給用戶。
圖3 ELK架構三
這種架構解決了Logstash在各計算機點上占用系統資源較高的問題。經測試得出，相比Logstash，Logstash-forwarder所占用系統CPU和MEM幾乎可以忽略不計。另外，Logstash-forwarder和Logstash間的通信是通過SSL加密傳輸，起到了安全保障。如果是較大集群，用戶亦可以如結構三那樣配置logstash集群和Elasticsearch集群，引入High Available機制，提高數據傳輸和存儲安全。更主要的配置多個Elasticsearch服務，有助於搜索和數據存儲效率。但在此種架構下發現Logstash-forwarder和Logstash間通信必須由SSL加密傳輸，這樣便有了一定的限制性。
第四種架構（圖4），將Logstash-forwarder替換為Beats。經測試，Beats滿負荷狀態所耗系統資源和Logstash-forwarder相當，但其擴展性和靈活性有很大提高。Beats platform目前包含有Packagebeat、Topbeat和Filebeat三個產品，均為Apache 2.0 License。同時用戶可根據需要進行二次開發。
圖4 ELK架構四
這種架構原理基於第三種架構，但是更靈活，擴展性更強。同時可配置Logstash 和Elasticsearch 集群用於支持大集群系統的運維日志數據監控和查詢。