For the complete documentation index, see llms.txt. This page is also available as Markdown.

Dynatrace Enrichment

The Dynatrace Enrichment processor sets the Dynatrace primary fields (security context, cost center, product) and primary Grail tags on telemetry bound for Dynatrace. Each value is a literal string or an ordered list of source fields, and every enrichment is written as a resource attribute so it lands on the Dynatrace side as a primary field or tag.

Use it ahead of a Dynatrace destination. Bindplane recommends it automatically on every Dynatrace destination in a configuration.

Supported Telemetry Types

Logs
Metrics
Traces

✓

✓

✓

The processor runs on the signals you select in Choose Telemetry Type. One set of enrichments applies to every selected signal; there are no per-signal sections.

Configuration

Basic Configuration

You pick which Dynatrace fields to set and, for each one, where its value comes from. A field you leave empty is never added to the data.

Parameter
Type
Required
Default
Description

Choose Telemetry Type

Telemetry Selector

No

Logs, Metrics, Traces

The signals this processor applies to. The same enrichments are applied to every selected signal.

Condition

OTTL Condition

No

(empty)

An OTTL condition that must be true for the processor to run. Empty applies it to every record of the selected signals.

Security Context

Source rows

No

(empty)

Sets dt.security_context, which controls who can access the data in Dynatrace. A literal value or an ordered list of source fields (see Source Entries).

Cost Center

Source rows

No

(empty)

Sets dt.cost.costcenter for Dynatrace cost allocation. A literal value or an ordered list of source fields.

Product

Source rows

No

(empty)

Sets dt.cost.product for Dynatrace cost allocation. A literal value or an ordered list of source fields.

Primary Tags

Tag rows

No

(empty)

Customer-defined organizational tags such as team, app, stage, or env. Each row has a plain key and its own source rows; the processor writes it as primary_tags.<key>. Keys must be unique within the processor.

Every enrichment is written as a resource attribute: resource.attributes["dt.security_context"], resource.attributes["dt.cost.costcenter"], resource.attributes["dt.cost.product"], and resource.attributes["primary_tags.<key>"].

Source Entries

Each value (a primary field or a tag) is an ordered list of source rows. A row is one of two kinds:

Entry type
Fields
Behavior

Field

Context (attributes / resource) + Key

Copies the field's value. The source field is kept. If the field is absent on a record, the row is skipped for that record.

Literal

Value

A fixed string. Leading and trailing whitespace is trimmed. Always present, so it works as the fallback when placed last.

Rows are evaluated in order and the first source present on a record wins. If no row resolves on a record, the enrichment is not set on that record: the field is never written as an empty string or null.

The primary_tags. prefix is applied by the processor. Type the plain key (env, not primary_tags.env). Tag keys may contain letters, digits, and _ . : / -.

Examples

Security context from the Kubernetes namespace, with a fallback

Multi-tenant clusters usually key access on the namespace. Listing resource / k8s.namespace.name first and a literal shared last sets dt.security_context to the namespace on Kubernetes telemetry and to shared on everything else, so no record leaves the pipeline without a security context. Cost Center is a fixed literal, and the env tag is copied from whichever cloud tag the record carries.

Coalesce an environment tag from several cloud providers

The same env tag may arrive as aws.tags.env on EC2 hosts and azure.tags.env on Azure VMs. Listing both as field rows writes primary_tags.env from whichever one the record carries, and skips the tag on records that carry neither.

Configuration Tips

Order is priority

  • Rows are evaluated top to bottom and the first source present wins. Put the most authoritative source first and a literal last if you want a guaranteed value.

  • A value that is entirely field rows is skipped on records where none of the fields exist. Add a literal row when the field must always be set.

Security context is an access boundary

  • dt.security_context decides who can see the data in Dynatrace. A typo, or a value that happens to match a broader policy, puts records in the wrong access boundary. Prefer a literal, or a source field whose values you control; avoid fields that carry arbitrary user-supplied text.

  • Leaving Security Context empty leaves dt.security_context unset on the record; Dynatrace then treats the record as data with no security context.

Cost center and product

  • Cost Center and Product accept any text. Values registered later in Dynatrace cost allocation still match as long as they are spelled the same.

Troubleshooting

A field or tag is missing in Dynatrace

Symptoms: Records arrive in Dynatrace but dt.security_context, dt.cost.*, or a primary_tags.* tag is absent on some or all of them.

Solutions:

  1. Confirm at least one source row resolves on those records: right context (attributes vs resource) and the exact key. Use a snapshot to check which fields the record actually carries at the processor's position in the pipeline.

  2. Add a literal row at the end of the list if the value must be set on every record.

  3. If a Condition is set, confirm it evaluates true for the records you expect to enrich.

  4. Confirm the processor is on the pipeline that feeds the Dynatrace destination, and that the selected telemetry types include the signal you are looking at.

The value is wrong or in the wrong access boundary

Symptoms: Records land with an unexpected dt.security_context or cost center.

Solutions:

  1. Check row order. An earlier field row that resolves wins over a later literal.

  2. Check for whitespace differences in Dynatrace policy names; literal values are trimmed, values copied from fields are not.

  3. If a source field is populated by upstream processors, confirm the enrichment processor runs after them.

Save fails with a duplicate or invalid tag key

Symptoms: The processor cannot be saved and a tag key is highlighted.

Solutions:

  1. Tag keys must be unique within one processor. Merge the two rows, adding the extra sources to the surviving row.

  2. Keys may contain only letters, digits, and _ . : / -. Remove spaces and quotes, and do not include the primary_tags. prefix.

Standalone Processor

Recommendations

When a configuration has a Dynatrace destination, Bindplane recommends:

  • Enrich for Dynatrace on the destination: this processor, with no fields pre-filled.

  • Detect Resources for Dynatrace on each source that is not a Dynatrace ActiveGate or Bindplane Gateway source: the Resource Detection processor with the system detector, so host telemetry carries the resource attributes Dynatrace uses for entity mapping.

Last updated

Was this helpful?