WildFly 20 JSON日志格式化器key-overrides配置不生效

核心根因 #

WildFly 20版本内置的JSON日志格式化器存在属性刷新机制缺陷：

• 初始化阶段（即通过add命令创建格式化器实例时）传入的key-overrides配置会被正常加载到运行时实例中，你第一次配置后看到的@source、@source_host字段，就是初始化时加载的重写规则生效的结果；
• 实例创建完成后，meta-data属性因为实现逻辑支持运行时动态读取，修改后可立刻生效；但key-overrides属性仅在实例初始化时被一次性拷贝到内部不可变字段，后续动态修改只会将值持久化到服务模型（也就是通过read-attribute能读到配置值），不会触发已被日志处理器引用的格式化器实例刷新，因此修改的配置不会实际应用到日志输出中。

分步排查与解决操作 #

• 第一步：修正key-overrides的CLI写入语法
  WildFly CLI解析key-overrides这类Map类型属性时，列表格式的写法无法被正确解析为键值对映射，必须使用大括号包裹的键值对格式写入。正确的写入命令示例：

  /subsystem=logging/json-formatter=LOG-STASH:write-attribute(name="key-overrides", value={
    level=severity,
    timestamp=@timestamp,
    message=@message,
    logger-name=@source,
    host-name=@source_host
  })
  

• 第二步：触发日志处理器重新加载格式化器实例
  修改完key-overrides属性后，手动移除并重新关联socket handler，强制其重新拉取最新的JSON格式化器实例：

  # 移除原有socket handler
  /subsystem=logging/socket-handler=LOGSTASH-SOCKET:remove
  # 重新添加socket handler，自动关联最新的格式化器配置
  /subsystem=logging/socket-handler=LOGSTASH-SOCKET:add(named-formatter=LOG-STASH, outbound-socket-binding-ref=log-stash, level=DEBUG)
  

  关联的异步handler不需要额外操作，会自动识别子handler的初始化变更。
• 第三步：校验基础网络连通性，避免干扰判断
  确认 outbound socket binding配置的地址和端口，与实际Logstash监听的TCP端口（本案例中为5300）匹配，避免因网络不通导致日志发送失败、误以为配置不生效的问题。
• 生效验证标准
  操作完成后不需要重启整个WildFly服务，产生新的日志事件时，在Logstash的stdout输出中检查字段名：例如配置了level=severity重写规则后，原输出中的"level" => "DEBUG"字段应替换为"severity" => "DEBUG"，即代表规则正常生效。

版本注意事项 #

WildFly 20的JSON格式化器未为key-overrides属性注册运行时变更监听器，该缺陷在WildFly 21及后续版本才被修复，升级到更高版本后，动态修改key-overrides属性可自动触发配置刷新，无需手动重启handler。

内容的提问来源于stack exchange，提问作者Andreas.Krueger