elasticsearch - 使用 fluent-bit/fluentd 处理大量日志

Question

我们有以下可观察性堆栈。

我们经常面临来自 ECS 上运行的某些应用程序的大量日志涌入的挑战，这会导致日志聚合器重新启动并最终使 ES 不稳定。我们采用了一些方法来缓解这种情况。

1. 在聚合器级别引入限制（超过阈值时丢弃消息） - 无需人工干预

2. 在聚合器进行任何处理之前过滤来自 App1 的日志消息（需要使用过滤器重新部署聚合器 - 需要手动干预）

3. 在收集器级别引入节流（节流过滤器插件）（仍需测试）

虽然选项 1 在日志量合理时有效，但在日志量很大（1 小时内 300 万条记录）时，它并没有被证明是最佳解决方案。日志聚合器容器不断重启，每次重启都会重置节流限制

使用选项 2，我们尝试解决解决方案 - 但它需要操作员使用过滤器重新启动日志聚合app器。我们通常会更新 CF 堆栈来实现这一点。

当前 fluentd 配置 - APP_LOGS_DROP 将需要设置为创建大量日志并重新启动聚合器容器的应用程序

 <match "#{ENV['APP_LOGS_DROP']}">
      @type null
   </match>
   <match **>
     @type relabel
     @label @throttle
   </match>
</label>
<label @throttle>
  <filter log.**>
    @type record_modifier
    <record>
      app ${tag_parts[1]}
    </record>
  </filter>
  <filter log.**>
    @type throttle
    group_key app
    group_bucket_period_s   "#{ENV['THROTTLE_PERIOD']}"
    group_bucket_limit      "#{ENV['THROTTLE_LIMIT']}"
    group_reset_rate_s      "#{ENV['THROTTLE_RESET_RATE']}"
  </filter>
  <match log.**>
   @type relabel
   @label @continue
  </match>

我想知道是否有其他方法可以解决此问题以及自动化选项 2 的方法。目前，我们了解巨大日志量的方式是通过 Elasticsearch 中的观察者警报，当它变得不稳定时。

提前致谢。