Elastic Stack是一套完整的從數據采集，解析，分析，豐富，到搜索，檢索，數據程序等一套完整的軟件棧。在具體的實踐中，我們應該如何搭建我們的系統呢？
下圖描述了常用的Elastic Stack的部署架構：
該圖描述了三種可能的體系結構：
- 將操作指標直接發送到Elasticsearch：如上圖所示，您將在要從其發送操作指標/日志的邊緣服務器上安裝各種類型的Beats，例如Metricbeat，Filebeat，Packetbeat等。 如果不需要進一步處理，那么可以將生成的事件直接傳送到Elasticsearch集群。 一旦數據出現在Elasticsearch中，就可以使用Kibana對其進行可視化/分析。 在這種體系結構中，事件流將是Beats→Elasticsearch→Kibana。當然如果您需要做進一步的處理，您也可以通過ingest node的pipleline幫助實現。
- 將操作指標發送到Logstash：Beats捕獲並安裝在邊緣服務器上的操作指標/日志將發送到Logstash進行進一步處理，例如解析日志或豐富日志事件。 然后，已解析/豐富的事件被推送到Elasticsearch。 為了提高處理能力，您可以擴展Logstash實例，例如，通過配置一組Beats將數據發送到Logstash實例1，並配置另一組Beats將數據發送到Logstash實例2，依此類推。 在這種架構中，事件流將是Beats→Logstash→Elasticsearch→Kibana。
- 將操作指標發送到彈性隊列：如果生成的事件發生率很高，並且Logstash停機時Logstash無法應付負載或防止數據/事件丟失，則可以使用諸如以下的彈性隊列 Apache Kafka，以便將事件排隊。 然后，Logstash可以以自己的速度處理它們，從而避免丟失Beats捕獲的操作指標/日志。 在這種體系結構中，事件流將是Beats→Kafka→Logstash→Elasticsearch→Kibana。
提示：從Logstash 5.x開始，您可以使用Logstash的持久隊列設置，也可以將其用作隊列。 但是，它不像Kafka一樣提供高度的彈性。
也有一些應用場景是這樣部署的：
同樣的，在這里，我們可以通過radis或Kafaka來提供一個彈性隊列來緩沖高發生率事件。
在實際的使用中，如果我們不把Elasticsearch當做唯一的數據庫來存儲的話，那么，我們可以采用如下的方案：
在這種架構中，您有兩個數據存儲，必須找到一種使它們保持同步的方法。 根據您的主要數據存儲區和數據布局方式，您可以部署Elasticsearch插件以使兩個實體保持同步。
如下的是另外一中有外部數據，物聯網等的一種架構：
或者一個更加全面的架構圖：
在Elastic的官方文檔中，有更多關於部署架構的描述。詳細文檔：https://www.elastic.co/assets/blt2614227bb99b9878/architecture-best-practices.pdf