- Fleet and Elastic Agent Guide: other versions:
- Fleet and Elastic Agent overview
- Beats and Elastic Agent capabilities
- Quick starts
- Migrate from Beats to Elastic Agent
- Deployment models
- Install Elastic Agents
- Install Fleet-managed Elastic Agents
- Install standalone Elastic Agents
- Install Elastic Agents in a containerized environment
- Run Elastic Agent in a container
- Run Elastic Agent on Kubernetes managed by Fleet
- Advanced Elastic Agent configuration managed by Fleet
- Configuring Kubernetes metadata enrichment on Elastic Agent
- Run Elastic Agent on GKE managed by Fleet
- Run Elastic Agent on Amazon EKS managed by Fleet
- Run Elastic Agent on Azure AKS managed by Fleet
- Run Elastic Agent Standalone on Kubernetes
- Scaling Elastic Agent on Kubernetes
- Using a custom ingest pipeline with the Kubernetes Integration
- Environment variables
- Install Elastic Agent from an MSI package
- Installation layout
- Air-gapped environments
- Using a proxy server with Elastic Agent and Fleet
- Uninstall Elastic Agents from edge hosts
- Start and stop Elastic Agents on edge hosts
- Elastic Agent configuration encryption
- Secure connections
- Manage Elastic Agents in Fleet
- Configure standalone Elastic Agents
- Create a standalone Elastic Agent policy
- Structure of a config file
- Inputs
- Providers
- Outputs
- SSL/TLS
- Logging
- Feature flags
- Agent download
- Config file examples
- Grant standalone Elastic Agents access to Elasticsearch
- Example: Use standalone Elastic Agent with Elastic Cloud Serverless to monitor nginx
- Example: Use standalone Elastic Agent with Elasticsearch Service to monitor nginx
- Debug standalone Elastic Agents
- Kubernetes autodiscovery with Elastic Agent
- Monitoring
- Reference YAML
- Manage integrations
- Define processors
- Processor syntax
- add_cloud_metadata
- add_cloudfoundry_metadata
- add_docker_metadata
- add_fields
- add_host_metadata
- add_id
- add_kubernetes_metadata
- add_labels
- add_locale
- add_network_direction
- add_nomad_metadata
- add_observer_metadata
- add_process_metadata
- add_tags
- community_id
- convert
- copy_fields
- decode_base64_field
- decode_cef
- decode_csv_fields
- decode_duration
- decode_json_fields
- decode_xml
- decode_xml_wineventlog
- decompress_gzip_field
- detect_mime_type
- dissect
- dns
- drop_event
- drop_fields
- extract_array
- fingerprint
- include_fields
- move_fields
- parse_aws_vpc_flow_log
- rate_limit
- registered_domain
- rename
- replace
- script
- syslog
- timestamp
- translate_sid
- truncate_fields
- urldecode
- Command reference
- Troubleshoot
- Release notes
Decode XML
editDecode XML
editThe decode_xml
processor decodes XML data that is stored under the field
key. It outputs the result into the target_field
.
Examples
editThis example demonstrates how to decode an XML string contained in the message
field and write the resulting fields into the root of the document. Any fields
that already exist are overwritten.
- decode_xml: field: message target_field: "" overwrite_keys: true
By default any decoding errors that occur will stop the processing chain, and
the error will be added to the error.message
field. To ignore all errors and
continue to the next processor, set ignore_failure: true
. To specifically
ignore failures caused by field
not existing, set ignore_missing: true
.
- decode_xml: field: example target_field: xml ignore_missing: true ignore_failure: true
By default the names of all keys converted from XML are converted to lowercase.
To disable this behavior, set to_lower: false
, for example:
- decode_xml: field: message target_field: xml to_lower: false
Example XML input:
<catalog> <book seq="1"> <author>William H. Gaddis</author> <title>The Recognitions</title> <review>One of the great seminal American novels of the 20th century.</review> </book> </catalog>
Will produce the following output:
{ "xml": { "catalog": { "book": { "author": "William H. Gaddis", "review": "One of the great seminal American novels of the 20th century.", "seq": "1", "title": "The Recognitions" } } } }
Configuration settings
editElastic Agent processors execute before ingest pipelines, which means that your processor configurations cannot refer to fields that are created by ingest pipelines or Logstash. For more limitations, refer to What are some limitations of using processors?
Name | Required | Default | Description |
---|---|---|---|
|
Yes |
|
Source field containing the XML. |
|
No |
The field under which the decoded XML will be written. By default the decoded XML object replaces the field from which it was read. To merge the decoded XML fields into the root of the event, specify |
|
|
No |
|
Whether keys that already exist in the event are overwritten by keys from the decoded XML object. |
|
No |
|
Whether to convert all keys to lowercase. |
|
No |
XML key to use as the document ID. If configured, the field will be removed from the original XML document and stored in |
|
|
No |
|
Whether to return an error if a specified field does not exist. |
|
No |
|
Whether to ignore all errors produced by the processor. |
See Conditions for a list of supported conditions.
On this page