> For the complete documentation index, see [llms.txt](https://docs.bindplane.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bindplane.com/integrations/processors/parse-xml.md).

# Parse XML

Parses an XML document string from a field you choose and writes it back as a structured map of tags, attributes, and content. Use it when telemetry carries a serialized XML document (an audit log, a Windows event, an application payload) that you want to turn into addressable fields for querying and filtering.

### Supported Telemetry Types

| Logs | Metrics | Traces |
| ---- | ------- | ------ |
| ✓    | ✓       | ✓      |

Choose Telemetry Type picks one signal per processor instance. Add another instance to handle a second signal.

### Configuration

#### Basic Configuration

<figure><img src="/files/JscwUL02KhaQSCiue6tC" alt="Bindplane docs - Parse XML - image 1"><figcaption></figcaption></figure>

**When to apply**

| Parameter             | Type               | Required | Default   | Description                                                                 |
| --------------------- | ------------------ | -------- | --------- | --------------------------------------------------------------------------- |
| Choose Telemetry Type | Telemetry Selector | Yes      | Logs      | The signal this instance runs on: Logs, Metrics, or Traces (one at a time). |
| Condition             | OTTL Condition     | No       | *(empty)* | Parse only the records that match. Empty runs on every record.              |

**Source and target fields**

| Parameter         | Type                                    | Required | Default   | Description                                                                                                                                       |
| ----------------- | --------------------------------------- | -------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Source Field Type | Enum: Resource, Attribute, Body, Custom | Yes      | Attribute | Where the XML string is read from. **Body is logs-only.** Custom gives access to the full record (any OTTL path).                                 |
| Source Field      | OTTL Field                              | Yes \*   | —         | The field holding the XML. Use bracket notation for nested fields (e.g. `parent["child"]`). For a Body source, leave empty to use the whole body. |
| Target Field Type | Enum: Resource, Attribute, Body, Custom | Yes      | Attribute | Where the parsed map is written. **Body is logs-only.**                                                                                           |
| Target Field      | OTTL Field                              | Yes \*   | —         | Destination for the parsed map. Leave empty to merge the parsed XML into the chosen context (resource, attributes, or body).                      |

\* The **Body** field type is the exception: it's optional, and leaving it empty targets the entire body.

**Body is available for Logs only.** For Metrics and Traces, the Source and Target Field Type options are Resource, Attribute, and Custom.

### How parsed XML is structured

The processor converts each XML element into a map with these fields:

1. The element's character data is trimmed and placed in a `content` field.
2. The element's tag name is trimmed and placed in a `tag` field.
3. The element's attributes are placed as a mapping of attribute name to attribute value in an `attributes` field.
4. Processing instructions, directives, and comments are ignored and not represented in the parsed output.
5. Child XML elements are parsed the same way and placed in an array in a `children` field.

For example, this XML:

```xml
<?xml version="1.0" encoding="UTF-8" ?>
<Log>
  <User>
    <ID>00001</ID>
    <Name type="first">Joe</Name>
    <Email>joe.smith@example.com</Email>
  </User>
  <Text>User fired alert A</Text>
</Log>
```

parses to:

```json
{
  "tag": "Log",
  "children": [
    {
      "tag": "User",
      "children": [
        { "tag": "ID", "content": "00001" },
        { "tag": "Name", "content": "Joe", "attributes": { "type": "first" } },
        { "tag": "Email", "content": "joe.smith@example.com" }
      ]
    },
    { "tag": "Text", "content": "User fired alert A" }
  ]
}
```

### Examples

#### Parse an XML audit log from the body into an attribute

Suppose a log carries a serialized XML audit record in its body and you want it as structured fields under the `parsed_xml` attribute.

Sample input log record:

```json
{
  "body": "<Log><User><ID>00001</ID><Name><First>Joe</First></Name></User><Text>User did a thing</Text></Log>"
}
```

Configure the processor as:

* Choose Telemetry Type: `Logs`
* Condition: leave empty (parse every record)
* Source Field Type: `Body`
* Source Field: leave empty (use the whole body)
* Target Field Type: `Attribute`
* Target Field: `parsed_xml`

After parsing, the record looks like:

```json
{
  "body": "<Log><User><ID>00001</ID><Name><First>Joe</First></Name></User><Text>User did a thing</Text></Log>",
  "attributes": {
    "parsed_xml": {
      "tag": "Log",
      "children": [
        {
          "tag": "User",
          "children": [
            { "tag": "ID", "content": "00001" },
            { "tag": "Name", "children": [ { "tag": "First", "content": "Joe" } ] }
          ]
        },
        { "tag": "Text", "content": "User did a thing" }
      ]
    }
  }
}
```

### Configuration Tips

* It's common for XML to span multiple lines. When reading XML logs from a file, configure the multiline section of the File source so the collector reads the whole XML document as a single entry before this processor runs.
* Leaving the Target Field empty merges the parsed map into the selected context (resource, attributes, or body) rather than nesting it under a named field.
* Set a Condition to skip records that don't carry XML, for example to avoid re-parsing records the processor has already turned into a map.

### Troubleshooting

#### The target field is empty or unchanged

Symptoms: nothing structured is written to the target after the processor runs.

Solutions:

1. Confirm the Source Field actually holds a valid XML string and the Condition evaluates true.
2. For a Body source, verify the field path, or leave Source Field empty to parse the entire body.

#### Multi-line XML is truncated

Symptoms: only the first line of an XML document is parsed, or parsing fails.

Solutions:

1. Configure the multiline section of the File source so each XML document is read as one entry.
2. Verify the source field contains the complete document, not a fragment.

### Standalone Processor

```yaml
apiVersion: bindplane.observiq.com/v1
kind: Processor
metadata:
  name: parse-xml
spec:
  type: parse_xml
  parameters:
    - name: telemetry_types
      value: Logs
    - name: log_condition
      value: ""
    - name: log_source_field_type
      value: Body
    - name: log_body_source_field
      value: ""
    - name: log_target_field_type
      value: Attribute
    - name: log_attribute_target_field
      value: parsed_xml
```

### Related Resources

* [ParseXML — OTTL function reference](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/ottlfuncs/README.md#parsexml)

### Bindplane Resources

These XML processors are designed to work together. Chain them to extract, parse, normalize, and reshape XML end to end:

* [Get XML](/integrations/processors/get-xml.md)
* [Parse Simplified XML](/integrations/processors/parse-simplified-xml.md)
* [Remove XML](/integrations/processors/remove-xml.md)
* [Convert XML Attributes To Elements](/integrations/processors/convert-xml-attributes-to-elements.md)
* [Convert XML Text To Elements](/integrations/processors/convert-xml-text-to-elements.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bindplane.com/integrations/processors/parse-xml.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.