Filebeat 7.14在Kubernetes中使用drop_fields删除字段失效问题咨询

第一次配置启动报错原因 #

你写的when条件结构不完整，contains是条件类型，必须补充待匹配的字段和对应值，仅写contains关键词会被识别为无效条件，直接触发初始化报错。

去掉条件后字段仍存在的常见原因 #

• 处理器执行顺序错误：drop_fields如果配置在add_host_metadata等会生成host.os相关字段的处理器之前，会出现先删除、后又被重新新增的情况
• 处理器作用范围不匹配：如果把drop_fields配置在单个input内部，只会对该input采集的日志生效，不会作用于全局采集任务
• 配置未生效：K8s部署场景下，ConfigMap更新后未重启Filebeat Pod，或者挂载配置错误，Pod内实际运行的还是旧配置
• 字段后续被补充：Elasticsearch侧配置的ingest pipeline、Logstash过滤规则等后续链路又重新写入了被删除的字段

正确配置示例 #

场景1：无条件删除所有采集日志的指定字段 #

保证drop_fields放在所有会生成待删字段的处理器之后：

processors:
  # 先执行生成host元数据的处理器
  - add_host_metadata: ~
  # 后执行删除操作
  - drop_fields:
      fields: ["host.os.name", "host.os.codename", "host.os.family"]
      ignore_missing: true # 开启后字段不存在时不会抛出异常，稳定性更高

场景2：带条件删除（仅符合规则的日志才删字段） #

完整的when条件需要指定匹配字段和值，示例（仅当日志的log.level字段包含debug时才删除目标字段）：

processors:
  - drop_fields:
      when:
        contains:
          log.level: "debug"
      fields: ["host.os.name", "host.os.codename", "host.os.family"]
      ignore_missing: true

配置后验证步骤 #

1. 进入Pod确认配置已更新：kubectl exec -it <filebeat-pod-name> -- cat /etc/filebeat/filebeat.yml
2. 查看Filebeat运行日志无报错：kubectl logs <filebeat-pod-name>
3. 输出日志到本地排查字段是否删除成功，可临时添加console输出配置验证：

output.console:
  pretty: true

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