我正在封装一个monolith应用程序，在每个当前vm中都有一个logstash进程，它通过python的 RotatingFileHandler .
在当前堆栈中，logstash将日志发送到弹性索引，有时会发生集群磁盘空间不足的情况，但是由于logstash会无限期重试，一旦我们为新数据腾出空间，就不会丢失任何日志。
现在，我们想尝试filebeat而不是logstash，因此我们决定尝试这种方法：
持久的外部文件系统
我们应用程序的一个容器示例，它挂载文件系统以写入循环日志，名称为uuid（类似于202011_uid.log.*），因此扩展不会引起冲突
一个容器，用于整个集群，带有filebeat，它装载文件系统，获取日志并将它们直接发送到elastic。
现在这种方法工作得很好，直到elastic耗尽空间并引发 cluster_block_exception . 在这种情况下，使用默认配置，filebeat应该无限期地重试(https://www.elastic.co/guide/en/beats/filebeat/7.10/elasticsearch-output.html#_max_retries)但实际上只做了3次尝试，在2分钟左右，然后完全放弃了这个项目。
在做一些研究时，我偶然发现一些用户设置了 max_retries 到-1，但由于我不能确保在生产中快速解决磁盘空间问题，并且不希望filebeat淹没我的索引，因此我最终以以下方式配置filebeat：

output.elasticsearch:
  backoff.init: 20s
  backoff.max: 72h
  max_retries: -1

现在，通过上面的配置，filebeat似乎忽略了重试，只进行了一次尝试。
我做错了什么？这是我的堆栈中的缺陷还是某些配置问题？