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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beats -> Elasticsearch链路的健康保障

对于不使用Kafka的场景，我们可能始终会有点觉得不踏实。因为对Beats -> Elasticsearch这个简单架构不够了解，以至于我们信心不足。接下来，我们讨论一下，在这种简单架构下，我们是如何面对各种可能出现的问题的。

大多数架构师会担心的问题是流量波动的问题，如果突然出现日志流量的洪峰，是不是会影响到后端的日志系统。这个问题的答案是，有影响，但影响有限。

我们先明确一下日志系统的主要作用：即日志的集中管理，在统一的日志平台上提供所有日志的准实时的关联查询与分析能力。这里的核心是准实时和查询能力。

在流量洪峰的情况下，受影响的是“准实时”的能力，因为受限于日志系统的处理能力，如果日志产生的速度，大于日志系统处理的速度，则我们无法读取到最新的数据。这个问题，即便是我们有了Kafka也是无法解决的。

而查询的能力，几乎不受影响。原因如下：

• ES的读写是由不同的线程处理的，有各自独立的线程池。过载的写流量，会导致后到的写请求，因为写线程池已满，而被拒绝。但不会导致查询情况的拒接服务
• ES从7.0开始，使用真实内存断路器，能够避免由于过多的请求࿰