Elastic：Elastic 部署架构介绍

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/pdf/architecture-best-practices.pdf

更多关于 Elastic Stack 的架构实现，请参阅我的文章 “Elastic：开发者上手指南” 中的 “Elastic Stack 架构” 章节。