XML filter 必须配合 codec=>"xml" 或 xml 输入插件使用，仅用于解析已结构化字段中的 XML；必须显式设置 target 避免根层级污染；需处理命名空间与数据类型转换。
XML filter 插件必须配合 codec => "xml" 或 xml 输入插件使用
Logstash 的 xml filter 本身不解析原始文本，它只对已解析为 Logstash 事件字段的 XML 结构做提取操作。如果你把原始 XML 字符串直接塞进 message 字段，然后只用 filter { xml { ... } }，它会静默失败——没有报错，但也不会生成任何新字段。
正确路径只有两条：
- 用
file或http等输入插件 +codec => "xml"，让 Logstash 在输入阶段就解析 XML 成事件 - 或先用
dissect/grok提取 XML 片段到某个字段（如xml_content），再用xmlfilter 配合source => "xml_content"解析该字段
绝大多数人卡在这一步，以为 filter 能“从字符串变结构”，其实不能。
target 参数决定解析结果存放位置，不是可选项
如果不指定 target，xml filter 默认把解析结果写入 event 根层级，这会导致字段名冲突（比如 XML 里有 <id>123</id>，就会覆盖掉原本可能存在的 id 字段）。更危险的是，如果 XML 顶层是多个同名节点（如 <item>...</item><item>...</item>），默认行为会把它们合并成数组，但若没设 target，这个数组会直接怼进根事件，极易引发后续 filter 异常。
推荐始终显式设置 target：
filter {
xml {
source => "xml_content"
target => "parsed_xml"
store_xml => false
}
}
这样所有提取结果都收在 [parsed_xml] 下，干净可控。若需扁平化字段，再用 mutate { rename => { "[parsed_xml][id]" => "id" } } 显式搬移。
嵌套 XML 节点和属性要用 xpath 或 strip_namespaces 处理
XML 带命名空间（如 <entry xmlns:ns="http://example.com"></entry>）时，直接写 field => { "entry" => "entry" } 会匹配失败。Logstash 的 xml filter 默认不剥离命名空间，XPath 表达式必须带前缀，或者开启 strip_namespaces => true。
常见做法：
- 加
strip_namespaces => true最省事，适合你完全不关心命名空间的场景 - 用
xpath参数写精确路径，例如xpath => ["/root/item/title/text()", "title"]，注意末尾/text()才能取值而非节点对象 - 若 XML 有混合内容（文本+子节点），
store_xml => true会保留原始 XML 字符串在target下，但通常没必要
不处理命名空间是线上解析为空的最常见原因。
force_array 和 convert_type 控制字段类型，否则全是字符串
XML 解析出来的所有值默认都是字符串，哪怕 <count>42</count> 也会变成 "42"。下游做数值聚合或比较时会出问题。用 convert_type 可以转类型：
filter {
xml {
source => "xml_content"
target => "parsed"
convert_type => {
"count" => "integer"
"price" => "float"
"active" => "boolean"
}
}
}
另外，单个节点和多个同名节点行为不一致：<tag>a</tag> 解析为字符串，<tag>a</tag><tag>b</tag> 解析为数组。如果业务上总是期望数组（比如统一用 foreach 处理），就设 force_array => ["tag", "item"]。
别依赖默认行为——XML 结构稍有变化，字段类型就可能从 string 变 array，后续 filter 很容易抛 Cannot concatenate string and array 这类错误。
xml filter 看似简单，实际要稳住输出，关键在三处：输入阶段是否真解析了、target 是否隔离了作用域、命名空间和数据类型是否显式处理。漏掉任意一个，都可能让日志在管道里“消失”或“变形”。 
