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

posted @ 2019-12-24 10:16  哈喽哈喽111111  阅读(1744)  评论(0编辑  收藏  举报