ElasticSearch/Logstash/Kibana 如何应对日志流量高峰

Question

在标准 ELK 设置中，处理写入 ElasticSearch 集群的日志消息激增的最佳方法是什么？

我们在 AWS 中使用标准的 ELK (ElasticSearch/Logstash/Kibana) 设置来满足我们网站的日志记录需求。

我们在负载均衡器后面有一组自动缩放的 Logstash 实例，它记录到另一个负载均衡器后面的一组自动缩放的 ElasticSearch 实例。然后我们有一个服务于 Kibana 的实例。

对于日常业务，我们运行 2 个 Logstash 实例和 2 个 ElasticSearch 实例。

我们的网站在事件期间会经历短时间的高流量 - 在这些事件期间，我们的流量增加了约 2000%。我们很早就知道这些正在发生的事件。

目前我们只是在事件期间临时增加了ElasticSearch实例的数量。然而，我们遇到了随后缩减速度过快的问题，这意味着我们丢失了分片并损坏了我们的索引。

我一直在考虑将 auto_expand_replicas 设置为 "1-all" 以确保每个节点都有所有数据的副本，所以我们不需要担心我们扩大或缩小规模的速度有多快。将所有数据传输到新节点的开销有多大？我们目前只保留大约 2 周的日志数据 - 总共大约 50GB。

我还看到有人提到使用一个单独的非数据节点自动缩放组来处理搜索流量的增加，同时保持数据节点的数量不变。这是否有助于写入繁重的情况，例如我之前提到的事件？

Answer 1

我的建议

您最好的选择是使用 Redis 作为 Logstash 和 Elasticsearch 之间的代理:

这在一些旧的 Logstash docs 上有描述但仍然非常相关。

是的，您会看到从生成日志到它们最终登陆 Elasticsearch 之间的延迟最小，但它应该是最小的，因为 Redis 和 Logstash 之间的延迟相对较小。根据我的经验，Logstash 倾向于很快处理 Redis 上的积压工作。

这种设置还为您提供了更强大的设置，即使 Logstash 出现故障，您仍然可以通过 Redis 接受事件。

只需扩展 Elasticsearch

关于额外的非数据节点是否有助于写入密集期的问题:我不这么认为，不。当您看到正在执行大量搜索(读取)时，非数据节点非常有用，因为它们将搜索委托(delegate)给所有数据节点，然后在将结果发送回客户端之前聚合结果。它们消除了从数据节点聚合结果的负担。

写入将始终涉及您的数据节点。

我认为添加和删除节点不是解决此问题的好方法。

您可以尝试调整 thread pools and queues在你的高峰期。假设通常情况下您有以下内容:

threadpool:
  index:
    type: fixed
    size: 30
    queue_size: 1000
  search
    type: fixed
    size: 30
    queue_size: 1000

因此您有均匀数量的搜索和索引线程可用。在高峰时间之前，您可以将设置 ( on the run) 更改为以下内容:

threadpool:
  index:
    type: fixed
    size: 50
    queue_size: 2000
  search
    type: fixed
    size: 10
    queue_size: 500

现在您有更多的线程进行索引，允许更快的索引吞吐量，同时搜索被搁置。为了更好地衡量，我还增加了 queue_size 以允许建立更多的积压。不过，这可能无法按预期工作，建议进行试验和调整。