Elastic Stack最佳实践系列：Beats-＞ES，一个更轻型的架构选择-Toy模板网

这篇具有很好参考价值的文章主要介绍了Elastic Stack最佳实践系列：Beats-＞ES，一个更轻型的架构选择。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

ELK生态下，构建日志分析系统的选择

说起开源的日志分析系统，ELK几乎无人不晓，这个生态并非是Elastic特意而为，毕竟Elasticsearch的初心是分布式的搜索引擎，被广泛用作日志系统纯粹一个“美丽的意外”，这是社区使用者推动而成。而现在各大云厂商推广自己的日志服务时，也往往将各种指标对标于ELK，可见其影响之广。

但其实，流行的架构中并非只有ELKB，当我们使用ELKB搭建一套日志系统时，除了Elasticsearch, Logstash, Kibana, beats之外，其实被广泛使用的还有另一个工具 —— Kafka。在这当中，Kafka的作用是明显的，作为一个中间件，一个缓冲，它起到了提高吞吐，隔离峰值影响，缓存日志数据，快速落盘，同时通过producer/consumer模式，让Logstash能够横向拓展的作用，还能够用作数据的多路分发。因此，大多数时候，我们看到的实际架构，按数据流转顺序排列，应该是BKLEK架构。

Elastic Stack最佳实践系列：Beats-＞ES，一个更轻型的架构选择

但我们在使用Kafka的时候，也并非是没有成本的，额外的一套分布式系统，更长的数据链路，都会是我们在做最后架构选型时的一些痒点，特别是随着我们产生的数据越来越多，BKLEK架构会变得越来越大，越来越重，成本、性能、运维的简易性都会成为我们评估日志系统的重要指标。因此，我们的问题是：在Elastic Stack都已经进化到了8.1的当下，我们是否还需要延续一直以来的惯性思维，认为在我们仍然在任何情况下都是需要BKLEK的架构呢？

在我们开始正式探讨之前，我们可以从现在普遍看到的新的架构图可以一猜端倪：

Elastic Stack最佳实践系列：Beats-＞ES，一个更轻型的架构选择

在这个架构中，所有的Integration的输出都是Elasticsearch，所有的数据处理都由ingest pipeline完成，数据的完整性和可靠性，由端点和elasticsearch之间的应答确认来保证。因此，我们本文探讨的是：

我们数据采集端直接到ES的架构，是否可取
我们什么时候可以使用这种架构

数据采集端直接到ES的架构分析

虽然Elastic原厂的Fleet与Elastic Agent已经处于GA（普遍可用）的阶段，但因为其本身的一些限制，比如：

Integration Repository需要连接外网
需要单独的Fleet Server (在最新版本已经与APM server合并为Integration Server)
Elastic Agent还没有能完全覆盖Beats所支持的数据源

因此，现阶段，我们讨论数据采集端直接到ES的架构时，会主要集中在Beats->Elasticsearch这一架构。这一架构，相对于BKLEK架构来说，少了中间的Kafka，甚至我们可以忽略Logstash，因此，架构会相对精简，带来的好处包括：

相对更低的成本
更高的传输和数据处理效率
更一致的安全特性
更容易进行监控

当然，在带来以上好处的同时，我们也会失去Kafka所带来的各种好处。不过不用担心，Kafka的特性只是构建一个稳健的日志分析系统的充分条件，而非必要条件，在不少场景下，我们不一定是非Kafka不可。接下来，我们将讨论几个我们相对会比较关心的问题，以让大家了解，我们是否可以选择这种架构，什么时候选择这种架构，以及相应的最佳实践。