Elastic Stack的日志分析架构

“ 前文我们讲到ELK Stack在解决日志采集、分析、可视化的使用方式。但是使用Logstash进行日志采集+解析处理时会有较大的问题，所以Elastic.Inc推出了Beats解决该问题,并且整体命名为Elastic Stack。”

Beats是什么?

ELK Stack在前一篇文章中讲过了，主要是三大组件构成 Logstash、ElasticSearch与Kibana。提供了数据的采集、存储分析与数据可视化的能力。这些组件满足了日志管理和分析领域的常用需求。

在ELK Stack中Logstash的定位既是数据的采集Agent又是数据的解析处理工具。最终数据发送到ElasticSearch中。这样就会造成在真实环境中Logstash对于数据的采集、富化、解析等都会占用较高的资源。同时Logstash也具有固有的性能问题。

Beats是一组开源的日志搜集器。采用Go语言进行编写（对比Logstash的Java）。不同的Beat用于搜集不同的日志数据，包含Filebeat、Winlogbeat、Packetbeat、Heartbeat等。Beat采用Go语言编写，在Elastic Stack中主要负责日志的采集工作。例如Filebeat用于采集文本类型的数据，Packetbeat用于采集实时网络包的数据。Beats提供简单的对于数据的解析方式如果需要实现较为复杂的数据解析可以通过Beats把数据发送到Logstash进行解析。Logstash提供强大的数据解析处理插件。所以对于Elastic Stack就变成了

增加beats之后，数据的采集端处理的问题就变少了，正常来说例如filbeats仅仅需要处理的是单行数据的采集或者是多行数据的合并采集等问题。数据采集完成后beats直接使用TCP的方式把数据发送到Logstash中，Logstash再进行复杂的数据解析、富化问题。这样就把生产服务与日志处理框架的资源基本进行了隔离。并且实现非常的简单，不需要太多的额外配置。能够沿用之前的Logstash的配置。

Elastic Stack与消息队列集成

以上内容可以使用于小型的数据分析处理场景。在生产中处理大量的数据还需要考虑其他的因素，例如弹性伸缩，安全性，削峰，重新解析等。那么就可以引入消息队列。

引入Kafka或其他消息队列能够实现对于数据的缓存与保证其不会产生丢失。ElasticSearch是整个系统的核心，但是它在对大量的数据建立索引时会非常容易受到负载的影响。在ElasticSearch非常的忙碌时，Logstash也会受之影响而变慢。所以一般都会增加Kafka来保证数据获得更好的可用性。

总结

Elastic Stack增加了Beats来分离了数据的采集与解析端或者说Beats提供了更好的，资源占用率更低的数据采集、简单解析、发送方案。使当前的Elastic Stack更加适用于生产中。