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文档中有所描述，但仍然非常相关。

是的，您将看到正在生成的日志与最终登陆Elasticsearch之间的最小延迟，但它应该是最小的，因为Redis和Logstash之间的延迟相对较小。 根据我的经验，Logstash很快就可以通过Redis的积压工作。

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

只是缩放Elasticsearch

至于你的问题是关于额外的非数据节点是否会有助于写入繁重的时期：我不相信，不。 当您看到正在执行大量搜索（读取）时，非数据节点很棒，因为它们将搜索委托给所有数据节点，然后在将结果发送回客户端之前聚合结果。 它们消除了聚合数据节点结果的负担。

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

我不认为添加和删除节点是一个很好的方式来迎合这一点。

您可以尝试在高峰期调整线程池和队列 。 我们通常说你有以下几点：

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

因此，您可以获得均匀的搜索和索引线程。 在高峰时间之前，您可以将设置（ 在运行中 ）更改为以下内容：

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

现在你有更多的线程正在进行索引，允许更快的索引吞吐量，而搜索则放在backburner上。 为了更好的衡量，我还增加了queue_size以允许更多的积压来建立。 但是，这可能无法按预期工作，建议进行实验和调整。