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 或未转义的 /<code>&，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 解析后字段名可能和直觉不符——比如 <event level="ERROR"><msg>fail</msg></event> 中，level 是属性，msg 是子元素文本，二者提取方式不同，且默认不会合并到同一层级。
- 用
@type stdout暂时替换目标输出，观察实际生成的字段键名 - 注意属性需显式声明：XPath 写
@level才能提取属性值；写level只匹配同名子节点 - 嵌套结构如
<data><item id="1">a</item><item id="2">b</item></data>，filter_xml默认只取第一个item，需配合split插件或自定义 Ruby 过滤器展开数组
真正麻烦的不是解析本身，而是 XML 日志缺乏 schema 约束——同一字段今天是属性，明天变成子节点，这类变动必须同步更新 XPath 和字段映射，否则转发数据就断层了。
