Fluentd 不能原生解析 XML 日志，因其核心不内置 XML 解析能力，需依赖社区插件 fluent-plugin-xml 的 filter_xml 实现稳定解析，并注意编码、命名空间、XPath 表达式及 schema 变更等关键问题。

Fluentd 能否原生解析 XML 日志

不能。Fluentd 核心不内置 XML 解析能力，parser 插件默认支持的格式只有 json、regexp、csv、ltsv 等，xml 不在其中。强行用 regexp 提取字段既脆弱又难维护，尤其当嵌套层级变化或属性/文本混用时极易出错。

推荐方案：用 filter_xml 插件（需手动安装）

社区维护的 fluent-plugin-xml 提供 filter_xml，是目前最稳定、可配置性强的 XML 解析方式。它基于 Nokogiri，支持 XPath、属性提取、扁平化嵌套等。

• 安装命令：

  fluent-gem install fluent-plugin-xml

• 关键配置项：
  • root_xpath：指定顶层节点路径（如 /log/event），避免解析整个文档树
  • strip_namespaces：设为 true 可忽略命名空间，省去 XPath 写 ns:tag 的麻烦
  • flatten：设为 true 将嵌套结构转为点号分隔键（如 user.name → user_name）
• 示例配置片段：

  <filter>
    @type xml
    root_xpath /event
    strip_namespaces true
    flatten true
    xpath_keys user/name,user/email,level,message,timestamp
  </filter>

常见坑：XML 字符编码与特殊字符处理

如果日志含中文、UTF-8 BOM 或未转义的 /&，Nokogiri 会直接报错 REXML::ParseException 或静默丢弃整条记录。这不是配置问题，而是输入不合法。

• 前置清洗建议：在 filter_xml 前加一层 record_transformer，用 Ruby 表达式预处理 record["message"]
• 典型修复逻辑：

  record["message"] = record["message"].force_encoding("UTF-8").encode("UTF-8", invalid: :replace, undef: :replace, replace: "")

• 若日志来自 Java 应用，检查是否启用了 escapeXml="true"（Log4j2）或等效设置；否则需在 Fluentd 端做 HTML 实体解码（用 fluent-plugin-record-modifier + ruby 脚本）

转发前验证 XML 解析结果是否符合预期

XML 解析后字段名可能和直觉不符——比如 fail 中，level 是属性，msg 是子元素文本，二者提取方式不同，且默认不会合并到同一层级。

• 用 @type stdout 暂时替换目标输出，观察实际生成的字段键名
• 注意属性需显式声明：XPath 写 @level 才能提取属性值；写 level 只匹配同名子节点
• 嵌套结构如 ab，filter_xml 默认只取第一个 item，需配合 split 插件或自定义 Ruby 过滤器展开数组

真正麻烦的不是解析本身，而是 XML 日志缺乏 schema 约束——同一字段今天是属性，明天变成子节点，这类变动必须同步更新 XPath 和字段映射，否则转发数据就断层了。