首先得明确几个核心关键点：Windows事件日志的原生查询确实存在最多22个事件ID的限制，而你使用的Winlogbeat 6.1.2版本不支持在winlogbeat.event_logs条目下嵌套processors——这就是第二个配置直接崩溃的原因，这个特性是7.x版本之后才新增的。

正确的配置方案 #

要绕过22个ID的限制，我们需要让Winlogbeat先收集全部Security日志，再通过全局处理器过滤保留你需要的500+个事件ID。这里提供两种实用的配置方式：

方式1：用or匹配单个事件ID（适合少量ID或需要精确匹配的场景）

winlogbeat.event_logs:
  - name: Security
    # 不要设置event_id参数，这样会收集所有Security日志
    ignore_older: 24h # 可选配置，仅收集最近24小时的日志，降低资源占用

processors:
  - drop_event.when.not.or:
      - equals.event_id: "4618"
      - equals.event_id: "4624"
      - equals.event_id: "4625"
      # 继续添加所有你需要的事件ID，每个ID单独占一行，保持缩进一致

方式2：用contains匹配ID列表（适合大量ID的场景，配置更简洁）

把所有需要的事件ID整理成字符串列表，用contains判断事件ID是否在列表内：

winlogbeat.event_logs:
  - name: Security
    ignore_older: 24h

processors:
  - drop_event.when.not.contains.event_id: 
      - "4618"
      - "4624"
      - "4625"
      # 批量添加你的500+个事件ID即可

为什么你之前的配置失效？ #

1. 第一个配置：如果当时域控制器没有产生4618事件，Winlogbeat过滤后自然没有日志输出。另外要注意YAML的缩进规则——所有同级配置的缩进必须完全一致（比如统一用2个或4个空格，不能混用），缩进错误会直接导致配置不生效。
2. 第二个配置：Winlogbeat 6.x版本不允许在winlogbeat.event_logs的单个日志条目下定义processors，这属于语法错误，所以客户端直接崩溃报错。

额外的排查和优化建议 #

• 验证配置语法：运行winlogbeat.exe test config -c winlogbeat.yml，如果输出Config OK说明配置格式没问题，否则根据提示修复即可。
• 检查权限：确保运行Winlogbeat的用户（默认是Local System）拥有读取域控制器Security日志的权限，否则会无法收集日志。
• 查看详细日志：Winlogbeat的日志默认存储在C:\ProgramData\winlogbeat\logs目录下，启动失败或无输出时，这里的日志会告诉你具体问题（比如权限不足、配置语法错误等）。

内容的提问来源于stack exchange，提问作者FanteG