【问题标题】:Redis Length growingRedis 长度增长
【发布时间】:2016-05-24 13:28:38
【问题描述】:

我们的管道: VMware-Netflow -> Logstash -> Redis -> Logstash-indexer -> 3xElastic

我收集的数据:

  • 我在 kibana 中注意到流入的流量是 1 小时前,然后 2,然后是 3,依此类推。
  • 运行“redis-cli llen netflow”显示一个非常大的数字,该数字正在缓慢增加。
  • 运行 'redis-cli INFO 显示相当稳定的 80kbps 输入和 1kbps 输出。我认为这些应该几乎相等。
  • 所有节点上的 CPU 负载几乎可以忽略不计。

我尝试过的:

  • 我确保 logstash-indexer 正在发送到所有 3 个弹性节点。
  • 我在索引器上启动了许多额外的 logstash 实例,redis 现在显示 40 个客户端。

我不知道还能尝试什么。

【问题讨论】:

  • 您是否对单个组件进行过负载测试?例如。您的索引器每分钟可以处理多少日志。您每分钟从 Logstash Shipper 获得多少日志行?
  • 本质上取决于输入与索引器处理日志的速度。以我的经验,Redis 本身非常快,而且通常与 Logstash 有关,这就是问题所在。

标签: redis logstash elastic-stack


【解决方案1】:

TLDR:重新启动所有三个 elasticsearch 节点,生活又恢复了。

我无意中禁用了 elasticsearch 作为输出,并将我的 netflows 发送到以太网中。 redis 中的队列大小在几分钟内下降到 0。虽然很伤心,但这确实证明了它是 elasticsearch 而不是 logstash 或 redis。

我观察了弹性实例,它们之间的通信似乎有问题。这三个都显示了日志,表明 2/3 正在退出集群,并且需要永远响应集群 ping。我认为正在发生的事情是,写入被弹性接受,并且在成功写入之前反弹了一段时间。

重新启动它们后,它们进行了正确协商,并且写入正常进行。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-06-07
    • 2015-04-12
    • 1970-01-01
    • 1970-01-01
    • 2020-04-03
    • 1970-01-01
    相关资源
    最近更新 更多