►问题描述：
场景一：启用解析规则过多时，Logstash-filter一直重启，且filter无监控数据，具体情况如下：
场景二：启用解析规则过多（解析规则中含有添加数据库数据解析方法），Logstash-filter报错，filter不重启，数据流无法正常消费，Logstash-filter无监控数据，几个小时后filter一直重启，具体报错如下：
►问题原因：
批量启用过多解析规则，当Logstash-filter资源配置无法完成加载解析规则时（场景一和场景二都是此原因），Logstash-filter会报错或者无法启动，导致最终一直重启。
►排查思路：
- 查看Logstash-filter容器日志是否有以上报错；
- 查看Logstash-filter容器是否一直重启；
- 查看监控是否有Logstash-filter的数据信息。
如果存在场景一或者场景二情况，说明同时启用解析规则数量过多，当前Logstash-filter配置已无法满足解析规则加载。
►排查方法：
1. 当标准一体机未执行性能优化脚本且启用的解析规则未到AR执行性能优化脚本之后可支持的解析规则上限时（标准一体机配置（x86：32C64G；arm：96C128G），可通过执行性能优化脚本（具体可查看实施指导手册优化性能）解决此问题。标准一体机性能调优后，AR可支持的解析规则上限（每个解析规则复杂程度不同，解析规则生效时间略有差异，以下数据仅供参考）：
- x86实体机性能调优之后，AR可支持的解析规则上限：38个解析规则（以内置14个+ab：19个+其他解析规则5个为例）解析规则生效时间：13分钟（即filter加载耗时：13分钟）；
- arm实体机性能调优之后：AR可支持的解析规则上限：33个解析规则（以内置14个+ab：19个为例）解析规则生效时间：13分钟（即filter加载耗时：13分钟）。
2. 当启用解析规则数据超过性能调优之后AR可支持的解析规则上限时（可能会出现场景一或者场景二情况），可通过手动调整Logstash-filter的配置解决（均在执行完性能优化脚本的基础上调整），需要调大Logstash-filter的JVM配置、内存限制（limits：Memory）以及健康检查时间（举例：若failureThreshold调整为6，意味着每5分钟检查1次，检查6次，即健康检查时间调整为30分钟，若6次都检查失败，Logstash-filter会重启）。
以批量启用50个解析规则为例：
（1）x86环境执行完性能优化脚本之后，需要调整的Logstash-filter的配置：JVM：15G，limits：Memory：16G，failureThreshold：6，如下所示：
当前配置下解析规则生效时间参考（每个解析规则复杂程度不同，解析规则生效时间略有差异，以下数据仅供参考）：
- 启用50个解析规则后重新部署filter，解析规则生效时间：25分钟（filter加载配置耗时：25分钟，即filter生效时间为filter重新部署的25分钟之后）；
- 启用50个解析规则后，编辑其中1个解析规则（即修改解析规则），filter生效时间：44分钟（等待21分钟+filter加载配置耗时23分钟）。
（2）ARM环境执行完性能优化脚本之后，需要调整的Logstash-filter的配置：JVM：20G，limits：Memory：21G，failureThreshold：6，如下所示：
当前配置下解析规则生效时间参考（每个解析规则复杂程度不同，解析规则生效时间略有差异，以下数据仅供参考）：
- 启用50个解析规则后重新部署filter，解析规则生效时间：23分钟（filter加载配置耗时：23分钟，即filter生效时间为filter重新部署的23分钟之后）；
- 启用50个解析规则后，编辑其中1个解析规则（即修改解析规则），filter生效时间：46分钟（等待23分钟+加载配置耗时23分钟）。