Elasticsearch数据采集和处理--Logstash VS Ingest Node

参考地址:

Should I use Logstash or Elasticsearch ingest nodes?

1、背景

Logstash是Elastic Stack的重要组成部分(即ELK中的L),在该架构中负责数据采集,处理,输出等功能,支持多种数据输入,数据处理,数据输出方式,并且具有可扩展性好,功能强大等优点。典型的采用Logstash进行数据采集和处理的Elastic Stack架构如下图:

Logstash数据采集和处理

而Ingest Node是在Elasticsearch5.0之后引入的特性,用于在文档实际索引动作执行前对文档进行预处理,在数据处理层面上与Logstash有许多功能重叠之处。引入Ingest Node后的Elastic Stack数据采集和处理架构如下:

IngestNode数据采集和处理

Ignest Node的出现为Elastic Stack 数据的采集和处理提供了一种新的方式,在许多场景下用户可以在不使用Logstash的情况下,完成数据的采集和处理,简化了系统架构。那么Logstash和Ignest Node有何异同?在实际使用中该如何选择呢?

2、Logstash与Ignest Node的比较

2.1 数据输入和输出

Ingest Node:作为Elasticsearch索引文档过程的一部分,仅能使用Elasticsearch支持的方式来输入,如Restful接口等,处理过后的数据也只能索引入Elasicsearch中,而不能输出到其他地方。

Logstash:支持多种数据源,包括各种Beats,Mysql,kafka等,不仅可以作为服务端接收Client通过TCP,UDP,HTTP等方式推送过来的数据,也可以主动从数据库,消息队列等处拉取数据。数据输出功能也非常强大,可以输出到消息队列,对象存储,HDFS等。

2.2 数据缓冲

Ingest Node:Elasticsearch本身并没有提供数据缓冲策略,数据输入端需要自行解决ES拒绝写入请求的情况。而Ingest Node作为ES索引文档的一部分也没有数据缓冲策略。

Logstash:提供队列机制,可以防止数据丢失和承受一定的负载尖刺。另外,还支持多种队列,可以根据业务实际情况选择合适的队列。

2.3 数据处理

Ingest Node:支持超过20多种processors,这些processors覆盖了Logstash的常用场景。限制是只能在单个数据的上下文执行,另外不能调用外部的系统,如文件,数据库等

Logstash:支持大量的processors,用户甚至可以自己的需要编写plugins,也可以调用包括磁盘文件,数据库,ES等外部资源。另外Logstash支持根据条件过滤和丢弃数据。

2.4 配置和使用

Ingest Node:通过ES接口创建Pipeline, 并存入Elasticsearch中,无监控和可视化管理界面

Logstash:主要通过配置文件来定义Pipeline,支持条件控制流和多pipeline,并提供有监控和可视化Pipeline管理功能,对于性能调优和问题定位非常有帮助。Kibana中的Logstash pipeline管理界面如下图:

[图片上传失败...(image-a61b5f-1574901926119)]

3、分析

(1)输入方面,虽然Logstash支持更多的输入方式,但是Ingest Node也可以通过与Beats,甚至Logstash配合来解决不同数据源的输入问题。

(2)输出方面,由于Ingest Node 作为Elasticsearch索引文档过程的一部分,因此除非对源码进行改造,否则无法将数据导出到其他地方。因此如果有将处理过后的数据导出到其他地方的需求,建议使用Logstash。

(3)数据缓冲方面,Ingest Node 可以通过在文档输入前接入Kafka等消息队列来解决。另外在实际使用中,即使Logstash自身有队列机制,一般也会在Logstash前增加Kafka来更好的缓冲数据传输压力。

(4)数据处理方面,IgnestNode支持Logstash的大多数常用场景,如果在使用前可以明确所有使用场景,确定Ignest Node可以满足需求,可以使用IgnestNode,如果IgnestNode不能满足要求,则需要采用Logstash。

(5)配置和使用方面,在这方面Logstash有明显优势,灵活的配置方式,可视化监控和pipeline管理,在复杂系统中有着重要的帮助作用。

(6)性能和架构方面,Ignest作为Elasticsearch集群的一部分,当数据处理逻辑相对简单时,可以简化数据采集和处理架构。但是当数据处理相对逻辑复杂时,Ingest Node数据处理过程可能影响节点的性能。这时一般采用专用Ingest Node的方式解决,而引入专用Ingest Node会使Elasticsearch集群的结构变得复杂,这与Ingest Node简化数据采集和处理架构的优势背道而驰。而Logstash是处于Elasticsearch前的专用数据采集和处理模块,当性能出现瓶颈时可以通过横向扩展的方式来提高处理能力,在架构上更为清晰。

(7)Ingest Node与Logstash的联用,Ingest Node是Elasticsearch集群的一部分,而Logstash处于Elasticsearch的前端,在结构上两者完全可以配合使用。PS:Ignest Node一个用法是为数据添加时间戳,以便更精确地记录文档索引时间,在耗时计算时有一定用处。Ingest Node与Logstash联用的Elastic Stack架构图如下:

Ingest Node与Logstash联用

4、结论和建议

通过上面的比较和分析不难发现,Ignest Node 在功能上基本为 Logstash 的子集, 在数据处理逻辑简单,没有其他额外输出端的时候,可以简化系统架构,实现快速部署。但是当处理逻辑复杂,多输入源和多输出源的场景下,Logstash的功能强大和灵活更为合适。

在实际使用中可以根据自己的业务特点来选择Ingest Node或Logstash。

(1)如果是将Elastic Stack使用在特定场景下,且数据处理逻辑相对简单,可以考察Ignest Node是否满足需求,优先使用Ignest Node实现系统的快速部署。

(2)当需要搭建的是一个通用的Elastic Stack平台,需要支持多种输入源,输出源,数据处理逻辑也相对复杂时,建议采用Logstash, 利用Logstash的功能强大,灵活,可扩展等特性,保证系统的功能性和稳定性。

(3)如果在系统搭建初期,需求不明确,由于Ignest Node和Logstash可以联用,因此可以先使用Ingest Node来搭建系统,当功能无法满足时,再在Elasticsearch前面增加Logstash。

Ingest Node和Logstash虽然在功能上有很多重叠,但是仍有各自的特点,在实际的业务场景中,可以根据业务需要灵活选择。

欢迎关注公众号Elastic慕容,和我一起进入Elastic的奇妙世界吧

image

你可能感兴趣的:(Elasticsearch数据采集和处理--Logstash VS Ingest Node)